Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Tue, 28 Nov 2017, SF Markus Elfring wrote: > >> It seems that I got no responses so far for clarification requests > >> according to the documentation in a direction I hoped for. > > > > That's because you are pretty unresponsive to direction. > > From which places did you get this impression? Perhaps from the text that you have written only four lines below. All comments are dismissed as "the usual mixture of disagreements and acceptance". If you look at the patches sent by others, who learn from the feedback provided to them, there are not so many responses on the disagreements side. So the mixture is not usual. Since you send lots of patches on the same issues, there should be no disagreements at all at this point. julia > > > You've gotten _many_ replies to your patches > > I got the usual mixture of disagreements and acceptance for > my selection of change possibilities. > Some constructive feedback was also provided which might need > further software development considerations. > Is the situation improvable here? > > > > to which you have seemingly decided to ignore. > > You might eventually notice that I react to special information > occasionally with a big delay. > > For which concrete details are you still waiting for a better > response from me? > > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Tue, 2017-11-28 at 08:41 +0100, SF Markus Elfring wrote: > > > It seems that I got no responses so far for clarification requests > > > according to the documentation in a direction I hoped for. > > > > That's because you are pretty unresponsive to direction. > > From which places did you get this impression? How many times have I told you to include the reason for your patches in your proposed commit message? Too often. For instance, specific to this patch: Many people do not know that a generic kmalloc does a dump_stack() on OOM. That information should be part of the commit message. Also removing the printk code reduces overall code size. The actual size reduction should be described in the commit message too. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Mon, Nov 27, 2017 at 06:27:08PM +0100, SF Markus Elfring wrote: > >> Omit an extra message for a memory allocation failure in these functions. > … > > nak, unlike many others, these message give extra info on which > > allocation failed, that can be useful. > > Can a default allocation failure report provide the information > which you might expect so far? You should be able to answer that question yourself. And if you are unable to do so, just do not sent changes pointed by any code analysis tools. As a side note, if you look at whole call chain, you'll find quite some room for optimizations - look how dev and pdev are used. That also applies to other patches. Best regards, ladis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/17] drm/sun4i: Wire in DE2 scaler support
Calculate scaling parameters and call appropriate scaler set up
function.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 12 +++-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 115 +---
drivers/gpu/drm/sun4i/sun8i_mixer.h | 4 --
3 files changed, 90 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index e1b6ad82145e..6860271e5415 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -25,8 +25,11 @@
static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
struct drm_crtc *crtc = state->crtc;
struct drm_crtc_state *crtc_state;
+ int min_scale, max_scale;
+ bool scaler_supported;
struct drm_rect clip;
if (!crtc)
@@ -41,9 +44,14 @@ static int sun8i_mixer_layer_atomic_check(struct drm_plane
*plane,
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
+ scaler_supported = !!(layer->mixer->cfg->scaler_mask & BIT(layer->id));
+
+ min_scale = scaler_supported ? 1 : DRM_PLANE_HELPER_NO_SCALING;
+ max_scale = scaler_supported ? (1UL << 20) - 1 :
+ DRM_PLANE_HELPER_NO_SCALING;
+
return drm_plane_helper_check_state(state, &clip,
- DRM_PLANE_HELPER_NO_SCALING,
- DRM_PLANE_HELPER_NO_SCALING,
+ min_scale, max_scale,
true, true);
}
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 291dd8806444..7c9c87a0535b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -28,6 +28,7 @@
#include "sun8i_mixer.h"
#include "sun8i_layer.h"
#include "sunxi_engine.h"
+#include "sun8i_scaler.h"
struct de2_fmt_info {
u32 drm_fmt;
@@ -194,29 +195,34 @@ int sun8i_mixer_update_ui_layer_coord(struct sun8i_mixer
*mixer,
int layer, struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
- u32 width, height, size;
+ u32 src_w, src_h, dst_w, dst_h;
+ u32 outsize, insize;
+ u32 hphase, vphase;
- DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
+ DRM_DEBUG_DRIVER("Updating UI layer %d\n", layer);
- /*
-* Same source and destination width and height are guaranteed
-* by atomic check function.
-*/
- width = drm_rect_width(&state->dst);
- height = drm_rect_height(&state->dst);
- size = SUN8I_MIXER_SIZE(width, height);
+ src_w = drm_rect_width(&state->src) >> 16;
+ src_h = drm_rect_height(&state->src) >> 16;
+ dst_w = drm_rect_width(&state->dst);
+ dst_h = drm_rect_height(&state->dst);
+
+ hphase = state->src.x1 & 0x;
+ vphase = state->src.y1 & 0x;
+
+ insize = SUN8I_MIXER_SIZE(src_w, src_h);
+ outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
bool interlaced = false;
u32 val;
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
-width, height);
+dst_w, dst_h);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_GLOBAL_SIZE,
-size);
+outsize);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
-size);
+outsize);
if (state->crtc)
interlaced = state->crtc->state->adjusted_mode.flags
@@ -237,23 +243,40 @@ int sun8i_mixer_update_ui_layer_coord(struct sun8i_mixer
*mixer,
}
/* Set height and width */
- DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n", width, height);
+ DRM_DEBUG_DRIVER("Layer source offset X: %d Y: %d\n",
+state->src.x1 >> 16, state->src.y1 >> 16);
+ DRM_DEBUG_DRIVER("Layer source size W: %d H: %d\n", src_w, src_h);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_LAYER_SIZE(layer, 0),
-size);
+SUN8I_MIXER_CHAN_UI_LAYER_SIZE(layer, 0), insize);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_OVL_SIZE(layer),
-size);
+SUN8I_MIXER_CHAN_UI_OVL_SIZE(layer), insize);
+
+ if (insize != outsize || hphase || vphase) {
+ u32 hscale, vscale;
+
+ DRM_DEBUG_DRIVER("HW scaling is enabled\n");
[PATCH 02/17] drm/sun4i: Start using layer id in DE2 driver
Till now, plane selection was hardcoded to first overlay in first UI
channel.
It turns out that overlays don't fit well in current DRM design, because
they can't be blended together or scaled independetly when they are set
to same channel.
Beause of that, always use only first overlay in each channel. This
simplifies things, since layer parameter can be then used as channel
selection.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 31 +++
2 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 23810ff72684..5b2d45a9db8a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -126,7 +126,7 @@ struct drm_plane **sun8i_layers_init(struct drm_device *drm,
return ERR_CAST(layer);
};
- layer->id = i;
+ layer->id = mixer->cfg->vi_num + i;
planes[i] = &layer->plane;
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 015943c0ed5a..37eb5f6f8ee8 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -41,11 +41,8 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
int layer, bool enable)
{
u32 val;
- /* Currently the first UI channel is used */
- int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("%sabling layer %d in channel %d\n",
-enable ? "En" : "Dis", layer, chan);
+ DRM_DEBUG_DRIVER("%sabling layer %d\n", enable ? "En" : "Dis", layer);
if (enable)
val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
@@ -53,17 +50,17 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
val = 0;
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(layer, 0),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
if (enable)
- val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan);
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(layer);
else
val = 0;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL,
- SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan), val);
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(layer), val);
}
static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
@@ -94,8 +91,6 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
{
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
- /* Currently the first UI channel is used */
- int chan = mixer->cfg->vi_num;
DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
@@ -107,7 +102,7 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
state->crtc_h));
DRM_DEBUG_DRIVER("Updating blender size\n");
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(chan),
+SUN8I_MIXER_BLEND_ATTR_INSIZE(layer),
SUN8I_MIXER_SIZE(state->crtc_w,
state->crtc_h));
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
@@ -115,7 +110,7 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
state->crtc_h));
DRM_DEBUG_DRIVER("Updating channel size\n");
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_OVL_SIZE(chan),
+SUN8I_MIXER_CHAN_UI_OVL_SIZE(layer),
SUN8I_MIXER_SIZE(state->crtc_w,
state->crtc_h));
}
@@ -123,21 +118,21 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
/* Set the line width */
DRM_DEBUG_DRIVER("Layer line width: %d bytes\n", fb->pitches[0]);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_LAYER_PITCH(chan, layer),
+SUN8I_MIXER_CHAN_UI_LAYER_PITCH(layer, 0),
fb->pitches[0]);
/* Set height and width */
DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n",
state->crtc_w, state->crtc_h);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_LAYER_SIZE(chan, layer),
+SUN8I_MIXER_CHAN_UI_LAYER_SIZE(layer, 0),
SUN8I_MIXER_SIZE(state->crtc_w, state->crtc_h));
/* Set base coordinates */
DRM_DEBUG_DRIVER("Laye
[PATCH 05/17] drm/sun4i: Reorder some code in DE2
While DE2 driver works, parts of the code are not in optimal place. Reorder
it so it will be easier to support multiple planes.
This commit doesn't do any functional change besides removing two not
very useful debug messages.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 60 -
1 file changed, 32 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 6aa3240186c1..c1b7685603fe 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -90,7 +90,6 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
int layer, struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
- struct drm_framebuffer *fb = state->fb;
u32 width, height, size;
DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
@@ -104,34 +103,43 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
size = SUN8I_MIXER_SIZE(width, height);
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
+ bool interlaced = false;
+ u32 val;
+
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
width, height);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_GLOBAL_SIZE,
size);
- DRM_DEBUG_DRIVER("Updating blender size\n");
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(layer),
-size);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
size);
- DRM_DEBUG_DRIVER("Updating channel size\n");
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_OVL_SIZE(layer),
-size);
- }
- /* Set the line width */
- DRM_DEBUG_DRIVER("Layer line width: %d bytes\n", fb->pitches[0]);
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_LAYER_PITCH(layer, 0),
-fb->pitches[0]);
+ if (state->crtc)
+ interlaced = state->crtc->state->adjusted_mode.flags
+ & DRM_MODE_FLAG_INTERLACE;
+
+ if (interlaced)
+ val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_OUTCTL,
+ SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
+ val);
+
+ DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
+interlaced ? "on" : "off");
+ }
/* Set height and width */
DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n", width, height);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_LAYER_SIZE(layer, 0),
size);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_CHAN_UI_OVL_SIZE(layer),
+size);
/* Set base coordinates */
DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n",
@@ -139,6 +147,9 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_COORD(layer),
SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_BLEND_ATTR_INSIZE(layer),
+size);
return 0;
}
@@ -148,22 +159,9 @@ int sun8i_mixer_update_layer_formats(struct sun8i_mixer
*mixer,
{
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
- bool interlaced = false;
u32 val;
int ret;
- if (plane->state->crtc)
- interlaced = plane->state->crtc->state->adjusted_mode.flags
- & DRM_MODE_FLAG_INTERLACE;
-
- regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTCTL,
- SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
- interlaced ?
- SUN8I_MIXER_BLEND_OUTCTL_INTERLACED : 0);
-
- DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
-interlaced ? "on" : "off");
-
ret = sun8i_mixer_drm_format_to_layer(plane, fb->format->format,
&val);
if (ret) {
@@ -201,6 +199,12 @@ int sun8i_mixer_update_layer_buffer(struct sun8i_mixer
*mixer,
paddr += (state->src.x1 >> 16) * bpp;
paddr += (state->src.y1 >> 16) * fb->pitches[0];
+
Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
+dri-devel@lists.freedesktop.org
On 11/27/2017 11:57 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Extract the domain number from drm_device and pass it into
> pci_get_domain_bus_and_slot() function.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9f45cfe..5a8cb79 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
>
> static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
> {
> - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> + int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
> +
> + dev_priv->bridge_dev =
> + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
> if (!dev_priv->bridge_dev) {
> DRM_ERROR("bridge device not found\n");
> return -1;
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/17] drm/sun4i: Add constraints checking to DE2 driver
Since current DE2 driver doesn't know how to scale yet, add atomic check
function which checks that.
Nice side effect of that function is that populates clipped coordinates
and checks visibility of the plane. That data will be used in the
future.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 5b2d45a9db8a..54739e12311d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -13,7 +13,9 @@
* the License, or (at your option) any later version.
*/
+#include
#include
+#include
#include
#include
@@ -26,6 +28,31 @@ struct sun8i_plane_desc {
uint32_tnformats;
};
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_rect clip;
+
+ if (!crtc)
+ return 0;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+ return drm_plane_helper_check_state(state, &clip,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ true, true);
+}
+
static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
struct drm_plane_state
*old_state)
{
@@ -48,6 +75,7 @@ static void sun8i_mixer_layer_atomic_update(struct drm_plane
*plane,
}
static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
+ .atomic_check = sun8i_mixer_layer_atomic_check,
.atomic_disable = sun8i_mixer_layer_atomic_disable,
.atomic_update = sun8i_mixer_layer_atomic_update,
};
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/17] drm/sun4i: Expand DE2 scaler lib with YUV support
Basic principle of operation when using YUV framebuffer is that chroma
planes have to be upscaled to same size as luma.
Because of that, expand DE2 scaler library to support that.
BSP driver uses another set of FIR filter coefficients for YUV planes.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 3 +-
drivers/gpu/drm/sun4i/sun8i_scaler.c | 458 ++-
drivers/gpu/drm/sun4i/sun8i_scaler.h | 3 +-
3 files changed, 451 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 00edfdc98499..6fb7dfd789f9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -424,6 +424,7 @@ int sun8i_mixer_update_vi_layer_coord(struct sun8i_mixer
*mixer,
int layer, struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
+ const struct drm_format_info *format = state->fb->format;
u32 src_w, src_h, dst_w, dst_h;
u32 outsize, insize;
u32 hphase, vphase;
@@ -459,7 +460,7 @@ int sun8i_mixer_update_vi_layer_coord(struct sun8i_mixer
*mixer,
vscale = state->src_h / state->crtc_h;
sun8i_scaler_vsu_setup(mixer, layer, src_w, src_h, dst_w, dst_h,
- hscale, vscale, hphase, vphase);
+ hscale, vscale, hphase, vphase, format);
sun8i_scaler_vsu_enable(mixer, layer, true);
} else {
DRM_DEBUG_DRIVER("HW scaling is not needed\n");
diff --git a/drivers/gpu/drm/sun4i/sun8i_scaler.c
b/drivers/gpu/drm/sun4i/sun8i_scaler.c
index 23525beceaa2..6e2168070229 100644
--- a/drivers/gpu/drm/sun4i/sun8i_scaler.c
+++ b/drivers/gpu/drm/sun4i/sun8i_scaler.c
@@ -498,6 +498,417 @@ static const u32 lan2coefftab32[480] = {
0x0e1d1401, 0x0f1d1301, 0x0f1d1301, 0x101e1200,
};
+static const u32 bicubic8coefftab32_left[480] = {
+ 0x4000, 0x40ff, 0x3ffe, 0x3efe,
+ 0x3dfd, 0x3cfc, 0x3bfc, 0x39fc,
+ 0x36fc, 0x35fb, 0x33fb, 0x31fb,
+ 0x2ffb, 0x2cfb, 0x29fc, 0x27fc,
+ 0x24fc, 0x21fc, 0x1efd, 0x1cfd,
+ 0x19fd, 0x16fe, 0x14fe, 0x11fe,
+ 0x0dff, 0x0cff, 0x0aff, 0x08ff,
+ 0x0500, 0x0300, 0x0200, 0x0100,
+
+ 0x3904ff00, 0x3903ff00, 0x3902ff00, 0x3801,
+ 0x3700, 0x36ff, 0x35ff, 0x34fe,
+ 0x32fe, 0x31fd, 0x30fd, 0x2efc,
+ 0x2cfc, 0x2afc, 0x28fc, 0x26fc,
+ 0x24fc, 0x22fc, 0x20fc, 0x1efc,
+ 0x1cfc, 0x19fc, 0x17fc, 0x15fd,
+ 0x12fd, 0x11fd, 0x0ffd, 0x0dfe,
+ 0x0bfe, 0x09fe, 0x08fe, 0x06ff,
+
+ 0x3209fe00, 0x3407fe00, 0x3306fe00, 0x3305fe00,
+ 0x3204fe00, 0x3102ff00, 0x3102ff00, 0x3001ff00,
+ 0x2f00ff00, 0x2e00, 0x2cff, 0x2bfe,
+ 0x29fe, 0x28fe, 0x26fd, 0x24fd,
+ 0x23fd, 0x21fd, 0x20fc, 0x1efc,
+ 0x1dfc, 0x1bfc, 0x19fc, 0x17fc,
+ 0x16fc, 0x14fc, 0x12fc, 0x10fd,
+ 0x0ffd, 0x0dfd, 0x0cfd, 0x0afd,
+
+ 0x2e0cfd00, 0x2e0bfd00, 0x2e09fd00, 0x2e08fd00,
+ 0x2e07fd00, 0x2c06fe00, 0x2c05fe00, 0x2b04fe00,
+ 0x2b03fe00, 0x2a02fe00, 0x2901fe00, 0x2701ff00,
+ 0x2700ff00, 0x2600, 0x2400, 0x2300,
+ 0x22feff00, 0x20fe, 0x1ffe, 0x1efd,
+ 0x1dfd, 0x1bfd, 0x1afd, 0x19fd,
+ 0x17fd, 0x15fd, 0x13fd, 0x12fd,
+ 0x11fd, 0x10fd, 0x0ffd, 0x0cfd,
+
+ 0x2a0efd00, 0x2a0dfd00, 0x2a0cfd00, 0x290bfd00,
+ 0x290afd00, 0x2909fd00, 0x2908fd00, 0x2807fd00,
+ 0x2706fd00, 0x2705fd00, 0x2604fe00, 0x2603fe00,
+ 0x2502fe00, 0x2402fe00, 0x2401fe00, 0x2200fe00,
+ 0x2200fe00, 0x2000ff00, 0x1f00, 0x1e00,
+ 0x1dfeff00, 0x1cfeff00, 0x1afeff00, 0x19feff00,
+ 0x17fe, 0x16fd, 0x15fd, 0x14fd,
+ 0x12fd, 0x11fd, 0x10fd, 0x0ffd,
+
+ 0x2610fd00, 0x260ffd00, 0x260efd00, 0x260dfd00,
+ 0x260cfd00, 0x260bfd00, 0x260afd00, 0x2609fd00,
+ 0x2508fd00, 0x2507fd00, 0x2406fd00, 0x2406fd00,
+ 0x2305fd00, 0x2304fd00, 0x2203fe00, 0x2103fe00,
+ 0x2002fe00, 0x1f01fe00, 0x1e01fe00, 0x1e00fe00,
+ 0x1c00fe00, 0x1b00fe00, 0x1afffe00, 0x1900,
+ 0x1800, 0x17feff00, 0x16feff00, 0x15feff00,
+ 0x14feff00, 0x13feff00, 0x11feff00, 0x10fd,
+
+ 0x2411feff, 0x2410feff, 0x240ffeff, 0x230efeff,
+ 0x240dfeff, 0x240cfeff, 0x230cfd00, 0x230bfd00,
+ 0x230afd00, 0x2309fd00, 0x2208fd00, 0x2108fd00,
+ 0x2007fd00, 0x2106fd00, 0x2005fd00, 0x1f05fd00,
+ 0x1f04fd00, 0x1e03fd00, 0x1d03fe00, 0x1c02fe00,
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Mon, Nov 27, 2017 at 07:12:50PM +0100, SF Markus Elfring wrote:
> >> Can a default allocation failure report provide the information
> >> which you might expect so far?
> >
> > You should be able to answer that question yourself.
>
> I can not answer this detail completely myself because my knowledge
> is incomplete about your concrete expectations for the exception handling
> which can lead to different views for the need of additional error messages.
The rule is to be able to get idea what failed without recompiling kernel.
If you think you can point to failed allocation with your changes, then
you might be able to convice Andrew your change is an improvement.
> > And if you are unable to do so, just do not sent changes pointed
> > by any code analysis tools.
>
> They can point aspects out for further software development considerations,
> can't they?
So?
> > As a side note, if you look at whole call chain, you'll find quite some
> > room for optimizations - look how dev and pdev are used. That also applies
> > to other patches.
>
> Would you prefer to improve the source code in other ways?
I would prefer you to look at code as a whole, not as an isolated set
of lines which can be changes to shut up some random warning obtained
from code analysis tool.
Behold, here we saved over 100 bytes just by minor clean up. Patch
is a mess, should be probably polished and splitted, but you'll get
an idea. That said, we saved more than by deleting one error message
and if you can prove we will not loose information _what_ failed
with your patch, we can save even more.
textdata bss dec hex filename
5931923724184 65875 10153 dispc.o.orig
5917823724184 65734 100c6 dispc.o
There is intentionally no signoff...
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 7a75dfda9845..4c8463957634 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -3976,52 +3976,33 @@ static const struct dispc_features omap54xx_dispc_feats
= {
.has_writeback = true,
};
-static int dispc_init_features(struct platform_device *pdev)
+static const struct dispc_features* dispc_get_features(void)
{
- const struct dispc_features *src;
- struct dispc_features *dst;
-
- dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
- if (!dst) {
- dev_err(&pdev->dev, "Failed to allocate DISPC Features\n");
- return -ENOMEM;
- }
-
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
- src = &omap24xx_dispc_feats;
- break;
+ return &omap24xx_dispc_feats;
case OMAPDSS_VER_OMAP34xx_ES1:
- src = &omap34xx_rev1_0_dispc_feats;
- break;
+ return &omap34xx_rev1_0_dispc_feats;
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
case OMAPDSS_VER_AM43xx:
- src = &omap34xx_rev3_0_dispc_feats;
- break;
+ return &omap34xx_rev3_0_dispc_feats;
case OMAPDSS_VER_OMAP4430_ES1:
case OMAPDSS_VER_OMAP4430_ES2:
case OMAPDSS_VER_OMAP4:
- src = &omap44xx_dispc_feats;
- break;
+ return &omap44xx_dispc_feats;
case OMAPDSS_VER_OMAP5:
case OMAPDSS_VER_DRA7xx:
- src = &omap54xx_dispc_feats;
- break;
+ return &omap54xx_dispc_feats;
default:
- return -ENODEV;
+ return NULL;
}
-
- memcpy(dst, src, sizeof(*dst));
- dispc.feat = dst;
-
- return 0;
}
static irqreturn_t dispc_irq_handler(int irq, void *arg)
@@ -4068,54 +4049,61 @@ EXPORT_SYMBOL(dispc_free_irq);
/* DISPC HW IP initialisation */
static int dispc_bind(struct device *dev, struct device *master, void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
u32 rev;
int r = 0;
+ const struct dispc_features *features;
struct resource *dispc_mem;
- struct device_node *np = pdev->dev.of_node;
+ struct device_node *np = dev->of_node;
- dispc.pdev = pdev;
+ dispc.pdev = to_platform_device(dev);
spin_lock_init(&dispc.control_lock);
- r = dispc_init_features(dispc.pdev);
- if (r)
- return r;
+ features = dispc_get_features();
+ if (!features)
+ return -ENODEV;
+
+ dispc.feat = devm_kzalloc(dev, sizeof(*features), GFP_KERNEL);
+ if (dispc.feat) {
+ dev_err(dev, "Failed to allocate DISPC Features\n");
+ return -ENOMEM;
+ }
+ memcpy(dispc.feat, features, sizeof(*features));
dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
if (!dispc_mem) {
-
[PATCH 12/17] drm/sun4i: Add CCSC property to DE2 configuration
Base addresses of channel output CSC (CCSC) depends whether mixer in
question is first or second and if it is second, if supports VEP or not.
This new property will tell which set of base addresses to take.
0 - first mixer or second mixer with VEP support
1 - second mixer without VEP support
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 7c9c87a0535b..2276eff8798d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -622,6 +622,7 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
.scaler_mask = 0x3,
+ .ccsc = 0,
};
static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 355a45e6cfb4..4fcf1653e345 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -136,6 +136,7 @@ struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
int scaler_mask;
+ int ccsc;
};
struct sun8i_mixer {
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/17] drm/sun4i: Add DE2 CSC library
DE2 have many CSC units - channel input CSC, channel output CSC and
mixer output CSC and maybe more.
Fortunately, they have all same register layout, only base offsets
differs.
Add support only for channel output CSC for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile| 2 +-
drivers/gpu/drm/sun4i/sun8i_csc.c | 90 +++
drivers/gpu/drm/sun4i/sun8i_csc.h | 36
3 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 70df480792f9..f82cc69ede72 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,7 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
-sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o sun8i_scaler.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o sun8i_scaler.o
sun8i_csc.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
b/drivers/gpu/drm/sun4i/sun8i_csc.c
new file mode 100644
index ..d48c28f8d568
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) Jernej Skrabec
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include "sun8i_csc.h"
+
+static const u32 ccsc_base[2][2] = {
+ {CCSC00_OFFSET, CCSC01_OFFSET},
+ {CCSC10_OFFSET, CCSC11_OFFSET},
+};
+
+/*
+ * Factors are in two's complement format, 10 bits for fractinal part.
+ * First tree values in each line are multiplication factor and last
+ * value is constant, which is added at the end.
+ */
+static const u32 yuv2rgb[] = {
+ 0x04A8, 0x, 0x0662, 0xFFFC845A,
+ 0x04A8, 0xFE6F, 0xFCBF, 0x00021DF4,
+ 0x04A8, 0x0813, 0x, 0xFFFBAC4A,
+};
+
+static const u32 yvu2rgb[] = {
+ 0x04A8, 0x0662, 0x, 0xFFFC845A,
+ 0x04A8, 0xFCBF, 0xFE6F, 0x00021DF4,
+ 0x04A8, 0x, 0x0813, 0xFFFBAC4A,
+};
+
+static void sun8i_csc_set_coefficients(struct regmap *map, u32 base,
+ enum sun8i_csc_mode mode)
+{
+ const u32 *table;
+ int i, data;
+
+ switch (mode) {
+ case SUN8I_CSC_MODE_YUV2RGB:
+ table = yuv2rgb;
+ break;
+ case SUN8I_CSC_MODE_YVU2RGB:
+ table = yvu2rgb;
+ break;
+ default:
+ WARN(1, "Wrong CSC mode specified.");
+ return;
+ }
+
+ for (i = 0; i < 12; i++) {
+ data = table[i];
+ /* For some reason, 0x200 must be added to constant parts */
+ if (((i + 1) & 3) == 0)
+ data += 0x200;
+ regmap_write(map, SUN8I_CSC_COEFF(base, i), data);
+ }
+}
+
+static void sun8i_csc_enable(struct regmap *map, u32 base, bool enable)
+{
+ u32 val;
+
+ if (enable)
+ val = SUN8I_CSC_CTRL_EN;
+ else
+ val = 0;
+
+ regmap_update_bits(map, SUN8I_CSC_CTRL(base), SUN8I_CSC_CTRL_EN, val);
+}
+
+void sun8i_csc_set_ccsc_coefficients(struct sun8i_mixer *mixer, int layer,
+enum sun8i_csc_mode mode)
+{
+ u32 base;
+
+ base = ccsc_base[mixer->cfg->ccsc][layer];
+
+ sun8i_csc_set_coefficients(mixer->engine.regs, base, mode);
+}
+
+void sun8i_csc_enable_ccsc(struct sun8i_mixer *mixer, int layer, bool enable)
+{
+ u32 base;
+
+ base = ccsc_base[mixer->cfg->ccsc][layer];
+
+ sun8i_csc_enable(mixer->engine.regs, base, enable);
+}
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.h
b/drivers/gpu/drm/sun4i/sun8i_csc.h
new file mode 100644
index ..19ae1dda06c4
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) Jernej Skrabec
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef _SUN8I_CSC_H_
+#define _SUN8I_CSC_H_
+
+#include "sun8i_mixer.h"
+
+/* VI channel CSC units offsets */
+#define CCSC00_OFFSET 0xAA050
+#define CCSC01_OFFSET 0xFA000
+#define CCSC10_OFFSET 0xA
+#define CCSC11_OFFSET 0xF
+
+#define SUN8I_CSC_CTRL(base) (base + 0x0)
+#define SUN8I_CSC_COEFF(base, i) (base + 0x10 + 4 * i)
+
+#define SUN
Re: [PATCH] omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Mon, Nov 27, 2017 at 03:33:13PM -0600, Andrew F. Davis wrote: > On 11/27/2017 01:07 PM, Joe Perches wrote: > > On Mon, 2017-11-27 at 10:43 -0600, Andrew F. Davis wrote: > >> On 11/26/2017 12:55 PM, SF Markus Elfring wrote: > >>> From: Markus Elfring > >>> Date: Sun, 26 Nov 2017 19:46:09 +0100 > >>> > >>> Omit an extra message for a memory allocation failure in these functions. > >>> > >>> This issue was detected by using the Coccinelle software. > >>> > >>> Signed-off-by: Markus Elfring > >>> --- > >> > >> nak, unlike many others, these message give extra info on which > >> allocation failed, that can be useful. > > > > Not really. There are tradeoffs. > > > > There is the generic stack dump on OOM so the module/line > > is already known. > > > > If that is the case then I have no strong feelings either way. > > > The existence of these messages increases code size which > > also make the OOM condition slightly more likely. > > > > These are generally used only at initialization and those > > if you are OOM at initialization, bad things happen anyway > > so where the specific OOM occurred doesn't really matter. > > > > True, these messages will probably only ever get displayed if someone is > messing with the allocated structs and accidentally balloons their size, > so these are more debug statements than anything. All those messages are result of allocation failure. The memory allocated is later used to hold duplicate of static const data. Do we need that copy (and thus allocation) at all? ladis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()
+nouv...@lists.freedesktop.org
On 11/27/2017 11:57 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
> and extract the domain number from
> 1. struct pci_dev
> 2. struct pci_dev through drm_device->pdev
> 3. struct pci_dev through fb->subdev->drm_device->pdev
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++-
> drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
> drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
> 4 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> index 90075b6..c79160c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> @@ -213,8 +213,10 @@ struct nv_sim_state {
> if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
> (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
> uint32_t type;
> + int domain = pci_domain_nr(dev->pdev->bus);
>
> - pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, &type);
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
> + 0x7c, &type);
>
> sim_data.memory_type = (type >> 12) & 1;
> sim_data.memory_width = 64;
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> index b985990..0c9bdf0 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
> @@ -216,12 +216,15 @@
> {
> struct nvkm_pll_vals pllvals;
> int ret;
> + int domain;
> +
> + domain = pci_domain_nr(dev->pdev->bus);
>
> if (plltype == PLL_MEMORY &&
> (dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
> uint32_t mpllP;
> -
> - pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, &mpllP);
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
> + 0x6c, &mpllP);
> mpllP = (mpllP >> 8) & 0xf;
> if (!mpllP)
> mpllP = 4;
> @@ -232,7 +235,8 @@
> (dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
> uint32_t clock;
>
> - pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, &clock);
> + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
> + 0x4c, &clock);
> return clock / 1000;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 595630d..0b6c639 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> }
>
> /* subfunction one is a hdmi audio device? */
> - drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
> + drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> + (unsigned int)pdev->bus->number,
>
> PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
>
> if (!drm->hdmi_device) {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> index 3c6a871..8849b71 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
> @@ -28,8 +28,16 @@
> {
> struct pci_dev *bridge;
> u32 mem, mib;
> + int domain = 0;
> + struct pci_dev *pdev = NULL;
>
> - bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
> + if (dev_is_pci(fb->subdev.device->dev))
> + pdev = to_pci_dev(fb->subdev.device->dev);
> +
> + if (pdev)
> + domain = pci_domain_nr(pdev->bus);
> +
> + bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
> if (!bridge) {
> nvkm_error(&fb->subdev, "no bridge device\n");
> return -ENODEV;
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb/dss: Delete an error message for a failed memory allocation in three functions
On 11/27/2017 01:07 PM, Joe Perches wrote:
> On Mon, 2017-11-27 at 10:43 -0600, Andrew F. Davis wrote:
>> On 11/26/2017 12:55 PM, SF Markus Elfring wrote:
>>> From: Markus Elfring
>>> Date: Sun, 26 Nov 2017 19:46:09 +0100
>>>
>>> Omit an extra message for a memory allocation failure in these functions.
>>>
>>> This issue was detected by using the Coccinelle software.
>>>
>>> Signed-off-by: Markus Elfring
>>> ---
>>
>> nak, unlike many others, these message give extra info on which
>> allocation failed, that can be useful.
>
> Not really. There are tradeoffs.
>
> There is the generic stack dump on OOM so the module/line
> is already known.
>
If that is the case then I have no strong feelings either way.
> The existence of these messages increases code size which
> also make the OOM condition slightly more likely.
>
> These are generally used only at initialization and those
> if you are OOM at initialization, bad things happen anyway
> so where the specific OOM occurred doesn't really matter.
>
True, these messages will probably only ever get displayed if someone is
messing with the allocated structs and accidentally balloons their size,
so these are more debug statements than anything.
> Markus' commit messages are always really poor descriptions
> of why these removals are somewhat useful and the commit
> could/should/might be applied.
>
> Your choice.
>
>>> drivers/video/fbdev/omap2/omapfb/dss/dispc.c| 4 +---
>>> drivers/video/fbdev/omap2/omapfb/dss/dss.c | 4 +---
>>> drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 4 +---
>>> 3 files changed, 3 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
>>> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
>>> index 7a75dfda9845..10164a3bae4a 100644
>>> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
>>> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
>>> @@ -3982,10 +3982,8 @@ static int dispc_init_features(struct
>>> platform_device *pdev)
>>> struct dispc_features *dst;
>>>
>>> dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
>>> - if (!dst) {
>>> - dev_err(&pdev->dev, "Failed to allocate DISPC Features\n");
>>> + if (!dst)
>>> return -ENOMEM;
>>> - }
>>>
>>> switch (omapdss_get_version()) {
>>> case OMAPDSS_VER_OMAP24xx:
>>> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
>>> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
>>> index 48c6500c24e1..a5de13777e2b 100644
>>> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
>>> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
>>> @@ -893,10 +893,8 @@ static int dss_init_features(struct platform_device
>>> *pdev)
>>> struct dss_features *dst;
>>>
>>> dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
>>> - if (!dst) {
>>> - dev_err(&pdev->dev, "Failed to allocate local DSS Features\n");
>>> + if (!dst)
>>> return -ENOMEM;
>>> - }
>>>
>>> switch (omapdss_get_version()) {
>>> case OMAPDSS_VER_OMAP24xx:
>>> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
>>> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
>>> index 9a13c35fd6d8..d25eea10c665 100644
>>> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
>>> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
>>> @@ -195,10 +195,8 @@ static int hdmi_phy_init_features(struct
>>> platform_device *pdev)
>>> const struct hdmi_phy_features *src;
>>>
>>> dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
>>> - if (!dst) {
>>> - dev_err(&pdev->dev, "Failed to allocate HDMI PHY Features\n");
>>> + if (!dst)
>>> return -ENOMEM;
>>> - }
>>>
>>> switch (omapdss_get_version()) {
>>> case OMAPDSS_VER_OMAP4430_ES1:
>>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/17] drm/sun4i: Add DE2 definitions for YUV formats
This commit expands translation of DRM YUV format to HW specific
information.
It doesn't do any functional changes.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 147 +++-
drivers/gpu/drm/sun4i/sun8i_mixer.h | 16
2 files changed, 159 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 2276eff8798d..00edfdc98499 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -29,92 +29,231 @@
#include "sun8i_layer.h"
#include "sunxi_engine.h"
#include "sun8i_scaler.h"
+#include "sun8i_csc.h"
struct de2_fmt_info {
- u32 drm_fmt;
- u32 de2_fmt;
+ u32 drm_fmt;
+ u32 de2_fmt;
+ boolrgb;
+ enum sun8i_csc_mode csc;
};
static const struct de2_fmt_info de2_formats[] = {
{
.drm_fmt = DRM_FORMAT_ARGB,
.de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ABGR,
.de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBA,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRA,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_XRGB,
.de2_fmt = SUN8I_MIXER_FBFMT_XRGB,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_XBGR,
.de2_fmt = SUN8I_MIXER_FBFMT_XBGR,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBX,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBX,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRX,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRX,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGB888,
.de2_fmt = SUN8I_MIXER_FBFMT_RGB888,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGR888,
.de2_fmt = SUN8I_MIXER_FBFMT_BGR888,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGB565,
.de2_fmt = SUN8I_MIXER_FBFMT_RGB565,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGR565,
.de2_fmt = SUN8I_MIXER_FBFMT_BGR565,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ARGB,
.de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ABGR,
.de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBA,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRA,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ARGB1555,
.de2_fmt = SUN8I_MIXER_FBFMT_ARGB1555,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_ABGR1555,
.de2_fmt = SUN8I_MIXER_FBFMT_ABGR1555,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_RGBA5551,
.de2_fmt = SUN8I_MIXER_FBFMT_RGBA5551,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
},
{
.drm_fmt = DRM_FORMAT_BGRA5551,
.de2_fmt = SUN8I_MIXER_FBFMT_BGRA5551,
+ .rgb = true,
+ .csc = SUN8I_CSC_MODE_OFF,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_UYVY,
+ .de2_fmt = SUN8I_MIXER_FBFMT_UYVY,
+ .rgb = false,
+
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Mon, Nov 27, 2017 at 08:22:51PM +0100, Ladislav Michl wrote:
> On Mon, Nov 27, 2017 at 07:12:50PM +0100, SF Markus Elfring wrote:
> > >> Can a default allocation failure report provide the information
> > >> which you might expect so far?
> > >
> > > You should be able to answer that question yourself.
> >
> > I can not answer this detail completely myself because my knowledge
> > is incomplete about your concrete expectations for the exception handling
> > which can lead to different views for the need of additional error messages.
>
> The rule is to be able to get idea what failed without recompiling kernel.
> If you think you can point to failed allocation with your changes, then
> you might be able to convice Andrew your change is an improvement.
>
> > > And if you are unable to do so, just do not sent changes pointed
> > > by any code analysis tools.
> >
> > They can point aspects out for further software development considerations,
> > can't they?
>
> So?
>
> > > As a side note, if you look at whole call chain, you'll find quite some
> > > room for optimizations - look how dev and pdev are used. That also applies
> > > to other patches.
> >
> > Would you prefer to improve the source code in other ways?
>
> I would prefer you to look at code as a whole, not as an isolated set
> of lines which can be changes to shut up some random warning obtained
> from code analysis tool.
>
> Behold, here we saved over 100 bytes just by minor clean up. Patch
> is a mess, should be probably polished and splitted, but you'll get
> an idea. That said, we saved more than by deleting one error message
> and if you can prove we will not loose information _what_ failed
> with your patch, we can save even more.
Well, if we remove allocation, we do not need to print error message...
And numbers are even better.
>text data bss dec hex filename
> 59319 23724184 65875 10153 dispc.o.orig
> 59178 23724184 65734 100c6 dispc.o
59095 23724184 65651 10073 dispc.o.noalloc
Care to test this? It is a mess of unrelated changes, but I'm just
interested if it works...
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 7a75dfda9845..f6d631a68c70 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -3976,52 +3976,33 @@ static const struct dispc_features omap54xx_dispc_feats
= {
.has_writeback = true,
};
-static int dispc_init_features(struct platform_device *pdev)
+static const struct dispc_features* dispc_get_features(void)
{
- const struct dispc_features *src;
- struct dispc_features *dst;
-
- dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
- if (!dst) {
- dev_err(&pdev->dev, "Failed to allocate DISPC Features\n");
- return -ENOMEM;
- }
-
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
- src = &omap24xx_dispc_feats;
- break;
+ return &omap24xx_dispc_feats;
case OMAPDSS_VER_OMAP34xx_ES1:
- src = &omap34xx_rev1_0_dispc_feats;
- break;
+ return &omap34xx_rev1_0_dispc_feats;
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
case OMAPDSS_VER_AM43xx:
- src = &omap34xx_rev3_0_dispc_feats;
- break;
+ return &omap34xx_rev3_0_dispc_feats;
case OMAPDSS_VER_OMAP4430_ES1:
case OMAPDSS_VER_OMAP4430_ES2:
case OMAPDSS_VER_OMAP4:
- src = &omap44xx_dispc_feats;
- break;
+ return &omap44xx_dispc_feats;
case OMAPDSS_VER_OMAP5:
case OMAPDSS_VER_DRA7xx:
- src = &omap54xx_dispc_feats;
- break;
+ return &omap54xx_dispc_feats;
default:
- return -ENODEV;
+ return NULL;
}
-
- memcpy(dst, src, sizeof(*dst));
- dispc.feat = dst;
-
- return 0;
}
static irqreturn_t dispc_irq_handler(int irq, void *arg)
@@ -4068,54 +4049,53 @@ EXPORT_SYMBOL(dispc_free_irq);
/* DISPC HW IP initialisation */
static int dispc_bind(struct device *dev, struct device *master, void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
u32 rev;
int r = 0;
struct resource *dispc_mem;
- struct device_node *np = pdev->dev.of_node;
+ struct device_node *np = dev->of_node;
- dispc.pdev = pdev;
+ dispc.pdev = to_platform_device(dev);
spin_lock_init(&dispc.control_lock);
- r = dispc_init_features(dispc.pdev);
- if (r)
- return r;
+ dispc.feat = dispc_get_features();
+ if (dispc.feat)
+ return -ENODEV;
dispc_mem = platform_get_reso
[PATCH 04/17] drm/sun4i: Use values calculated by atomic check
Now that we have properly clipped coordinates in plane state structure,
use them.
This also fixes bug where source x and y were adjusted for negative
value, but width and height weren't. It wasn't discovered because
primary plane usually doesn't have negative coordinates.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 5
drivers/gpu/drm/sun4i/sun8i_mixer.c | 52 -
2 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 54739e12311d..511d2f8afef6 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -68,6 +68,11 @@ static void sun8i_mixer_layer_atomic_update(struct drm_plane
*plane,
struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
struct sun8i_mixer *mixer = layer->mixer;
+ if (!plane->state->visible) {
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+ return;
+ }
+
sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 37eb5f6f8ee8..6aa3240186c1 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -91,28 +91,34 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
{
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
+ u32 width, height, size;
DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
+ /*
+* Same source and destination width and height are guaranteed
+* by atomic check function.
+*/
+ width = drm_rect_width(&state->dst);
+ height = drm_rect_height(&state->dst);
+ size = SUN8I_MIXER_SIZE(width, height);
+
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
-state->crtc_w, state->crtc_h);
- regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_SIZE,
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+width, height);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_GLOBAL_SIZE,
+size);
DRM_DEBUG_DRIVER("Updating blender size\n");
regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_INSIZE(layer),
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+size);
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+size);
DRM_DEBUG_DRIVER("Updating channel size\n");
regmap_write(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_OVL_SIZE(layer),
-SUN8I_MIXER_SIZE(state->crtc_w,
- state->crtc_h));
+size);
}
/* Set the line width */
@@ -122,18 +128,17 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
fb->pitches[0]);
/* Set height and width */
- DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n",
-state->crtc_w, state->crtc_h);
+ DRM_DEBUG_DRIVER("Layer size W: %u H: %u\n", width, height);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_LAYER_SIZE(layer, 0),
-SUN8I_MIXER_SIZE(state->crtc_w, state->crtc_h));
+size);
/* Set base coordinates */
DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n",
-state->crtc_x, state->crtc_y);
+state->dst.x1, state->dst.y1);
regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_COORD(layer),
-SUN8I_MIXER_COORD(state->crtc_x, state->crtc_y));
+SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
return 0;
}
@@ -193,21 +198,8 @@ int sun8i_mixer_update_layer_buffer(struct sun8i_mixer
*mixer,
paddr = gem->paddr + fb->offsets[0];
/* Fixup framebuffer address for src coordinates */
- paddr += (state->src_x >> 16) * bpp;
- paddr += (state->src_y >> 16) * fb->pitches[0];
-
- /*
-* The hardware cannot correctly deal with negative crtc
-* coordinates, the display is cropped to the requ
[PATCH 06/17] drm/sun4i: Add multi plane support to DE2 driver
Support for multiple UI planes can now be easily enabled just by adding
more planes with different index.
For now, add immutable zpos property.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 38 +
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 511d2f8afef6..371d6b359262 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -22,12 +22,6 @@
#include "sun8i_layer.h"
#include "sun8i_mixer.h"
-struct sun8i_plane_desc {
- enum drm_plane_type type;
- const uint32_t *formats;
- uint32_tnformats;
-};
-
static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -100,35 +94,38 @@ static const uint32_t sun8i_mixer_layer_formats[] = {
DRM_FORMAT_XRGB,
};
-static const struct sun8i_plane_desc sun8i_mixer_planes[] = {
- {
- .type = DRM_PLANE_TYPE_PRIMARY,
- .formats = sun8i_mixer_layer_formats,
- .nformats = ARRAY_SIZE(sun8i_mixer_layer_formats),
- },
-};
-
static struct sun8i_layer *sun8i_layer_init_one(struct drm_device *drm,
struct sun8i_mixer *mixer,
- const struct sun8i_plane_desc
*plane)
+ int index)
{
struct sun8i_layer *layer;
+ enum drm_plane_type type;
int ret;
layer = devm_kzalloc(drm->dev, sizeof(*layer), GFP_KERNEL);
if (!layer)
return ERR_PTR(-ENOMEM);
+ type = index == 0 ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+
/* possible crtcs are set later */
ret = drm_universal_plane_init(drm, &layer->plane, 0,
&sun8i_mixer_layer_funcs,
- plane->formats, plane->nformats,
- NULL, plane->type, NULL);
+ sun8i_mixer_layer_formats,
+ ARRAY_SIZE(sun8i_mixer_layer_formats),
+ NULL, type, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
return ERR_PTR(ret);
}
+ /* fixed zpos for now */
+ ret = drm_plane_create_zpos_immutable_property(&layer->plane, index);
+ if (ret) {
+ dev_err(drm->dev, "Couldn't add zpos property\n");
+ return ERR_PTR(ret);
+ }
+
drm_plane_helper_add(&layer->plane,
&sun8i_mixer_layer_helper_funcs);
layer->mixer = mixer;
@@ -143,16 +140,15 @@ struct drm_plane **sun8i_layers_init(struct drm_device
*drm,
struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
int i;
- planes = devm_kcalloc(drm->dev, ARRAY_SIZE(sun8i_mixer_planes) + 1,
+ planes = devm_kcalloc(drm->dev, mixer->cfg->ui_num + 1,
sizeof(*planes), GFP_KERNEL);
if (!planes)
return ERR_PTR(-ENOMEM);
- for (i = 0; i < ARRAY_SIZE(sun8i_mixer_planes); i++) {
- const struct sun8i_plane_desc *plane = &sun8i_mixer_planes[i];
+ for (i = 0; i < mixer->cfg->ui_num; i++) {
struct sun8i_layer *layer;
- layer = sun8i_layer_init_one(drm, mixer, plane);
+ layer = sun8i_layer_init_one(drm, mixer, i);
if (IS_ERR(layer)) {
dev_err(drm->dev, "Couldn't initialize %s plane\n",
i ? "overlay" : "primary");
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: > > > On 11/23/2017 03:11 AM, Christian König wrote: >> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: >>> On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: > On 11/22/2017 05:09 AM, Christian König wrote: >> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >>> On 11/21/2017 08:34 AM, Christian König wrote: Hi Boris, attached are two patches. The first one is a trivial fix for the infinite loop issue, it now correctly aborts the fixup when it can't find address space for the root window. The second is a workaround for your board. It simply checks if there is exactly one Processor Function to apply this fix on. Both are based on linus current master branch. Please test if they fix your issue. >>> Yes, they do fix it but that's because the feature is disabled. >>> >>> Do you know what the actual problem was (on Xen)? >> I still haven't understood what you actually did with Xen. >> >> When you used PCI pass through with those devices then you have >> made a >> major configuration error. >> >> When the problem happened on dom0 then the explanation is most >> likely >> that some PCI device ended up in the configured space, but the >> routing >> was only setup correctly on one CPU socket. > The problem is that dom0 can be (and was in my case() booted with > less > than full physical memory and so the "rest" of the host memory is not > necessarily reflected in iomem. Your patch then tried to configure > that > memory for MMIO and the system hang. > > And so my guess is that this patch will break dom0 on a single-socket > system as well. Oh, thanks! I've thought about that possibility before, but wasn't able to find a system which actually does that. May I ask why the rest of the memory isn't reported to the OS? >>> That memory doesn't belong to the OS (dom0), it is owned by the >>> hypervisor. >>> Sounds like I can't trust Linux resource management and probably need to read the DRAM config to figure things out after all. >>> >>> My question is whether what you are trying to do should ever be done >>> for >>> a guest at all (any guest, not necessarily Xen). >> >> The issue is probably that I don't know enough about Xen: What >> exactly is dom0? My understanding was that dom0 is the hypervisor, >> but that seems to be incorrect. >> >> The issue is that under no circumstances *EVER* a virtualized guest >> should have access to the PCI devices marked as "Processor Function" >> on AMD platforms. Otherwise it is trivial to break out of the >> virtualization. >> >> When dom0 is something like the system domain with all hardware >> access then the approach seems legitimate, but then the hypervisor >> should report the stolen memory to the OS using the e820 table. >> >> When the hypervisor doesn't do that and the Linux kernel isn't aware >> that there is memory at a given location mapping PCI space there will >> obviously crash the hypervisor. >> >> Possible solutions as far as I can see are either disabling this >> feature when we detect that we are a Xen dom0, scanning the DRAM >> settings to update Linux resource handling or fixing Xen to report >> stolen memory to the dom0 OS as reserved. >> >> Opinions? > > You are right, these functions are not exposed to a regular guest. > > I think for dom0 (which is a special Xen guest, with additional > privileges) we may be able to add a reserved e820 region for host > memory that is not assigned to dom0. Let me try it on Monday (I am out > until then). One thing I realized while looking at solution for Xen dom0 is that this patch may cause problems for memory hotplug. What happens if new memory is added to the system and we have everything above current memory set to MMIO? -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/17] drm/sun4i: Add support for DE2 VI planes
This commit adds basic support for VI planes. They are meant for video
overlay and because of that they support YUV formats too. However, using
YUV planes is not straightforward, so only RGB support for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 40 +++---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 144 +---
drivers/gpu/drm/sun4i/sun8i_mixer.h | 38 --
3 files changed, 196 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 49ccdd0149bd..e1b6ad82145e 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -47,13 +47,22 @@ static int sun8i_mixer_layer_atomic_check(struct drm_plane
*plane,
true, true);
}
+static void sun8i_mixer_layer_enable(struct sun8i_layer *layer, bool enable)
+{
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ if (layer->id < mixer->cfg->vi_num)
+ sun8i_mixer_vi_layer_enable(mixer, layer->id, enable);
+ else
+ sun8i_mixer_ui_layer_enable(mixer, layer->id, enable);
+}
+
static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
struct drm_plane_state
*old_state)
{
struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
- struct sun8i_mixer *mixer = layer->mixer;
- sun8i_mixer_layer_enable(mixer, layer->id, false);
+ sun8i_mixer_layer_enable(layer, false);
}
static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
@@ -63,14 +72,21 @@ static void sun8i_mixer_layer_atomic_update(struct
drm_plane *plane,
struct sun8i_mixer *mixer = layer->mixer;
if (!plane->state->visible) {
- sun8i_mixer_layer_enable(mixer, layer->id, false);
+ sun8i_mixer_layer_enable(layer, false);
return;
}
- sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
- sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
- sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
- sun8i_mixer_layer_enable(mixer, layer->id, true);
+ if (layer->id < mixer->cfg->vi_num) {
+ sun8i_mixer_update_vi_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_vi_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_vi_layer_buffer(mixer, layer->id, plane);
+ } else {
+ sun8i_mixer_update_ui_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_ui_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_ui_layer_buffer(mixer, layer->id, plane);
+ }
+
+ sun8i_mixer_layer_enable(layer, true);
}
static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
@@ -123,7 +139,8 @@ static struct sun8i_layer *sun8i_layer_init_one(struct
drm_device *drm,
if (!layer)
return ERR_PTR(-ENOMEM);
- type = index == 0 ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ type = index == mixer->cfg->vi_num ?
+ DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
/* possible crtcs are set later */
ret = drm_universal_plane_init(drm, &layer->plane, 0,
@@ -162,17 +179,18 @@ struct drm_plane **sun8i_layers_init(struct drm_device
*drm,
if (!planes)
return ERR_PTR(-ENOMEM);
- for (i = 0; i < mixer->cfg->ui_num; i++) {
+ for (i = 0; i < mixer->cfg->vi_num + mixer->cfg->ui_num; i++) {
struct sun8i_layer *layer;
layer = sun8i_layer_init_one(drm, mixer, i);
if (IS_ERR(layer)) {
dev_err(drm->dev, "Couldn't initialize %s plane\n",
- i ? "overlay" : "primary");
+ i == mixer->cfg->vi_num ?
+ "overlay" : "primary");
return ERR_CAST(layer);
};
- layer->id = mixer->cfg->vi_num + i;
+ layer->id = i;
planes[i] = &layer->plane;
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index fe81c048cc08..dc97351be973 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -136,12 +136,13 @@ static void sun8i_mixer_commit(struct sunxi_engine
*engine)
SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
}
-void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
- int layer, bool enable)
+void sun8i_mixer_ui_layer_enable(struct sun8i_mixer *mixer,
+int layer, bool enable)
{
u32 val;
- DRM_DEBUG_DRIVER("%sabling layer %d\n", enable ? "En" : "Dis", layer);
+ DRM_DEBUG_DRIVER("%sabling UI layer %d\n",
+enable
[PATCH 07/17] drm/sun4i: Add support for all HW supported DE2 RGB formats
Currently only a few RGB formats are supported by the DE2 driver. Add
support for all formats supported by the HW.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 19 -
drivers/gpu/drm/sun4i/sun8i_mixer.c | 134
drivers/gpu/drm/sun4i/sun8i_mixer.h | 17 +
3 files changed, 139 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 371d6b359262..49ccdd0149bd 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -89,8 +89,25 @@ static const struct drm_plane_funcs sun8i_mixer_layer_funcs
= {
};
static const uint32_t sun8i_mixer_layer_formats[] = {
- DRM_FORMAT_RGB888,
+ DRM_FORMAT_ABGR1555,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_ARGB,
DRM_FORMAT_ARGB,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_BGRA5551,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGBX,
+ DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index c1b7685603fe..fe81c048cc08 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -29,6 +29,105 @@
#include "sun8i_layer.h"
#include "sunxi_engine.h"
+struct de2_fmt_info {
+ u32 drm_fmt;
+ u32 de2_fmt;
+};
+
+static const struct de2_fmt_info de2_formats[] = {
+ {
+ .drm_fmt = DRM_FORMAT_ARGB,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ABGR,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_XRGB,
+ .de2_fmt = SUN8I_MIXER_FBFMT_XRGB,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_XBGR,
+ .de2_fmt = SUN8I_MIXER_FBFMT_XBGR,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBX,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBX,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRX,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRX,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGB888,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGB888,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGR888,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGR888,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGB565,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGB565,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGR565,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGR565,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ARGB,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ARGB,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ABGR,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ABGR,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRA,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRA,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ARGB1555,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ARGB1555,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_ABGR1555,
+ .de2_fmt = SUN8I_MIXER_FBFMT_ABGR1555,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_RGBA5551,
+ .de2_fmt = SUN8I_MIXER_FBFMT_RGBA5551,
+ },
+ {
+ .drm_fmt = DRM_FORMAT_BGRA5551,
+ .de2_fmt = SUN8I_MIXER_FBFMT_BGRA5551,
+ },
+};
+
+static const struct de2_fmt_info *sun8i_mixer_format_info(u32 format)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(de2_formats); ++i)
+ if (de2_formats[i].drm_fmt == format)
+ return &de2_formats[i];
+
+ return NULL;
+}
+
static void sun8i_mixer_commit(struct sunxi_engine *engine)
{
DRM_DEBUG_DRIVER("Committing changes\n");
@@ -63,29 +162,6 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
SUN8I_MIXER_BLEND_PIPE_CTL_EN(layer), val);
}
-static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
-u32 format, u32 *mode)
-{
- switch (format) {
- case DRM_FORMAT_ARGB:
- *mode =
[PATCH 00/17] Improve DE2 support
Current DE2 driver is very basic and uses a lot of magic constants since there is no documentation and knowledge about it was limited at the time. With studying BSP source code, deeper knowledge was gained which allows to improve mainline driver considerably. At the beginning of this series, some code refactoring is done as well as adding some checks (patches 1-5). Further patches add multi-plane support with HW scaling and all possible RGB formats (patches 6-11). At last, support for YUV formats is added (patches 12-16). At the end, I included patch which puts lowest plane before second lowest. This should help testing VI planes when mixer has configuration 1 VI plane and 1 on more UI planes (most SoCs except V3s). This code was developed on H3, but it should work on every SoC if correct configuration structure is provided. H3 code can be found here: https://github.com/jernejsk/linux-1/commits/de2_impr_for_next Best regards, Jernej Jernej Skrabec (17): drm/sun4i: Refactor DE2 code drm/sun4i: Start using layer id in DE2 driver drm/sun4i: Add constraints checking to DE2 driver drm/sun4i: Use values calculated by atomic check drm/sun4i: Reorder some code in DE2 drm/sun4i: Add multi plane support to DE2 driver drm/sun4i: Add support for all HW supported DE2 RGB formats drm/sun4i: Add support for DE2 VI planes drm/sun4i: Add scaler library for DE2 drm/sun4i: Add scaler configuration to DE2 mixers drm/sun4i: Wire in DE2 scaler support drm/sun4i: Add CCSC property to DE2 configuration drm/sun4i: Add DE2 CSC library drm/sun4i: Add DE2 definitions for YUV formats drm/sun4i: Expand DE2 scaler lib with YUV support drm/sun4i: Wire in DE2 YUV support [DO NOT MERGE]drm/sun4i: Change zpos of bottom VI plane drivers/gpu/drm/sun4i/Makefile |2 +- drivers/gpu/drm/sun4i/sun8i_csc.c| 90 +++ drivers/gpu/drm/sun4i/sun8i_csc.h| 36 ++ drivers/gpu/drm/sun4i/sun8i_layer.c | 176 +- drivers/gpu/drm/sun4i/sun8i_mixer.c | 679 + drivers/gpu/drm/sun4i/sun8i_mixer.h | 108 +++- drivers/gpu/drm/sun4i/sun8i_scaler.c | 1103 ++ drivers/gpu/drm/sun4i/sun8i_scaler.h | 79 +++ 8 files changed, 2096 insertions(+), 177 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_scaler.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_scaler.h -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/17] drm/sun4i: Wire in DE2 YUV support
Now that we have all required bits, add support for YUV formats.
DRM subsystem doesn't know YUV411 semi-planar format, so leave that out
for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 56 +-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 110 +++-
2 files changed, 137 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
index 6860271e5415..9e431eaa3430 100644
--- a/drivers/gpu/drm/sun4i/sun8i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -112,7 +112,7 @@ static const struct drm_plane_funcs sun8i_mixer_layer_funcs
= {
.update_plane = drm_atomic_helper_update_plane,
};
-static const uint32_t sun8i_mixer_layer_formats[] = {
+static const u32 sun8i_mixer_ui_layer_formats[] = {
DRM_FORMAT_ABGR1555,
DRM_FORMAT_ABGR,
DRM_FORMAT_ABGR,
@@ -135,26 +135,76 @@ static const uint32_t sun8i_mixer_layer_formats[] = {
DRM_FORMAT_XRGB,
};
+/*
+ * While all RGB formats are supported, VI planes don't support
+ * alpha blending, so there is no point having formats with alpha
+ * channel if their opaque analog exist.
+ */
+static const u32 sun8i_mixer_vi_layer_formats[] = {
+ DRM_FORMAT_ABGR1555,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_BGRA5551,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_RGBX,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV21,
+ DRM_FORMAT_NV61,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_YUV411,
+ DRM_FORMAT_YUV420,
+ DRM_FORMAT_YUV422,
+ DRM_FORMAT_YUV444,
+ DRM_FORMAT_YVU411,
+ DRM_FORMAT_YVU420,
+ DRM_FORMAT_YVU422,
+ DRM_FORMAT_YVU444,
+};
+
static struct sun8i_layer *sun8i_layer_init_one(struct drm_device *drm,
struct sun8i_mixer *mixer,
int index)
{
struct sun8i_layer *layer;
enum drm_plane_type type;
+ unsigned int format_cnt;
+ const u32 *formats;
int ret;
layer = devm_kzalloc(drm->dev, sizeof(*layer), GFP_KERNEL);
if (!layer)
return ERR_PTR(-ENOMEM);
+ if (index < mixer->cfg->vi_num) {
+ formats = sun8i_mixer_vi_layer_formats;
+ format_cnt = ARRAY_SIZE(sun8i_mixer_vi_layer_formats);
+ } else {
+ formats = sun8i_mixer_ui_layer_formats;
+ format_cnt = ARRAY_SIZE(sun8i_mixer_ui_layer_formats);
+ }
+
type = index == mixer->cfg->vi_num ?
DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
/* possible crtcs are set later */
ret = drm_universal_plane_init(drm, &layer->plane, 0,
&sun8i_mixer_layer_funcs,
- sun8i_mixer_layer_formats,
- ARRAY_SIZE(sun8i_mixer_layer_formats),
+ formats, format_cnt,
NULL, type, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 6fb7dfd789f9..4d2b42804008 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -428,6 +428,7 @@ int sun8i_mixer_update_vi_layer_coord(struct sun8i_mixer
*mixer,
u32 src_w, src_h, dst_w, dst_h;
u32 outsize, insize;
u32 hphase, vphase;
+ bool subsampled;
DRM_DEBUG_DRIVER("Updating VI layer %d\n", layer);
@@ -439,19 +440,45 @@ int sun8i_mixer_update_vi_layer_coord(struct sun8i_mixer
*mixer,
hphase = state->src.x1 & 0x;
vphase = state->src.y1 & 0x;
+ /* make coordinates dividable by subsampling factor */
+ if (format->hsub > 1) {
+ int mask, remainder;
+
+ mask = format->hsub - 1;
+ remainder = (state->src.x1 >> 16) & mask;
+ src_w = (src_w + remainder) & ~mask;
+ hphase += remainder << 16;
+ }
+
+ if (format->vsub > 1) {
+ int mask, remainder;
+
+ mask = format->vsub - 1;
+ remainder = (state->src.y1 >> 16) & mask;
+ src_h = (src_h + remainder) & ~mask;
+ vphase += remainder << 16;
+ }
+
insize = SUN8I_MIXER_SIZE(src_w, src_h);
outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
/*
[PATCH 09/17] drm/sun4i: Add scaler library for DE2
Scaler library currently supports scaling only RGB planes on VI planes.
Coefficients and algorithm which ones to select are taken from BSP driver.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile | 2 +-
drivers/gpu/drm/sun4i/sun8i_scaler.c | 667 +++
drivers/gpu/drm/sun4i/sun8i_scaler.h | 78
3 files changed, 746 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_scaler.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_scaler.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 0c2f8c7facae..70df480792f9 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,7 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
-sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o
+sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o sun8i_scaler.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_scaler.c
b/drivers/gpu/drm/sun4i/sun8i_scaler.c
new file mode 100644
index ..23525beceaa2
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_scaler.c
@@ -0,0 +1,667 @@
+/*
+ * Copyright (C) 2017 Jernej Skrabec
+ *
+ * Coefficients are taken from BSP driver, which is:
+ * Copyright (C) 2014-2015 Allwinner
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include "sun8i_scaler.h"
+
+static const u32 lan2coefftab16[240] = {
+ 0x4000, 0x00033ffe, 0x00063efc, 0x000a3bfb,
+ 0xff0f37fb, 0xfe1433fb, 0xfd192ffb, 0xfd1f29fb,
+ 0xfc2424fc, 0xfb291ffd, 0xfb2f19fd, 0xfb3314fe,
+ 0xfb370fff, 0xfb3b0a00, 0xfc3e0600, 0xfe3f0300,
+
+ 0xff053804, 0xff083801, 0xff0a3700, 0xff0e34ff,
+ 0xff1232fd, 0xfe162ffd, 0xfd1b2cfc, 0xfd1f28fc,
+ 0xfd2323fd, 0xfc281ffd, 0xfc2c1bfd, 0xfd2f16fe,
+ 0xfd3212ff, 0xff340eff, 0x00360a00, 0x02370700,
+
+ 0xff083207, 0xff0a3205, 0xff0d3103, 0xfe113001,
+ 0xfe142e00, 0xfe182bff, 0xfe1b29fe, 0xfe1f25fe,
+ 0xfefe, 0xfe251ffe, 0xfe291bfe, 0xff2b18fe,
+ 0x002e14fe, 0x013010ff, 0x03310dff, 0x05310a00,
+
+ 0xff0a2e09, 0xff0c2e07, 0xff0f2d05, 0xff122c03,
+ 0xfe152b02, 0xfe182901, 0xfe1b2700, 0xff1e24ff,
+ 0xff2121ff, 0xff241eff, 0x00261bff, 0x012818ff,
+ 0x022a15ff, 0x032c12ff, 0x052d0fff, 0x072d0c00,
+
+ 0xff0c2a0b, 0xff0e2a09, 0xff102a07, 0xff132905,
+ 0xff162803, 0xff182702, 0xff1b2501, 0xff1e2300,
+ 0x00202000, 0x01221d00, 0x01251bff, 0x032618ff,
+ 0x042815ff, 0x052913ff, 0x072a10ff, 0x092a0d00,
+
+ 0xff0d280c, 0xff0f280a, 0xff112808, 0xff142706,
+ 0xff162605, 0xff192503, 0x001b2302, 0x001d2201,
+ 0x011f1f01, 0x01221d00, 0x02231b00, 0x04241800,
+ 0x052616ff, 0x072713ff, 0x08271100, 0x0a280e00,
+
+ 0xff0e260d, 0xff10260b, 0xff122609, 0xff142508,
+ 0x00152506, 0x00182305, 0x001b2203, 0x011d2002,
+ 0x011f1f01, 0x02201d01, 0x03221b00, 0x04231801,
+ 0x06241600, 0x08251300, 0x09261100, 0x0b260f00,
+
+ 0xff0e250e, 0xff10250c, 0x0011250a, 0x00142408,
+ 0x00162307, 0x00182206, 0x011a2104, 0x011c2003,
+ 0x021e1e02, 0x03201c01, 0x04211a01, 0x05221801,
+ 0x07231600, 0x08241400, 0x0a241200, 0x0c241000,
+
+ 0x000e240e, 0x0010240c, 0x0013230a, 0x00142309,
+ 0x00162208, 0x01182106, 0x011a2005, 0x021b1f04,
+ 0x031d1d03, 0x041e1c02, 0x05201a01, 0x06211801,
+ 0x07221601, 0x09231400, 0x0a231300, 0x0c231100,
+
+ 0x000f220f, 0x0011220d, 0x0013220b, 0x0015210a,
+ 0x01162108, 0x01182007, 0x02191f06, 0x031a1e05,
+ 0x041c1c04, 0x051d1b03, 0x061f1902, 0x07201801,
+ 0x08211601, 0x0a211500, 0x0b221300, 0x0d221100,
+
+ 0x0010210f, 0x0011210e, 0x0013210c, 0x0114200b,
+ 0x01161f0a, 0x02171f08, 0x03181e07, 0x031a1d06,
+ 0x041c1c04, 0x051d1a04, 0x071d1903, 0x081e1802,
+ 0x091f1602, 0x0b1f1501, 0x0c211300, 0x0e201200,
+
+ 0x00102010, 0x0012200e, 0x0013200d, 0x01151f0b,
+ 0x01161f0a, 0x02171e09, 0x03191d07, 0x041a1c06,
+ 0x051b1b05, 0x061c1a04, 0x071d1903, 0x081e1703,
+ 0x0a1f1601, 0x0b1f1501, 0x0d201300, 0x0e201200,
+
+ 0x00102010, 0x00121f0f, 0x00141f0d, 0x01141f0c,
+ 0x02161e0a, 0x03171d09, 0x03181d08, 0x041a1c06,
+ 0x051b1b05, 0x061c1a04, 0x081c1903, 0x091d1703,
+ 0x0a1e1602, 0x0c1e1501, 0x0d1f1400, 0x0e1f1201,
+
+ 0x00111e11, 0x00131e0f, 0x01131e0e, 0x02151d0c,
+ 0x02161d0b, 0x03171c0a, 0x04181b09, 0x05191b07,
+ 0x061a1a06, 0x071b1905, 0x091b1804, 0x0a1c1703,
+ 0x0b1d1602, 0x0c1d1502, 0x0e1d1401, 0x0f1e1300,
+
+ 0x00111e11, 0x00131d10, 0x01141d0e, 0x02151c0d,
+ 0x0
[PATCH 17/17] [DO NOT MERGE]drm/sun4i: Change zpos of bottom VI plane
Change zpos of VI plane so it is above primary.
Clearly this works only if mixer supports only one VI plane, but it is
good enough for testing and developing.
Proper solution with zpos property should be developed instead.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 4d2b42804008..041b7136175c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -38,6 +38,8 @@ struct de2_fmt_info {
enum sun8i_csc_mode csc;
};
+static int lmap[] = {1, 0, 2, 3, 4};
+
static const struct de2_fmt_info de2_formats[] = {
{
.drm_fmt = DRM_FORMAT_ARGB,
@@ -294,13 +296,13 @@ void sun8i_mixer_ui_layer_enable(struct sun8i_mixer
*mixer,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
if (enable)
- val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(layer);
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[layer]);
else
val = 0;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL,
- SUN8I_MIXER_BLEND_PIPE_CTL_EN(layer), val);
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[layer]), val);
}
void sun8i_mixer_vi_layer_enable(struct sun8i_mixer *mixer,
@@ -321,13 +323,13 @@ void sun8i_mixer_vi_layer_enable(struct sun8i_mixer
*mixer,
SUN8I_MIXER_CHAN_VI_LAYER_ATTR_EN, val);
if (enable)
- val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(layer);
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[layer]);
else
val = 0;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL,
- SUN8I_MIXER_BLEND_PIPE_CTL_EN(layer), val);
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(lmap[layer]), val);
}
int sun8i_mixer_update_ui_layer_coord(struct sun8i_mixer *mixer,
@@ -411,10 +413,10 @@ int sun8i_mixer_update_ui_layer_coord(struct sun8i_mixer
*mixer,
state->dst.x1, state->dst.y1);
DRM_DEBUG_DRIVER("Layer destination size W: %d H: %d\n", dst_w, dst_h);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_COORD(layer),
+SUN8I_MIXER_BLEND_ATTR_COORD(lmap[layer]),
SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(layer),
+SUN8I_MIXER_BLEND_ATTR_INSIZE(lmap[layer]),
outsize);
return 0;
@@ -499,10 +501,10 @@ int sun8i_mixer_update_vi_layer_coord(struct sun8i_mixer
*mixer,
state->dst.x1, state->dst.y1);
DRM_DEBUG_DRIVER("Layer destination size W: %d H: %d\n", dst_w, dst_h);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_COORD(layer),
+SUN8I_MIXER_BLEND_ATTR_COORD(lmap[layer]),
SUN8I_MIXER_COORD(state->dst.x1, state->dst.y1));
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(layer),
+SUN8I_MIXER_BLEND_ATTR_INSIZE(lmap[layer]),
outsize);
return 0;
@@ -771,7 +773,7 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
SUN8I_MIXER_BLEND_COLOR_BLACK);
/* Fixed zpos for now */
- regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE, 0x43210);
+ regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE, 0x43201);
plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
for (i = 0; i < plane_cnt; i++)
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 08/29] drm/gma500: deprecate pci_get_bus_and_slot()
+dri-devel@lists.freedesktop.org
On 11/27/2017 11:57 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
>
> Add domain parameter to CDV_MSG_READ32, CDV_MSG_WRITE32, MRST_MSG_READ32,
> MRST_MSG_WRITE32, MDFLD_MSG_READ32, MDFLD_MSG_WRITE32.
>
> Extract pci_dev from struct drm_device and use pdev to find the domain
> number while calling pci_get_domain_bus_and_slot().
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/gpu/drm/gma500/cdv_device.c | 16 +---
> drivers/gpu/drm/gma500/gma_device.c | 4 +++-
> drivers/gpu/drm/gma500/mid_bios.c | 12 +---
> drivers/gpu/drm/gma500/psb_drv.c| 10 --
> drivers/gpu/drm/gma500/psb_drv.h| 18 ++
> 5 files changed, 39 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_device.c
> b/drivers/gpu/drm/gma500/cdv_device.c
> index 8745971..3a3bf75 100644
> --- a/drivers/gpu/drm/gma500/cdv_device.c
> +++ b/drivers/gpu/drm/gma500/cdv_device.c
> @@ -185,21 +185,22 @@ static int cdv_backlight_init(struct drm_device *dev)
> * for this and the MID devices.
> */
>
> -static inline u32 CDV_MSG_READ32(uint port, uint offset)
> +static inline u32 CDV_MSG_READ32(int domain, uint port, uint offset)
> {
> int mcr = (0x10<<24) | (port << 16) | (offset << 8);
> uint32_t ret_val = 0;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
> pci_write_config_dword(pci_root, 0xD0, mcr);
> pci_read_config_dword(pci_root, 0xD4, &ret_val);
> pci_dev_put(pci_root);
> return ret_val;
> }
>
> -static inline void CDV_MSG_WRITE32(uint port, uint offset, u32 value)
> +static inline void CDV_MSG_WRITE32(int domain, uint port, uint offset,
> +u32 value)
> {
> int mcr = (0x11<<24) | (port << 16) | (offset << 8) | 0xF0;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
> pci_write_config_dword(pci_root, 0xD4, value);
> pci_write_config_dword(pci_root, 0xD0, mcr);
> pci_dev_put(pci_root);
> @@ -216,11 +217,12 @@ static void cdv_init_pm(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> u32 pwr_cnt;
> + int domain = pci_domain_nr(dev->pdev->bus);
> int i;
>
> - dev_priv->apm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
> + dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
> PSB_APMBA) & 0x;
> - dev_priv->ospm_base = CDV_MSG_READ32(PSB_PUNIT_PORT,
> + dev_priv->ospm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
> PSB_OSPMBA) & 0x;
>
> /* Power status */
> @@ -251,7 +253,7 @@ static void cdv_errata(struct drm_device *dev)
>* Bonus Launch to work around the issue, by degrading
>* performance.
>*/
> - CDV_MSG_WRITE32(3, 0x30, 0x08027108);
> + CDV_MSG_WRITE32(pci_domain_nr(dev->pdev->bus), 3, 0x30, 0x08027108);
> }
>
> /**
> diff --git a/drivers/gpu/drm/gma500/gma_device.c
> b/drivers/gpu/drm/gma500/gma_device.c
> index 4a295f9..a7fb6de 100644
> --- a/drivers/gpu/drm/gma500/gma_device.c
> +++ b/drivers/gpu/drm/gma500/gma_device.c
> @@ -19,7 +19,9 @@
> void gma_get_core_freq(struct drm_device *dev)
> {
> uint32_t clock;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root =
> + pci_get_domain_bus_and_slot(pci_domain_nr(dev->pdev->bus),
> + 0, 0);
> struct drm_psb_private *dev_priv = dev->dev_private;
>
> /*pci_write_config_dword(pci_root, 0xD4, 0x00C32004);*/
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c
> b/drivers/gpu/drm/gma500/mid_bios.c
> index d75ecb3..5c23d4e 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -32,7 +32,9 @@
> static void mid_get_fuse_settings(struct drm_device *dev)
> {
> struct drm_psb_private *dev_priv = dev->dev_private;
> - struct pci_dev *pci_root = pci_get_bus_and_slot(0, 0);
> + struct pci_dev *pci_root =
> + pci_get_domain_bus_and_slot(pci_domain_nr(dev->pdev->bus),
> + 0, 0);
> uint32_t fuse_value = 0;
> uint32_t fuse_value_tmp = 0;
>
> @@ -104,7 +106,9 @@ static void mid_get_fuse_settings(struct drm_device *dev)
> static void mid_get_pci_revID(struct drm_psb_private *dev_priv)
> {
> uint32_t platform_rev_id = 0;
> - struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI
[PATCH 10/17] drm/sun4i: Add scaler configuration to DE2 mixers
No all SoCs support scaling on all channels. For example, V3s support
scaling only on VI channels. Because of that, add additional
configuration bitmask which tells which channel support scaler.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index dc97351be973..291dd8806444 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -576,6 +576,7 @@ static int sun8i_mixer_remove(struct platform_device *pdev)
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
+ .scaler_mask = 0x3,
};
static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 572ef184a21a..ad5aef5846ae 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -139,6 +139,7 @@
struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
+ int scaler_mask;
};
struct sun8i_mixer {
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/guc: Fix doc reference to intel_guc_fw.c
Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
The file has been renamed.
Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
intel_guc_fw.c")
Cc: Michal Wajdeczko
Signed-off-by: Jonathan Neuschäfer
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee0313c1c..e21698e16534 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,10 @@ GuC
GuC-specific firmware loader
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:doc: GuC-specific firmware loader
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
GuC-based command submission
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/17] drm/sun4i: Refactor DE2 code
Since the time initial DE2 driver was written, some knowledge was gained
what setting are really necessary and what most of the magic values
mean.
This commit renames some of the macro names to better fit the real
meaning, replace default values with self explaining macros where
possible and removes settings which are not really needed.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 65 +++--
drivers/gpu/drm/sun4i/sun8i_mixer.h | 31 --
2 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index cb193c5f1686..015943c0ed5a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -44,7 +44,8 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
/* Currently the first UI channel is used */
int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", layer, chan);
+ DRM_DEBUG_DRIVER("%sabling layer %d in channel %d\n",
+enable ? "En" : "Dis", layer, chan);
if (enable)
val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
@@ -55,15 +56,14 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
- /* Set the alpha configuration */
- regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF);
+ if (enable)
+ val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan);
+ else
+ val = 0;
+
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF);
+ SUN8I_MIXER_BLEND_PIPE_CTL,
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan), val);
}
static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
@@ -71,15 +71,15 @@ static int sun8i_mixer_drm_format_to_layer(struct drm_plane
*plane,
{
switch (format) {
case DRM_FORMAT_ARGB:
- *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB;
+ *mode = SUN8I_MIXER_FBFMT_ARGB;
break;
case DRM_FORMAT_XRGB:
- *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_XRGB;
+ *mode = SUN8I_MIXER_FBFMT_XRGB;
break;
case DRM_FORMAT_RGB888:
- *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888;
+ *mode = SUN8I_MIXER_FBFMT_RGB888;
break;
default:
@@ -107,7 +107,7 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
*mixer,
state->crtc_h));
DRM_DEBUG_DRIVER("Updating blender size\n");
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_ATTR_INSIZE(0),
+SUN8I_MIXER_BLEND_ATTR_INSIZE(chan),
SUN8I_MIXER_SIZE(state->crtc_w,
state->crtc_h));
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
@@ -173,6 +173,7 @@ int sun8i_mixer_update_layer_formats(struct sun8i_mixer
*mixer,
return ret;
}
+ val <<= SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET;
regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK, val);
@@ -247,6 +248,7 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
struct sun8i_mixer *mixer;
struct resource *res;
void __iomem *regs;
+ int plane_cnt;
int i, ret;
/*
@@ -325,27 +327,26 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_CTL,
SUN8I_MIXER_GLOBAL_CTL_RT_EN);
- /* Initialize blender */
- regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_FCOLOR_CTL,
-SUN8I_MIXER_BLEND_FCOLOR_CTL_DEF);
- regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PREMULTIPLY,
-SUN8I_MIXER_BLEND_PREMULTIPLY_DEF);
+ /* Set background color to black */
regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR,
-SUN8I_MIXER_BLEND_BKCOLOR_DEF);
- regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_MODE(0),
-SUN8I_MIXER_BLEND_MODE_D
Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)
On 2017-11-27 11:00 +0200, Laurent Pinchart wrote:
> On Monday, 27 November 2017 06:05:03 EET Archit Taneja wrote:
> > On 2017-11-05 11:41 -0500, Nick Bowler wrote:
[...]
> > > Bisection implicates the following commit:
> > >
> > > 181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
> > > commit 181e0ef092a4952aa523c5b9cb21394cf43bcd46
> > > Author: Laurent Pinchart
> > > Date: Mon Mar 6 01:35:57 2017 +0200
> > >
> > > drm: bridge: dw-hdmi: Fix the PHY power up sequence
[...]
> >
> > The two main things the commit below does it to a) correctly wait on the
> > TX_PHY_LOCK bit to be asserted and b) use usleep_range() instead of
> > udelay().
>
> Another difference is that the PWDN and TMDS signals, in theory needed for
> Gen1 PHYs only, are not set anymore for Gen2 PHYs. Nick, could you test the
> following change to see if it makes a difference ?
I do not notice any difference with this change applied on top of Linux
4.15-rc1.
A note about the test setup: I had to remove the test equipment so I
no longer have any information about the video mode from the sink side
(like in the photos). Thus, with the current setup, I am using the
presense or absense of audio to determine whether the issue is present
or not.
The test procedure is: boot up, start music, then hotplug the hdmi four
times. If sound is heard after all four connections, PASS; otherwise FAIL.
- I retested on 4.15-rc1 to confirm that the issue is still present (it is).
- I applied the functional revert from earlier on top of 4.15-rc1 and the
problem is fixed.
- Returning to 4.15-rc1 and applying this next patch -- the issue is
present again (no change in behaviour compared to 4.15-rc1).
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/
> bridge/synopsys/dw-hdmi.c
> index b172139502d6..1c18ff1bf24a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1104,14 +1104,14 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
> unsigned int i;
> u8 val;
>
> - if (phy->gen == 1) {
> - dw_hdmi_phy_enable_powerdown(hdmi, false);
> + dw_hdmi_phy_enable_powerdown(hdmi, false);
>
> - /* Toggle TMDS enable. */
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_tmds(hdmi, 1);
> + /* Toggle TMDS enable. */
> + dw_hdmi_phy_enable_tmds(hdmi, 0);
> + dw_hdmi_phy_enable_tmds(hdmi, 1);
> +
> + if (phy->gen == 1)
> return 0;
> - }
>
> dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> dw_hdmi_phy_gen2_pddq(hdmi, 0);
>
> > I don't see (b) being a problem. About (a), it's possible that the bit above
> > is interpreted differently on a rockchip SoC versus a renesas chip. Could
> > you print the value of HDMI_PHY_STAT0 that's read back?
[...]
> > As an experiment, could you forcefully return 0 instead of -ETIMEDOUT and
> > see if things return back to normal?
I did both of these tests at once by applying the below patch on top of
4.15-rc1. There is no change in behaviour compared to 4.15-rc1 (except
for the added printouts).
With this, every time after inserting the cable the following is printed:
[ 128.002965] dwhdmi-rockchip ff98.hdmi: 0: HDMI_PHY_STAT0: f2
[ 128.004614] dwhdmi-rockchip ff98.hdmi: 1: HDMI_PHY_STAT0: f3
[ 128.013752] dwhdmi-rockchip ff98.hdmi: 0: HDMI_PHY_STAT0: f2
[ 128.015605] dwhdmi-rockchip ff98.hdmi: 1: HDMI_PHY_STAT0: f3
And there is no difference in output between working and non-working
cases. I've attached the full log; I manually logged extra messages
to give context from the test procedure:
"hdmi (not) working" - after bootup or connecting the cable
(indicating test pass/fail)
"hdmi disconnect"- after unplugging the cable.
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..0358f6020fb4 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1118,7 +1118,11 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
/* Wait for PHY PLL lock */
for (i = 0; i < 5; ++i) {
- val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
+ val = hdmi_readb(hdmi, HDMI_PHY_STAT0);
+
+ dev_info(hdmi->dev, "%u: HDMI_PHY_STAT0: %.2hhx\n", i, val);
+
+ val &= HDMI_PHY_TX_PHY_LOCK;
if (val)
break;
@@ -1127,7 +1131,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
if (!val) {
dev_err(hdmi->dev, "PHY PLL failed to lock\n");
- return -ETIMEDOUT;
+ return 0;
}
dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
Let me know if there's anything else I should try.
Thanks,
Nick
aidos-hdmi-stat0.log.gz
Description: Binary data
[PATCH] drm/i915: Mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 141432
Addresses-Coverity-ID: 141433
Addresses-Coverity-ID: 141434
Addresses-Coverity-ID: 141435
Addresses-Coverity-ID: 141436
Addresses-Coverity-ID: 1357360
Addresses-Coverity-ID: 1357403
Addresses-Coverity-ID: 1357433
Addresses-Coverity-ID: 1392622
Addresses-Coverity-ID: 1415273
Addresses-Coverity-ID: 1435752
Addresses-Coverity-ID: 1441500
Addresses-Coverity-ID: 1454596
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/intel_cdclk.c | 4
drivers/gpu/drm/i915/intel_display.c| 2 ++
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
drivers/gpu/drm/i915/intel_sdvo.c | 6 ++
7 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3a140ee..326cf16 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1977,6 +1977,7 @@ int i915_gem_fault(struct vm_fault *vmf)
ret = VM_FAULT_SIGBUS;
break;
}
+ /* fall through */
case -EAGAIN:
/*
* EAGAIN means the gpu is hung and we'll wait for the error
@@ -2644,7 +2645,7 @@ static void *i915_gem_object_map(const struct
drm_i915_gem_object *obj,
switch (type) {
default:
MISSING_CASE(type);
- /* fallthrough to use PAGE_KERNEL anyway */
+ /* fall through - To use PAGE_KERNEL anyway */
case I915_MAP_WB:
pgprot = PAGE_KERNEL;
break;
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index b2a6d62..5879cd3 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -316,6 +316,7 @@ static void pnv_get_cdclk(struct drm_i915_private *dev_priv,
break;
default:
DRM_ERROR("Unknown pnv display core clock 0x%04x\n", gcfgc);
+ /* fall through */
case GC_DISPLAY_CLOCK_133_MHZ_PNV:
cdclk_state->cdclk = 13;
break;
@@ -1110,6 +,7 @@ static int bxt_de_pll_vco(struct drm_i915_private
*dev_priv, int cdclk)
switch (cdclk) {
default:
MISSING_CASE(cdclk);
+ /* fall through */
case 144000:
case 288000:
case 384000:
@@ -1134,6 +1136,7 @@ static int glk_de_pll_vco(struct drm_i915_private
*dev_priv, int cdclk)
switch (cdclk) {
default:
MISSING_CASE(cdclk);
+ /* fall through */
case 79200:
case 158400:
case 316800:
@@ -1592,6 +1595,7 @@ static int cnl_cdclk_pll_vco(struct drm_i915_private
*dev_priv, int cdclk)
switch (cdclk) {
default:
MISSING_CASE(cdclk);
+ /* fall through */
case 168000:
case 336000:
ratio = dev_priv->cdclk.hw.ref == 19200 ? 35 : 28;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 878acc4..1f7907f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9049,6 +9049,7 @@ static bool hsw_get_transcoder_state(struct intel_crtc
*crtc,
switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
default:
WARN(1, "unknown pipe linked to edp transcoder\n");
+ /* fall through */
case TRANS_DDI_EDP_INPUT_A_ONOFF:
case TRANS_DDI_EDP_INPUT_A_ON:
trans_edp_pipe = PIPE_A;
@@ -10751,6 +10752,7 @@ static bool check_digital_port_conflicts(struct
drm_atomic_state *state)
case INTEL_OUTPUT_UNKNOWN:
if (WARN_ON(!HAS_DDI(to_i915(dev
break;
+ /* fall through */
case INTEL_OUTPUT_DP:
case INTEL_OUTPUT_HDMI:
case INTEL_OUTPUT_EDP:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7bc60c8..4c3696c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1149,6 +1149,7 @@ enc_to_dig_port(struct drm_encoder *encoder)
switch (intel_encoder->type) {
case INTEL_OUTPUT_UNKNOWN:
WARN_ON(!HAS_DDI(to_i915(encoder->dev)));
+ /* fall through */
case INTEL_OUTPUT_DP:
case INTEL_OUTPUT_EDP:
case INTEL_OUTPUT_HDMI:
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ab5bf4e..d02f37d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@
linux-4.15-rc1/drivers/gpu/drm/i915/gvt/cmd_parser.c:1640: poor error checking ?
Hello there, linux-4.15-rc1/drivers/gpu/drm/i915/gvt/cmd_parser.c:1640]: (style) Checking if unsigned variable 'bb_size' is less than zero. Source code is /* get the size of the batch buffer */ bb_size = find_bb_size(s); if (bb_size < 0) return -EINVAL; but static int find_bb_size(struct parser_exec_state *s) so the code isn't properly checking the return value. Suggest code rework. Regards David Binderman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
It seems that I got no responses so far for clarification requests according to the documentation in a direction I hoped for. >>> >>> That's because you are pretty unresponsive to direction. >> >> From which places did you get this impression? > > Perhaps from the text that you have written only four lines below. > All comments are dismissed as "the usual mixture of disagreements and > acceptance". A mixture will always evolve. * Some acceptance might not need further considerations. * But the disagreements are remembered differently. They have got a potential for further improvements in some areas. > If you look at the patches sent by others, who learn from > the feedback provided to them, I am also learning to some degree continuously. > there are not so many responses on the disagreements side. How do you think about to look at the details for such an observation? > So the mixture is not usual. I find that it can be also a matter of statistics. > Since you send lots of patches on the same issues, Yes. - I am trying to fix some implementation details by the means of source code analysis and corresponding transformation. The patch count is still growing. > there should be no disagreements at all at this point. I got an other impression. The probability for disagreements is increasing in relation to the number of contributors to which I show change possibilities. There are also other open issues remaining which can get another solution somehow. Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/guc: Fix doc reference to intel_guc_fw.c
On Tue, 28 Nov 2017 07:50:52 +0100, Jonathan Neuschäfer
wrote:
Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
The file has been renamed.
Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
intel_guc_fw.c")
Cc: Michal Wajdeczko
Signed-off-by: Jonathan Neuschäfer
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee0313c1c..e21698e16534 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,10 @@ GuC
GuC-specific firmware loader
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:doc: GuC-specific firmware loader
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
GuC-based command submission
+ Ville
Well, this will fix sphinx error, but in my opinion it will not make
i915 documentation any better. See my earlier patch/comments in [1].
So maybe better to wait for other comments which way to go.
Thanks for the patch,
Michal
[1] https://patchwork.freedesktop.org/patch/188424/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/18] drm/sun4i: Force the mixer rate at 150MHz
On Mon, Nov 27, 2017 at 05:07:04PM +0100, Jernej Škrabec wrote: > Hi Maxime, > > Dne ponedeljek, 27. november 2017 ob 16:41:29 CET je Maxime Ripard napisal(a): > > It seems like the mixer can only run properly when clocked at 150MHz. In > > order to have something more robust than simply a fire-and-forget > > assigned-clocks-rate, let's put that in the code. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/sun4i/sun8i_mixer.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c > > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index cb193c5f1686..c0cdccf772a2 > > 100644 > > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c > > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c > > @@ -315,6 +315,13 @@ static int sun8i_mixer_bind(struct device *dev, struct > > device *master, } > > clk_prepare_enable(mixer->mod_clk); > > > > + /* > > +* It seems that we need to enforce that rate for whatever > > +* reason for the mixer to be functional. Make sure it's the > > +* case. > > +*/ > > + clk_set_rate(mixer->mod_clk, 15000); > > + > > H3 mixer works at much higher rate and if we want to support tv out, it must > be dividable by 432 MHz, so either 432 MHz or maybe even 864 MHz. > > We talked about that few months ago. > > I guess this should be read from mixer configuration structure. That works for me. Actually, I didn't need it at all for the LVDS output on the A83t, the default seems to work just fine. Do you know what it's related to? Maybe we can make that a bit more dynamic? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/18] drm/sun4i: Add A83T support
Hi, On Tue, Nov 28, 2017 at 12:19:44AM +0800, Chen-Yu Tsai wrote: > On Mon, Nov 27, 2017 at 11:41 PM, Maxime Ripard > wrote: > > Add support for the A83T display pipeline. > > > > Reviewed-by: Chen-Yu Tsai > > Signed-off-by: Maxime Ripard > > --- > > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++ > > Rob mentioned that he'd like to see these multiple one-liners be > in a separate patch. I'll change that. > > > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++ > > drivers/gpu/drm/sun4i/sun4i_tcon.c| 5 + > > drivers/gpu/drm/sun4i/sun8i_mixer.c | 4 > > 4 files changed, 14 insertions(+) > > Also not sure why you have two patches with the same subject. Yeah, it's a rebase gone wrong... The second one was meant to be folded into this one. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/18] drm/sun4i: Add A83T support
Hi,
On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
> Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard napisal(a):
> > Add support for the A83T display pipeline.
> >
> > Reviewed-by: Chen-Yu Tsai
> > Signed-off-by: Maxime Ripard
> > ---
> > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
> > drivers/gpu/drm/sun4i/sun4i_tcon.c| 5 +
> > drivers/gpu/drm/sun4i/sun8i_mixer.c | 4
> > 4 files changed, 14 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > d4259a4f5171..d6b52e5c48c0 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -93,6 +93,7 @@ Required properties:
> > * allwinner,sun6i-a31s-tcon
> > * allwinner,sun7i-a20-tcon
> > * allwinner,sun8i-a33-tcon
> > + * allwinner,sun8i-a83t-tcon-lcd
> > * allwinner,sun8i-v3s-tcon
> > - reg: base address and size of memory-mapped region
> > - interrupts: interrupt associated to this IP
> > @@ -224,6 +225,7 @@ supported.
> >
> > Required properties:
> >- compatible: value must be one of:
> > +* allwinner,sun8i-a83t-de2-mixer
>
> What will be the name of the second mixer, once support for HDMI is added?
> Should we start directly with 0 and 1 postfix ?
What are the differences exactly without the two mixers?
I was hoping to be able to cover them all using properties, indices
are usually pretty badly received in compatibles.
> > static const struct of_device_id sun8i_mixer_of_table[] = {
> > {
> > + .compatible = "allwinner,sun8i-a83t-de2-mixer",
> > + .data = &sun8i_v3s_mixer_cfg,
> > + },
> > + {
>
> Maybe you want to squash 12 patch since this works only by luck.
Yeah, I totally meant to do that :)
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
> How many times have I told you to include the reason for > your patches in your proposed commit message? It might be useful to look again. > Too often. I answered this feedback to some degree. > Many people do not know that a generic kmalloc does a > dump_stack() on OOM. This is another interesting information, isn't it? It is expected that the function “devm_kzalloc” has got a similar property. > That information should be part of the commit message. How do you think about to provide it also in any reference documentation in a clearer way? I would be more confident then to copy it into my messages. Do you want that I take your current answer as an official note for my work (instead of waiting for adjustments of other areas)? > Also removing the printk code reduces overall code size. Such an effect can be nice if the involved contributors can agree on the deletion of questionable error messages at all. > The actual size reduction should be described in the > commit message too. For which hardware and software combinations would you like to see facts there? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky: On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: On 11/23/2017 03:11 AM, Christian König wrote: Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: On 11/22/2017 05:09 AM, Christian König wrote: Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: On 11/21/2017 08:34 AM, Christian König wrote: Hi Boris, attached are two patches. The first one is a trivial fix for the infinite loop issue, it now correctly aborts the fixup when it can't find address space for the root window. The second is a workaround for your board. It simply checks if there is exactly one Processor Function to apply this fix on. Both are based on linus current master branch. Please test if they fix your issue. Yes, they do fix it but that's because the feature is disabled. Do you know what the actual problem was (on Xen)? I still haven't understood what you actually did with Xen. When you used PCI pass through with those devices then you have made a major configuration error. When the problem happened on dom0 then the explanation is most likely that some PCI device ended up in the configured space, but the routing was only setup correctly on one CPU socket. The problem is that dom0 can be (and was in my case() booted with less than full physical memory and so the "rest" of the host memory is not necessarily reflected in iomem. Your patch then tried to configure that memory for MMIO and the system hang. And so my guess is that this patch will break dom0 on a single-socket system as well. Oh, thanks! I've thought about that possibility before, but wasn't able to find a system which actually does that. May I ask why the rest of the memory isn't reported to the OS? That memory doesn't belong to the OS (dom0), it is owned by the hypervisor. Sounds like I can't trust Linux resource management and probably need to read the DRAM config to figure things out after all. My question is whether what you are trying to do should ever be done for a guest at all (any guest, not necessarily Xen). The issue is probably that I don't know enough about Xen: What exactly is dom0? My understanding was that dom0 is the hypervisor, but that seems to be incorrect. The issue is that under no circumstances *EVER* a virtualized guest should have access to the PCI devices marked as "Processor Function" on AMD platforms. Otherwise it is trivial to break out of the virtualization. When dom0 is something like the system domain with all hardware access then the approach seems legitimate, but then the hypervisor should report the stolen memory to the OS using the e820 table. When the hypervisor doesn't do that and the Linux kernel isn't aware that there is memory at a given location mapping PCI space there will obviously crash the hypervisor. Possible solutions as far as I can see are either disabling this feature when we detect that we are a Xen dom0, scanning the DRAM settings to update Linux resource handling or fixing Xen to report stolen memory to the dom0 OS as reserved. Opinions? You are right, these functions are not exposed to a regular guest. I think for dom0 (which is a special Xen guest, with additional privileges) we may be able to add a reserved e820 region for host memory that is not assigned to dom0. Let me try it on Monday (I am out until then). One thing I realized while looking at solution for Xen dom0 is that this patch may cause problems for memory hotplug. Good point. My assumption was that when you got an BIOS which can handle memory hotplug then you also got an BIOS which doesn't need this fixup. But I've never validated that assumption. What happens if new memory is added to the system and we have everything above current memory set to MMIO? In theory the BIOS would search for address space and won't find anything, so the hotplug operation should fail even before it reaches the kernel in the first place. In practice I think that nobody ever tested if that works correctly. So I'm pretty sure the system would just crash. How about the attached patch? It limits the newly added MMIO space to the upper 256GB of the address space. That should still be enough for most devices, but we avoid both issues with Xen dom0 as most likely problems with memory hotplug as well. Christian. -boris >From 586bd9d67ebb6ca48bd0a6b1bd9203e94093cc8e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= Date: Tue, 28 Nov 2017 10:02:35 +0100 Subject: [PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This avoids problems with Xen which hides some memory resources from the OS and potentially also allows memory hotplug while this fixup is enabled. Signed-off-by: Christian König --- arch/x86/pci/fixup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ar
Re: 4.9.62: intermittent flicker after upgrade from 4.9.61
On Fri, Nov 24, 2017 at 07:48:22AM +0100, Greg KH wrote:
> On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote:
> > Rainer Fiebig wrote:
> > > Maarten Lankhorst wrote:
> > >> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
> > >>> Jani Nikula wrote:
> > On Sun, 19 Nov 2017, Greg KH wrote:
> > > On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
> > >> Greg KH wrote:
> > >>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
> > Greg KH wrote:
> > > On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
> > >> Greg KH wrote:
> > >>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
> > Hi!
> >
> > Hopefully the right addressee.
> >
> > Encountered two bad backports which cause screen-flicker.
> > dmesg shows:
> >
> > ...
> > [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO
> > underrun
> > [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A
> > FIFO underrun
> > [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO
> > underrun
> > [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B
> > FIFO underrun
> > ...
> >
> > CPU: Intel Core i3 (Clarkdale/Ironlake)
> >
> > The backports are:
> >
> > - diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 49de476..277a802 100644
> > - diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index a19ec06..3ce9ba3 100644
> >
> > After reversing them the flicker is gone, no more messages in
> > dmesg. All
> > else OK so far.
> > >>> So which commit was the one that caused the problem? I will be
> > >>> glad to
> > >>> revert it.
> > >>>
> > >>> thanks,
> > >>>
> > >>> greg k-h
> > >>>
> > >>>
> > >> I started by reverting the more complex one first ("index
> > >> 49de476..277a802100644"). But the kernel wouldn't compile then.
> > > What git commit id is that? I don't see those ids in the
> > > 4.9-stable
> > > tree.
> > >
> > >> So I also reverted "index a19ec06..3ce9ba3 100644". After that
> > >> the
> > >> kernel compiled just fine and the problems were gone (still are).
> > > Same here, what git commit id was this?
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > OK, no mistake. IIRC, I took the patches (and the IDs) from the
> > changelog for patch-4.9.62. I've attached both, so you can check
> > yourself.
> >
> > I've also applied a freshly downloaded patch-4.9.62 to a freshly
> > expanded 4.9 and re-compiled. The flicker is there. I haven't yet
> > reverted the two patches but I'm confident that after having done
> > so the
> > flicker will be gone. If not I'll let you know.
> >
> > As a good news: 4.14 is *not* affected. So to me it seems those two
> > patches are part of sort of a package and can not be backported
> > alone.
> >
> > So long!
> > Rainer Fiebig
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 49de476..277a802 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -27,6 +27,7 @@
> >
> > #include
> > #include
> > +#include
> > #include "i915_drv.h"
> > #include "intel_drv.h"
> > #include "../../../platform/x86/intel_ips.h"
> > @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const
> > struct drm_i915_private *dev_priv,
> > const struct intel_crtc *intel_crtc,
> > int level,
> > struct intel_crtc_state *cstate,
> > - struct intel_plane_state *pristate,
> > - struct intel_plane_state *sprstate,
> > - struct intel_plane_state *curstate,
> > + const struct intel_plane_state
> > *pristate,
> > + const struct intel_plane_state
> > *sprstate,
> > + const struct intel_plane_state
> > *curstate,
> >
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Tue, 28 Nov 2017, SF Markus Elfring wrote: > It seems that I got no responses so far for clarification requests > according to the documentation in a direction I hoped for. > >>> > >>> That's because you are pretty unresponsive to direction. > >> > >> From which places did you get this impression? > > > > Perhaps from the text that you have written only four lines below. > > All comments are dismissed as "the usual mixture of disagreements and > > acceptance". > > A mixture will always evolve. > > * Some acceptance might not need further considerations. > > * But the disagreements are remembered differently. > They have got a potential for further improvements in some areas. > > > > If you look at the patches sent by others, who learn from > > the feedback provided to them, > > I am also learning to some degree continuously. > > > > there are not so many responses on the disagreements side. > > How do you think about to look at the details for such an observation? > > > > So the mixture is not usual. > > I find that it can be also a matter of statistics. > > > > Since you send lots of patches on the same issues, > > Yes. - I am trying to fix some implementation details by the means > of source code analysis and corresponding transformation. > The patch count is still growing. > > > > there should be no disagreements at all at this point. > > I got an other impression. The probability for disagreements is increasing > in relation to the number of contributors to which I show change > possibilities. No. You should learn from the previous submissions what concerns people have and address them up front. julia > > There are also other open issues remaining which can get another > solution somehow. > > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Tue, 28 Nov 2017, SF Markus Elfring wrote: > > How many times have I told you to include the reason for > > your patches in your proposed commit message? > > It might be useful to look again. > > > > Too often. > > I answered this feedback to some degree. > > > > Many people do not know that a generic kmalloc does a > > dump_stack() on OOM. > > This is another interesting information, isn't it? > > It is expected that the function “devm_kzalloc” has got a similar property. You don't have to expect this. Go look at the definition of devm_kzalloc and see whether it has the property or not. > For which hardware and software combinations would you like to see > facts there? This is not for Joe to decide, it's for the person who receives the patch to decide. You could start with the ones for which the code actually compiles, using the standard make file and no special options, and a recent version of gcc. julia___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors
https://bugzilla.kernel.org/show_bug.cgi?id=197925 beniwtv (beni...@relamp.tk) changed: What|Removed |Added CC||beni...@relamp.tk --- Comment #2 from beniwtv (beni...@relamp.tk) --- I have similar problems as 2) and 3) on Polaris hardware (AMD RX 480 8GB reference card) since switching to the 4.15 DC implementation (either self-compiled or Kernel provided by Manjaro). Every time display settings are changed from the default I'm currently running, or if the monitors go to idle (blank), one or more monitors will report "No signal". For me however, no amount of changing settings will get them back (though they will light up shortly after changing a setting). Previous Kernels + DC patches did not exhibit this issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata
Hi Brian,
On 11/28/2017 02:05 AM, Brian Norris wrote:
> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> parent driver might need to own this. Instead, let's return our
> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
And many thanks for this cleanup.
(please update the headline with "synopsys")
Successfully tested on stm.
Acked-by: Philippe Cornu
Many thanks,
Philippe :-)
>
> Signed-off-by: Brian Norris
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36
> ++-
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 14 +++
> include/drm/bridge/dw_mipi_dsi.h | 17 -
> 3 files changed, 33 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4fd66ec..c39c7dce20ed 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -922,8 +922,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dsi->bridge.of_node = pdev->dev.of_node;
> #endif
>
> - dev_set_drvdata(dev, dsi);
> -
> return dsi;
> }
>
> @@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi
> *dsi)
> /*
>* Probe/remove API, used from platforms based on the DRM bridge API.
>*/
> -int dw_mipi_dsi_probe(struct platform_device *pdev,
> - const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_probe(struct platform_device *pdev,
> + const struct dw_mipi_dsi_plat_data *plat_data)
> {
> - struct dw_mipi_dsi *dsi;
> -
> - dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> - if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> -
> - return 0;
> + return __dw_mipi_dsi_probe(pdev, plat_data);
> }
> EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
>
> -void dw_mipi_dsi_remove(struct platform_device *pdev)
> +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
> {
> - struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
> -
> mipi_dsi_host_unregister(&dsi->dsi_host);
>
> __dw_mipi_dsi_remove(dsi);
> @@ -961,31 +952,30 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
> /*
>* Bind/unbind API, used from platforms based on the component framework.
>*/
> -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder
> *encoder,
> - const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
> + const struct dw_mipi_dsi_plat_data *plat_data)
> {
> struct dw_mipi_dsi *dsi;
> int ret;
>
> dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> + return dsi;
>
> ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
> if (ret) {
> - dw_mipi_dsi_remove(pdev);
> + dw_mipi_dsi_remove(dsi);
> DRM_ERROR("Failed to initialize bridge with drm\n");
> - return ret;
> + return ERR_PTR(ret);
> }
>
> - return 0;
> + return dsi;
> }
> EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
>
> -void dw_mipi_dsi_unbind(struct device *dev)
> +void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
> {
> - struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
> -
> __dw_mipi_dsi_remove(dsi);
> }
> EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index e5b6310240fe..7ed0ef7f6ec2 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -66,6 +66,7 @@ enum dsi_color {
> struct dw_mipi_dsi_stm {
> void __iomem *base;
> struct clk *pllref_clk;
> + struct dw_mipi_dsi *dsi;
> };
>
> static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
> @@ -318,21 +319,24 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
> *pdev)
> dw_mipi_dsi_stm_plat_data.base = dsi->base;
> dw_mipi_dsi_stm_plat_data.priv_data = dsi;
>
> - ret = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
> - if (ret) {
> + platform_set_drvdata(pdev, dsi);
> +
> + dsi->dsi = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
> + if (IS_ERR(dsi->dsi)) {
> DRM_ERROR("Failed to initialize mipi dsi host\n");
> clk_disable_unprepare(dsi->pllref_clk);
> + return PTR_ERR(dsi->dsi);
> }
>
> - return ret;
> + return 0;
> }
>
> static int dw_mipi_dsi_stm_remove(struct platform_device *pdev)
> {
> - struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
> + struct dw_mipi_dsi_stm *dsi = platform_get_drvdata(pdev);
>
> clk_disable_unprepare(dsi->pllref_clk);
> - dw_mipi_dsi_remove(pdev);
> +
Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel
On 2017-11-28 06:43 AM, Christian Zigotzky wrote: > Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB > enabled? I doubt SWIOTLB provides any benefit for you. Can you test if Christian's patch fixes the problem with SWIOTLB disabled? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
>> I got an other impression. The probability for disagreements is increasing >> in relation to the number of contributors to which I show change >> possibilities. > > No. You should learn from the previous submissions what concerns people > have and address them up front. The concerns can vary as contributors and changes are different. How would you like to “address” the data structure for a default allocation failure report finally? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: use sun4i_tcon_of_table to check if a device node is a TCON
Hi,
On Mon, Nov 27, 2017 at 04:46:32PM +0800, Chen-Yu Tsai wrote:
> The sun4i DRM driver maintains a list of compatible strings it uses to
> check if a device node within the display component graph is a TCON.
> The TCON driver also has this list, used to bind the TCON driver to
> the device. These two lists are identical.
>
> Instead of maintaining two identical lists, export the list from the
> TCON driver for the DRM driver to use.
>
> Suggested-by: Rob Herring
> Signed-off-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
> 3 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 75c76cdd82bc..49215d91c853 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -187,13 +187,7 @@ static bool sun4i_drv_node_is_frontend(struct
> device_node *node)
>
> static bool sun4i_drv_node_is_tcon(struct device_node *node)
> {
> - return of_device_is_compatible(node, "allwinner,sun4i-a10-tcon") ||
> - of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
> - of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
> - of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
> - of_device_is_compatible(node, "allwinner,sun7i-a20-tcon") ||
> - of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
> - of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
> + return !!of_match_node(sun4i_tcon_of_table, node);
> }
>
> static int compare_of(struct device *dev, void *data)
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index e122f5b2a395..a1ed462c2430 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -900,7 +900,8 @@ static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
> /* nothing is supported */
> };
>
> -static const struct of_device_id sun4i_tcon_of_table[] = {
> +/* sun4i_drv uses this list to check if a device node is a TCON */
> +const struct of_device_id sun4i_tcon_of_table[] = {
> { .compatible = "allwinner,sun4i-a10-tcon", .data = &sun4i_a10_quirks },
> { .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks },
> { .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks },
> @@ -911,6 +912,7 @@ static const struct of_device_id sun4i_tcon_of_table[] = {
> { }
> };
> MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
> +EXPORT_SYMBOL(sun4i_tcon_of_table);
>
> static struct platform_driver sun4i_tcon_platform_driver = {
> .probe = sun4i_tcon_probe,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index f61bf6d83b4a..839266a38505 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -197,4 +197,6 @@ void sun4i_tcon_mode_set(struct sun4i_tcon *tcon,
> void sun4i_tcon_set_status(struct sun4i_tcon *crtc,
> const struct drm_encoder *encoder, bool enable);
>
> +extern const struct of_device_id sun4i_tcon_of_table[];
> +
I'm not very fond of that approach. Maybe we can place the structure
in the tcon header?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
>>> Many people do not know that a generic kmalloc does a >>> dump_stack() on OOM. >> >> This is another interesting information, isn't it? >> >> It is expected that the function “devm_kzalloc” has got a similar property. > > > You don't have to expect this. Go look at the definition of devm_kzalloc > and see whether it has the property or not. I find that the corresponding documentation of these programming interfaces is incomplete for a desired format which could be different than C source code. https://elixir.free-electrons.com/linux/v4.15-rc1/source/include/linux/device.h#L657 https://elixir.free-electrons.com/linux/v4.15-rc1/source/drivers/base/devres.c#L763 https://www.kernel.org/doc/html/latest/driver-api/basics.html#c.devm_kmalloc Can the Coccinelle software help more to determine desired function properties? >> For which hardware and software combinations would you like to see >> facts there? > > This is not for Joe to decide, This view is fine in principle. > it's for the person who receives the patch to decide. I am curious on further comments from these contributors. > You could start with the ones for which the code actually compiles, > using the standard make file and no special options, and a > recent version of gcc. The variation space could become too big to handle for me (alone). How will this aspect evolve further? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote: > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with > > > the same code. Extract common part from PCI drivers into separate > > > remove_conflicting_pci_framebuffers(). > > > > > > Signed-off-by: Michał Mirosław > > > > Since the only driver that seems to use this is the staging one, which imo > > is a DOA project, not sure it's worth to bother with this here. > > afaik, this device is used in production by few manufacturers and it is > usefull for them to have it in the tree and the only reason it is still > in staging is because Tomi announced he will not take any new drivers in > fbdev. And, so I have not taken the initiative to properly move it out > of staging. I think Bartlomiej will also not accept new drivers in fbdev. Imo, if no one cares about porting it to kms (which will give you an fbdev driver for free), then we should throw it out. At least I thought staging was only for stuff that had a reasonable chance to get mainlined. Not as a dumping ground for drivers that people use, but don't bother to get ready for mainline. Greg? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.
Hi and sorry for the delayed reply! > Hi Kees, > > On Sat, 25 Nov 2017 12:57:04 -0800 > Kees Cook wrote: > > > On Wed, Nov 22, 2017 at 11:57 PM, Daniel Vetter wrote: > > > On Wed, Nov 22, 2017 at 07:21:00PM +0100, Boris Brezillon wrote: > > >> On Wed, 22 Nov 2017 19:13:09 +0100 > > >> Daniel Vetter wrote: > > >> > > >> > On Wed, Nov 22, 2017 at 6:51 PM, Boris Brezillon > > >> > wrote: > > >> > > Hi Stefan, > > >> > > > > >> > > On Wed, 22 Nov 2017 17:43:35 +0100 (CET) > > >> > > Stefan Wahren wrote: > > >> > > > > >> > >> Hi Boris, > > >> > >> if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) > > >> > >> with > sufficient CMA memory (32 MB), i'll get this warning during boot: > > >> > >> > > >> > >> [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops > > >> > >> vc4_hdmi_ops > [vc4]) > > >> > >> [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops > [vc4]) > > >> > >> [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops > [vc4]) > > >> > >> [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops > vc4_crtc_ops [vc4]) > > >> > >> [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops > vc4_crtc_ops [vc4]) > > >> > >> [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops > vc4_crtc_ops [vc4]) > > >> > >> [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops > [vc4]) > > >> > >> [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on > > >> > >> minor 0 > > >> > >> [7.750841] [drm] Supports vblank timestamp caching Rev 2 > > >> > >> (21.10.2013). > > >> > >> [7.757620] [drm] Driver supports precise vblank timestamp query. > > >> > >> [7.811775] [ cut here ] > > >> > >> [7.811780] refcount_t: increment on 0; use-after-free. > > >> > >> [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 > refcount_inc+0x44/0x50 > > >> > >> [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper > smsc95xx usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma crc32_ce > i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6 > > >> > >> [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted > > >> > >> 4.14.0- > next-20171122 #1 > > >> > >> [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) > > >> > >> [7.811958] task: 800036b91c00 task.stack: 0d6f > > >> > >> [7.811967] pstate: 2005 (nzCv daif -PAN -UAO) > > >> > >> [7.811974] pc : refcount_inc+0x44/0x50 > > >> > >> [7.811981] lr : refcount_inc+0x44/0x50 > > >> > >> [7.811984] sp : 0d6f3300 > > >> > >> [7.811988] x29: 0d6f3300 x28: > > >> > >> [7.811996] x27: 0003 x26: 800037107800 > > >> > >> [7.812004] x25: 0001 x24: 800035afdc00 > > >> > >> [7.812012] x23: x22: 800035dfa600 > > >> > >> [7.812020] x21: 800035afd9b0 x20: 800035afd9a4 > > >> > >> [7.812027] x19: x18: > > >> > >> [7.812034] x17: 0001 x16: 0019 > > >> > >> [7.812042] x15: 0001 x14: fff0 > > >> > >> [7.812049] x13: 090ae840 x12: 08fa2d50 > > >> > >> [7.812057] x11: 08fa2000 x10: 090ad000 > > >> > >> [7.812064] x9 : x8 : 090b5c2f > > >> > >> [7.812072] x7 : x6 : 0015ee00 > > >> > >> [7.812079] x5 : x4 : > > >> > >> [7.812087] x3 : x2 : 800030047000 > > >> > >> [7.812094] x1 : 800036b91c00 x0 : 002b > > >> > >> [7.812102] Call trace: > > >> > >> [7.812109] refcount_inc+0x44/0x50 > > >> > >> [7.812226] vc4_bo_inc_usecnt+0x84/0x88 [vc4] > > >> > >> [7.812310] vc4_prepare_fb+0x40/0xf0 [vc4] > > >> > >> [7.812460] drm_atomic_helper_prepare_planes+0x54/0xf0 > [drm_kms_helper] > > >> > >> [7.812543] vc4_atomic_commit+0x88/0x130 [vc4] > > >> > >> [7.812868] drm_atomic_commit+0x48/0x68 [drm] > > >> > >> [7.813002] restore_fbdev_mode_atomic+0x1d8/0x1e8 > [drm_kms_helper] > > >> > >> [7.813113] restore_fbdev_mode+0x28/0x160 [drm_kms_helper] > > >> > >> [7.813223] > drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 > [drm_kms_helper] > > >> > >> [7.813331] drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper] > > >> > >> [7.813346] fbcon_init+0x4e8/0x538 > > >> > >> [7.813357] visual_init+0xb4/0x108 > > >> > >> [7.813366] do_bind_con_driver+0x1b8/0x3a0 > > >> > >> [7.813373] do_take_over_console+0x150/0x1d0 > > >> > >> [7.813380] do_fbcon_takeover+0x6c/0xf0 > > >> > >> [7.813387] fbcon_event_notify+0x8fc/0x928 > > >> > >> [7.813399] notifier_call_chain+0x50/0x90 > > >> > >> [7.813406] __blocking_notifier_call_chain+0x4c/0x90 > > >> > >> [7.813413] blocking_notifier_call_chain+0x14/0x20 > > >> > >> [7.813
Re: [Intel-gfx] [PATCH v6 5/7] drm/i915: Add "panel orientation" property to the panel connector, v6.
On Sat, Nov 25, 2017 at 06:33:39PM +0100, Hans de Goede wrote:
> Ideally we could use the VBT for this, that would be simple, in
> intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
> connector->display_info.panel_orientation accordingly and call
> drm_connector_init_panel_orientation_property(), done.
>
> Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
> with an upside down LCD and where the GOP is properly rotating the
> EFI fb in hardware.
>
> So instead we end up reading the rotation from the primary plane.
>
> This commit only implements the panel orientation property for DSI
> panels on BYT / CHT hardware, as all known non normal oriented panels
> sofar are only found on this hardware.
>
> Changes in v2:
> -Read back the rotation applied by the GOP from the primary plane
> instead of relying on dev_priv->vbt.dsi.config->rotation, because it
> seems that the VBT rotation filed is always 0 even on devices where the
> GOP does apply a rotation
>
> Changes in v3:
> -Rewrite the code to read back the orientation from the primary
> plane to contain all of this in intel_dsi.c instead of poking a bunch
> of holes between all the different layers
>
> Changes in v6:
> -Move hardware readout to intel_dsi_init()
Yeah, this is what I had in mind. A small hack, but much more well
contained.
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index f09474b0c4d3..f67d321376e4 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1666,6 +1666,27 @@ static const struct drm_connector_funcs
> intel_dsi_connector_funcs = {
> .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> };
>
> +static int intel_dsi_get_panel_orientation(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> + enum i9xx_plane_id plane;
> + u32 val;
> +
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + if (connector->encoder->crtc_mask == BIT(PIPE_B))
> + plane = PLANE_B;
> + else
> + plane = PLANE_A;
> +
> + val = I915_READ(DSPCNTR(plane));
> + if (val & DISPPLANE_ROTATE_180)
> + orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> + }
> +
> + return orientation;
> +}
> +
> static void intel_dsi_add_properties(struct intel_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -1681,6 +1702,13 @@ static void intel_dsi_add_properties(struct
> intel_connector *connector)
>
> allowed_scalers);
>
> connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
> +
> + connector->base.display_info.panel_orientation =
> + intel_dsi_get_panel_orientation(connector);
> + drm_connector_init_panel_orientation_property(
> + &connector->base,
> + connector->panel.fixed_mode->hdisplay,
> + connector->panel.fixed_mode->vdisplay);
> }
> }
>
> --
> 2.14.3
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
>>> On 28.11.17 at 10:12, wrote: > In theory the BIOS would search for address space and won't find > anything, so the hotplug operation should fail even before it reaches > the kernel in the first place. How would the BIOS know what the OS does or plans to do? I think it's the other way around - the OS needs to avoid using any regions for MMIO which are marked as hotpluggable in SRAT. Since there is no vNUMA yet for Xen Dom0, that would need special handling. Jan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: Fix modifiers_property kernel-doc comment
On Sat, Nov 25, 2017 at 08:27:31PM +0100, Hans de Goede wrote:
> This fixes the following make kerneldocs messages:
>
> ./include/drm/drm_mode_config.h:772: warning: No description found for
> parameter 'modifiers_property'
> ./include/drm/drm_mode_config.h:772: warning: Excess struct member
> 'modifiers' description in 'drm_mode_config'
>
> Signed-off-by: Hans de Goede
Reviewed-by: Daniel Vetter
Pls push to drm-misc-next, thanks.
-Daniel
> ---
> include/drm/drm_mode_config.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 3716e6b8fed5..cb9ffbda36cc 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -759,7 +759,7 @@ struct drm_mode_config {
> bool allow_fb_modifiers;
>
> /**
> - * @modifiers: Plane property to list support modifier/format
> + * @modifiers_property: Plane property to list support modifier/format
>* combination.
>*/
> struct drm_property *modifiers_property;
> --
> 2.14.3
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 0/7] drm/fbdev: Panel orientation connector property support
On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote: > Hi All, > > Here is v6 of my series to add a "panel orientation" property to > the drm-connector for the LCD panel to let userspace know about LCD > panels which are not mounted upright, as well as detecting upside-down > panels without needing quirks (like we do for 90 degree rotated screens). > > Bartlomiej, can we please have your Acked-by for merging patches 1, > 6 and 7 through the drm tree? > > New in v6: > -Fix / reference kernel-doc comments > -Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI > -Move i915 dsi hardware rotation state read-out to intel_dsi_init() > > New in v5: > -Add kernel-doc comment documenting drm_get_panel_orientation_quirk() > -drm_fb_helper: Only use hardware (crtc primary plane) rotation for > 180 degrees for now as 9-/270 degrees rotation requires special handling > > New in v4: > -Fix drm_fb_helper code setting an invalid rotation value on the primary > plane of disabled/unused crtcs (caught by Fi.CI) > > New in v3: > -As requested by Daniel v3 moves the quirks over from the fbdev > subsys to the drm subsys. I've done this by simpy starting with a copy of > the quirk table and eventually removing the fbdev version. > > The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5 > are all drm patches and patches 6-7 are fbdev/fbcon patches again. As > discussed previously the plan is to merge all 7 patches through the > drm tree. I think from the drm and i915 side of things this all looks ready (well pls double-check that CI also approves before merging). Just needs an ack/review from Bart, and then it's probably simplest if you merge it all through drm-misc - the i915 side is tiny. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
Am 28.11.2017 um 10:46 schrieb Jan Beulich: On 28.11.17 at 10:12, wrote: In theory the BIOS would search for address space and won't find anything, so the hotplug operation should fail even before it reaches the kernel in the first place. How would the BIOS know what the OS does or plans to do? As far as I know the ACPI BIOS should work directly with the register content. So when we update the register content to enable the MMIO decoding the BIOS should know that as well. I think it's the other way around - the OS needs to avoid using any regions for MMIO which are marked as hotpluggable in SRAT. I was under the impression that this is exactly what acpi_numa_memory_affinity_init() does. Since there is no vNUMA yet for Xen Dom0, that would need special handling. I think that the problem is rather that SRAT is NUMA specific and if I'm not totally mistaken the content is ignored when NUMA support isn't compiled into the kernel. When Xen steals some memory from Dom0 by hocking up itself into the e820 call then I would say the cleanest way is to report this memory in e820 as reserved as well. But take that with a grain of salt, I'm seriously not a Xen expert. Regards, Christian. Jan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
>> How will this aspect evolve further? > > I do not follow. Interesting … > This is OMAP framebuffer driver, so in this case, there is zero variation. How much are you interested to compare differences in build results also for this software module because of varying parameters? Which parameters were applied for your size comparisons so far? > Could you, please, review following patch I assume that other OMAP developers are in a better position to decide about the deletion of extra memory allocations (instead of keeping questionable error messages). > and verify is it satisfies your automated static code analysis test? I am not going to “verify” your update suggestion by my evolving approaches around the semantic patch language (Coccinelle software) at the moment. But I thank you for this contribution. How will further feedback evolve for such an idea? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
>>> On 28.11.17 at 11:17, wrote: > Am 28.11.2017 um 10:46 schrieb Jan Beulich: > On 28.11.17 at 10:12, wrote: >>> In theory the BIOS would search for address space and won't find >>> anything, so the hotplug operation should fail even before it reaches >>> the kernel in the first place. >> How would the BIOS know what the OS does or plans to do? > > As far as I know the ACPI BIOS should work directly with the register > content. > > So when we update the register content to enable the MMIO decoding the > BIOS should know that as well. I'm afraid I don't follow: During memory hotplug, surely you don't expect the BIOS to do a PCI bus scan? Plus even if it did, it would be racy - some device could, at this very moment, have memory decoding disabled, just for the OS to re-enable it a millisecond later. Yet looking at BAR values is meaningless when memory decode of a device is disabled. >> I think >> it's the other way around - the OS needs to avoid using any regions >> for MMIO which are marked as hotpluggable in SRAT. > > I was under the impression that this is exactly what > acpi_numa_memory_affinity_init() does. Perhaps, except that (when I last looked) insufficient state is (was) being recorded to have that information readily available at the time MMIO space above 4Gb needs to be allocated for some device. >> Since there is >> no vNUMA yet for Xen Dom0, that would need special handling. > > I think that the problem is rather that SRAT is NUMA specific and if I'm > not totally mistaken the content is ignored when NUMA support isn't > compiled into the kernel. > > When Xen steals some memory from Dom0 by hocking up itself into the e820 > call then I would say the cleanest way is to report this memory in e820 > as reserved as well. But take that with a grain of salt, I'm seriously > not a Xen expert. The E820 handling in PV Linux is all fake anyway - there's a single chunk of memory given to a PV guest (including Dom0), contiguous in what PV guests know as "physical address space" (not to be mixed up with "machine address space", which is where MMIO needs to be allocated from). Xen code in the kernel then mimics an E820 matching the host one, moving around pieces of memory in physical address space if necessary. Since Dom0 knows the machine E820, MMIO allocation shouldn't need to be much different there from the non-Xen case. Jan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote: > Hi, > > This series is to add new drm formats needed by some Xilinx IPs. > Some formats have unique characteristics such as pixels not being > byte-aligned. For instance, some 10bit formats have 2bit padding > after every 3-10bit components: > > 32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding > 32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding > ... > > To model this, additional information is added to struct drm_format_info. > The patch has been tested with downstream drivers as well as the downstream > user space component (ex, modified modetest). > > Thanks, > hyun > > Jeffrey Mouroux (2): > uapi: drm: New fourcc codes needed by Xilinx Video IP > drm: fourcc: Update DRM Framework with new fourcc codes > > Satish Kumar Nagireddy (1): > drm: drm_fourcc: Add scaling and padding factor to drm_format_info We need the driver for this. -Daniel > > drivers/gpu/drm/drm_fourcc.c | 143 > ++ > include/drm/drm_fourcc.h | 9 +++ > include/uapi/drm/drm_fourcc.h | 9 +++ > 3 files changed, 93 insertions(+), 68 deletions(-) > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.
Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.
Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.
Signed-off-by: Maarten Lankhorst
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Cc: # v4.14+
Reported-by: Thomas Voegtle
---
drivers/gpu/drm/drm_fb_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 07374008f146..e56166334455 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,10 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+
+ /* First time: disable all crtc's.. */
+ if (!fb_helper->deferred_setup &&
!READ_ONCE(fb_helper->dev->master))
+ restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/5] Update ROCKCHIP DSI driver that uses dw-mipi-dsi bridge
We now have a generic dw-mipi-dsi bridge driver.So we send this patchs to moving rockchip dw-mipi-dsi driver to that in order to add new features(dual mipi support). Update ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge. ChangeLog: v2: add err_pllref、remove unnecessary encoder.enable & disable correct spelling mistakes v3: add Brian's patch "drm/bridge/synopsys: stop clobbering drvdata" (Link:https://patchwork.kernel.org/patch/10078493/) adjust drm/stm/dsi code for above drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver: call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind() fix typo, use of_device_get_match_data(), change some ‘bind()’ logic into 'probe()' add 'dev_set_drvdata()' Nickey Yang (5): drm/bridge/synopsys: stop clobbering drvdata drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove dt-bindings: display: rockchip: update DSI controller drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver arm64: dts: rockchip: update mipi node for RK3399 .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi |8 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 +- drivers/gpu/drm/rockchip/Kconfig |2 +- drivers/gpu/drm/rockchip/Makefile |2 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c| 764 +++ drivers/gpu/drm/rockchip/rockchip_drm_drv.c|2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h|2 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c |8 +- include/drm/bridge/dw_mipi_dsi.h | 17 +- 11 files changed, 821 insertions(+), 1392 deletions(-) delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/5] drm/bridge/synopsys: stop clobbering drvdata
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.
Signed-off-by: Brian Norris
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Archit Taneja
Acked-by: Philippe Cornu
Link:https://patchwork.kernel.org/patch/10078493/
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 ++-
include/drm/bridge/dw_mipi_dsi.h | 17 -
2 files changed, 24 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d9cca4f..c39c7dc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -922,8 +922,6 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
*bridge)
dsi->bridge.of_node = pdev->dev.of_node;
#endif
- dev_set_drvdata(dev, dsi);
-
return dsi;
}
@@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
/*
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-int dw_mipi_dsi_probe(struct platform_device *pdev,
- const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_probe(struct platform_device *pdev,
+ const struct dw_mipi_dsi_plat_data *plat_data)
{
- struct dw_mipi_dsi *dsi;
-
- dsi = __dw_mipi_dsi_probe(pdev, plat_data);
- if (IS_ERR(dsi))
- return PTR_ERR(dsi);
-
- return 0;
+ return __dw_mipi_dsi_probe(pdev, plat_data);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
-void dw_mipi_dsi_remove(struct platform_device *pdev)
+void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
{
- struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
-
mipi_dsi_host_unregister(&dsi->dsi_host);
__dw_mipi_dsi_remove(dsi);
@@ -961,31 +952,30 @@ void dw_mipi_dsi_remove(struct platform_device *pdev)
/*
* Bind/unbind API, used from platforms based on the component framework.
*/
-int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
+const struct dw_mipi_dsi_plat_data *plat_data)
{
struct dw_mipi_dsi *dsi;
int ret;
dsi = __dw_mipi_dsi_probe(pdev, plat_data);
if (IS_ERR(dsi))
- return PTR_ERR(dsi);
+ return dsi;
ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
if (ret) {
- dw_mipi_dsi_remove(pdev);
+ dw_mipi_dsi_remove(dsi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ret;
+ return ERR_PTR(ret);
}
- return 0;
+ return dsi;
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
-void dw_mipi_dsi_unbind(struct device *dev)
+void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
{
- struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
-
__dw_mipi_dsi_remove(dsi);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
index 9b30fec..d9c6d54 100644
--- a/include/drm/bridge/dw_mipi_dsi.h
+++ b/include/drm/bridge/dw_mipi_dsi.h
@@ -10,6 +10,8 @@
#ifndef __DW_MIPI_DSI__
#define __DW_MIPI_DSI__
+struct dw_mipi_dsi;
+
struct dw_mipi_dsi_phy_ops {
int (*init)(void *priv_data);
int (*get_lane_mbps)(void *priv_data, struct drm_display_mode *mode,
@@ -29,11 +31,14 @@ struct dw_mipi_dsi_plat_data {
void *priv_data;
};
-int dw_mipi_dsi_probe(struct platform_device *pdev,
- const struct dw_mipi_dsi_plat_data *plat_data);
-void dw_mipi_dsi_remove(struct platform_device *pdev);
-int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data *plat_data);
-void dw_mipi_dsi_unbind(struct device *dev);
+struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device *pdev,
+ const struct dw_mipi_dsi_plat_data
+ *plat_data);
+void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
+struct dw_mipi_dsi *dw_mipi_dsi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_mipi_dsi_plat_data
+*plat_data);
+void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
#endif /* __DW_MIPI_DSI__ */
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/5] dt-bindings: display: rockchip: update DSI controller
This patch update documentation of device tree bindings for the rockchip
DSI controller based on the Synopsys DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
---
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 ++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 6bb59ab..336909d 100644
---
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -14,6 +14,8 @@ Required properties:
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
- ports: contain a port node with endpoint definitions as defined in [2].
For vopb,set the reg = <0> and set the reg = <1> for vopl.
+- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
+- video port 1 for either a panel or subsequent encoder
Optional properties:
- power-domains: a phandle to mipi dsi power domain node.
@@ -40,11 +42,10 @@ Example:
ports {
#address-cells = <1>;
#size-cells = <0>;
- reg = <1>;
- mipi_in: port {
- #address-cells = <1>;
- #size-cells = <0>;
+ mipi_in: port@0 {
+ reg = <0>;
+
mipi_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <&vopb_out_mipi>;
@@ -54,6 +55,14 @@ Example:
remote-endpoint = <&vopl_out_mipi>;
};
};
+
+ mipi_out: port@1 {
+ reg = <1>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&panel_in_mipi>;
+ };
+ };
};
panel {
@@ -64,5 +73,11 @@ Example:
pinctrl-names = "default";
pinctrl-0 = <&lcd_en>;
backlight = <&backlight>;
+
+ port {
+ panel_in_mipi: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.
So adjust it.
Signed-off-by: Nickey Yang
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index e5b6310..80f9950 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -66,6 +66,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
struct clk *pllref_clk;
+ struct dw_mipi_dsi *dmd;
};
static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
@@ -318,10 +319,11 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
dw_mipi_dsi_stm_plat_data.base = dsi->base;
dw_mipi_dsi_stm_plat_data.priv_data = dsi;
- ret = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
- if (ret) {
+ dsi->dmd = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
+ if (IS_ERR(dsi->dmd)) {
DRM_ERROR("Failed to initialize mipi dsi host\n");
clk_disable_unprepare(dsi->pllref_clk);
+ return PTR_ERR(dsi->dmd);
}
return ret;
@@ -332,7 +334,7 @@ static int dw_mipi_dsi_stm_remove(struct platform_device
*pdev)
struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
clk_disable_unprepare(dsi->pllref_clk);
- dw_mipi_dsi_remove(pdev);
+ dw_mipi_dsi_remove(dsi->dmd);
return 0;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] arm64: dts: rockchip: update mipi node for RK3399
This patch update mipi node for RK3399 DSI controller
based on the Synopsys DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d340b58a..0ac67a9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1652,9 +1652,11 @@
status = "disabled";
ports {
- mipi_in: port {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_in: port@0 {
+ reg = <0>;
mipi_in_vopb: endpoint@0 {
reg = <0>;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver
Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge. v2: add err_pllref, remove unnecessary encoder.enable & disable correct spelling mistakes v3: call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind() fix typo, use of_device_get_match_data(), change some ‘bind()’ logic into 'probe()' add 'dev_set_drvdata()' Signed-off-by: Nickey Yang --- drivers/gpu/drm/rockchip/Kconfig|2 +- drivers/gpu/drm/rockchip/Makefile |2 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 --- drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c | 764 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +- 6 files changed, 768 insertions(+), 1353 deletions(-) delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc762..9eb4795 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -7,7 +7,7 @@ config DRM_ROCKCHIP select VIDEOMODE_HELPERS select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI - select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a314e21..c05fe47 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o -rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c deleted file mode 100644 index b15755b..000 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c +++ /dev/null @@ -1,1349 +0,0 @@ -/* - * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "rockchip_drm_drv.h" -#include "rockchip_drm_vop.h" - -#define DRIVER_NAME"dw-mipi-dsi" - -#define RK3288_GRF_SOC_CON60x025c -#define RK3288_DSI0_SEL_VOP_LITBIT(6) -#define RK3288_DSI1_SEL_VOP_LITBIT(9) - -#define RK3399_GRF_SOC_CON20 0x6250 -#define RK3399_DSI0_SEL_VOP_LITBIT(0) -#define RK3399_DSI1_SEL_VOP_LITBIT(4) - -/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */ -#define RK3399_GRF_SOC_CON22 0x6258 -#define RK3399_GRF_DSI_MODE0x - -#define DSI_VERSION0x00 -#define DSI_PWR_UP 0x04 -#define RESET 0 -#define POWERUPBIT(0) - -#define DSI_CLKMGR_CFG 0x08 -#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) -#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) - -#define DSI_DPI_VCID 0x0c -#define DPI_VID(vid) (((vid) & 0x3) << 0) - -#define DSI_DPI_COLOR_CODING 0x10 -#define EN18_LOOSELY BIT(8) -#define DPI_COLOR_CODING_16BIT_1 0x0 -#define DPI_COLOR_CODING_16BIT_2 0x1 -#define DPI_COLOR_CODING_16BIT_3 0x2 -#define DPI_COLOR_CODING_18BIT_1 0x3 -#define DPI_COLOR_CODING_18BIT_2 0x4 -#define DPI_COLOR_CODING_24BIT 0x5 - -#define DSI_DPI_CFG_POL0x14 -#define COLORM_ACTIVE_LOW BIT(4) -#define SHUTD_ACTIVE_LOW BIT(3) -#define HSYNC_ACTIVE_LOW BIT(2) -#define VSYNC_ACTIVE_LOW BIT(1) -#define DATAEN_ACTIVE_LOW BIT(0) - -#define DSI_DPI_LP_CMD_TIM 0x18 -#define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) -#define INVACT_LPCMD_TIME(p) ((p) & 0xff) - -#define DSI_DBI_CFG0x20 -#define DSI
Re: [PATCH v2 2/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver
Hi Archit, On 2017年11月28日 14:27, Archit Taneja wrote: Hi, Thanks a lot for working on this. Some comments below. Those comments have fixed in patch_v3 https://patchwork.kernel.org/patch/10079857/ Thanks for review. On 11/28/2017 07:25 AM, Nickey Yang wrote: Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge. Signed-off-by: Nickey Yang --- drivers/gpu/drm/rockchip/Kconfig | 2 +- drivers/gpu/drm/rockchip/Makefile | 2 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 --- drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c | 756 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +- 6 files changed, 760 insertions(+), 1353 deletions(-) delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc762..9eb4795 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -7,7 +7,7 @@ config DRM_ROCKCHIP select VIDEOMODE_HELPERS select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI - select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a314e21..c05fe47 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o -rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c deleted file mode 100644 index b15755b..000 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c +++ /dev/null @@ -1,1349 +0,0 @@ -/* - * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "rockchip_drm_drv.h" -#include "rockchip_drm_vop.h" - -#define DRIVER_NAME "dw-mipi-dsi" - -#define RK3288_GRF_SOC_CON6 0x025c -#define RK3288_DSI0_SEL_VOP_LIT BIT(6) -#define RK3288_DSI1_SEL_VOP_LIT BIT(9) - -#define RK3399_GRF_SOC_CON20 0x6250 -#define RK3399_DSI0_SEL_VOP_LIT BIT(0) -#define RK3399_DSI1_SEL_VOP_LIT BIT(4) - -/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */ -#define RK3399_GRF_SOC_CON22 0x6258 -#define RK3399_GRF_DSI_MODE 0x - -#define DSI_VERSION 0x00 -#define DSI_PWR_UP 0x04 -#define RESET 0 -#define POWERUP BIT(0) - -#define DSI_CLKMGR_CFG 0x08 -#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) -#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) - -#define DSI_DPI_VCID 0x0c -#define DPI_VID(vid) (((vid) & 0x3) << 0) - -#define DSI_DPI_COLOR_CODING 0x10 -#define EN18_LOOSELY BIT(8) -#define DPI_COLOR_CODING_16BIT_1 0x0 -#define DPI_COLOR_CODING_16BIT_2 0x1 -#define DPI_COLOR_CODING_16BIT_3 0x2 -#define DPI_COLOR_CODING_18BIT_1 0x3 -#define DPI_COLOR_CODING_18BIT_2 0x4 -#define DPI_COLOR_CODING_24BIT 0x5 - -#define DSI_DPI_CFG_POL 0x14 -#define COLORM_ACTIVE_LOW BIT(4) -#define SHUTD_ACTIVE_LOW BIT(3) -#define HSYNC_ACTIVE_LOW BIT(2) -#define VSYNC_ACTIVE_LOW BIT(1) -#define DATAEN_ACTIVE_LOW BIT(0) - -#define DSI_DPI_LP_CMD_TIM 0x18 -#define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) -#define INVACT_LPCMD_TIME(p) ((p) & 0xff) - -#define DSI_DBI_CFG 0x20 -#define DSI_DBI_CMDSIZE 0x28 - -#define DSI_PCKHDL_CFG 0x2c -#define EN_CRC_RX BIT(4) -#define EN_ECC_RX BIT(3) -#define EN_BTA BIT(2) -#define EN_EOTP_RX
Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote: > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote: > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with > > > > the same code. Extract common part from PCI drivers into separate > > > > remove_conflicting_pci_framebuffers(). > > > > > > > > Signed-off-by: Michał Mirosław > > > > > > Since the only driver that seems to use this is the staging one, which imo > > > is a DOA project, not sure it's worth to bother with this here. > > > > afaik, this device is used in production by few manufacturers and it is > > usefull for them to have it in the tree and the only reason it is still > > in staging is because Tomi announced he will not take any new drivers in > > fbdev. And, so I have not taken the initiative to properly move it out > > of staging. I think Bartlomiej will also not accept new drivers in fbdev. > > Imo, if no one cares about porting it to kms (which will give you an fbdev > driver for free), then we should throw it out. At least I thought staging > was only for stuff that had a reasonable chance to get mainlined. Not as a > dumping ground for drivers that people use, but don't bother to get ready > for mainline. > > Greg? Yes, if no one is working to get it out of staging, that means no one cares about it, and it needs to be removed from the tree. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging/sm750fb: Add "port to atomic kms" to TODO
fbdev is closed for new drivers, drm won't take anything but atomic drivers. Cc: Greg Kroah-Hartman Cc: Sudip Mukherjee Cc: Teddy Wang Cc: Sudip Mukherjee Cc: Bartlomiej Zolnierkiewicz Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/staging/sm750fb/TODO | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/sm750fb/TODO b/drivers/staging/sm750fb/TODO index a3a877d90066..f710ab15abfe 100644 --- a/drivers/staging/sm750fb/TODO +++ b/drivers/staging/sm750fb/TODO @@ -6,8 +6,8 @@ TODO: - check on hardware effects of removal of USE_HW_I2C and USE_DVICHIP (these two are supposed to be sample code which is given here if someone wants to use those functionalities) -- move it to drivers/video/fbdev -- modify the code for drm framework +- must be ported to the atomic kms framework in the drm subsystem (which will + give you a basic fbdev driver for free) Please send any patches to Greg Kroah-Hartman -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.
On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
> Some drivers like i915 start with crtc's enabled, but with deferred
> fbcon setup they were no longer disabled as part of fbdev setup.
> Headless units could no longer enter pc3 state because the crtc was
> still enabled.
>
> Fix this by calling restore_fbdev_mode when we would have called
> it otherwise once during initial fbdev setup.
>
> Signed-off-by: Maarten Lankhorst
> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Please use dim fixes to get a more complete Cc: list for regression fixes.
> Cc: # v4.14+
> Reported-by: Thomas Voegtle
Reviewed-by: Daniel Vetter
But please confirm with the reporter that it indeed fixes the issue before
pushing.
-Daniel
> ---
> drivers/gpu/drm/drm_fb_helper.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 07374008f146..e56166334455 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1809,6 +1809,10 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
>
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> DRM_INFO("Cannot find any crtc or sizes\n");
> +
> + /* First time: disable all crtc's.. */
> + if (!fb_helper->deferred_setup &&
> !READ_ONCE(fb_helper->dev->master))
> + restore_fbdev_mode(fb_helper);
> return -EAGAIN;
> }
>
> --
> 2.15.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] arm64: dts: exynos: remove i80-if-timings nodes
On Fri, Sep 8, 2017 at 6:47 PM, Krzysztof Kozlowski wrote: > On Thu, Aug 24, 2017 at 03:33:59PM +0200, Andrzej Hajda wrote: >> Since i80/command mode is determined in runtime by propagating info >> from panel this property can be removed. >> >> Signed-off-by: Andrzej Hajda >> --- >> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 -- >> 1 file changed, 6 deletions(-) >> > > I understand this should go in after merging the driver changes to > preserve bisectability? Dear Inki Dae, This was a DeviceTree patch and it should be kept separate from driver changes. You should not apply it then. Especially without an ack from arm-soc or Exynos maintainers... because the usual path is through arm-soc. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88a5e22a90efd12dfde642ed55d4c669ab658b0f Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
>> I am not going to “verify” your update suggestion by my evolving approaches >> around the semantic patch language (Coccinelle software) at the moment. > > As you are sending patches as Markus Elfring I am contributing also some update suggestions. > I would expect you take Coccinelle's suggestion into account The proposed change is based on a semantic patch script which I developed with the support of other well-known Linux contributors. > and actually try to understand code before sending patch. I concentrated my understanding on the concrete transformation pattern in this use case. > That suggestion may lead to actual bug in code which your patch just leaves > unnoticed as it is not apparent from the patch itself There can be other change possibilities left over as usual. > (no, not talking about this very patch it all started with) Thanks for your distinction. > That said, I'm considering Markus Elfring being a human. Thanks for this view. > If you do not like reactions to your patches I am looking for constructive responses. - Disagreements can trigger special communication challenges. > or are interested only in improving tool that generates them, How do you think about to look at any more background information? https://github.com/coccinelle/coccinelle/issues https://systeme.lip6.fr/pipermail/cocci/ > it would be better to just setup a "tip bot for Markus > Elfring" and let it send patches automatically. There is already an other automatic source code analysis system active. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scripts/coccinelle > The way you are sending patches makes impression (at least to me), > that you spent some time on fixing issue Coccinelle found Yes. - This view is appropriate. > and not just shut the warning up. Additional improvement possibilities can be taken into account after corresponding software development discussions, can't they? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
Am 28.11.2017 um 11:53 schrieb Jan Beulich: On 28.11.17 at 11:17, wrote: Am 28.11.2017 um 10:46 schrieb Jan Beulich: On 28.11.17 at 10:12, wrote: In theory the BIOS would search for address space and won't find anything, so the hotplug operation should fail even before it reaches the kernel in the first place. How would the BIOS know what the OS does or plans to do? As far as I know the ACPI BIOS should work directly with the register content. So when we update the register content to enable the MMIO decoding the BIOS should know that as well. I'm afraid I don't follow: During memory hotplug, surely you don't expect the BIOS to do a PCI bus scan? Plus even if it did, it would be racy - some device could, at this very moment, have memory decoding disabled, just for the OS to re-enable it a millisecond later. Yet looking at BAR values is meaningless when memory decode of a device is disabled. No, sorry you misunderstood me. The PCI bus is not even involved here. In AMD Family CPUs you have four main types of address space routed by the NB: 1. Memory space targeting system DRAM. 2. Memory space targeting IO (MMIO). 3. IO space. 4. Configuration space. See section "2.8.2 NB Routing" in the BIOS and Kernel Developer’s Guide (https://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf). Long story short you have fix addresses for configuration and legacy IO (VGA for example) and then configurable memory space for DRAM and MMIO. What the ACPI BIOS does (or at least should do) is taking a look at the registers to find space during memory hotplug. Now in theory the MMIO space should be configurable by similar ACPI BIOS functions, but unfortunately most BIOS doesn't enable that function because it can break some older Windows versions. So what we do here is just what the BIOS should have provided in the first place. I think it's the other way around - the OS needs to avoid using any regions for MMIO which are marked as hotpluggable in SRAT. I was under the impression that this is exactly what acpi_numa_memory_affinity_init() does. Perhaps, except that (when I last looked) insufficient state is (was) being recorded to have that information readily available at the time MMIO space above 4Gb needs to be allocated for some device. That was also my concern, but in the most recent version I'm intentionally doing this fixup very late after all the PCI setup is already done. This way the extra address space is only available for devices which are added by PCI hotplug or for resizing BARs on the fly (which is the use case I'm interested in). Since there is no vNUMA yet for Xen Dom0, that would need special handling. I think that the problem is rather that SRAT is NUMA specific and if I'm not totally mistaken the content is ignored when NUMA support isn't compiled into the kernel. When Xen steals some memory from Dom0 by hocking up itself into the e820 call then I would say the cleanest way is to report this memory in e820 as reserved as well. But take that with a grain of salt, I'm seriously not a Xen expert. The E820 handling in PV Linux is all fake anyway - there's a single chunk of memory given to a PV guest (including Dom0), contiguous in what PV guests know as "physical address space" (not to be mixed up with "machine address space", which is where MMIO needs to be allocated from). Xen code in the kernel then mimics an E820 matching the host one, moving around pieces of memory in physical address space if necessary. Good to know. Since Dom0 knows the machine E820, MMIO allocation shouldn't need to be much different there from the non-Xen case. Yes, completely agree. I think even if we don't do MMIO allocation with this fixup letting the kernel in Dom0 know which memory/address space regions are in use is still a good idea. Otherwise we will run into exactly the same problem when we do the MMIO allocation with an ACPI method and that is certainly going to come in the next BIOS generations because Microsoft is pushing for it. Regards, Christian. Jan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103743] Nier:Automata - "if" in fragment shader incorrectly evaluated, causes artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=103743 --- Comment #7 from Nicolai Hähnle --- Created attachment 135749 --> https://bugs.freedesktop.org/attachment.cgi?id=135749&action=edit patch for related issue -- 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 103743] Nier:Automata - "if" in fragment shader incorrectly evaluated, causes artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=103743 --- Comment #8 from Nicolai Hähnle --- Created attachment 135750 --> https://bugs.freedesktop.org/attachment.cgi?id=135750&action=edit patch to fix this issue Two patches for LLVM attached that fix the issue for me. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote: > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote: > > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote: > > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it > > > > > with > > > > > the same code. Extract common part from PCI drivers into separate > > > > > remove_conflicting_pci_framebuffers(). > > > > > > > > > > Signed-off-by: Michał Mirosław > > > > > > > > Since the only driver that seems to use this is the staging one, which > > > > imo > > > > is a DOA project, not sure it's worth to bother with this here. > > > > > > afaik, this device is used in production by few manufacturers and it is > > > usefull for them to have it in the tree and the only reason it is still > > > in staging is because Tomi announced he will not take any new drivers in > > > fbdev. And, so I have not taken the initiative to properly move it out > > > of staging. I think Bartlomiej will also not accept new drivers in fbdev. > > > > Imo, if no one cares about porting it to kms (which will give you an fbdev > > driver for free), then we should throw it out. At least I thought staging > > was only for stuff that had a reasonable chance to get mainlined. Not as a > > dumping ground for drivers that people use, but don't bother to get ready > > for mainline. > > > > Greg? > > Yes, if no one is working to get it out of staging, that means no one > cares about it, and it needs to be removed from the tree. Agreed. I was not working on getting it out of staging as there is no place for it to go. But, Teddy Wang told me that they have a working drm driver for it, but it is not atomic like Daniel was asking for. If it is ok, then I can send in a patch to remove the existing sm750 from staging and add the new sm750 drm driver to staging. And after it is ready, we can go ahead with moving it out of staging to drm. Greg? Daniel? -- Regards Sudip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata
Hi Brian,
Thank you for the patch.
I'd mention dw-mipi-dsi in the subject line as the directory contains the dw-
hdmi driver as well that this patch doesn't touch.
On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote:
> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> parent driver might need to own this.
By parent driver I assume you mean a glue driver that binds to the SoC-
specific compatible string for the DSI transmitter.
> Instead, let's return our
> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
>
> Signed-off-by: Brian Norris
Wouldn't it be cleaner to embed the dw_mipi_dsi structure in the parent-
specific data structure (struct dw_mipi_dsi_stm and struct
dw_mipi_dsi_rockchip when the "[PATCH v3 0/5] Update ROCKCHIP DSI driver that
uses dw-mipi-dsi bridge" patch series will land) instead of allocating it
dynamically ? We would then have a single object to track.
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 ++--
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 14 +++
> include/drm/bridge/dw_mipi_dsi.h | 17 -
> 3 files changed, 33 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
> d9cca4fd66ec..c39c7dce20ed 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -922,8 +922,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dsi->bridge.of_node = pdev->dev.of_node;
> #endif
>
> - dev_set_drvdata(dev, dsi);
> -
> return dsi;
> }
>
> @@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi
> *dsi) /*
> * Probe/remove API, used from platforms based on the DRM bridge API.
> */
> -int dw_mipi_dsi_probe(struct platform_device *pdev,
> - const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_probe(struct platform_device *pdev,
> + const struct dw_mipi_dsi_plat_data *plat_data)
> {
> - struct dw_mipi_dsi *dsi;
> -
> - dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> - if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> -
> - return 0;
> + return __dw_mipi_dsi_probe(pdev, plat_data);
> }
> EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
>
> -void dw_mipi_dsi_remove(struct platform_device *pdev)
> +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
> {
> - struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
> -
> mipi_dsi_host_unregister(&dsi->dsi_host);
>
> __dw_mipi_dsi_remove(dsi);
> @@ -961,31 +952,30 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
> /*
> * Bind/unbind API, used from platforms based on the component framework.
> */
> -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder
> *encoder, -const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
> + const struct dw_mipi_dsi_plat_data *plat_data)
> {
> struct dw_mipi_dsi *dsi;
> int ret;
>
> dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> + return dsi;
>
> ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
> if (ret) {
> - dw_mipi_dsi_remove(pdev);
> + dw_mipi_dsi_remove(dsi);
> DRM_ERROR("Failed to initialize bridge with drm\n");
> - return ret;
> + return ERR_PTR(ret);
> }
>
> - return 0;
> + return dsi;
> }
> EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
>
> -void dw_mipi_dsi_unbind(struct device *dev)
> +void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
> {
> - struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
> -
> __dw_mipi_dsi_remove(dsi);
> }
> EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c index e5b6310240fe..7ed0ef7f6ec2
> 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -66,6 +66,7 @@ enum dsi_color {
> struct dw_mipi_dsi_stm {
> void __iomem *base;
> struct clk *pllref_clk;
> + struct dw_mipi_dsi *dsi;
> };
>
> static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
> @@ -318,21 +319,24 @@ static int dw_mipi_dsi_stm_probe(struct
> platform_device *pdev) dw_mipi_dsi_stm_plat_data.base = dsi->base;
> dw_mipi_dsi_stm_plat_data.priv_data = dsi;
>
> - ret = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
> - if (ret) {
> + platform_set_drvdata(pdev, dsi);
> +
> + dsi->dsi = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
> + if (IS_ERR(dsi->dsi)) {
> DRM_ERROR("Failed to initialize mipi dsi host\n");
> clk_disable_unprepare(dsi->pllref_clk)
[PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)
This is a false positive, but I wonder if it is really necessary to put
the assignment in the conditional test expression.
julia
-- Forwarded message --
Date: Tue, 28 Nov 2017 13:23:36 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings
CC: kbuild-...@01.org
CC: linux-ker...@vger.kernel.org
TO: Ben Skeggs
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
CC: nouv...@lists.freedesktop.org
CC: linux-ker...@vger.kernel.org
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:109:5-11: inconsistent IS_ERR
and PTR_ERR on line 110.
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:109:5-11: inconsistent IS_ERR
and PTR_ERR on line 111.
PTR_ERR should access the value just tested by IS_ERR
Semantic patch information:
There can be false positives in the patch case, where it is the call to
IS_ERR that is wrong.
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 920d2b5ef215 ("drm/nouveau/mmu: define user interfaces to mmu vmm
opertaions")
Signed-off-by: Fengguang Wu
---
Please take the patch only if it's a positive warning. Thanks!
uvmm.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
@@ -107,8 +107,9 @@ nvkm_uvmm_mthd_map(struct nvkm_uvmm *uvm
return ret;
if (IS_ERR((memory = nvkm_umem_search(client, handle {
- VMM_DEBUG(vmm, "memory %016llx %ld\n", handle, PTR_ERR(memory));
- return PTR_ERR(memory);
+ VMM_DEBUG(vmm, "memory %016llx %ld\n", handle,
+ PTR_ERR((memory = nvkm_umem_search(client, handle;
+ return PTR_ERR((memory = nvkm_umem_search(client, handle)));
}
mutex_lock(&vmm->mutex);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 Bug ID: 103953 Summary: [DC] Polaris10: Missing modes when enabling DC 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: freedesktop-bugzi...@dominik-paulus.de Created attachment 135751 --> https://bugs.freedesktop.org/attachment.cgi?id=135751&action=edit dmesg with amdgpu.dc=1 I have a Dell U2713HM connected to a Radeon RX470 (MSI board, 'Radeon RX470 Gaming 4G') over dual-link DVI on Linux 4.15-rc1. When enabling DC (Kernel commandline amdgpu.dc=1), the monitors native resolution of 2560x1440 is not detected, when falling back to default modesetting, everything works fine. Xorg.log and (relevant parts) of dmesg for both amdgpu.dc=1 and =0 are attached. -- 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 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 --- Comment #1 from Dominik Paulus --- Created attachment 135752 --> https://bugs.freedesktop.org/attachment.cgi?id=135752&action=edit dmesg with default settings -- 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 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 --- Comment #2 from Dominik Paulus --- Created attachment 135753 --> https://bugs.freedesktop.org/attachment.cgi?id=135753&action=edit Xorg.log with dc enabled -- 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 02/13] fbdev: add remove_conflicting_pci_framebuffers()
On Tue, Nov 28, 2017 at 12:30:30PM +, Sudip Mukherjee wrote: > On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote: > > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote: > > > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote: > > > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it > > > > > > with > > > > > > the same code. Extract common part from PCI drivers into separate > > > > > > remove_conflicting_pci_framebuffers(). > > > > > > > > > > > > Signed-off-by: Michał Mirosław > > > > > > > > > > Since the only driver that seems to use this is the staging one, > > > > > which imo > > > > > is a DOA project, not sure it's worth to bother with this here. > > > > > > > > afaik, this device is used in production by few manufacturers and it is > > > > usefull for them to have it in the tree and the only reason it is still > > > > in staging is because Tomi announced he will not take any new drivers in > > > > fbdev. And, so I have not taken the initiative to properly move it out > > > > of staging. I think Bartlomiej will also not accept new drivers in > > > > fbdev. > > > > > > Imo, if no one cares about porting it to kms (which will give you an fbdev > > > driver for free), then we should throw it out. At least I thought staging > > > was only for stuff that had a reasonable chance to get mainlined. Not as a > > > dumping ground for drivers that people use, but don't bother to get ready > > > for mainline. > > > > > > Greg? > > > > Yes, if no one is working to get it out of staging, that means no one > > cares about it, and it needs to be removed from the tree. > > Agreed. I was not working on getting it out of staging as there is no > place for it to go. > But, Teddy Wang told me that they have a working drm driver for it, but > it is not atomic like Daniel was asking for. If it is ok, then I can send > in a patch to remove the existing sm750 from staging and add the new sm750 > drm driver to staging. And after it is ready, we can go ahead with moving > it out of staging to drm. > > Greg? Daniel? I'll always take patches that delete code from staging :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103953] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=103953 --- Comment #3 from Dominik Paulus --- Created attachment 135754 --> https://bugs.freedesktop.org/attachment.cgi?id=135754&action=edit Xorg.log with dc disabled -- 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 libdrm 1/2] amdgpu: Switch amdgpu CS tests enabling to new API.
Am 27.11.2017 um 13:31 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
tests/amdgpu/amdgpu_test.c | 2 +-
tests/amdgpu/amdgpu_test.h | 5
tests/amdgpu/cs_tests.c| 64 +++---
3 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index ee64152..e611276 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -146,7 +146,7 @@ static Suites_Active_Status suites_active_stat[] = {
},
{
.pName = CS_TESTS_STR,
- .pActive = always_active,
+ .pActive = suite_cs_tests_enable,
},
{
.pName = VCE_TESTS_STR,
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index 414fcb8..3238e05 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -85,6 +85,11 @@ int suite_cs_tests_init();
int suite_cs_tests_clean();
/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_cs_tests_enable(void);
+
+/**
* Tests in cs test suite
*/
extern CU_TestInfo cs_tests[];
diff --git a/tests/amdgpu/cs_tests.c b/tests/amdgpu/cs_tests.c
index 3b2f17d..4880b74 100644
--- a/tests/amdgpu/cs_tests.c
+++ b/tests/amdgpu/cs_tests.c
@@ -66,6 +66,26 @@ CU_TestInfo cs_tests[] = {
CU_TEST_INFO_NULL,
};
+CU_BOOL suite_cs_tests_enable(void)
+{
+ if (amdgpu_device_initialize(drm_amdgpu[0], &major_version,
+&minor_version, &device_handle))
+ return CU_FALSE;
+
+ family_id = device_handle->info.family_id;
+
+ if (amdgpu_device_deinitialize(device_handle))
+ return CU_FALSE;
+
+
+ if (family_id >= AMDGPU_FAMILY_RV || family_id == AMDGPU_FAMILY_SI) {
+ printf("\n\nThe ASIC NOT support UVD, suite disabled\n");
+ return CU_FALSE;
+ }
+
+ return CU_TRUE;
+}
+
int suite_cs_tests_init(void)
{
amdgpu_bo_handle ib_result_handle;
@@ -90,11 +110,6 @@ int suite_cs_tests_init(void)
chip_rev = device_handle->info.chip_rev;
chip_id = device_handle->info.chip_external_rev;
- if (family_id >= AMDGPU_FAMILY_RV || family_id == AMDGPU_FAMILY_SI) {
- printf("\n\nThe ASIC NOT support UVD, all sub-tests will
pass\n");
- return CUE_SUCCESS;
- }
-
r = amdgpu_cs_ctx_create(device_handle, &context_handle);
if (r)
return CUE_SINIT_FAILED;
@@ -119,24 +134,18 @@ int suite_cs_tests_clean(void)
{
int r;
- if (family_id >= AMDGPU_FAMILY_RV || family_id == AMDGPU_FAMILY_SI) {
- r = amdgpu_device_deinitialize(device_handle);
- if (r)
- return CUE_SCLEAN_FAILED;
- } else {
- r = amdgpu_bo_unmap_and_free(ib_handle, ib_va_handle,
-ib_mc_address, IB_SIZE);
- if (r)
- return CUE_SCLEAN_FAILED;
-
- r = amdgpu_cs_ctx_free(context_handle);
- if (r)
- return CUE_SCLEAN_FAILED;
-
- r = amdgpu_device_deinitialize(device_handle);
- if (r)
- return CUE_SCLEAN_FAILED;
- }
+ r = amdgpu_bo_unmap_and_free(ib_handle, ib_va_handle,
+ib_mc_address, IB_SIZE);
+ if (r)
+ return CUE_SCLEAN_FAILED;
+
+ r = amdgpu_cs_ctx_free(context_handle);
+ if (r)
+ return CUE_SCLEAN_FAILED;
+
+ r = amdgpu_device_deinitialize(device_handle);
+ if (r)
+ return CUE_SCLEAN_FAILED;
return CUE_SUCCESS;
}
@@ -203,9 +212,6 @@ static void amdgpu_cs_uvd_create(void)
void *msg;
int i, r;
- if (family_id >= AMDGPU_FAMILY_RV || family_id == AMDGPU_FAMILY_SI)
- return;
-
req.alloc_size = 4*1024;
req.preferred_heap = AMDGPU_GEM_DOMAIN_GTT;
@@ -277,9 +283,6 @@ static void amdgpu_cs_uvd_decode(void)
uint8_t *ptr;
int i, r;
- if (family_id >= AMDGPU_FAMILY_RV || family_id == AMDGPU_FAMILY_SI)
-return;
-
req.alloc_size = 4*1024; /* msg */
req.alloc_size += 4*1024; /* fb */
if (family_id >= AMDGPU_FAMILY_VI)
@@ -419,9 +422,6 @@ static void amdgpu_cs_uvd_destroy(void)
void *msg;
int i, r;
- if (family_id >= AMDGPU_FAMILY_RV || family_id == AMDGPU_FAMILY_SI)
-return;
-
req.alloc_size = 4*1024;
req.preferred_heap = AMDGPU_GEM_DOMAIN_GTT;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] staging: ion: reorder include
On Mon, Nov 06, 2017 at 04:59:44PM +0100, Benjamin Gaignard wrote: > Put include in alphabetic order Why??? That should not matter at all. I'll take this, but really, ick ick ick ick ick. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] staging: ion: create one device entry per heap
On Mon, Nov 06, 2017 at 04:59:45PM +0100, Benjamin Gaignard wrote:
> Instead a getting only one common device "/dev/ion" for
> all the heaps this patch allow to create one device
> entry ("/dev/ionX") per heap.
> Getting an entry per heap could allow to set security rules
> per heap and global ones for all heaps.
>
> Allocation requests will be only allowed if the mask_id
> match with device minor.
> Query request could be done on any of the devices.
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/staging/android/TODO| 1 -
> drivers/staging/android/ion/Kconfig | 7
> drivers/staging/android/ion/ion-ioctl.c | 18 --
> drivers/staging/android/ion/ion.c | 62
> +
> drivers/staging/android/ion/ion.h | 15 ++--
> 5 files changed, 91 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> index 687e0ea..8a11931 100644
> --- a/drivers/staging/android/TODO
> +++ b/drivers/staging/android/TODO
> @@ -8,7 +8,6 @@ TODO:
> ion/
> - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
> involve putting appropriate bindings in a memory node for Ion to find.
> - - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> - Better test framework (integration with VGEM was suggested)
>
> Please send patches to Greg Kroah-Hartman and Cc:
> diff --git a/drivers/staging/android/ion/Kconfig
> b/drivers/staging/android/ion/Kconfig
> index a517b2d..cb4666e 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -10,6 +10,13 @@ menuconfig ION
> If you're not using Android its probably safe to
> say N here.
>
> +config ION_LEGACY_DEVICE_API
> + bool "Keep using Ion legacy misc device API"
> + depends on ION
You want to default to Y here, so when you do 'make oldconfig' nothing
breaks, right?
> + help
> + Choose this option to keep using Ion legacy misc device API
> + i.e. /dev/ion
You need more text here to describe the trade offs. Why would I not
want to keep doing this? What does turning this off get me? What does
keeping it on keep me from doing?
> +
> config ION_SYSTEM_HEAP
> bool "Ion system heap"
> depends on ION
> diff --git a/drivers/staging/android/ion/ion-ioctl.c
> b/drivers/staging/android/ion/ion-ioctl.c
> index e26b786..bb5c77b 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -25,7 +25,8 @@ union ion_ioctl_arg {
> struct ion_heap_query query;
> };
>
> -static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
> +static int validate_ioctl_arg(struct file *filp,
> + unsigned int cmd, union ion_ioctl_arg *arg)
> {
> switch (cmd) {
> case ION_IOC_HEAP_QUERY:
> @@ -34,6 +35,19 @@ static int validate_ioctl_arg(unsigned int cmd, union
> ion_ioctl_arg *arg)
> arg->query.reserved2 )
> return -EINVAL;
> break;
> +
> + case ION_IOC_ALLOC:
> + {
> + int mask = 1 << iminor(filp->f_inode);
> +
> +#ifdef CONFIG_ION_LEGACY_DEVICE_API
> + if (imajor(filp->f_inode) == MISC_MAJOR)
> + return 0;
Why return 0? Because it is already allocated?
Some comments here as to exactly what you are doing would be nice.
> +#endif
> + if (!(arg->allocation.heap_id_mask & mask))
This doesn't allocate anthing, just check to see if it is?
> + return -EINVAL;
> + break;
> + }
> default:
> break;
> }
> @@ -69,7 +83,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
> unsigned long arg)
> if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd)))
> return -EFAULT;
>
> - ret = validate_ioctl_arg(cmd, &data);
> + ret = validate_ioctl_arg(filp, cmd, &data);
> if (WARN_ON_ONCE(ret))
> return ret;
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index fda9756..2c2568b 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -40,6 +40,9 @@
>
> #include "ion.h"
>
> +#define ION_DEV_MAX 32
Why 32? Where did that number come from?
> +#define ION_NAME "ion"
> +
> static struct ion_device *internal_dev;
> static int heap_id;
>
> @@ -535,15 +538,38 @@ static int debug_shrink_get(void *data, u64 *val)
> DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
> debug_shrink_set, "%llu\n");
>
> -void ion_device_add_heap(struct ion_heap *heap)
> +static struct device ion_bus = {
> + .init_name = ION_NAME,
> +};
Oh look, a struct device on the stack. Watch bad things happen :(
This is a dynamic device, make it dynamic, or else you had better know
exactly what you are doing...
> +
> +static str
Re: [PATCH v6 1/2] staging: ion: reorder include
2017-11-28 14:20 GMT+01:00 Greg KH : > On Mon, Nov 06, 2017 at 04:59:44PM +0100, Benjamin Gaignard wrote: >> Put include in alphabetic order > > Why??? Mainly because the next patch in the series adds new includes and I have decide to split clean-up and new feature patches > > That should not matter at all. > > I'll take this, but really, ick ick ick ick ick. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 0/7] drm/fbdev: Panel orientation connector property support
Hi, On 28-11-17 11:27, Daniel Vetter wrote: On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote: Hi All, Here is v6 of my series to add a "panel orientation" property to the drm-connector for the LCD panel to let userspace know about LCD panels which are not mounted upright, as well as detecting upside-down panels without needing quirks (like we do for 90 degree rotated screens). Bartlomiej, can we please have your Acked-by for merging patches 1, 6 and 7 through the drm tree? New in v6: -Fix / reference kernel-doc comments -Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI -Move i915 dsi hardware rotation state read-out to intel_dsi_init() New in v5: -Add kernel-doc comment documenting drm_get_panel_orientation_quirk() -drm_fb_helper: Only use hardware (crtc primary plane) rotation for 180 degrees for now as 9-/270 degrees rotation requires special handling New in v4: -Fix drm_fb_helper code setting an invalid rotation value on the primary plane of disabled/unused crtcs (caught by Fi.CI) New in v3: -As requested by Daniel v3 moves the quirks over from the fbdev subsys to the drm subsys. I've done this by simpy starting with a copy of the quirk table and eventually removing the fbdev version. The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5 are all drm patches and patches 6-7 are fbdev/fbcon patches again. As discussed previously the plan is to merge all 7 patches through the drm tree. I think from the drm and i915 side of things this all looks ready (well pls double-check that CI also approves before merging). The CI says state is warning, see: https://patchwork.freedesktop.org/series/32447/ and specifically: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7290/shards.html Which I find hard to read as I see no tests going to orange, only 3 tests moving to red, which AFAICT is failed. Clicking on the tests link to get history all 3 tests seem to fail in the same way quite often (2 out of 3) or somewhat often (the last one). Also the failures seem unrelated to my changes So how do I deal with this, resend v7 to get CI to run again and hope I get a success result for all tests this time ? Just needs an ack/review from Bart, and then it's probably simplest if you merge it all through drm-misc - the i915 side is tiny. Ok, I will wait for an Ack from Bart and then merge this through drm-misc, thank you for the review. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] staging: ion: reorder include
On Tue, Nov 28, 2017 at 02:34:00PM +0100, Benjamin Gaignard wrote: > 2017-11-28 14:20 GMT+01:00 Greg KH : > > On Mon, Nov 06, 2017 at 04:59:44PM +0100, Benjamin Gaignard wrote: > >> Put include in alphabetic order > > > > Why??? > > Mainly because the next patch in the series adds new includes and I have > decide to split clean-up and new feature patches That's fine, but this really isn't needed for any type of "clean-up" at all. But oh well, if you all like it that way, I'm not going to complain that much :) greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
Hi Daniel,
On 2017-11-20 08:33, Daniel Vetter wrote:
On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:
2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
On 26 October 2017 at 11:37, Inki Dae wrote:
Improving Exynos DRM HDMI and Mixer drivers and also adding
HDMI audio support.
Please kindly let me know if there is any problem.
Ps. we are reviewing IPP v2 driver[1] which controls post processor devices
such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request
git pull one more time after review.
I dropped the ball a bit here, I do think the second pull with IPP is
probably a bit late,
I think I'd like more assurance that the UAPI for IPP is to be used in
some upstream
shipping project (forks of mpv not withstanding, unless this fork
ships in some distro
or product).
I also commented same thing internally to author - Marek - of IPP v2 but I
thought existing one is really ugly thing so may be better to change it as soon
as possible before other users use this one.
Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux
platform. I hope IPPv2 would be merged as soon as possible in next turn.
Beyond what Daniel said we unfortunately don't have time machines, so
fixing bad uapi isn't really possible. The problem is that even if you
create ippv2, then people can still use ippv1, and it needs to keep
working (almost) forever. So once a bad uapi is in, it's in, and there's
no good reason to add more uapi (since in 2 years you might again realize
it's not a good idea) to "fix" that. You can't fix bad uapi.
That's why we have all these rules to make sure as little bad uapi as
possible lands, since the cost is so bad.
So yeah unless you have new hw that needs it, or there's another clear
need (performance, features), you're stuck with ippv1. "It's cleaner" is
not a good reason to rev uapi, since our experience with all the uapi in
drm clearly shows we can't predict the future :-)
I generally agree that UAPI interface has to be stable and well designed.
There are however some 'features' IPPv1 uapi that really allows us to
obsolete it:
1. IPP API can be optional in Exynos DRM, so userspace should not rely that
it is always available and should have a software fallback in case it is not
available.
2. The only mode which was initially semi-working was memory-to-memory. The
remaining modes (lcd-writeback and output) were never operational (both in
mainline and even vendor kernels).
3. IPP mainline uapi compatibility for memory-to-memory got broken very
early by commit 083500baefd5f4c215a5a93aef2492c1aa775828 ("drm: remove
DRM_FORMAT_NV12MT", which removed the support for tiled formats, the main
feature which made this api somehow useful on Exynos platforms (video codec
that time produced only tiled frames, to implement xvideo or any other
video overlay, one has to detile them for proper display).
4. Broken drivers. Especially once support for IOMMU has been added, it
revealed that drivers don't configure DMA operations properly and in many
cases operate outside the provided buffers trashing memory around.
5. Need for external patches. Although IPP uapi has been used in some
vendor kernels, but in such cases there were additional patches applied
(like reverting mentioned 083500baefd5 patch) what means that those
userspace apps which might use it, still won't work with the mainline
version.
Right, as you already said we don't have time machines, so we cannot change
it, but IPP extension should never have been merged to mainline in that
form.
We can however obsolete it now as it is really non-functional and frankly
speaking dead-code. If you agree with the above than at least the first
patch can be merged, which clearly marks that Exynos IPP is broken and
ever really functional. I bet no one will complain. Then we can continue
the discussion about IPPv2 uapi/patches.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/17] drm/sun4i: Add CCSC property to DE2 configuration
在 2017-11-28 04:57，Jernej Skrabec 写道：
Base addresses of channel output CSC (CCSC) depends whether mixer in
question is first or second and if it is second, if supports VEP or
not.
This new property will tell which set of base addresses to take.
0 - first mixer or second mixer with VEP support
1 - second mixer without VEP support
Maxime,
I think here the ID of the mixer matters.
P.S. I didn't found any SoC with a second mixer with VEP currently
Thanks!
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 7c9c87a0535b..2276eff8798d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -622,6 +622,7 @@ static const struct sun8i_mixer_cfg
sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
.scaler_mask = 0x3,
+ .ccsc = 0,
Jernej, the lowlevel_sun8iw8/de_feat.c in the BSP DE2 source code
claims that V3/V3s have no VEP support even for mixer0.
};
static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 355a45e6cfb4..4fcf1653e345 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -136,6 +136,7 @@ struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
int scaler_mask;
+ int ccsc;
};
struct sun8i_mixer {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/18] drm/sun4i: Add A83T support
在 2017-11-28 17:02，Maxime Ripard 写道：
Hi,
On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard
napisal(a):
> Add support for the A83T display pipeline.
>
> Reviewed-by: Chen-Yu Tsai
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
> drivers/gpu/drm/sun4i/sun4i_tcon.c| 5 +
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 4
> 4 files changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> d4259a4f5171..d6b52e5c48c0 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -93,6 +93,7 @@ Required properties:
> * allwinner,sun6i-a31s-tcon
> * allwinner,sun7i-a20-tcon
> * allwinner,sun8i-a33-tcon
> + * allwinner,sun8i-a83t-tcon-lcd
> * allwinner,sun8i-v3s-tcon
> - reg: base address and size of memory-mapped region
> - interrupts: interrupt associated to this IP
> @@ -224,6 +225,7 @@ supported.
>
> Required properties:
>- compatible: value must be one of:
> +* allwinner,sun8i-a83t-de2-mixer
What will be the name of the second mixer, once support for HDMI is
added?
Should we start directly with 0 and 1 postfix ?
What are the differences exactly without the two mixers?
I was hoping to be able to cover them all using properties, indices
are usually pretty badly received in compatibles.
1. VEP is only available on the VI channel in mixer0. (VEP may mean
Video Enhance Processor)
2. Smart Backlight is only available in mixer0's on SoCs with LCD.
3. Writeback function is only available in mixer0.
> static const struct of_device_id sun8i_mixer_of_table[] = {
>{
> + .compatible = "allwinner,sun8i-a83t-de2-mixer",
> + .data = &sun8i_v3s_mixer_cfg,
> + },
> + {
Maybe you want to squash 12 patch since this works only by luck.
Yeah, I totally meant to do that :)
Thanks!
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Tue, Nov 28, 2017 at 12:04:04AM -0800, Joe Perches wrote: > On Tue, 2017-11-28 at 08:41 +0100, SF Markus Elfring wrote: > > > > It seems that I got no responses so far for clarification requests > > > > according to the documentation in a direction I hoped for. > > > > > > That's because you are pretty unresponsive to direction. > > > > From which places did you get this impression? > > How many times have I told you to include the reason for > your patches in > your proposed commit message? Too often. > > For instance, specific to this patch: > > Many people do not know that a generic kmalloc does a > dump_stack() on OOM. That information should be part > of the commit message. > > Also removing the printk code reduces overall code size. > The actual size reduction should be described in the > commit message too. Could we, please, return one step back and reevaluate need for kmalloc. That would eliminate original "problem" as well. ladis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/guc: Fix doc reference to intel_guc_fw.c
On Tue, Nov 28, 2017 at 09:51:13AM +0100, Michal Wajdeczko wrote:
> On Tue, 28 Nov 2017 07:50:52 +0100, Jonathan Neuschäfer
> wrote:
>
> > Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
> > The file has been renamed.
> >
> > Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
> > intel_guc_fw.c")
> > Cc: Michal Wajdeczko
> > Signed-off-by: Jonathan Neuschäfer
> > ---
> > Documentation/gpu/i915.rst | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 2e7ee0313c1c..e21698e16534 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -341,10 +341,10 @@ GuC
> > GuC-specific firmware loader
> >
> > -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
> > :doc: GuC-specific firmware loader
> > -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
> > :internal:
> > GuC-based command submission
>
> + Ville
>
> Well, this will fix sphinx error, but in my opinion it will not make
> i915 documentation any better. See my earlier patch/comments in [1].
Thanks for the pointer.
Hmm, right, given that there's no "DOC:" line in intel_guc_fw.c anymore,
the ":doc:" directive above is not useful.
As a tiny step towards more complete documentation (and to keep people
from patching this spot again ;), IMHO it makes sense to do this (it's
of course up to the maintainers whether they agree):
---
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee0313c1c..e94d3ac2bdd0 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,7 @@ GuC
GuC-specific firmware loader
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
- :doc: GuC-specific firmware loader
-
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
GuC-based command submission
---
> So maybe better to wait for other comments which way to go.
Makes sense.
Thanks,
Jonathan Neuschäfer
>
> Thanks for the patch,
> Michal
>
> [1] https://patchwork.freedesktop.org/patch/188424/
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Tue, Nov 28, 2017 at 11:15:37AM +0100, SF Markus Elfring wrote:
> >>> Many people do not know that a generic kmalloc does a
> >>> dump_stack() on OOM.
> >>
> >> This is another interesting information, isn't it?
> >>
> >> It is expected that the function “devm_kzalloc” has got a similar property.
> >
> >
> > You don't have to expect this. Go look at the definition of devm_kzalloc
> > and see whether it has the property or not.
>
> I find that the corresponding documentation of these programming interfaces
> is incomplete for a desired format which could be different than C source
> code.
>
> https://elixir.free-electrons.com/linux/v4.15-rc1/source/include/linux/device.h#L657
> https://elixir.free-electrons.com/linux/v4.15-rc1/source/drivers/base/devres.c#L763
> https://www.kernel.org/doc/html/latest/driver-api/basics.html#c.devm_kmalloc
>
> Can the Coccinelle software help more to determine desired function
> properties?
>
>
> >> For which hardware and software combinations would you like to see
> >> facts there?
> >
> > This is not for Joe to decide,
>
> This view is fine in principle.
>
>
> > it's for the person who receives the patch to decide.
>
> I am curious on further comments from these contributors.
>
>
> > You could start with the ones for which the code actually compiles,
> > using the standard make file and no special options, and a
> > recent version of gcc.
>
> The variation space could become too big to handle for me (alone).
> How will this aspect evolve further?
I do not follow. This is OMAP framebuffer driver, so in this case, there
is zero variation. Could you, please, review following patch and verify
is it satisfies your automated static code analysis test?
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 7a75dfda9845..6be13a106ece 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -3976,52 +3976,33 @@ static const struct dispc_features omap54xx_dispc_feats
= {
.has_writeback = true,
};
-static int dispc_init_features(struct platform_device *pdev)
+static const struct dispc_features* dispc_get_features(void)
{
- const struct dispc_features *src;
- struct dispc_features *dst;
-
- dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
- if (!dst) {
- dev_err(&pdev->dev, "Failed to allocate DISPC Features\n");
- return -ENOMEM;
- }
-
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
- src = &omap24xx_dispc_feats;
- break;
+ return &omap24xx_dispc_feats;
case OMAPDSS_VER_OMAP34xx_ES1:
- src = &omap34xx_rev1_0_dispc_feats;
- break;
+ return &omap34xx_rev1_0_dispc_feats;
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
case OMAPDSS_VER_AM43xx:
- src = &omap34xx_rev3_0_dispc_feats;
- break;
+ return &omap34xx_rev3_0_dispc_feats;
case OMAPDSS_VER_OMAP4430_ES1:
case OMAPDSS_VER_OMAP4430_ES2:
case OMAPDSS_VER_OMAP4:
- src = &omap44xx_dispc_feats;
- break;
+ return &omap44xx_dispc_feats;
case OMAPDSS_VER_OMAP5:
case OMAPDSS_VER_DRA7xx:
- src = &omap54xx_dispc_feats;
- break;
+ return &omap54xx_dispc_feats;
default:
- return -ENODEV;
+ return NULL;
}
-
- memcpy(dst, src, sizeof(*dst));
- dispc.feat = dst;
-
- return 0;
}
static irqreturn_t dispc_irq_handler(int irq, void *arg)
@@ -4078,9 +4059,9 @@ static int dispc_bind(struct device *dev, struct device
*master, void *data)
spin_lock_init(&dispc.control_lock);
- r = dispc_init_features(dispc.pdev);
- if (r)
- return r;
+ dispc.feat = dispc_get_features();
+ if (!dispc.feat)
+ return -ENODEV;
dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
if (!dispc_mem) {
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 48c6500c24e1..9a255ffe77c5 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -887,58 +887,37 @@ static const struct dss_features dra7xx_dss_feats = {
.num_ports = ARRAY_SIZE(dra7xx_ports),
};
-static int dss_init_features(struct platform_device *pdev)
+static const struct dss_features* dss_get_features(void)
{
- const struct dss_features *src;
- struct dss_features *dst;
-
- dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
- if (!dst) {
- dev_err(&pdev->dev, "Failed to allocate local DSS Features\n");
-
AW: [PATCH 4/5] ARM: dts: Add support for emtrion emCON-MX6 series
Hi Rob,
thanks for your feedback, the changes will be included in V2 of the
patch-series.
Jan
> Von: Rob Herring
> Gesendet: Sonntag, 26. November 2017 20:24
> On Thu, Nov 23, 2017 at 01:55:54PM +0100, Jan Tuerk wrote:
> > This patch adds support for the emtrion GmbH emCON-MX6 modules.
> > They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> > equipped with Memory from 512MB to 2GB (configured by U-Boot).
[...]
> > +&i2c3 {
> > + clock-frequency = <10>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c3>;
> > + status = "okay";
> > +
> > + sgtl5000: sgtl5000@0a {
>
> audio-codec@a
>
> same errors repeat below.
changed for v2
>
> > + compatible = "fsl,sgtl5000";
> > + reg = <0x0a>;
> > + clocks = <&sndosc>;
> > + VDDA-supply = <&base3p3>;
> > + VDDIO-supply = <&base3p3>;
> > + };
> > +
> > + boardID: pca8754a@3A {
>
> ...@3a
changed in V2
>
> > + compatible = "nxp,pca8574";
> > + reg = <0x3A>;
>
> 0x3a
>
> > + gpio-controller;
> > + #gpio-cells = <1>;
> > + };
> > +
> > + captouch: edt-ft5x06@38 {
>
> touchscreen@38
>
> > + reg = <0x38>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_irq_touch2 &pinctrl_emcon_gpio4>;
> > + interrupt-parent = <&gpio6>;
> > + interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
> > + compatible = "edt,edt-ft5406";
> > + wake-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
> > + wakeup-source;
> > + };
> > +};
> > +
> > +&ssi2 {
> > + status = "okay";
> > +};
> > +
> > +&rgb_encoder {
> > + status = "okay";
> > +};
> > +
[...]
> > +
> > + rgb_panel: panel {
> > + backlight = <&rgb_backlight>;
> > + power-supply = <®_prallel_disp>;
> > + port {
> > + rgb_panel_in: endpoint {
> > + remote-endpoint = <&rgb_encoder_out>;
> > + };
> > + };
> > + };
> > +
> > + rgb_backlight: rgb_backlight {
>
> rgb-backlight {
[...]
> > +
> > + lvds_backlight: lvds_backlight {
>
> lvds-backlight {
Ok, I'll change that in V2
[...]
> > +
> > +&i2c1 {
> > + clock-frequency = <10>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c1>;
> > + status = "okay";
> > +
> > + rtc: rtc@68 {
> > + compatible = "dallas,ds1307";
> > + reg = <0x68>;
> > + };
> > +
> > + da9063: da9063@58 {
>
> pmic@38
changed
>
> > + compatible = "dlg,da9063";
> > + reg = <0x58>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pmic>;
> > + interrupt-parent = <&gpio2>;
> > +
[]
> > +
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ksz9031: phy {
>
> phy@0
>
> Building with W=2 or W=1 will tell you this.
thanks for the hint, it will be also included in v2
>
> > + reg = <0>;
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + interrupt-parent = <&gpio1>;
> > + interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
> > + rxdv-skew-ps = <480>;
> > + txen-skew-ps = <480>;
[...]
emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___
Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions
On Tue, Nov 28, 2017 at 11:50:14AM +0100, SF Markus Elfring wrote: > >> How will this aspect evolve further? > > > > I do not follow. > > Interesting … > > > This is OMAP framebuffer driver, so in this case, there is zero variation. > > How much are you interested to compare differences in build results > also for this software module because of varying parameters? > > Which parameters were applied for your size comparisons so far? It was just omap2plus_defconfig build using gcc-7.2.0 > > Could you, please, review following patch > > I assume that other OMAP developers are in a better position to decide > about the deletion of extra memory allocations (instead of keeping > questionable error messages). > > > and verify is it satisfies your automated static code analysis test? > > I am not going to “verify” your update suggestion by my evolving approaches > around the semantic patch language (Coccinelle software) at the moment. As you are sending patches as Markus Elfring I would expect you take Coccinelle's suggestion into account and actually try to understand code before sending patch. That suggestion may lead to actual bug in code which your patch just leaves unnoticed as it is not apparent from the patch itself (no, not talking about this very patch it all started with) That said, I'm considering Markus Elfring being a human. If you do not like reactions to your patches or are interested only in improving tool that generates them, it would be better to just setup a "tip bot for Markus Elfring" and let it send patches automatically. This way noone is going to waste time on them as it would be clear those are purely machine only generated and there's no point to reply. The way you are sending patches makes impression (at least to me), that you spent some time on fixing issue Coccinelle found and not just shut the warning up. > But I thank you for this contribution. > How will further feedback evolve for such an idea? And the idea is? > Regards, > Markus Thank you, ladis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: Fix modifiers_property kernel-doc comment
Hi,
On 28-11-17 11:28, Daniel Vetter wrote:
On Sat, Nov 25, 2017 at 08:27:31PM +0100, Hans de Goede wrote:
This fixes the following make kerneldocs messages:
./include/drm/drm_mode_config.h:772: warning: No description found for
parameter 'modifiers_property'
./include/drm/drm_mode_config.h:772: warning: Excess struct member 'modifiers'
description in 'drm_mode_config'
Signed-off-by: Hans de Goede
Reviewed-by: Daniel Vetter
Pls push to drm-misc-next, thanks.
Ville Syrjälä has already fixed this, but I missed that because the
fix was not yet in dinq when I prepared my panel-orientation patch
series.
Regards,
Hans
-Daniel
---
include/drm/drm_mode_config.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3716e6b8fed5..cb9ffbda36cc 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -759,7 +759,7 @@ struct drm_mode_config {
bool allow_fb_modifiers;
/**
-* @modifiers: Plane property to list support modifier/format
+* @modifiers_property: Plane property to list support modifier/format
* combination.
*/
struct drm_property *modifiers_property;
--
2.14.3
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/vmwgfx: Initial DX support
Hello Thomas Hellstrom,
The patch d80efd5cb3de: "drm/vmwgfx: Initial DX support" from Aug 10,
2015, leads to the following static checker warning:
drivers/gpu/drm/vmwgfx/vmwgfx_so.c:335 vmw_view_add()
error: buffer overflow 'vmw_view_define_sizes' 3 <= 3
drivers/gpu/drm/vmwgfx/vmwgfx_so.c
2709 static int vmw_cmd_dx_view_define(struct vmw_private *dev_priv,
2710struct vmw_sw_context *sw_context,
2711SVGA3dCmdHeader *header)
2712 {
2713 struct vmw_resource_val_node *ctx_node =
sw_context->dx_ctx_node;
2714 struct vmw_resource_val_node *srf_node;
2715 struct vmw_resource *res;
2716 enum vmw_view_type view_type;
2717 int ret;
2718 /*
2719 * This is based on the fact that all affected define commands
have
2720 * the same initial command body layout.
2721 */
2722 struct {
2723 SVGA3dCmdHeader header;
2724 uint32 defined_id;
2725 uint32 sid;
2726 } *cmd;
2727
2728 if (unlikely(ctx_node == NULL)) {
2729 DRM_ERROR("DX Context not set.\n");
2730 return -EINVAL;
2731 }
2732
2733 view_type = vmw_view_cmd_to_type(header->id);
^
view_type is set to vmw_view_max for unknown values.
2734 cmd = container_of(header, typeof(*cmd), header);
2735 ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
2736 user_surface_converter,
2737 &cmd->sid, &srf_node);
2738 if (unlikely(ret != 0))
2739 return ret;
2740
2741 res = vmw_context_cotable(ctx_node->res,
vmw_view_cotables[view_type]);
^
but we use it without checking vmw_view_id_ok().
2742 ret = vmw_cotable_notify(res, cmd->defined_id);
2743 vmw_resource_unreference(&res);
2744 if (unlikely(ret != 0))
2745 return ret;
2746
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix potential NULL pointer dereferences in amdgpu_dm_atomic_commit_tail
Reviewed-by: Andrey Grodzovsky
Thanks,
Andrey
On 11/27/2017 09:57 AM, Gustavo A. R. Silva wrote:
dm_new_crtc_state->stream and disconnected_acrtc are being dereferenced
before they are null checked, hence there is a potential null pointer
dereference.
Fix this by null checking such pointers before they are dereferenced.
Addresses-Coverity-ID: 1423745 ("Dereference before null check")
Addresses-Coverity-ID: 1423833 ("Dereference before null check")
Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm")
Fixes: 54d765752467 ("drm/amd/display: Unify amdgpu_dm state variable namings.")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 889ed24..3bdd137 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4190,6 +4190,9 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ if (!dm_new_crtc_state->stream)
+ continue;
+
update_stream_scaling_settings(&dm_new_con_state->base.crtc->mode,
dm_new_con_state, (struct dc_stream_state
*)dm_new_crtc_state->stream);
@@ -4197,9 +4200,6 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)
WARN_ON(!status);
WARN_ON(!status->plane_count);
- if (!dm_new_crtc_state->stream)
- continue;
-
/*TODO How it works with MPO ?*/
if (!dc_commit_planes_to_stream(
dm->dc,
@@ -4332,9 +4332,11 @@ void dm_restore_drm_connector_state(struct drm_device
*dev,
return;
disconnected_acrtc = to_amdgpu_crtc(connector->encoder->crtc);
- acrtc_state = to_dm_crtc_state(disconnected_acrtc->base.state);
+ if (!disconnected_acrtc)
+ return;
- if (!disconnected_acrtc || !acrtc_state->stream)
+ acrtc_state = to_dm_crtc_state(disconnected_acrtc->base.state);
+ if (!acrtc_state->stream)
return;
/*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
