Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection
On 12/15/18 2:47 AM, Christoph Hellwig wrote: On Fri, Dec 14, 2018 at 10:30:18PM -0800, Guenter Roeck wrote: and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem. Hi Guenter, can you check which of the three new ops is used in this case? Or provide the qemu config and rootfs? sparc32 defconfig+CONFIG_SQUASHFS=y+CONFIG_DEVTMPFS=y, and: qemu-system-sparc -M SPARCClassic -kernel arch/sparc/boot/image \ -no-reboot -snapshot -drive file=/var/cache/buildbot/sparc/hda.sqf,if=scsi,format=raw \ -append 'root=/dev/sda rw init=/sbin/init.sh panic=1 console=ttyS0' \ -nographic qemu version doesn't seem to matter. I used gcc-7.3.0 using the toolchain from kernel.org to build the image. Root file system is at https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc/. Guenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes
+Rob +Stephen,
On 14-12-18, 09:04, Doug Anderson wrote:
> Hi,
>
> On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar wrote:
> >
> > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > + gpu_opp_table: opp-table {
> > > + compatible =
> > > "operating-points-v2-qcom-level";
> >
> > I think you need to mention "operating-points-v2" as well here.
>
> Are you saying the above should be:
> compatible = "operating-points-v2-qcom-level", "operating-points-v2";
>
> If so I'm not sure I agree.
Well I have my doubts as well on this. This is where the ordering was discussed
earlier:
https://lore.kernel.org/lkml/152328979897.180276.15963925877442657...@swboyd.mtv.corp.google.com/
@Rob/Stephen: Should the opp-table node above also have "operating-points-v2"
string in the compatible property ?
> It's _not_ really compatible with the
> "operating-points-v2" binding. If you had a driver that had never
> heard of "operating-points-v2-qcom-level" and had only heard of
> "operating-points-v2" and it took a look at this node it would have no
> idea what to do with it.
Well it will parse everything apart from the qcom,level thing, so it can
actually parse stuff here.
> I'll also note that other instances posted to the list don't list both:
>
> https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
> https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for sdm845
>
> The bindings patch also makes no mention of needing
> "operating-points-v2". I think the common case when a fallback is
> required it is explicitly called out in the bindings:
>
> https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings
Sure, maybe I am wrong but its better to get some clarity on it from
Rob/Stephen.
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] video: lcd: Remove useless BACKLIGHT_LCD_SUPPORT kernel symbol
Symbol BACKLIGHT_LCD_SUPPORT affecting anything, except enabling the backlight & LCD Kconfig menu. The patch removes this symbol as useless and converts it into a menu. Signed-off-by: Alexander Shiyan --- arch/unicore32/Kconfig| 1 - drivers/gpu/drm/Kconfig | 2 -- drivers/gpu/drm/bridge/Kconfig| 1 - drivers/gpu/drm/fsl-dcu/Kconfig | 1 - drivers/gpu/drm/i915/Kconfig | 1 - drivers/gpu/drm/nouveau/Kconfig | 1 - drivers/gpu/drm/shmobile/Kconfig | 1 - drivers/gpu/drm/tilcdc/Kconfig| 1 - drivers/staging/olpc_dcon/Kconfig | 1 - drivers/usb/misc/Kconfig | 1 - drivers/video/backlight/Kconfig | 10 ++ drivers/video/fbdev/Kconfig | 5 - 12 files changed, 2 insertions(+), 24 deletions(-) diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig index a4c0515..afeea3d 100644 --- a/arch/unicore32/Kconfig +++ b/arch/unicore32/Kconfig @@ -211,7 +211,6 @@ config I2C_EEPROM_AT24 config LCD_BACKLIGHT tristate "LCD Backlight support" - select BACKLIGHT_LCD_SUPPORT select BACKLIGHT_PWM endmenu diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 4385f00..ef442a7 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -198,7 +198,6 @@ config DRM_RADEON select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE - select BACKLIGHT_LCD_SUPPORT select INTERVAL_TREE help Choose this option if you have an ATI Radeon graphics card. There @@ -219,7 +218,6 @@ config DRM_AMDGPU select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE - select BACKLIGHT_LCD_SUPPORT select INTERVAL_TREE select CHASH help diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 9eeb8ef..0f724e2 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -75,7 +75,6 @@ config DRM_PARADE_PS8622 depends on OF select DRM_PANEL select DRM_KMS_HELPER - select BACKLIGHT_LCD_SUPPORT select BACKLIGHT_CLASS_DEVICE ---help--- Parade eDP-LVDS bridge chip driver. diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig index 14a72c4..dc82588 100644 --- a/drivers/gpu/drm/fsl-dcu/Kconfig +++ b/drivers/gpu/drm/fsl-dcu/Kconfig @@ -2,7 +2,6 @@ config DRM_FSL_DCU tristate "DRM Support for Freescale DCU" depends on DRM && OF && ARM && COMMON_CLK select BACKLIGHT_CLASS_DEVICE - select BACKLIGHT_LCD_SUPPORT select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_PANEL diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 33a458b..90d406e73 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -15,7 +15,6 @@ config DRM_I915 select IRQ_WORK # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick - select BACKLIGHT_LCD_SUPPORT if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI select INPUT if ACPI select ACPI_VIDEO if ACPI diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 4b75ad40..a0238bf 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -11,7 +11,6 @@ config DRM_NOUVEAU select MXM_WMI if ACPI && X86 select POWER_SUPPLY # Similar to i915, we need to select ACPI_VIDEO and it's dependencies - select BACKLIGHT_LCD_SUPPORT if ACPI && X86 select BACKLIGHT_CLASS_DEVICE if ACPI && X86 select INPUT if ACPI && X86 select THERMAL if ACPI && X86 diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig index 61bbe8e..e2a6c82 100644 --- a/drivers/gpu/drm/shmobile/Kconfig +++ b/drivers/gpu/drm/shmobile/Kconfig @@ -4,7 +4,6 @@ config DRM_SHMOBILE depends on DRM && ARM depends on ARCH_SHMOBILE || COMPILE_TEST select BACKLIGHT_CLASS_DEVICE - select BACKLIGHT_LCD_SUPPORT select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig index 5259804..cb7df20 100644 --- a/drivers/gpu/drm/tilcdc/Kconfig +++ b/drivers/gpu/drm/tilcdc/Kconfig @@ -8,7 +8,6 @@ config DRM_TILCDC select DRM_PANEL_BRIDGE select VIDEOMODE_HELPERS select BACKLIGHT_CLASS_DEVICE - select BACKLIGHT_LCD_SUPPORT help Choose this option if you have an TI SoC with LCDC display controller, for example AM33xx in beagle-bone, DA8xx, or diff --git a/drivers/staging/olpc_dcon/Kconfig b/drivers/staging/olpc_dcon/Kconfig index 192cc8d..c91a56f 100644 --- a/drivers/staging/olpc_dcon/Kconfig +++ b/drivers/staging/olpc_dcon/Kconfig @@ -2,7 +2,6 @@ config FB_OLPC_DCON tristate "One
[PATCH 6/6] drm/exynos: mixer: Make input buffer color range configurable
Mixer hardware supports RGB input buffers with full and limited range.
Set the csc matrix accordingly to chosen range. Note that range setting
has to be equal for both graphic layers.
Signed-off-by: Christoph Manszewski
---
drivers/gpu/drm/exynos/exynos_mixer.c | 57 ---
drivers/gpu/drm/exynos/regs-mixer.h | 2 ++
2 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 895c6268025d..035d635188d7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -35,6 +35,8 @@
#include
#include
+#include
+#include
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
@@ -133,7 +135,9 @@ static const struct exynos_drm_plane_config
plane_configs[MIXER_WIN_NR] = {
.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE |
EXYNOS_DRM_PLANE_CAP_ZPOS |
EXYNOS_DRM_PLANE_CAP_PIX_BLEND |
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND |
+ EXYNOS_DRM_PLANE_CAP_RANGE,
+ .range = DRM_COLOR_FULL_RANGE,
}, {
.zpos = 1,
.type = DRM_PLANE_TYPE_CURSOR,
@@ -142,7 +146,9 @@ static const struct exynos_drm_plane_config
plane_configs[MIXER_WIN_NR] = {
.capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE |
EXYNOS_DRM_PLANE_CAP_ZPOS |
EXYNOS_DRM_PLANE_CAP_PIX_BLEND |
- EXYNOS_DRM_PLANE_CAP_WIN_BLEND,
+ EXYNOS_DRM_PLANE_CAP_WIN_BLEND |
+ EXYNOS_DRM_PLANE_CAP_RANGE,
+ .range = DRM_COLOR_FULL_RANGE,
}, {
.zpos = 2,
.type = DRM_PLANE_TYPE_OVERLAY,
@@ -389,13 +395,19 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx,
struct drm_display_mode
if (format == HDMI_COLORIMETRY_ITU_601) {
val = MXR_CFG_RGB601;
+
+ mixer_reg_write(ctx, MXR_CM_COEFF_Y,
+ MXR_CSC_CT( 0.257, 0.504, 0.098));
+ mixer_reg_write(ctx, MXR_CM_COEFF_CB,
+ MXR_CSC_CT(-0.148, -0.291, 0.439));
+ mixer_reg_write(ctx, MXR_CM_COEFF_CR,
+ MXR_CSC_CT( 0.439, -0.368, -0.071));
} else {
val = MXR_CFG_RGB709;
/* Configure the BT.709 CSC matrix for full range RGB. */
mixer_reg_write(ctx, MXR_CM_COEFF_Y,
- MXR_CSC_CT( 0.184, 0.614, 0.063) |
- MXR_CM_COEFF_RGB_FULL);
+ MXR_CSC_CT( 0.184, 0.614, 0.063));
mixer_reg_write(ctx, MXR_CM_COEFF_CB,
MXR_CSC_CT(-0.102, -0.338, 0.440));
mixer_reg_write(ctx, MXR_CM_COEFF_CR,
@@ -560,6 +572,20 @@ static void mixer_layer_update(struct mixer_context *ctx)
mixer_reg_writemask(ctx, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
}
+static void mixer_set_input_buffer_range(struct mixer_context *ctx,
+struct exynos_drm_plane *plane)
+{
+ u32 cm_coeff;
+
+ if (plane->base.state->color_range == DRM_COLOR_LIMITED_RANGE)
+ cm_coeff = MXR_CM_COEFF_RGB_LIMITED;
+ else
+ cm_coeff = MXR_CM_COEFF_RGB_FULL;
+
+ mixer_reg_writemask(ctx, MXR_CM_COEFF_Y, cm_coeff,
+ MXR_CM_COEFF_RGB_RANGE_MASK);
+}
+
static void mixer_graph_buffer(struct mixer_context *ctx,
struct exynos_drm_plane *plane)
{
@@ -647,6 +673,9 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
+ /* set the input buffer rgb range */
+ mixer_set_input_buffer_range(ctx, plane);
+
spin_unlock_irqrestore(>reg_slock, flags);
mixer_regs_dump(ctx);
@@ -917,6 +946,25 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
*crtc)
mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
}
+static int mixer_atomic_check(struct exynos_drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ const struct drm_plane_state *pstate;
+ enum drm_color_range range_val[2];
+ struct drm_plane *plane;
+ unsigned int cnt = 0;
+
+ drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
+ if (plane->color_range_property && cnt < 2) {
+ range_val[cnt] = pstate->color_range;
+ ++cnt;
+ }
+ }
+ if (cnt == 2 && range_val[0] != range_val[1])
+ return -EINVAL;
+ return 0;
+}
+
static void mixer_atomic_begin(struct
[PATCH] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
As a side effect, removing #ifdef CONFIG_PM_SLEEP will improve
compilation coverage.
Signed-off-by: Alexander Shiyan
---
drivers/video/backlight/pwm_bl.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index f9ef067..33503ce 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -667,8 +667,7 @@ static void pwm_backlight_shutdown(struct platform_device
*pdev)
pwm_backlight_power_off(pb);
}
-#ifdef CONFIG_PM_SLEEP
-static int pwm_backlight_suspend(struct device *dev)
+static int __maybe_unused pwm_bl_suspend(struct device *dev)
{
struct backlight_device *bl = dev_get_drvdata(dev);
struct pwm_bl_data *pb = bl_get_data(bl);
@@ -684,7 +683,7 @@ static int pwm_backlight_suspend(struct device *dev)
return 0;
}
-static int pwm_backlight_resume(struct device *dev)
+static int __maybe_unused pwm_bl_resume(struct device *dev)
{
struct backlight_device *bl = dev_get_drvdata(dev);
@@ -692,21 +691,13 @@ static int pwm_backlight_resume(struct device *dev)
return 0;
}
-#endif
-static const struct dev_pm_ops pwm_backlight_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
- .suspend = pwm_backlight_suspend,
- .resume = pwm_backlight_resume,
- .poweroff = pwm_backlight_suspend,
- .restore = pwm_backlight_resume,
-#endif
-};
+static SIMPLE_DEV_PM_OPS(pwm_bl_pm_ops, pwm_bl_suspend, pwm_bl_resume);
static struct platform_driver pwm_backlight_driver = {
.driver = {
.name = "pwm-backlight",
- .pm = _backlight_pm_ops,
+ .pm = _bl_pm_ops,
.of_match_table = of_match_ptr(pwm_backlight_of_match),
},
.probe = pwm_backlight_probe,
--
2.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
VC4 DRM
Eric, Noralf, could either of you answer a question about Vc4 DRM, please ? I am trying to connect MIPI DSI display to VC4 but it isn't showing anything. I have noticed that the DSI host transfer() method vc4_dsi_host_transfer gets called for the commands that I am sending from my panel driver, but not for pixel data. My question: are pixel data normally transferred the same method within vc4_dsi driver or any "behind the scene" way ? Thank you, Sergey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.
Hello, On 12/13/18 7:01 AM, Daniel Vetter wrote: > On Thu, Dec 13, 2018 at 04:43:57PM +0900, Tomasz Figa wrote: >> Hi Helen, >> >> On Sat, Nov 24, 2018 at 6:54 AM Helen Koike >> wrote: >>> >>> This flag tells core to jump ahead the queued update if the conditions >>> in drm_atomic_async_check() are met. That means we are only able to do an >>> async update if no modeset is pending and update for the same plane is >>> not queued. >> >> First of all, thanks for the patch. Please see my comments below. >> >> If the description above applies (and AFAICT that's what the existing >> code does indeed), then this doesn't sound like "amend" to me. It >> sounds exactly as the kernel code calls it - "async update" or perhaps >> "instantaneous commit" could better describe it? There is an error in this patch (please, see below). Async should fail if there is no pending commit, at least is what I understand from the discussion at https://patchwork.freedesktop.org/patch/243088/ >> >>> >>> It uses the already in place infrastructure for async updates. >>> >>> It is useful for cursor updates and async PageFlips over the atomic >>> ioctl, otherwise in some cases updates may be delayed to the point the >>> user will notice it. Note that for now it's only enabled for cursor >>> planes. >>> >>> DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this >>> feature. >>> >>> Signed-off-by: Gustavo Padovan >>> Signed-off-by: Enric Balletbo i Serra >>> [updated for upstream] >>> Signed-off-by: Helen Koike >>> --- >>> Hi, >>> >>> This is the second attempt to introduce the new ATOMIC_AMEND flag for atomic >>> operations, see the commit message for a more detailed description. >>> >>> This was tested using a small program that exercises the uAPI for easy >>> sanity testing. The program was created by Alexandros and modified by >>> Enric to test the capability flag [2]. >>> >>> To test, just build the program and use the --atomic flag to use the cursor >>> plane with the ATOMIC_AMEND flag. E.g. >>> >>> drm_cursor --atomic >>> >>> The test worked on a rockchip Ficus v1.1 board on top of mainline plus >>> the patch to update cursors asynchronously through atomic for the >>> drm/rockchip driver plus the DRM_CAP_ASYNC_UPDATE patch. >>> >>> Alexandros also did a proof-of-concept to use this flag and draw cursors >>> using atomic if possible on ozone [1]. >>> >>> Thanks >>> Helen >>> >>> [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711 >>> [2] >>> https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability >>> >>> >>> Changes in v2: >>> - rebase tree >>> - do not fall back to a non-async update if if there isn't any >>> pending commit to amend >>> >>> Changes in v1: >>> - https://patchwork.freedesktop.org/patch/243088/ >>> - Only enable it if userspace requests it. >>> - Only allow async update for cursor type planes. >>> - Rename ASYNC_UPDATE for ATOMIC_AMEND. >>> >>> drivers/gpu/drm/drm_atomic_helper.c | 6 +- >>> drivers/gpu/drm/drm_atomic_uapi.c | 6 ++ >>> include/uapi/drm/drm_mode.h | 4 +++- >>> 3 files changed, 14 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >>> b/drivers/gpu/drm/drm_atomic_helper.c >>> index 269f1a74de38..333190c6a0a4 100644 >>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>> @@ -934,7 +934,7 @@ int drm_atomic_helper_check(struct drm_device *dev, >>> if (ret) >>> return ret; >>> >>> - if (state->legacy_cursor_update) >>> + if (state->async_update || state->legacy_cursor_update) >>> state->async_update = !drm_atomic_helper_async_check(dev, >>> state); I just realized this is wrong, drm_atomic_helper_async_check() should return error if there is a pending old_plane_state->commit (this v2 patch is not doing this, but v1 was), if drm_atomic_helper_async_check() returned because of it, then we should return error here to scale this failure to userspace. Make sense? Tomasz, do you agree? >>> >>> return ret; >>> @@ -1602,6 +1602,10 @@ int drm_atomic_helper_async_check(struct drm_device >>> *dev, >>> if (new_plane_state->fence) >>> return -EINVAL; >>> >>> + /* Only allow async update for cursor type planes. */ >>> + if (plane->type != DRM_PLANE_TYPE_CURSOR) >>> + return -EINVAL; >>> + >> >> So the existing upstream code already allowed this for any planes and >> we're restricting this to cursor planes only. Is this expected? No >> potential users that already started using this for other plane types? > > The backend supports it for anything right now (if the driver implements > it, that is). We do expose it through the legacy cursor api, and the > legacy page_flip api, but not through atomic itself. It also has the > problem that the not all drivers who support the async legacy cursor mode > in atomic use this new infrastructure, so there's a
[PATCH v6 1/2] dt-bindings: panel: Add Sitronix ST7701 panel documentation
Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel
with inbuilt ST7701 chip.
The default regulator names in ST7701 chip is renamed in Techstar TS8550B
so, add specific binding names for them.
Signed-off-by: Jagan Teki
---
Changes for v6:
- none
.../display/panel/sitronix,st7701.txt | 30 +++
1 file changed, 30 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
new file mode 100644
index ..ccd17597f1f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
@@ -0,0 +1,30 @@
+Sitronix ST7701 based LCD panels
+
+ST7701 designed for small and medium sizes of TFT LCD display, is
+capable of supporting up to 480RGBX864 in resolution. It provides
+several system interfaces like MIPI/RGB/SPI.
+
+Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has
+inbuilt ST7701 chip.
+
+Required properties:
+- compatible: must be "sitronix,st7701" and one of
+ * "techstar,ts8550b"
+- reset-gpios: a GPIO phandle for the reset pin
+
+Required properties for techstar,ts8550b:
+- reg: DSI virtual channel used by that screen
+- VCC-supply: analog regulator for MIPI circuit
+- IOVCC-supply: I/O system regulator
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+ compatible = "techstar,ts8550b", "sitronix,st7701";
+ reg = <0>;
+ VCC-supply = <_dldo2>;
+ IOVCC-supply = <_dldo2>;
+ reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <>;
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/exynos: plane: Minor cleanup
Use available drm_plane pointer, for consistency. Signed-off-by: Christoph Manszewski --- drivers/gpu/drm/exynos/exynos_drm_plane.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index df0508e0e49e..cf352d980eee 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -303,7 +303,7 @@ int exynos_plane_init(struct drm_device *dev, BIT(DRM_MODE_BLEND_COVERAGE); struct drm_plane *plane = _plane->base; - err = drm_universal_plane_init(dev, _plane->base, + err = drm_universal_plane_init(dev, plane, 1 << dev->mode_config.num_crtc, _plane_funcs, config->pixel_formats, @@ -314,12 +314,12 @@ int exynos_plane_init(struct drm_device *dev, return err; } - drm_plane_helper_add(_plane->base, _helper_funcs); + drm_plane_helper_add(plane, _helper_funcs); exynos_plane->index = index; exynos_plane->config = config; - exynos_plane_attach_zpos_property(_plane->base, config->zpos, + exynos_plane_attach_zpos_property(plane, config->zpos, !(config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS)); if (config->capabilities & EXYNOS_DRM_PLANE_CAP_PIX_BLEND) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Fri, Dec 14, 2018 at 11:48:35AM +0100, Hans de Goede wrote: > > > +#include > > > > Why is this include needed? > > It is no longer needed in v4, since the parsing of the raw > MIPI sequence data (which needed this include) has been moved > to the i915 VBT code now. > > I've dropped this from my local version of the patch. OK. > Note sure if you (Mika) are the right person to ask, but in the > coverletter of v1 I suggested merging all 3 patches through the i915 tree > since the drivers/acpi/pmic/intel_pmic* files typically do > not see all that churn. If I can get an Ack from you or > Rafael for that then I can push the version with the include > dropped to drm-next (through drm-intel-next-queued) myself > once the 3th patch also has been acked. I guess it is up to Rafael whether my ack is enough but here it is for both patches, Acked-by: Mika Westerberg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] dt-bindings: panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Changes for v2:
- none
.../display/panel/feiyang,fy07024di26a30d.txt | 20 +++
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
new file mode 100644
index ..82caa7b65ae8
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
@@ -0,0 +1,20 @@
+Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel
+
+Required properties:
+- compatible: must be "feiyang,fy07024di26a30d"
+- reg: DSI virtual channel used by that screen
+- avdd-supply: analog regulator dc1 switch
+- dvdd-supply: 3v3 digital regulator
+- reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+ compatible = "feiyang,fy07024di26a30d";
+ reg = <0>;
+ avdd-supply = <_dc1sw>;
+ dvdd-supply = <_dldo2>;
+ reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <>;
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/exynos: drm_drv: Extend exynos_drm_plane_config
Define new range capability and add range value to
exynos_drm_plane_config.
Signed-off-by: Christoph Manszewski
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5e61e707f955..1bc334d846c5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -94,6 +94,7 @@ struct exynos_drm_plane {
#define EXYNOS_DRM_PLANE_CAP_TILE (1 << 3)
#define EXYNOS_DRM_PLANE_CAP_PIX_BLEND (1 << 4)
#define EXYNOS_DRM_PLANE_CAP_WIN_BLEND (1 << 5)
+#define EXYNOS_DRM_PLANE_CAP_RANGE (1 << 6)
/*
* Exynos DRM plane configuration structure.
@@ -111,6 +112,7 @@ struct exynos_drm_plane_config {
const uint32_t *pixel_formats;
unsigned int num_pixel_formats;
unsigned int capabilities;
+ enum drm_color_range range;
};
/*
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 02/12] gpu: ipu-csi: Swap fields according to input/output field types
On 12/13/18 4:59 AM, Philipp Zabel wrote:
Hi Steve,
On Tue, 2018-10-16 at 17:00 -0700, Steve Longerbeam wrote:
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().
Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).
When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.
Signed-off-by: Steve Longerbeam
---
Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
by Philipp Zabel.
- Fixed a regression in csi_setup(), caught by Philipp.
---
drivers/gpu/ipu-v3/ipu-csi.c | 119 +++---
drivers/staging/media/imx/imx-media-csi.c | 17 +---
include/video/imx-ipu-v3.h| 3 +-
3 files changed, 88 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..4a15e513fa05 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,6 +325,15 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config
*cfg, u32 mbus_code,
return 0;
}
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+ return (field != V4L2_FIELD_ALTERNATE) ? field :
+ ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
/*
* Fill a CSI bus config struct from mbus_config and mbus_framefmt.
*/
@@ -374,22 +383,75 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config
*csicfg,
return 0;
}
+static int ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+ struct v4l2_mbus_framefmt *infmt,
+ struct v4l2_mbus_framefmt *outfmt,
infmt and outfmt parameters could be const.
Agreed, I will convert these pointer args to const. And since we are
changing the API to ipu_csi_init_interface() anyway, I went ahead and
converted the mbus_cfg, infmt, and outfmt pointer args to const there as
well.
+ v4l2_std_id std)
+{
+ enum v4l2_field infield, outfield;
+ bool swap_fields;
+
+ /* get translated field type of input and output */
+ infield = ipu_csi_translate_field(infmt->field, std);
+ outfield = ipu_csi_translate_field(outfmt->field, std);
+
+ /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+ swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+ V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+ infield != outfield);
+
+ if (!swap_fields) {
+ /*
+* Field0BlankEnd = 110, Field0BlankStart = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd = 111, Field1BlankStart = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+ ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+ } else {
+ dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+ /* same as above but with F-bit inverted */
+ ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+ }
+
+ ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
+
+ return 0;
+}
+
+
int ipu_csi_init_interface(struct ipu_csi *csi,
struct v4l2_mbus_config *mbus_cfg,
- struct v4l2_mbus_framefmt *mbus_fmt)
+ struct v4l2_mbus_framefmt *infmt,
+ struct v4l2_mbus_framefmt *outfmt)
{
struct ipu_csi_bus_config cfg;
unsigned long flags;
u32 width, height,
Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields
On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
wrote:
>
> With jiffies been replaced by raw ns in PM core accounting, 915 driver is
> updated to use this new time infrastructure.
>
> Signed-off-by: Vincent Guittot
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index d6c8f8f..cf6437d 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
> */
> if (kdev->power.runtime_status == RPM_SUSPENDED) {
> if
> (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> - i915->pmu.suspended_jiffies_last =
> -
> kdev->power.suspended_jiffies;
> + i915->pmu.suspended_time_last =
> + kdev->power.suspended_time;
>
Huh, so patch 2 introduces a complier error because of removing the
old fields. We can't have that.
Ideally the driver shouldn't touch these fields in the first place,
but because the fields are defined in a public header, there is always
a risk that they becomes abused. I would appreciate if we can change
the driver move away from using these fields and make that a patch
preceding patch 2.
> - val = kdev->power.suspended_jiffies -
> - i915->pmu.suspended_jiffies_last;
> - val += jiffies - kdev->power.accounting_timestamp;
> + val = kdev->power.suspended_time -
> + i915->pmu.suspended_time_last;
> + val += ktime_to_ns(ktime_get()) -
> + kdev->power.accounting_timestamp;
>
> - val = jiffies_to_nsecs(val);
> val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
>
> i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur =
> val;
> diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
> index 7f164ca..3dc2a30 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.h
> +++ b/drivers/gpu/drm/i915/i915_pmu.h
> @@ -95,9 +95,9 @@ struct i915_pmu {
> */
> struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
> /**
> -* @suspended_jiffies_last: Cached suspend time from PM core.
> +* @suspended_time_last: Cached suspend time from PM core.
> */
> - unsigned long suspended_jiffies_last;
> + u64 suspended_time_last;
> /**
> * @i915_attr: Memory block holding device attributes.
> */
> --
> 2.7.4
>
Kind regards
Uffe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: renesas: lvds: Document r8a774c0 bindings
The RZ/G2E (r8a774c0) supports two LVDS channels. Extend the binding to support them. Signed-off-by: Fabrizio Castro --- Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt index 3aeb0ec..cb7c328 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@ -8,6 +8,7 @@ Required properties: - compatible : Shall contain one of - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders + - "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders @@ -24,7 +25,7 @@ Required properties: - clock-names: Name of the clocks. This property is model-dependent. - The functional clock, which mandatory for all models, shall be listed first, and shall be named "fck". - - On R8A77990 and R8A77995, the LVDS encoder can use the EXTAL or + - On R8A77990, R8A77995 and R8A774C0, the LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must be named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN numerical index. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] include/drm: color_mgmt: Add enum labels
Range setting makes sense for YCbCr and RGB buffers. Current
drm_color_range enum labels suggest use with YCbCr buffers.
Create enum labels without colorspace specification.
Signed-off-by: Christoph Manszewski
---
include/drm/drm_color_mgmt.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 90ef9996d9a4..52f6d5221a0d 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -62,6 +62,8 @@ enum drm_color_range {
DRM_COLOR_YCBCR_LIMITED_RANGE,
DRM_COLOR_YCBCR_FULL_RANGE,
DRM_COLOR_RANGE_MAX,
+ DRM_COLOR_LIMITED_RANGE = DRM_COLOR_YCBCR_LIMITED_RANGE,
+ DRM_COLOR_FULL_RANGE = DRM_COLOR_YCBCR_FULL_RANGE,
};
int drm_plane_create_color_properties(struct drm_plane *plane,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/12] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
On Fri, Dec 14, 2018 at 1:25 AM Sean Paul wrote:
>
> On Fri, Dec 14, 2018 at 12:56:03AM +0530, Jagan Teki wrote:
> > On Thu, Dec 13, 2018 at 8:37 PM Sean Paul wrote:
> > >
> > > On Fri, Nov 16, 2018 at 10:09:15PM +0530, Jagan Teki wrote:
> > > > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> > > >
> > > > Add panel driver for it.
> > > >
> > > > Signed-off-by: Jagan Teki
> > > > ---
> > > > MAINTAINERS | 6 +
> > > > drivers/gpu/drm/panel/Kconfig | 9 +
> > > > drivers/gpu/drm/panel/Makefile| 1 +
> > > > .../drm/panel/panel-feiyang-fy07024di26a30d.c | 286 ++
> > > > 4 files changed, 302 insertions(+)
> > > > create mode 100644
> > > > drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > >
>
> /snip
>
> > > > diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > > > new file mode 100644
> > > > index ..a4b46bd8fdbe
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
>
> /snip
>
> > > > +static int feiyang_prepare(struct drm_panel *panel)
> > > > +{
> > > > + struct feiyang *ctx = panel_to_feiyang(panel);
> > > > + struct mipi_dsi_device *dsi = ctx->dsi;
> > > > + unsigned int i;
> > > > + int ret;
> > > > +
> > > > + ret = regulator_enable(ctx->dvdd);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + msleep(100);
> > >
> > > nit: You should do your best to correlate the sleeps with the timing
> > > parameters
> > > from the datasheet with a comment.
> > >
> > > ie:
> > > /* T1: > 100ms */
> > > msleep(100);
> >
> > Sorry, what does this mean?
>
> On page 9 of the datasheet you sent me [1], it has the delays required to
> safely
> power up the panel. This delay is the time between dvdd going high and avdd
> going high. On the figure in the datasheet, this would be T2 (T1 is dvdd rise
time between dvdd going high and avdd going high is T1 + T3 right?
T2 > 0ms
T3 > 20ms
In this case the delay can be msleep(20) ?
> time and should be handled in the regulator subsystem (iirc)). Also according
> to
> the datasheet, T2 just needs to be > 0, so you don't even need this delay. You
> could replace this with a comment like:
>
> /* T1 (dvdd rise time) + T2 (dvdd->avdd) > 0 */
>
> So for all of the msleeps below you should get the delays from the datasheet
> and
> add a comment referencing them.
T5 and T6 are delay between avdd to reset enable it can be 10 + 10
= 20ms and finally T12 which is 200 after reset.
What about the delay between resets, I need to understand it a bit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes
On 12-12-18, 14:18, Jordan Crouse wrote:
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2-qcom-level";
I think you need to mention "operating-points-v2" as well here.
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: rpi-touchscreen: Add backlight support
This patch exposes backlight control into userspace by creating a
backlight device instead of directly accessing the PWM registers.
The backlight driver can't go on a separate file as it shares the I2C
bus & address with the panel.
Signed-off-by: Nicolas Saenz Julienne
---
.../drm/panel/panel-raspberrypi-touchscreen.c | 33 +--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 2c9c9722734f..838b5c8767bc 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
@@ -196,6 +197,7 @@ struct rpi_touchscreen {
struct drm_panel base;
struct mipi_dsi_device *dsi;
struct i2c_client *i2c;
+ struct backlight_device *backlight;
};
static const struct drm_display_mode rpi_touchscreen_modes[] = {
@@ -256,7 +258,8 @@ static int rpi_touchscreen_disable(struct drm_panel *panel)
{
struct rpi_touchscreen *ts = panel_to_ts(panel);
- rpi_touchscreen_i2c_write(ts, REG_PWM, 0);
+ ts->backlight->props.brightness = 0;
+ backlight_update_status(ts->backlight);
rpi_touchscreen_i2c_write(ts, REG_POWERON, 0);
udelay(1);
@@ -300,7 +303,8 @@ static int rpi_touchscreen_enable(struct drm_panel *panel)
msleep(100);
/* Turn on the backlight. */
- rpi_touchscreen_i2c_write(ts, REG_PWM, 255);
+ ts->backlight->props.brightness = 255;
+ backlight_update_status(ts->backlight);
/* Default to the same orientation as the closed source
* firmware used for the panel. Runtime rotation
@@ -358,12 +362,26 @@ static const struct drm_panel_funcs rpi_touchscreen_funcs
= {
.get_modes = rpi_touchscreen_get_modes,
};
+static int raspberrypi_bl_update_status(struct backlight_device *bl)
+{
+ struct rpi_touchscreen *ts = bl_get_data(bl);
+
+ rpi_touchscreen_i2c_write(ts, REG_PWM, bl->props.brightness);
+
+ return 0;
+}
+
+static const struct backlight_ops raspberrypi_bl_ops = {
+ .update_status = raspberrypi_bl_update_status,
+};
+
static int rpi_touchscreen_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct device *dev = >dev;
struct rpi_touchscreen *ts;
struct device_node *endpoint, *dsi_host_node;
+ struct backlight_properties props;
struct mipi_dsi_host *host;
int ret, ver;
struct mipi_dsi_device_info info = {
@@ -398,6 +416,17 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
/* Turn off at boot, so we can cleanly sequence powering on. */
rpi_touchscreen_i2c_write(ts, REG_POWERON, 0);
+ memset(, 0, sizeof(props));
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = 255;
+ ts->backlight = devm_backlight_device_register(dev, dev_name(dev), dev,
+ ts, _bl_ops,
+ );
+ if (IS_ERR(ts->backlight)) {
+ dev_err(dev, "Failed to create backlight device\n");
+ return PTR_ERR(ts->backlight);
+ }
+
/* Look up the DSI host. It needs to probe before we do. */
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
dsi_host_node = of_graph_get_remote_port_parent(endpoint);
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/2] drm/panel: Add Sitronix ST7701 panel driver
ST7701 designed for small and medium sizes of TFT LCD display, is capable of supporting up to 480RGBX864 in resolution. It provides several system interfaces like MIPI/RGB/SPI. Currently added support for Techstar TS8550B which is ST7701 based 480x854, 2-lane MIPI DSI LCD panel. Driver now registering mipi_dsi device, but indeed it can extendable for RGB if any requirement trigger in future. Signed-off-by: Jagan Teki --- Changes for v6: - use sleep delay value as per datasheet - add panel_sleep_delay variable for panel specific delay - use command sequnce display on and off instead panel functions - add proper comments on the delays - remove delays from command switch - move mode type on struct display mode - drop refresh rate value, let drm compute Changes for v5: - found the chip from vendor, so added new panel driver - here is v4: https://patchwork.kernel.org/patch/10680335/ MAINTAINERS | 6 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-sitronix-st7701.c | 427 ++ 4 files changed, 444 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7701.c diff --git a/MAINTAINERS b/MAINTAINERS index 3f6db876be1f..d2928a4d2847 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4831,6 +4831,12 @@ S: Orphan / Obsolete F: drivers/gpu/drm/sis/ F: include/uapi/drm/sis_drm.h +DRM DRIVER FOR SITRONIX ST7701 PANELS +M: Jagan Teki +S: Maintained +F: drivers/gpu/drm/panel/panel-sitronix-st7701.c +F: Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt + DRM DRIVER FOR SITRONIX ST7586 PANELS M: David Lechner S: Maintained diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 3f3537719beb..d93b2ba709bc 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -196,6 +196,16 @@ config DRM_PANEL_SHARP_LS043T1LE01 Say Y here if you want to enable support for Sharp LS043T1LE01 qHD (540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard +config DRM_PANEL_SITRONIX_ST7701 + tristate "Sitronix ST7701 panel driver" + depends on OF + depends on DRM_MIPI_DSI + depends on BACKLIGHT_CLASS_DEVICE + help + Say Y here if you want to enable support for the Sitronix + ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI + system interfaces. + config DRM_PANEL_SITRONIX_ST7789V tristate "Sitronix ST7789V panel" depends on OF && SPI diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 4396658a7996..6a9b4cec1891 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -20,5 +20,6 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o +obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7701.c b/drivers/gpu/drm/panel/panel-sitronix-st7701.c new file mode 100644 index ..8638a5463cb6 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-sitronix-st7701.c @@ -0,0 +1,427 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019, Amarula Solutions. + * Author: Jagan Teki + */ + +#include +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include + +/* Command2 BKx selection command */ +#define DSI_CMD2BKX_SEL0xFF + +/* Command2, BK0 commands */ +#define DSI_CMD2_BK0_PVGAMCTRL 0xB0 /* Positive Voltage Gamma Control */ +#define DSI_CMD2_BK0_NVGAMCTRL 0xB1 /* Negative Voltage Gamma Control */ +#define DSI_CMD2_BK0_LNESET0xC0 /* Display Line setting */ +#define DSI_CMD2_BK0_PORCTRL 0xC1 /* Porch control */ +#define DSI_CMD2_BK0_INVSEL0xC2 /* Inversion selection, Frame Rate Control */ + +/* Command2, BK1 commands */ +#define DSI_CMD2_BK1_VRHS 0xB0 /* Vop amplitude setting */ +#define DSI_CMD2_BK1_VCOM 0xB1 /* VCOM amplitude setting */ +#define DSI_CMD2_BK1_VGHSS 0xB2 /* VGH Voltage setting */ +#define DSI_CMD2_BK1_TESTCMD 0xB3 /* TEST Command Setting */ +#define DSI_CMD2_BK1_VGLS 0xB5 /* VGL Voltage setting */ +#define DSI_CMD2_BK1_PWCTLR1 0xB7 /* Power Control 1 */ +#define DSI_CMD2_BK1_PWCTLR2 0xB8 /* Power Control 2 */ +#define DSI_CMD2_BK1_SPD1 0xC1 /* Source pre_drive timing set1 */ +#define DSI_CMD2_BK1_SPD2 0xC2 /* Source EQ2 Setting */
Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection
On Sat, Dec 08, 2018 at 09:41:12AM -0800, Christoph Hellwig wrote: > There is no good reason to have a double indirection for the sparc32 > dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops > instance for the different IOMMU types. > Except maybe this: scsi host0: esp scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK2.5+ PQ: 0 ANSI: 5 scsi target0:0:0: Beginning Domain Validation scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem. Guenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: Change Andrzej Pietrasiewicz's e-mail address
My @samusung.com address is going to cease existing soon, so change it to an address which can actually be used to contact me. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/exynos/exynos_drm_scaler.c | 2 +- drivers/gpu/drm/exynos/regs-scaler.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c b/drivers/gpu/drm/exynos/exynos_drm_scaler.c index cd66774..cad9627 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c +++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c @@ -1,7 +1,7 @@ /* * Copyright (C) 2017 Samsung Electronics Co.Ltd * Author: - * Andrzej Pietrasiewicz + * Andrzej Pietrasiewicz * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as diff --git a/drivers/gpu/drm/exynos/regs-scaler.h b/drivers/gpu/drm/exynos/regs-scaler.h index fc7ccad..512a2ba 100644 --- a/drivers/gpu/drm/exynos/regs-scaler.h +++ b/drivers/gpu/drm/exynos/regs-scaler.h @@ -2,7 +2,7 @@ * * Copyright (c) 2017 Samsung Electronics Co., Ltd. * http://www.samsung.com/ - * Author: Andrzej Pietrasiewicz + * Author: Andrzej Pietrasiewicz * * Register definition file for Samsung scaler driver * -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: rcar-du: lvds: add R8A774C0 support
Hi Laurent,
> -Original Message-
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 13 December 2018 21:38
> To: Fabrizio Castro
> Cc: David Airlie ; Kieran Bingham
> ; dri-devel@lists.freedesktop.org;
> linux-renesas-...@vger.kernel.org; linux-ker...@vger.kernel.org; Simon Horman
> ; Geert Uytterhoeven
> ; Chris Paterson ; Biju
> Das
> Subject: Re: [PATCH] drm: rcar-du: lvds: add R8A774C0 support
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thursday, 13 December 2018 22:23:36 EET Fabrizio Castro wrote:
> > The LVDS implementation on the RZ/G2E (a.k.a. R8A774C0) is very similar
> > to the one found on R-Car E3 (a.k.a. R8A77990), therefore add RZ/G2E
> > LVDS support to the LVDS encoder driver in a similar fashion to what
>
> s/what/what is/
>
> > done for R-Car E3.
> >
> > Signed-off-by: Fabrizio Castro
>
> Reviewed-by: Laurent Pinchart
>
> and applied to my tree with the above fix.
Thank you for fixing.
Fab
>
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 173d7ad..329dfca 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -785,6 +785,7 @@ static const struct rcar_lvds_device_info
> > rcar_lvds_r8a77995_info = {
> >
> > static const struct of_device_id rcar_lvds_of_table[] = {
> > { .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
> > +{ .compatible = "renesas,r8a774c0-lvds", .data = _lvds_r8a77990_info
> > }, { .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info
> > }, { .compatible = "renesas,r8a7791-lvds", .data = _lvds_gen2_info },
> > { .compatible = "renesas,r8a7793-lvds", .data = _lvds_gen2_info },
>
>
> --
> Regards,
>
> Laurent Pinchart
>
>
[https://www2.renesas.eu/media/email/unicef.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have
decided to support Unicef with a donation. For further details click
here
Re: [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Thu, Dec 13, 2018 at 04:35:32PM +0100, Hans de Goede wrote: > Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove > PMIC. > > On some CHT devices this fixes the LCD panel not lighting up when it was > not initialized by the GOP, because an external monitor was plugged in and > the GOP initialized only the external monitor. > > Signed-off-by: Hans de Goede One question see below, but regardless Reviewed-by: Mika Westerberg > --- > Changes in v4: > -The decoding of the raw data of the PMIC MIPI sequence element is now done > in our caller, so drop this and adjust the callback prototype to accept > the decoded addresses, value and mask > > Changes in v3: > -Use hex values for out of range checks > -Make intel_cht_wc_exec_mipi_pmic_seq_element return errors > > Changes in v2: > -Interpret data passed to the PMIC MIPI elements according to the docs > instead of my own reverse engineered interpretation > --- > drivers/acpi/pmic/intel_pmic_chtwc.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c > b/drivers/acpi/pmic/intel_pmic_chtwc.c > index 078b0448f30a..c5037c5c5219 100644 > --- a/drivers/acpi/pmic/intel_pmic_chtwc.c > +++ b/drivers/acpi/pmic/intel_pmic_chtwc.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include Why is this include needed? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm_rockchip: rk3066_hdmi: No driver support for vblank timestamp query.
Bug fix? (PART 7)
A little bit of success here.
Penguins and other colors are on the screen.
DRM and FB old style seems to work with DVI-D.
Pure HDMI and sound not tested.
I think 'someone' forgot to add HCLK_HDMI to the pmu node.
Added a qos_hdmi idea. Let me know if that's OK?
Please advise what for qos_hdmi address I can use here.
Kind regards,
Johan Jonker
From d4d362ae19566539bf6f011a7a013a0682777afe Mon Sep 17 00:00:00 2001
From: Johan Jonker
Date: Thu, 13 Dec 2018 13:55:21 +0100
Subject: [PATCH] dts: rockchip: rk3066: add qos_hdmi and HCLK_HDMI to pmu node
Add qos_hdmi and HCLK_HDMI to pmu node.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 9 +++--
arch/arm/boot/dts/rk3xxx.dtsi | 5 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index ff7daec6a..190d6b68f 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -70,6 +70,7 @@
< DCLK_LCDC0>,
< HCLK_LCDC0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ power-domains = < RK3066_PD_VIO>;
resets = < SRST_LCDC0_AXI>,
< SRST_LCDC0_AHB>,
< SRST_LCDC0_DCLK>;
@@ -94,6 +95,7 @@
< DCLK_LCDC1>,
< HCLK_LCDC1>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ power-domains = < RK3066_PD_VIO>;
resets = < SRST_LCDC1_AXI>,
< SRST_LCDC1_AHB>,
< SRST_LCDC1_DCLK>;
@@ -112,6 +114,7 @@
interrupts = ;
clocks = < HCLK_HDMI>;
clock-names = "hclk";
+ power-domains = < RK3066_PD_VIO>;
rockchip,grf = <>;
pinctrl-names = "default";
pinctrl-0 = <_xfer>, <_hpd>;
@@ -753,13 +756,15 @@
< ACLK_IPP>,
< HCLK_IPP>,
< ACLK_RGA>,
- < HCLK_RGA>;
+ < HCLK_RGA>,
+ < HCLK_HDMI>;
pm_qos = <_lcdc0>,
<_lcdc1>,
<_cif0>,
<_cif1>,
<_ipp>,
- <_rga>;
+ <_rga>,
+ <_hdmi>;
};
pd_video@RK3066_PD_VIDEO {
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 97307a405..1f9496e81 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -187,6 +187,11 @@
reg = <0x1012f280 0x20>;
};
+ qos_hdmi: qos@1012f300 {
+ compatible = "syscon";
+ reg = <0x1012f300 0x20>;
+ };
+
usb_otg: usb@1018 {
compatible = "rockchip,rk3066-usb", "snps,dwc2";
reg = <0x1018 0x4>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/exynos: plane: Add range property to exynos plane
Create range property within exynos_drm_plane_init and set to default value
in exynos_drm_plane_reset.
Signed-off-by: Christoph Manszewski
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index cf352d980eee..a6ab0e7277f0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -140,6 +140,7 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)
if (exynos_state) {
__drm_atomic_helper_plane_reset(plane, _state->base);
plane->state->zpos = exynos_plane->config->zpos;
+ plane->state->color_range = exynos_plane->config->range;
}
}
@@ -301,6 +302,10 @@ int exynos_plane_init(struct drm_device *dev,
unsigned int supported_modes = BIT(DRM_MODE_BLEND_PIXEL_NONE) |
BIT(DRM_MODE_BLEND_PREMULTI) |
BIT(DRM_MODE_BLEND_COVERAGE);
+
+ u32 supported_ranges = BIT(DRM_COLOR_LIMITED_RANGE) |
+ BIT(DRM_COLOR_FULL_RANGE);
+
struct drm_plane *plane = _plane->base;
err = drm_universal_plane_init(dev, plane,
@@ -328,5 +333,9 @@ int exynos_plane_init(struct drm_device *dev,
if (config->capabilities & EXYNOS_DRM_PLANE_CAP_WIN_BLEND)
drm_plane_create_alpha_property(plane);
+ if (config->capabilities & EXYNOS_DRM_PLANE_CAP_RANGE)
+ drm_plane_create_range_property(plane, supported_ranges,
+ config->range);
+
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
Add panel driver for it.
Signed-off-by: Jagan Teki
---
Changes for v2:
- use simple structure for command init
- update proper comments on power, reset delay sequnce
- fix to use set_display_off in disable function
- move mode type to structure
- drop refres rate value, let drm compute
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 296 ++
4 files changed, 312 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d2928a4d2847..e643238855ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4732,6 +4732,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
+M: Jagan Teki
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+F:
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
+
DRM DRIVER FOR ILITEK ILI9225 PANELS
M: David Lechner
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d93b2ba709bc..cb8ca93550cf 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -38,6 +38,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIYANG_FY07024DI26A30D
+ tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y if you want to enable support for panels based on the
+ Feiyang FY07024DI26A30-D MIPI-DSI interface.
+
config DRM_PANEL_ILITEK_IL9322
tristate "Ilitek ILI9322 320x240 QVGA panels"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 6a9b4cec1891..0fa0ef69e109 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
new file mode 100644
index ..4abccbf62c3c
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#define FEIYANG_INIT_CMD_LEN 2
+
+struct feiyang {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct backlight_device *backlight;
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct gpio_desc*reset;
+};
+
+static inline struct feiyang *panel_to_feiyang(struct drm_panel *panel)
+{
+ return container_of(panel, struct feiyang, panel);
+}
+
+struct feiyang_init_cmd {
+ u8 data[FEIYANG_INIT_CMD_LEN];
+};
+
+static const struct feiyang_init_cmd feiyang_init_cmds[] = {
+ { .data = { 0x80, 0x58 } },
+ { .data = { 0x81, 0x47 } },
+ { .data = { 0x82, 0xD4 } },
+ { .data = { 0x83, 0x88 } },
+ { .data = { 0x84, 0xA9 } },
+ { .data = { 0x85, 0xC3 } },
+ { .data = { 0x86, 0x82 } },
+};
+
+static int feiyang_prepare(struct drm_panel *panel)
+{
+ struct feiyang *ctx = panel_to_feiyang(panel);
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ unsigned int i;
+ int ret;
+
+ ret = regulator_enable(ctx->dvdd);
+ if (ret)
+ return ret;
+
+ /* T1 (dvdd start + dvdd rise) 0 < T1 <= 10ms */
+ msleep(10);
+
+ ret = regulator_enable(ctx->avdd);
+ if (ret)
+ return ret;
+
+ /* T3 (dvdd rise + avdd start + avdd rise) T3 >= 20ms */
+ msleep(20);
+
+ gpiod_set_value(ctx->reset, 1);
+ msleep(50);
+
+ gpiod_set_value(ctx->reset, 0);
+ /* T5 + T6 (avdd rise + video & logic signal rise)
+* T5 >= 10ms, 0 < T6 <= 10ms
+*/
+ msleep(20);
+
+ gpiod_set_value(ctx->reset, 1);
+
+ /* T12 (video & logic signal rise + backlight rise) T12 >= 200ms */
+ msleep(200);
+
+ for (i = 0; i <
[PATCH 1/2] devicetree: Add vendor-prefix for Chefree Technology Corp.
Add vendor prefix for Chefree Technology Corp., http://www.chefree.com/ . The company is a LCD display manufacturer. Signed-off-by: Marek Vasut Cc: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 3bbe3b87a1ff9..3b1bb03d383c1 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -69,6 +69,7 @@ caviumCavium, Inc. cdns Cadence Design Systems Inc. cdtech CDTech(H.K.) Electronics Limited ceva Ceva, Inc. +chefreeChefree Technology Corp. chipidea Chipidea, Inc chiponeChipOne chipspark ChipSPARK -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/exynos: mixer: Add color range property
Hi, This patch series adds rgb input buffer range property to exynos_mixer. It applies on top of drm-exynos/exynos-drm-next with patches: - [PATCH 1/2] drm/edid: Add colorimetry helper function, - [PATCH 2/2] drm/exynos: mixer: Use colorimetry helper function Patch 1 Add apropriate labels Patch 2 Split color properties function Patch 3 Add default range field to exynos_drm_plane config Patch 4 Minor code cleanup Patch 5 Add optional range property to exynos plane Patch 6 Make input rgb range configurable in exynos_mixer Regards, Chris Christoph Manszewski (6): include/drm: color_mgmt: Add enum labels drm: color_mgmt: Split create_color_properties function drm/exynos: drm_drv: Extend exynos_drm_plane_config drm/exynos: plane: Minor cleanup drm/exynos: plane: Add range property to exynos plane drm/exynos: mixer: Make input buffer color range configurable drivers/gpu/drm/drm_color_mgmt.c | 93 --- drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 + drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 - drivers/gpu/drm/exynos/exynos_mixer.c | 57 +-- drivers/gpu/drm/exynos/regs-mixer.h | 2 + include/drm/drm_color_mgmt.h | 10 6 files changed, 152 insertions(+), 27 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: renesas: du: Document r8a774c0 bindings
Document the RZ/G2E (a.k.a. r8a774c0) SoC in the R-Car DU bindings. Signed-off-by: Fabrizio Castro --- Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index 3c855d9..aedb22b 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -7,6 +7,7 @@ Required Properties: - "renesas,du-r8a7744" for R8A7744 (RZ/G1N) compatible DU - "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU - "renesas,du-r8a77470" for R8A77470 (RZ/G1C) compatible DU +- "renesas,du-r8a774c0" for R8A774C0 (RZ/G2E) compatible DU - "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU - "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU - "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU @@ -57,6 +58,7 @@ corresponding to each DU output. R8A7744 (RZ/G1N) DPAD 0 LVDS 0 - - R8A7745 (RZ/G1E) DPAD 0 DPAD 1 - - R8A77470 (RZ/G1C) DPAD 0 DPAD 1 LVDS 0 - + R8A774C0 (RZ/G2E) DPAD 0 LVDS 0 LVDS 1 - R8A7779 (R-Car H1) DPAD 0 DPAD 1 - - R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1 - R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 - - -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] video: lcd: Remove useless BACKLIGHT_CLASS_DEVICE dependencies
This patch removes dependencies on BACKLIGHT_CLASS_DEVICE for items that are already placed under #ifdef BACKLIGHT_CLASS_DEVICE. Signed-off-by: Alexander Shiyan --- drivers/video/backlight/Kconfig | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index 3fdc18e..3ed1d90 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -193,7 +193,6 @@ config BACKLIGHT_IPAQ_MICRO config BACKLIGHT_LM3533 tristate "Backlight Driver for LM3533" - depends on BACKLIGHT_CLASS_DEVICE depends on MFD_LM3533 help Say Y to enable the backlight driver for National Semiconductor / TI @@ -317,7 +316,7 @@ config BACKLIGHT_ADP5520 config BACKLIGHT_ADP8860 tristate "Backlight Driver for ADP8860/ADP8861/ADP8863 using WLED" - depends on BACKLIGHT_CLASS_DEVICE && I2C + depends on I2C select NEW_LEDS select LEDS_CLASS help @@ -329,7 +328,7 @@ config BACKLIGHT_ADP8860 config BACKLIGHT_ADP8870 tristate "Backlight Driver for ADP8870 using WLED" - depends on BACKLIGHT_CLASS_DEVICE && I2C + depends on I2C select NEW_LEDS select LEDS_CLASS help @@ -347,28 +346,28 @@ config BACKLIGHT_88PM860X config BACKLIGHT_PCF50633 tristate "Backlight driver for NXP PCF50633 MFD" - depends on BACKLIGHT_CLASS_DEVICE && MFD_PCF50633 + depends on MFD_PCF50633 help If you have a backlight driven by a NXP PCF50633 MFD, say Y here to enable its driver. config BACKLIGHT_AAT2870 tristate "AnalogicTech AAT2870 Backlight" - depends on BACKLIGHT_CLASS_DEVICE && MFD_AAT2870_CORE + depends on MFD_AAT2870_CORE help If you have a AnalogicTech AAT2870 say Y to enable the backlight driver. config BACKLIGHT_LM3630A tristate "Backlight Driver for LM3630A" - depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM + depends on I2C && PWM select REGMAP_I2C help This supports TI LM3630A Backlight Driver config BACKLIGHT_LM3639 tristate "Backlight Driver for LM3639" - depends on BACKLIGHT_CLASS_DEVICE && I2C + depends on I2C select REGMAP_I2C select NEW_LEDS select LEDS_CLASS @@ -377,20 +376,20 @@ config BACKLIGHT_LM3639 config BACKLIGHT_LP855X tristate "Backlight driver for TI LP855X" - depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM + depends on I2C && PWM help This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and LP8557 backlight driver. config BACKLIGHT_LP8788 tristate "Backlight driver for TI LP8788 MFD" - depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788 && PWM + depends on MFD_LP8788 && PWM help This supports TI LP8788 backlight driver. config BACKLIGHT_OT200 tristate "Backlight driver for ot200 visualisation device" - depends on BACKLIGHT_CLASS_DEVICE && CS5535_MFGPT && GPIO_CS5535 + depends on CS5535_MFGPT && GPIO_CS5535 help To compile this driver as a module, choose M here: the module will be called ot200_bl. @@ -404,7 +403,7 @@ config BACKLIGHT_PANDORA config BACKLIGHT_SKY81452 tristate "Backlight driver for SKY81452" - depends on BACKLIGHT_CLASS_DEVICE && MFD_SKY81452 + depends on MFD_SKY81452 help If you have a Skyworks SKY81452, say Y to enable the backlight driver. @@ -414,14 +413,14 @@ config BACKLIGHT_SKY81452 config BACKLIGHT_TPS65217 tristate "TPS65217 Backlight" - depends on BACKLIGHT_CLASS_DEVICE && MFD_TPS65217 + depends on MFD_TPS65217 help If you have a Texas Instruments TPS65217 say Y to enable the backlight driver. config BACKLIGHT_AS3711 tristate "AS3711 Backlight" - depends on BACKLIGHT_CLASS_DEVICE && MFD_AS3711 + depends on MFD_AS3711 help If you have an Austrian Microsystems AS3711 say Y to enable the backlight driver. -- 2.10.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/12] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
On Thu, Dec 13, 2018 at 8:37 PM Sean Paul wrote:
>
> On Fri, Nov 16, 2018 at 10:09:15PM +0530, Jagan Teki wrote:
> > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> >
> > Add panel driver for it.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > MAINTAINERS | 6 +
> > drivers/gpu/drm/panel/Kconfig | 9 +
> > drivers/gpu/drm/panel/Makefile| 1 +
> > .../drm/panel/panel-feiyang-fy07024di26a30d.c | 286 ++
> > 4 files changed, 302 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3dac08d0b3cb..40c8bfc974f4 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4620,6 +4620,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
> > S: Maintained
> > F: drivers/gpu/drm/tve200/
> >
> > +DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
> > +M: Jagan Teki
> > +S: Maintained
> > +F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > +F:
> > Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
> > +
> > DRM DRIVER FOR ILITEK ILI9225 PANELS
> > M: David Lechner
> > S: Maintained
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index d0d4e60f5153..bc70896fe43c 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -47,6 +47,15 @@ config DRM_PANEL_SIMPLE
> > that it can be automatically turned off when the panel goes into a
> > low power state.
> >
> > +config DRM_PANEL_FEIYANG_FY07024DI26A30D
> > + tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + depends on BACKLIGHT_CLASS_DEVICE
> > + help
> > + Say Y if you want to enable support for panels based on the
> > + Feiyang FY07024DI26A30-D MIPI-DSI interface.
> > +
> > config DRM_PANEL_ILITEK_IL9322
> > tristate "Ilitek ILI9322 320x240 QVGA panels"
> > depends on OF && SPI
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index 88011f06edb8..e23c017639c7 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) +=
> > panel-arm-versatile.o
> > obj-$(CONFIG_DRM_PANEL_BANANAPI_S070WV20_ICN6211) +=
> > panel-bananapi-s070wv20-icn6211.o
> > obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> > obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> > +obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
> > panel-feiyang-fy07024di26a30d.o
> > obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
> > obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
> > obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
> > diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > new file mode 100644
> > index ..a4b46bd8fdbe
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> > @@ -0,0 +1,286 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018 Amarula Solutions
> > + * Author: Jagan Teki
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +struct feiyang {
> > + struct drm_panelpanel;
> > + struct mipi_dsi_device *dsi;
> > +
> > + struct backlight_device *backlight;
> > + struct regulator*dvdd;
> > + struct regulator*avdd;
> > + struct gpio_desc*reset;
> > +};
> > +
> > +static inline struct feiyang *panel_to_feiyang(struct drm_panel *panel)
> > +{
> > + return container_of(panel, struct feiyang, panel);
> > +}
> > +
> > +struct feiyang_init_cmd {
> > + size_t len;
> > + const char *data;
> > +};
> > +
> > +#define FY07024DI26A30D(...) { \
> > + .len = sizeof((char[]){__VA_ARGS__}), \
> > + .data = (char[]){__VA_ARGS__} }
> > +
> > +static const struct feiyang_init_cmd feiyang_init_cmds[] = {
> > + FY07024DI26A30D(0x80, 0x58),
> > + FY07024DI26A30D(0x81, 0x47),
> > + FY07024DI26A30D(0x82, 0xD4),
> > + FY07024DI26A30D(0x83, 0x88),
> > + FY07024DI26A30D(0x84, 0xA9),
> > + FY07024DI26A30D(0x85, 0xC3),
> > + FY07024DI26A30D(0x86, 0x82),
> > +};
>
> These init cmds don't have to be so complicated. You've only got len == 2, so
> just hardcode it in and avoid the macro:
>
> #define FEIYANG_INIT_CMD_LEN2
>
> struct feiyang_init_cmd {
> u8 data[FEIYANG_INIT_CMD];
> };
>
> static const struct feiyang_init_cmd feiyang_init_cmds[] = {
> { .data = { 0x80, 0x58 } },
> ...
> };
>
> > +
> > +static int feiyang_prepare(struct drm_panel *panel)
> > +{
> > + struct feiyang *ctx =
[PATCH 2/6] drm: color_mgmt: Split create_color_properties function
Split drm_plane_create_color_properties into two separate functions.
This allows to create range and encoding property independently.
Signed-off-by: Christoph Manszewski
---
drivers/gpu/drm/drm_color_mgmt.c | 93 +++-
include/drm/drm_color_mgmt.h | 8
2 files changed, 81 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 581cc3788223..416cc9c8560b 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -396,29 +396,24 @@ const char *drm_get_color_range_name(enum drm_color_range
range)
}
/**
- * drm_plane_create_color_properties - color encoding related plane properties
+ * drm_plane_create_encoding_property - color encoding related plane property
* @plane: plane object
* @supported_encodings: bitfield indicating supported color encodings
- * @supported_ranges: bitfileld indicating supported color ranges
* @default_encoding: default color encoding
- * @default_range: default color range
*
- * Create and attach plane specific COLOR_ENCODING and COLOR_RANGE
- * properties to @plane. The supported encodings and ranges should
- * be provided in supported_encodings and supported_ranges bitmasks.
- * Each bit set in the bitmask indicates that its number as enum
- * value is supported.
+ * Create and attach plane specific COLOR_ENCODING property to @plane.
+ * The supported encodings be provided in supported_encodings bitmask.
+ * Each bit set in the bitmask indicates that its number as enum value
+ * is supported.
*/
-int drm_plane_create_color_properties(struct drm_plane *plane,
- u32 supported_encodings,
- u32 supported_ranges,
- enum drm_color_encoding default_encoding,
- enum drm_color_range default_range)
+
+int drm_plane_create_encoding_property(struct drm_plane *plane,
+ u32 supported_encodings,
+ enum drm_color_encoding default_encoding)
{
struct drm_device *dev = plane->dev;
struct drm_property *prop;
- struct drm_prop_enum_list enum_list[max_t(int, DRM_COLOR_ENCODING_MAX,
- DRM_COLOR_RANGE_MAX)];
+ struct drm_prop_enum_list enum_list[DRM_COLOR_ENCODING_MAX];
int i, len;
if (WARN_ON(supported_encodings == 0 ||
@@ -426,11 +421,6 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
(supported_encodings & BIT(default_encoding)) == 0))
return -EINVAL;
- if (WARN_ON(supported_ranges == 0 ||
- (supported_ranges & -BIT(DRM_COLOR_RANGE_MAX)) != 0 ||
- (supported_ranges & BIT(default_range)) == 0))
- return -EINVAL;
-
len = 0;
for (i = 0; i < DRM_COLOR_ENCODING_MAX; i++) {
if ((supported_encodings & BIT(i)) == 0)
@@ -450,6 +440,36 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
if (plane->state)
plane->state->color_encoding = default_encoding;
+ return 0;
+}
+EXPORT_SYMBOL(drm_plane_create_encoding_property);
+
+/**
+ * drm_plane_create_range_property - color range related plane property
+ * @plane: plane object
+ * @supported_ranges: bitfileld indicating supported color ranges
+ * @default_range: default color range
+ *
+ * Create and attach plane specific COLOR_RANGE property to @plane.
+ * The supported ranges should be provided in supported_ranges bitmask.
+ * Each bit set in the bitmask indicates that its number as enum value
+ * is supported.
+ */
+
+int drm_plane_create_range_property(struct drm_plane *plane,
+ u32 supported_ranges,
+ enum drm_color_range default_range)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_property *prop;
+ struct drm_prop_enum_list enum_list[DRM_COLOR_RANGE_MAX];
+ int i, len;
+
+ if (WARN_ON(supported_ranges == 0 ||
+ (supported_ranges & -BIT(DRM_COLOR_RANGE_MAX)) != 0 ||
+ (supported_ranges & BIT(default_range)) == 0))
+ return -EINVAL;
+
len = 0;
for (i = 0; i < DRM_COLOR_RANGE_MAX; i++) {
if ((supported_ranges & BIT(i)) == 0)
@@ -471,4 +491,37 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
return 0;
}
+EXPORT_SYMBOL(drm_plane_create_range_property);
+
+/**
+ * drm_plane_create_color_properties - color encoding related plane properties
+ * @plane: plane object
+ * @supported_encodings: bitfield indicating supported color encodings
+ * @supported_ranges: bitfileld indicating supported color ranges
+ * @default_encoding: default color encoding
+ * @default_range: default color range
+ *
+ * Create and
[PATCH] drm: rcar-du: lvds: add R8A774C0 support
The LVDS implementation on the RZ/G2E (a.k.a. R8A774C0) is very similar
to the one found on R-Car E3 (a.k.a. R8A77990), therefore add RZ/G2E
LVDS support to the LVDS encoder driver in a similar fashion to what
done for R-Car E3.
Signed-off-by: Fabrizio Castro
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 173d7ad..329dfca 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -785,6 +785,7 @@ static const struct rcar_lvds_device_info
rcar_lvds_r8a77995_info = {
static const struct of_device_id rcar_lvds_of_table[] = {
{ .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
+ { .compatible = "renesas,r8a774c0-lvds", .data =
_lvds_r8a77990_info },
{ .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info
},
{ .compatible = "renesas,r8a7791-lvds", .data = _lvds_gen2_info },
{ .compatible = "renesas,r8a7793-lvds", .data = _lvds_gen2_info },
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm: remove DEFINE_DPU_DEBUGFS_SEQ_FOPS()
On Tue, Dec 4, 2018 at 10:59 PM Sean Paul wrote: > > On Sat, Dec 01, 2018 at 10:19:11PM -0500, Yangtao Li wrote: > > We already have the DEFINE_SHOW_ATTRIBUTE.There is no need to define > > such a macro separately,so remove DEFINE_DPU_DEBUGFS_SEQ_FOPS. > > Also use DEFINE_SHOW_ATTRIBUTE to simplify some code. > > > > Signed-off-by: Yangtao Li > > --- > > drivers/gpu/drm/armada/armada_debugfs.c | 21 > > drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 14 +--- > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 33 +++--- > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 ++--- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 36 > > For the dpu portion: > Acked-by: Sean Paul ping.. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: set preferred depth to 24
Otherwise DRM_CAP_DUMB_PREFERRED_DEPTH is zero. Signed-off-by: Simon Ser --- drivers/gpu/drm/vkms/vkms_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c index 07cfde1b413..88571ab0674 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.c +++ b/drivers/gpu/drm/vkms/vkms_drv.c @@ -96,6 +96,7 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev) dev->mode_config.min_height = YRES_MIN; dev->mode_config.max_width = XRES_MAX; dev->mode_config.max_height = YRES_MAX; + dev->mode_config.preferred_depth = 24; return vkms_output_init(vkmsdev); } -- 2.20.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: rcar-du: Add r8a774c0 device support
Add support for the RZ/G2E (R8A774C0) SoC to the R-Car DU driver.
Signed-off-by: Fabrizio Castro
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 9caff39..ac32510 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -104,6 +104,33 @@ static const struct rcar_du_device_info
rzg1_du_r8a77470_info = {
},
};
+static const struct rcar_du_device_info rcar_du_r8a774c0_info = {
+ .gen = 3,
+ .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
+ .channels_mask = BIT(1) | BIT(0),
+ .routes = {
+ /*
+* R8A774C0 has one RGB output and two LVDS outputs
+*/
+ [RCAR_DU_OUTPUT_DPAD0] = {
+ .possible_crtcs = BIT(0) | BIT(1),
+ .port = 0,
+ },
+ [RCAR_DU_OUTPUT_LVDS0] = {
+ .possible_crtcs = BIT(0),
+ .port = 1,
+ },
+ [RCAR_DU_OUTPUT_LVDS1] = {
+ .possible_crtcs = BIT(1),
+ .port = 2,
+ },
+ },
+ .num_lvds = 2,
+ .lvds_clk_mask = BIT(1) | BIT(0),
+};
+
static const struct rcar_du_device_info rcar_du_r8a7779_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_INTERLACED
@@ -371,6 +398,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7744", .data = _du_r8a7743_info },
{ .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
{ .compatible = "renesas,du-r8a77470", .data = _du_r8a77470_info },
+ { .compatible = "renesas,du-r8a774c0", .data = _du_r8a774c0_info },
{ .compatible = "renesas,du-r8a7779", .data = _du_r8a7779_info },
{ .compatible = "renesas,du-r8a7790", .data = _du_r8a7790_info },
{ .compatible = "renesas,du-r8a7791", .data = _du_r8a7791_info },
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE
Hi Tomasz,
On 12/13/18 2:02 AM, Tomasz Figa wrote:
> On Thu, Dec 6, 2018 at 1:12 AM Helen Koike wrote:
>>
>> Hi Ville
>>
>> On 11/27/18 11:34 AM, Ville Syrjälä wrote:
>>> On Fri, Nov 23, 2018 at 07:53:26PM -0200, Helen Koike wrote:
Allow userspace to identify if the driver supports async update.
>>>
>>> And what exactly is an "async update"?
>>
>> I agree we are lacking docs on this, I'll send in the next version as
>> soon as we agree on a name (please see below).
>>
>> For reference:
>> https://lists.freedesktop.org/archives/dri-devel/2017-April/138586.html
>>
>>>
>>> I keep asking people to come up with the a better name for this, and to
>>> document what it actually means. Recently I've been think we should
>>> maybe just adopt the vulkan terminology (immediate/fifo/mailbox) to
>>> avoid introducing yet another set of names for the same thing. We'd
>>> still want to document things properly though.
>>
>> Another name it was suggested was "atomic amend", this feature basically
>> allows userspace to complement an update previously sent (i.e. its in
>> the queue and wasn't commited yet), it allows adding a plane update to
>> the next commit. So what do you think in renaming it to "atomic amend"?
>
> Note that it doesn't seem to be what the code currently is doing. For
> example, for cursor updates, it doesn't seem to be working on the
> currently pending commit, but just directly issues an atomic async
> update call to the planes. The code actually seems to fall back to a
> normal sync commit, if there is an already pending commit touching the
> same plane or including a modeset.
It should fail as discussed at:
https://patchwork.freedesktop.org/patch/243088/
There was the following code inside the drm_atomic_helper_async_check()
in the previous patch which would fallback to a normal commit if there
isn't any pending commit to amend:
+ if (!old_plane_state->commit)
+ return -EINVAL;
In the v2 of the patch https://patchwork.freedesktop.org/patch/263712/
this got removed, but which means that async update will be enabled
anyway. So the following code is wrong:
- if (state->legacy_cursor_update)
+ if (state->async_update || state->legacy_cursor_update)
state->async_update = !drm_atomic_helper_async_check(dev,
state);
Does it make sense? If yes I'll fix this in the next version of the
Atomic IOCTL patch (and also those two patches should be in the same
series, I'll send them together next time).
Thanks for pointing this out.
Please let me know if you still don't agree on the name "atomic amend",
or if I am missing something.
Helen
>
> Best regards,
> Tomasz
>
>> Or do you suggest another name? I am not familiar with vulkan terminology.
>>
>>
>> Thanks
>> Helen
>>
>>>
Signed-off-by: Enric Balletbo i Serra
[prepared for upstream]
Signed-off-by: Helen Koike
---
Hi,
This patch introduces the ASYNC_UPDATE cap, which originated from the
discussion regarding DRM_MODE_ATOMIC_AMEND on [1], to allow user to
figure that async_update exists.
This was tested using a small program that exercises the uAPI for easy
sanity testing. The program was created by Alexandros and modified by
Enric to test the capability flag [2].
The test worked on a rockchip Ficus v1.1 board on top of mainline plus
the patch to update cursors asynchronously through atomic plus the patch
that introduces the ATOMIC_AMEND flag for the drm/rockchip driver.
To test, just build the program and use the --atomic flag to use the cursor
plane with the ATOMIC_AMEND flag. E.g.
drm_cursor --atomic
[1] https://patchwork.freedesktop.org/patch/243088/
[2]
https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability
Thanks
Helen
drivers/gpu/drm/drm_ioctl.c | 11 +++
include/uapi/drm/drm.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 94bd872d56c4..4a7e0f874171 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "drm_legacy.h"
#include "drm_internal.h"
#include "drm_crtc_internal.h"
@@ -229,6 +230,7 @@ static int drm_getcap(struct drm_device *dev, void
*data, struct drm_file *file_
{
struct drm_get_cap *req = data;
struct drm_crtc *crtc;
+struct drm_plane *plane;
req->value = 0;
@@ -292,6 +294,15 @@ static int drm_getcap(struct drm_device *dev, void
*data, struct drm_file *file_
case DRM_CAP_CRTC_IN_VBLANK_EVENT:
req->value = 1;
break;
+case DRM_CAP_ASYNC_UPDATE:
+req->value = 1;
+
[PATCH 2/2] drm/panel: simple: add support for Chefree CH101OLHLWH-002
This adds support for the Chefree CH101OLHLWH-002 LVDS 1280x720
LCD panel, which can be supported by the simple panel driver.
Timings are taken from the datasheet version P0.5.
Signed-off-by: Marek Vasut
Cc: Rob Herring
Cc: Thierry Reding
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9c69e739a524d..29e6c629864f2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -941,6 +941,35 @@ static const struct panel_desc cdtech_s070wv95_ct16 = {
},
};
+static const struct display_timing chefree_ch101olhlwh_002_timing = {
+ .pixelclock = { 6890, 7110, 7340 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 65, 80, 95 },
+ .hback_porch = { 64, 79, 94 },
+ .hsync_len = { 1, 1, 1 },
+ .vactive = { 800, 800, 800 },
+ .vfront_porch = { 7, 11, 14 },
+ .vback_porch = { 7, 11, 14 },
+ .vsync_len = { 1, 1, 1 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+
+};
+
+static const struct panel_desc chefree_ch101olhlwh_002 = {
+ .timings = _ch101olhlwh_002_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 135,
+ },
+ .delay = {
+ .enable = 200,
+ .disable = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -2553,6 +2582,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "cdtech,s070wv95-ct16",
.data = _s070wv95_ct16,
+ }, {
+ .compatible = "chefree,ch101olhlwh-002",
+ .data = _ch101olhlwh_002,
}, {
.compatible = "chunghwa,claa070wp03xg",
.data = _claa070wp03xg,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6] gpu: ipu-csi: Swap fields according to input/output field types
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().
Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).
When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
Changes since v5:
- Convert to const the infmt, outfmt, and mbus_cfg pointer args to
ipu_csi_init_interface(), suggested by Philipp Zabel.
- Bring back if_fmt local var and don't copy outfmt to local stack in
csi_setup(), suggested by Philipp.
Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
by Philipp.
- Fixed a regression in csi_setup(), caught by Philipp.
---
drivers/gpu/ipu-v3/ipu-csi.c | 126 +++---
drivers/staging/media/imx/imx-media-csi.c | 7 +-
include/video/imx-ipu-v3.h| 5 +-
3 files changed, 89 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..d1e575571a8d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,12 +325,21 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config
*cfg, u32 mbus_code,
return 0;
}
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+ return (field != V4L2_FIELD_ALTERNATE) ? field :
+ ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
/*
* Fill a CSI bus config struct from mbus_config and mbus_framefmt.
*/
static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
-struct v4l2_mbus_config *mbus_cfg,
-struct v4l2_mbus_framefmt *mbus_fmt)
+ const struct v4l2_mbus_config *mbus_cfg,
+ const struct v4l2_mbus_framefmt *mbus_fmt)
{
int ret;
@@ -374,22 +383,76 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config
*csicfg,
return 0;
}
+static int
+ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+ const struct v4l2_mbus_framefmt *infmt,
+ const struct v4l2_mbus_framefmt *outfmt,
+ v4l2_std_id std)
+{
+ enum v4l2_field infield, outfield;
+ bool swap_fields;
+
+ /* get translated field type of input and output */
+ infield = ipu_csi_translate_field(infmt->field, std);
+ outfield = ipu_csi_translate_field(outfmt->field, std);
+
+ /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+ swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+ V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+ infield != outfield);
+
+ if (!swap_fields) {
+ /*
+* Field0BlankEnd = 110, Field0BlankStart = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd = 111, Field1BlankStart = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+ ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+ } else {
+ dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+ /* same as above but with F-bit inverted */
+ ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+ }
+
+ ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
+
+ return 0;
+}
+
+
int ipu_csi_init_interface(struct ipu_csi *csi,
- struct v4l2_mbus_config *mbus_cfg,
- struct v4l2_mbus_framefmt *mbus_fmt)
+
Re: [PATCH v4 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
On Thu, Dec 13, 2018 at 04:35:31PM +0100, Hans de Goede wrote: > DSI LCD panels describe an initialization sequence in the Video BIOS > Tables using so called MIPI sequences. One possible element in these > sequences is a PMIC specific element of 15 bytes. > > Although this is not really an ACPI opregion, the ACPI opregion code is the > closest thing we have. We need to have support for these PMIC specific MIPI > sequence elements somwhere. Since we already instantiate a special platform > device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to, > with PMIC specific implementations of the OpRegion, the handling of MIPI > sequence PMIC elements fits very well in the ACPI PMIC OpRegion code. > > This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element() > function, which is to be backed by a PMIC specific > exec_mipi_pmic_seq_element callback. This function will be called by the > i915 code to execture MIPI sequence PMIC elements. > > Signed-off-by: Hans de Goede Reviewed-by: Mika Westerberg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: fix compiler warnings about wm variable
From: Huaisheng Ye
There are compiler warnings within functions 'dcn10_log_hubbub_state’
and 'dcn10_get_hubbub_state’. This patch avoids the compiler reports
the following warning when building amdgpu.ko.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
function ‘dcn10_log_hubbub_state’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:94:9:
warning: missing braces around initializer [-Wmissing-braces]
struct dcn_hubbub_wm wm = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:94:9:
warning: (near initialization for ‘wm.sets’) [-Wmissing-braces]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c: In
function ‘dcn10_get_hubbub_state’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9:
warning: missing braces around initializer [-Wmissing-braces]
struct dcn_hubbub_wm wm = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9:
warning: (near initialization for ‘wm.sets’) [-Wmissing-braces]
Signed-off-by: Huaisheng Ye
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 3 ++-
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 193184a..e96933a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -91,9 +91,10 @@ static void log_mpc_crc(struct dc *dc,
void dcn10_log_hubbub_state(struct dc *dc, struct dc_log_buffer_ctx *log_ctx)
{
struct dc_context *dc_ctx = dc->ctx;
- struct dcn_hubbub_wm wm = {0};
+ struct dcn_hubbub_wm wm;
int i;
+ memset(, 0, sizeof(struct dcn_hubbub_wm));
hubbub1_wm_read_state(dc->res_pool->hubbub, );
DTN_INFO("HUBBUB WM: data_urgent pte_meta_urgent"
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
index 6415890..f5610ea 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
@@ -71,7 +71,7 @@ static unsigned int snprintf_count(char *pBuf, unsigned int
bufSize, char *fmt,
static unsigned int dcn10_get_hubbub_state(struct dc *dc, char *pBuf, unsigned
int bufSize)
{
struct dc_context *dc_ctx = dc->ctx;
- struct dcn_hubbub_wm wm = {0};
+ struct dcn_hubbub_wm wm;
int i;
unsigned int chars_printed = 0;
@@ -80,6 +80,7 @@ static unsigned int dcn10_get_hubbub_state(struct dc *dc,
char *pBuf, unsigned i
const uint32_t ref_clk_mhz = dc_ctx->dc->res_pool->ref_clock_inKhz /
1000;
static const unsigned int frac = 1000;
+ memset(, 0, sizeof(struct dcn_hubbub_wm));
hubbub1_wm_read_state(dc->res_pool->hubbub, );
chars_printed = snprintf_count(pBuf, remaining_buffer,
"wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_chanage\n");
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ati_pcigart: Fix error code in drm_ati_pcigart_init()
The drm_ati_pcigart_init() function was originally suppose to return one
on success and zero on failure, but these days it returns a mix of
zero, one and -ENOMEM on failure.
This patch cleans it up and modifies the caller so now the function
returns zero on success and negative error codes on failure.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/ati_pcigart.c | 7 ---
drivers/gpu/drm/r128/r128_cce.c | 5 +++--
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
index 6c4d4b6eba80..2362f07fe1fc 100644
--- a/drivers/gpu/drm/ati_pcigart.c
+++ b/drivers/gpu/drm/ati_pcigart.c
@@ -103,7 +103,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
unsigned long pages;
u32 *pci_gart = NULL, page_base, gart_idx;
dma_addr_t bus_address = 0;
- int i, j, ret = 0;
+ int i, j, ret = -ENOMEM;
int max_ati_pages, max_real_pages;
if (!entry) {
@@ -117,7 +117,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
if (pci_set_dma_mask(dev->pdev, gart_info->table_mask)) {
DRM_ERROR("fail to set dma mask to 0x%Lx\n",
(unsigned long long)gart_info->table_mask);
- ret = 1;
+ ret = -EFAULT;
goto done;
}
@@ -160,6 +160,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
drm_ati_pcigart_cleanup(dev, gart_info);
address = NULL;
bus_address = 0;
+ ret = -ENOMEM;
goto done;
}
page_base = (u32) entry->busaddr[i];
@@ -188,7 +189,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
page_base += ATI_PCIGART_PAGE_SIZE;
}
}
- ret = 1;
+ ret = 0;
#if defined(__i386__) || defined(__x86_64__)
wbinvd();
diff --git a/drivers/gpu/drm/r128/r128_cce.c b/drivers/gpu/drm/r128/r128_cce.c
index c9890afe69d6..b91af1bf531b 100644
--- a/drivers/gpu/drm/r128/r128_cce.c
+++ b/drivers/gpu/drm/r128/r128_cce.c
@@ -560,11 +560,12 @@ static int r128_do_init_cce(struct drm_device *dev,
drm_r128_init_t *init)
dev_priv->gart_info.addr = NULL;
dev_priv->gart_info.bus_addr = 0;
dev_priv->gart_info.gart_reg_if = DRM_ATI_GART_PCI;
- if (!drm_ati_pcigart_init(dev, _priv->gart_info)) {
+ rc = drm_ati_pcigart_init(dev, _priv->gart_info);
+ if (rc) {
DRM_ERROR("failed to init PCI GART!\n");
dev->dev_private = (void *)dev_priv;
r128_do_cleanup_cce(dev);
- return -ENOMEM;
+ return rc;
}
R128_WRITE(R128_PCI_GART_PAGE, dev_priv->gart_info.bus_addr);
#if IS_ENABLED(CONFIG_AGP)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107826] amdgpu-pro 18.30/18.40: Missing xserver modesetting package (--px install)
https://bugs.freedesktop.org/show_bug.cgi?id=107826 --- Comment #5 from qnerd --- Thank's for your clarification! That will help with setting things up properly. Regards, -- 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] dts: rockchip: rk3066: add qos_hdmi and HCLK_HDMI to pmu node
Hi Johan,
On Sun, Dec 16, 2018 at 12:03 AM Johan Jonker wrote:
>
> A MK808 TV stick with rk3066 processor boots normal with logo and console.
> After the boot the monitor remains black.
> This patch fixes a vblank timeout crash by adding qos_hdmi and
> HCLK_HDMI to the pmu node.
> The HCLK_HDMI clock and the RK3066_PD_VIO power domain
> will now turn on and off together.
>
> Signed-off-by: Johan Jonker
> ---
> arch/arm/boot/dts/rk3066a.dtsi | 6 --
> arch/arm/boot/dts/rk3xxx.dtsi | 5 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
Thanks for the patch. Unfortunately, it looks like you didn't add the
necessary mailing lists to the recipient list. For reference, the
./scripts/get_maintainer.pl script in the kernel source tree should be
able to give you a reasonable recipient list. For now, I added the
mailing lists on CC and replied without snipping, so people should be
still able to review the patch.
Other than that, It looks reasonable to me, but we need someone with
access to SoC documentation to check it. Heiko, Sandy, is that
something you would be able to help with?
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 30dc8af0b..6e7cdde84 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -672,13 +672,15 @@
> < ACLK_IPP>,
> < HCLK_IPP>,
> < ACLK_RGA>,
> -< HCLK_RGA>;
> +< HCLK_RGA>,
> +< HCLK_HDMI>;
> pm_qos = <_lcdc0>,
> <_lcdc1>,
> <_cif0>,
> <_cif1>,
> <_ipp>,
> -<_rga>;
> +<_rga>,
> +<_hdmi>;
> };
>
> pd_video@RK3066_PD_VIDEO {
> diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
> index 97307a405..1f9496e81 100644
> --- a/arch/arm/boot/dts/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rk3xxx.dtsi
> @@ -187,6 +187,11 @@
> reg = <0x1012f280 0x20>;
> };
>
> + qos_hdmi: qos@1012f300 {
> + compatible = "syscon";
> + reg = <0x1012f300 0x20>;
> + };
> +
Is this really common for all rk3xxx SoCs?
> usb_otg: usb@1018 {
> compatible = "rockchip,rk3066-usb", "snps,dwc2";
> reg = <0x1018 0x4>;
> --
> 2.11.0
>
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201727] Hardware Error reported on Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=201727
Rafał Miłecki (zaj...@gmail.com) changed:
What|Removed |Added
CC||zaj...@gmail.com
--- Comment #12 from Rafał Miłecki (zaj...@gmail.com) ---
I was curious what could have fixed that. I tried to reproduce it on a totally
different notebook with 2500U (EliteBook 745 G5) but I wasn't getting any MCE
reported errors with the commit 284dec4317c8 ("drm/amdgpu: enable GTT PD/PT for
raven v3"). Probably because of having more stole VRAM:
[5.232179] [drm] amdgpu: 1024M of VRAM memory ready
It's probably one of those:
git log --oneline v4.20-rc2..v4.20-rc5 drivers/gpu/drm/amd/amdgpu/
ad97d9de4583 drm/amdgpu: Add delay after enable RLC ucode
1954db153d18 drm/amdgpu: Avoid endless loop in GPUVM fragment processing
9ce2b991f7ea drm/amdgpu: Cast to uint64_t before left shift
a5d0f4565996 drm/amdgpu: Enable HDP memory light sleep
8d4d7c589947 drm/amdgpu: Add missing firmware entry for HAINAN
919a52fc4ca1 drm/amdgpu: Fix oops when pp_funcs->switch_power_profile is unset
69756c6ff0de drm/amdgpu: Add amdgpu "max bpc" connector property (v2)
c1a1eb45 drm/amdgpu: fix huge page handling on Vega10
c837243ff401 drm/amdgpu: fix bug with IH ring setup
5581c670fb7e drm/amdgpu: set system aperture to cover whole FB region
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #28 from Shmerl --- Not sure if it's related, but with 4.20.0-rc6 the regression when monitor goes to sleep before reaching sddm is back. It's erratic, i.e. doesn't happen on every boot. And I do see this REG_WAIT in dmesg when it does. Turning monitor off and on, then going to tty and restarting sddm works around it. Similar bug was fixed in the previous kernels, so I wonder if the fix for this one somehow brought that issue back. GPU: Sapphire Pulse Vega 56. -- 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 115431] radeon 0000:01:00.0: VCE init error (-22).
https://bugzilla.kernel.org/show_bug.cgi?id=115431 Luya Tshimbalanga (l...@fedoraproject.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UNREPRODUCIBLE --- Comment #1 from Luya Tshimbalanga (l...@fedoraproject.org) --- Closing this report as I no longer have that laptop. -- 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 3/3] drm/panel: simple: Add support for VXT VL050-8048NT-C01 panel
Hi Thierry, On Tue, Dec 4, 2018 at 2:57 PM Fabio Estevam wrote: > > Add support for the VXT VL050-8048NT-C01 800x480 panel to the > panel-simple driver. > > This panel is used on some boards manufactured by TechNexion, such as > imx7d-pico. > > Signed-off-by: Fabio Estevam Do you think it is possible to get this series applied for 4.21? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108350] amd-staging-drm-next-git witcher3 crashes and graphical oddities vega10 radv
https://bugs.freedesktop.org/show_bug.cgi?id=108350 Alessandro changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 109073] AMDGPU Radeon RX540 system freezes poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #1 from tiredandn...@gmail.com --- Original launchpad bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1807511 -- 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 109073] AMDGPU Radeon RX540 system freezes poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 Bug ID: 109073 Summary: AMDGPU Radeon RX540 system freezes poor performance with ac adapter plugged in Product: DRI Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: tiredandn...@gmail.com Created attachment 142831 --> https://bugs.freedesktop.org/attachment.cgi?id=142831=edit dmesg with 4.20.0-042000rc6-generic kernel Various temporary UI freezes when booting Ubuntu 18.10. dmesg reports various amdgpu warnings and errors. Also tested with 4.20.0-042000rc6-generic kernel -- 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 108575] amd-staging-drm-next, R4 Mullins hdmi monitor wont wake up from S3 - *ERROR* REG_WAIT timeout 1us * 80000 tries - dce_abm_immediate_disable
https://bugs.freedesktop.org/show_bug.cgi?id=108575 --- Comment #3 from Przemek --- It seems also, that WARNING from the first comment is not related to this situation, it occurs, but less often tough, so in this case should we change the title of this bug report or leave it as is? Thanks, Przemek. -- 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 108575] amd-staging-drm-next, R4 Mullins hdmi monitor wont wake up from S3 - *ERROR* REG_WAIT timeout 1us * 80000 tries - dce_abm_immediate_disable
https://bugs.freedesktop.org/show_bug.cgi?id=108575 Przemek changed: What|Removed |Added Attachment #142606|0 |1 is obsolete|| --- Comment #2 from Przemek --- Created attachment 142828 --> https://bugs.freedesktop.org/attachment.cgi?id=142828=edit log with drm.debug=0x4 after wake up from suspend Glitched screen issue has been resolved (I think - Thank you very much), but the issue with black screens still persist in amd-staging-drm-next repo synced on 15th of December. There is a strange output in attached syslog, amdgpu is saying that hdmi monitor is disconnected while it's not true. It is connected and powered on, but its look like connector doesn't see it. Thanks, Przemek. -- 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] dma-buf: fix debugfs versus rcu and fence dumping
Hi Jérôme,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/jglisse-redhat-com/dma-buf-fix-debugfs-versus-rcu-and-fence-dumping/20181206-205935
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
include/linux/slab.h:332:43: warning: dubious: x & !y
include/linux/slab.h:332:43: warning: dubious: x & !y
>> drivers/dma-buf/dma-buf.c:1031:9: warning: context imbalance in
>> 'dma_buf_debug_show' - different lock contexts for basic block
vim +/dma_buf_debug_show +1031 drivers/dma-buf/dma-buf.c
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1008
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1009 #ifdef
CONFIG_DEBUG_FS
eb0b947e drivers/dma-buf/dma-buf.c Mathias Krause 2016-06-19 1010 static int
dma_buf_debug_show(struct seq_file *s, void *unused)
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1011 {
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1012 int ret;
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1013 struct
dma_buf *buf_obj;
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1014 struct
dma_buf_attachment *attach_obj;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1015 struct
reservation_object *robj;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1016 struct
reservation_object_list *fobj;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1017 struct
dma_fence *fence;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1018
unsigned seq;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1019 int
count = 0, attach_count, shared_count, i;
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1020 size_t
size = 0;
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1021
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1022 ret =
mutex_lock_interruptible(_list.lock);
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1023
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1024 if (ret)
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1025
return ret;
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1026
c0b00a52 drivers/base/dma-buf.cSumit Semwal 2014-02-03 1027
seq_puts(s, "\nDma-buf Objects:\n");
da6c8f5e drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1028
seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\n",
da6c8f5e drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1029
"size", "flags", "mode", "count");
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1030
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 @1031
list_for_each_entry(buf_obj, _list.head, list_node) {
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1032
ret = mutex_lock_interruptible(_obj->lock);
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1033
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1034
if (ret) {
c0b00a52 drivers/base/dma-buf.cSumit Semwal 2014-02-03 1035
seq_puts(s,
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1036
"\tERROR locking buffer object: skipping\n");
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1037
continue;
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1038
}
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1039
c0b00a52 drivers/base/dma-buf.cSumit Semwal 2014-02-03 1040
seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\n",
c0b00a52 drivers/base/dma-buf.cSumit Semwal 2014-02-03 1041
buf_obj->size,
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1042
buf_obj->file->f_flags, buf_obj->file->f_mode,
a1f6dbac drivers/dma-buf/dma-buf.c Al Viro2014-08-20 1043
file_count(buf_obj->file),
c0b00a52 drivers/base/dma-buf.cSumit Semwal 2014-02-03 1044
buf_obj->exp_name);
b89e3563 drivers/base/dma-buf.cSumit Semwal 2013-04-04 1045
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1046
robj = buf_obj->resv;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1047
while (true) {
5eb2c72c drivers/dma-buf/dma-buf.c Russell King 2017-03-31 1048
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296 Romain Reignier changed: What|Removed |Added CC||rom.reign...@gmail.com --- Comment #6 from Romain Reignier --- (In reply to darkbasic from comment #5) > I confirm, the same with B450M + 2400g and 4.18/4.19/4.20-rc1. Exactly like darkbasic, MSI B450M Mortar, 2400G on 4.19.8 (from Ubuntu kernel team). Most of the time, even with that "calltrace", the system is useable but from time to time, I get a freeze with the following (not sure it is related): [ 2590.157513] romain-desktop kernel: gmc_v9_0_process_interrupt: 10 callbacks suppressed [ 2590.157518] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157525] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010980b000 from 27 [ 2590.157528] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157535] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157539] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010981 from 27 [ 2590.157541] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157548] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157551] romain-desktop kernel: amdgpu :38:00.0: at address 0x000109811000 from 27 [ 2590.157553] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157560] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157562] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010980c000 from 27 [ 2590.157564] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157571] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157574] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010980b000 from 27 [ 2590.157576] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157583] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157585] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010980 from 27 [ 2590.157587] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157594] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157597] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010981 from 27 [ 2590.157599] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157605] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157608] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010981 from 27 [ 2590.157610] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157617] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157619] romain-desktop kernel: amdgpu :38:00.0: at address 0x000109811000 from 27 [ 2590.157621] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2590.157628] romain-desktop kernel: amdgpu :38:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:1 pasid:32768, for process Xorg pi ) [ 2590.157630] romain-desktop kernel: amdgpu :38:00.0: at address 0x00010981 from 27 [ 2590.157632] romain-desktop kernel: amdgpu :38:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00101031 [ 2600.376443] romain-desktop kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=107913, emitted seq=107915 [ 2600.376449] romain-desktop kernel: [drm] GPU recovery disabled. Does anyone know a workaround or a tree with a fix? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org
[Bug 108641] Interlaced dark lines in XCOM2 (UE3.5) on Aruba and Turks
https://bugs.freedesktop.org/show_bug.cgi?id=108641 --- Comment #2 from steelwin...@gmail.com --- Refreshing the upload due to the link expiring: https://www38.zippyshare.com/v/d0oWhmbR/file.html Just a remark, the capture was taken with RenderDoc 1.1 and the bug still occurs on Mesa 18.3.1. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #24 from quirin.blae...@freenet.de --- Bug is still alive. amd-staging-drm-next 4da295299bda146326b44f22d8eeaa797d6acb38 -- 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
