[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #33 from Alan W. Irwin --- Created attachment 142358 --> https://bugs.freedesktop.org/attachment.cgi?id=142358=edit tarball containing log information concerning latest lockup -- 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 v2 4/4] ARM: dts: imx6sx: Add DISPLAY power domain support
On Wed, Oct 31, 2018 at 12:17:50PM +, Leonard Crestez wrote: > On 10/31/2018 8:12 AM, Shawn Guo wrote: > > On Mon, Oct 08, 2018 at 06:06:23PM +, Leonard Crestez wrote: > >> This was implemented in the driver but not actually defined and > >> referenced in dts. This makes it always on. > >> > >> From reference manual in section "10.4.1.4.1 Power Distribution": > >> > >> "Display domain - The DISPLAY domain contains GIS, CSI, PXP, LCDIF, > >> PCIe, DCIC, and LDB. It is supplied by internal regulator." > >> > >> The current pd_pcie is actually only for PCIE_PHY, the PCIE ip block is > >> actually inside the DISPLAY domain. Handle this by adding the pcie node > >> in both power domains. > >> > >> Signed-off-by: Leonard Crestez > > > > Applied, thanks. > > As mentioned in the cover letter this requires multi-PD support in > imx-pci to be implemented, specifically PATCH 3/4 of this series: > > https://lore.kernel.org/patchwork/patch/996810/ > > Unless that also gets merged soon via pci I expect issues in linux-next. > The patch already has reviewed-by tags so "merging it soon" is not > unreasonable. Oops, I overlooked the notes in cover-letter. Let's use the approach as suggested there - applying the dts change after all driver dependencies are landed. Patch dropped, sorry. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #40 from John W. --- Is there any resolution or work being done on this issue? I've tried the frequency hack and it slightly delayed the issue I also tried the latest amd staging kernel with latest firmware and XF86 driver and found the same issue still happened but somewhat less. Reading my journalctl logs I found sometimes when it occurs it will attempt to recover but in the process loses NRAM and freezes the screen covered in odd colors At least when this occurs the machine is otherwise functional and I can change TTYs and kill X11 I'm using a 580 and I've added the relevant logs of the attempted recovery. Nov 02 15:31:26 Towering-DG kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, signaled seq=59193, emitted seq=59194 Nov 02 15:31:27 Towering-DG kernel: amdgpu :01:00.0: GPU reset begin! Nov 02 15:31:27 Towering-DG kernel: amdgpu :01:00.0: GPU pci config reset Nov 02 15:31:27 Towering-DG kernel: amdgpu :01:00.0: GPU reset succeeded, trying to resume Nov 02 15:31:27 Towering-DG kernel: [drm] PCIE GART of 256M enabled (table at 0x00F40030). Nov 02 15:31:27 Towering-DG kernel: [drm:amdgpu_device_gpu_recover [amdgpu]] *ERROR* VRAM is lost! Nov 02 15:31:27 Towering-DG kernel: amdgpu :01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring comp_1.2.1 test failed (-110) (Note: Usually it's ring SDMA0 instead of SDMA1 and occasionally GFX) -- 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] backlight/arcxcnn support newer chips in arcxcnn family and fix vendor prefix
On Thu, Nov 01, 2018 at 06:49:01PM -0400, Brian Dodge wrote:
> Support for ArcticSand arc1 and arc3 ships is added. Some ranges
> and control paths are modified based on the chip id probed via
> i2c.
This...
> Also updates vendor prefix to arctic from arc which was a
> mistake in the original driver submission
... and this looks like they would be better placed into separate
patches.
> Signed-off-by: Brian Dodge
This looks very similar to your patch of 10 minutes ago. Is it an
updated version? Sorry to get all procedural on you but if it is
an update then bumping the version number and summary of changes
would be helpful (even if the change summary is just "decided to
rewrite the patch header to improve clarity").
Daniel.
> ---
> .../bindings/leds/backlight/arcxcnn_bl.txt | 20
> ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> index dcaa239..230abde 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> @@ -1,8 +1,8 @@
> -Binding for ArcticSand arc family LED drivers
> +Binding for ArcticSand arc2c0608 LED driver
>
> Required properties:
> -- compatible:"arctic,arc1c0608", "arctic,arc2c0608",
> "arctic,arc3c0845"
> -- reg: slave address
> +- compatible:should be "arc,arc2c0608"
> +- reg: slave address
>
> Optional properties:
> - default-brightness:brightness value on boot, value from: 0-4095
> @@ -11,19 +11,19 @@ Optional properties:
> - led-sources: List of enabled channels from 0 to 5.
> See Documentation/devicetree/bindings/leds/common.txt
>
> -- arctic,led-config-0: setting for register ILED_CONFIG_0
> -- arctic,led-config-1: setting for register ILED_CONFIG_1
> -- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
> -- arctic,comp-config:setting for register CONFIG_COMP
> -- arctic,filter-config: setting for register FILTER_CONFIG
> -- arctic,trim-config:setting for register IMAXTUNE
> +- arc,led-config-0: setting for register ILED_CONFIG_0
> +- arc,led-config-1: setting for register ILED_CONFIG_1
> +- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
> +- arc,comp-config: setting for register CONFIG_COMP
> +- arc,filter-config: setting for register FILTER_CONFIG
> +- arc,trim-config: setting for register IMAXTUNE
>
> Note: Optional properties not specified will default to values in IC EPROM
>
> Example:
>
> arc2c0608@30 {
> - compatible = "arctic,arc2c0608";
> + compatible = "arc,arc2c0608";
> reg = <0x30>;
> default-brightness = <500>;
> label = "lcd-backlight";
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108644] driver/card crashes with latest polaris11 firmware
https://bugs.freedesktop.org/show_bug.cgi?id=108644 Bug ID: 108644 Summary: driver/card crashes with latest polaris11 firmware Product: DRI Version: unspecified Hardware: PowerPC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: d...@danny.cz CC: bcroc...@redhat.com Created attachment 142356 --> https://bugs.freedesktop.org/attachment.cgi?id=142356=edit dmesg-20181102 After updating to the latest polaris11 firmware (from linux-firmware-20181008-88.gitc6b6265d.fc28.noarch) I'm experiencing driver/card crashes. This is on a Power9 system running 4.19.0 kernel. There was no such crashes with the previous firmware and all 4.19-pre kernels (and even earlier). ... lis 02 11:54:00 talos.danny.cz kernel: EEH: Frozen PHB#0-PE#0 detected lis 02 11:54:00 talos.danny.cz kernel: EEH: PE location: N/A, PHB location: N/A lis 02 11:54:00 talos.danny.cz kernel: CPU: 35 PID: 3250 Comm: InputThread Not tainted 4.19.0-1.fc30.op.1.ppc64le #1 lis 02 11:54:00 talos.danny.cz kernel: Call Trace: lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bf810] [c0be3f9c] dump_stack+0xb0/0xf4 (unreliable) lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bf850] [c0040738] eeh_dev_check_failure+0x4a8/0x5d0 lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bf8f0] [c00408ec] eeh_check_failure+0x8c/0xd0 lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bf930] [c0080de61998] amdgpu_mm_rreg+0x240/0x2a0 [amdgpu] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bf990] [c0080df22a68] dce_v11_0_lock_cursor+0x50/0xf0 [amdgpu] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bf9d0] [c0080df236a0] dce_v11_0_crtc_cursor_move+0x38/0x80 [amdgpu] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfa10] [c0080d11f248] drm_mode_cursor_common+0x1e0/0x2c0 [drm] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfae0] [c0080d11f6c8] drm_mode_cursor_ioctl+0x50/0x70 [drm] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfb30] [c0080d0f7f14] drm_ioctl_kernel+0xdc/0x170 [drm] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfb90] [c0080d0f8414] drm_ioctl+0x20c/0x430 [drm] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfcd0] [c0080de60078] amdgpu_drm_ioctl+0x70/0xd0 [amdgpu] lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfd20] [c040f0f4] do_vfs_ioctl+0xd4/0x8d0 lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfdc0] [c040f9b4] ksys_ioctl+0xc4/0x110 lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfe10] [c040fa28] sys_ioctl+0x28/0x80 lis 02 11:54:00 talos.danny.cz kernel: [c0002006af9bfe30] [c000b9e4] system_call+0x5c/0x70 lis 02 11:54:00 talos.danny.cz kernel: EEH: Detected PCI bus error on PHB#0-PE#0 lis 02 11:54:00 talos.danny.cz kernel: EEH: This PCI device has failed 1 times in the last hour and will be permanently disabled after 5 failures. lis 02 11:54:00 talos.danny.cz kernel: EEH: Notify device drivers to shutdown lis 02 11:54:00 talos.danny.cz kernel: EEH: Beginning: 'error_detected(IO frozen)' lis 02 11:54:00 talos.danny.cz kernel: EEH: PE#0 (PCI :01:00.1): driver not EEH aware lis 02 11:54:00 talos.danny.cz kernel: EEH: PE#0 (PCI :01:00.0): driver not EEH aware lis 02 11:54:00 talos.danny.cz kernel: EEH: Finished:'error_detected(IO frozen)' with aggregate recovery state:'none' lis 02 11:54:00 talos.danny.cz kernel: EEH: Collect temporary log lis 02 11:54:00 talos.danny.cz kernel: EEH: of node=:01:00.1 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI device/vendor: aae01002 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI cmd/status register: 00100546 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E capabilities and status follow: lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E 00: 0012a010 8fa1 2930 00400883 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E 10: 1081 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E 20: lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E AER capability register set follows: lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E AER 00: 32820001 00462030 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E AER 10: 2000 01e0 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E AER 20: lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E AER 30: lis 02 11:54:00 talos.danny.cz kernel: EEH: of node=:01:00.0 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI device/vendor: 67e31002 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI cmd/status register: 00100546 lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E capabilities and status follow: lis 02 11:54:00 talos.danny.cz kernel: EEH: PCI-E 00: 0012a010 8fa1 2930 00400883
[Bug 201605] amdgpu: RX 570 reboots the PC when stressed
https://bugzilla.kernel.org/show_bug.cgi?id=201605 fin4...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from fin4...@hotmail.com --- RX 570 did blow up my 520W PSU when I played Just Cause 3. This bug was PSU problem. The Heaven benchmarks runs fine with a new Kolink 700 watt PSU. -- 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
[PATCH 04/10] drm/sun4i: sun6i_mipi_dsi: Setup burst mode
Setting up burst mode display would require to compute
- Horizontal timing edge values to fill burst drq register
- Line, sync values to fill burst line register
Since there is no direct documentation for these computations
the edge and line formulas are taken from BSP code
(in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
line_num = panel->lcd_ht*dsi_pixel_bits[panel->lcd_dsi_format]/
(8*panel->lcd_dsi_lane);
edge1 = sync_point+(panel->lcd_x+panel->lcd_hbp+20)*
dsi_pixel_bits[panel->lcd_dsi_format] /(8*panel->lcd_dsi_lane);
edge1 = (edge1>line_num)?line_num:edge1;
edge0 = edge1+(panel->lcd_x+40)*tcon_div/8;
edge0 = (edge0>line_num)?(edge0-line_num):1;
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 48 +-
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 4965b2c71e4c..b6c01891df36 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -375,20 +375,52 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
struct mipi_dsi_device *device = dsi->device;
+ unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format);
+ u32 line_num, edge0, edge1, hact_sync_bp;
+ u32 sync_point, tcon_div;
u32 val = 0;
- if ((mode->hsync_start - mode->hdisplay) > 20) {
- /* Maagic */
- u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
+ if (device->mode_flags != MIPI_DSI_MODE_VIDEO_BURST) {
+ if ((mode->hsync_start - mode->hdisplay) > 20) {
+ /* Maagic */
+ u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
- drq *= mipi_dsi_pixel_format_to_bpp(device->format);
- drq /= 32;
+ drq *= Bpp;
+ drq /= 32;
- val = (SUN6I_DSI_TCON_DRQ_ENABLE_MODE |
- SUN6I_DSI_TCON_DRQ_SET(drq));
+ val = (SUN6I_DSI_TCON_DRQ_ENABLE_MODE |
+ SUN6I_DSI_TCON_DRQ_SET(drq));
+ }
+
+ regmap_write(dsi->regs, SUN6I_DSI_TCON_DRQ_REG, val);
+
+ return;
}
- regmap_write(dsi->regs, SUN6I_DSI_TCON_DRQ_REG, val);
+ sync_point = 40;
+ tcon_div = 8; /* FIXME need to retrive the divider from TCON */
+
+ line_num = mode->htotal * Bpp / (8 * device->lanes);
+ /* Horizental timings duration excluding front porch */
+ hact_sync_bp = (mode->hdisplay + mode->htotal - mode->hsync_start);
+ edge1 = sync_point + ((hact_sync_bp + 20) * Bpp / (8 * device->lanes));
+ if (edge1 > line_num)
+ edge1 = line_num;
+
+ edge0 = edge1 + (mode->hdisplay + 40) * tcon_div / 8;
+ if (edge0 > line_num)
+ edge0 -= line_num;
+ else
+ edge0 = 1;
+
+ regmap_write(dsi->regs, SUN6I_DSI_BURST_DRQ_REG,
+SUN6I_DSI_BURST_DRQ_EDGE1(edge1) |
+SUN6I_DSI_BURST_DRQ_EDGE0(edge0));
+ regmap_write(dsi->regs, SUN6I_DSI_TCON_DRQ_REG,
+SUN6I_DSI_TCON_DRQ_ENABLE_MODE);
+ regmap_write(dsi->regs, SUN6I_DSI_BURST_LINE_REG,
+SUN6I_DSI_BURST_LINE_NUM(line_num) |
+SUN6I_DSI_BURST_LINE_SYNC_POINT(sync_point));
}
static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/10] 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
---
Note: init sequence is referenced from
https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/drivers/video/sunxi/disp2/disp/lcd/mb709_mipi.c
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 305 ++
3 files changed, 315 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
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 ..718631a72d8b
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+struct fy07024di26a30d {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct backlight_device *backlight;
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct gpio_desc*reset;
+
+ boolis_enabled;
+ boolis_prepared;
+};
+
+static inline struct fy07024di26a30d *panel_to_fy07024di26a30d(struct
drm_panel *panel)
+{
+ return container_of(panel, struct fy07024di26a30d, panel);
+}
+
+struct fy07024di26a30d_init_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define FY07024DI26A30D(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct fy07024di26a30d_init_cmd fy07024di26a30d_init_cmds[] = {
+ FY07024DI26A30D(0x80, 0x58),
+ FY07024DI26A30D(0x81, 0x47),
+ FY07024DI26A30D(0x82, 0xD4),
+ FY07024DI26A30D(0x83, 0x88),
+ FY07024DI26A30D(0x84, 0xA9),
+ FY07024DI26A30D(0x85, 0xC3),
+ FY07024DI26A30D(0x86, 0x82),
+};
+
+static int fy07024di26a30d_prepare(struct drm_panel *panel)
+{
+ struct fy07024di26a30d *ctx = panel_to_fy07024di26a30d(panel);
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ unsigned int i;
+ int ret;
+
+ if (ctx->is_prepared)
+ return 0;
+
+ gpiod_set_value(ctx->reset, 1);
+ msleep(50);
+
+ gpiod_set_value(ctx->reset, 0);
+ msleep(20);
+
+ gpiod_set_value(ctx->reset, 1);
+ msleep(200);
+
+ for (i = 0; i < ARRAY_SIZE(fy07024di26a30d_init_cmds); i++) {
+ const struct fy07024di26a30d_init_cmd *cmd =
+ _init_cmds[i];
+
+ ret = mipi_dsi_dcs_write_buffer(dsi, cmd->data, cmd->len);
+ if (ret < 0)
+ return ret;
+ }
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(panel->dev, "failed to set display on: %d\n", ret);
+ return ret;
+ }
+
+ ctx->is_prepared = true;
+
+ return 0;
+}
+
+static int fy07024di26a30d_enable(struct drm_panel *panel)
+{
+ struct fy07024di26a30d *ctx = panel_to_fy07024di26a30d(panel);
+
+ if (ctx->is_enabled)
+ return 0;
+
+
RE: [PATCH] drm/bridge/sii902x: Fix EDID readback
> > Here (and also in sii902x_i2c_bypass_deselect) you do a rmw access to the > > SII902X_SYS_CTRL_DATA register without coordinating with regmap. Regmap is > > also doing rmw accesses to that register in other parts of the driver. I > > think you need to either add comment as to why that is safe (maybe other > > things make it impossible for the two rmw accesses to cross?), or add the > > missing coordination. > > > > The other two places where SII902X_SYS_CTRL_DATA is being handled are > sii902x_bridge_disable and sii902x_bridge_enable, I didn’t think there is > any chance of the modes being probed while the bridge gets enabled/disabled, > but now that you make me think about it user space may trigger the readback > of the EDID at the most inconvenient times. Anyway, this is a good point, and > since I don't think I am supposed to access regmap's lock from outside the > APIs, > I could switch to the unlocked version of update_bits from within > sii902x_bridge_disable > and sii902x_bridge_enable, and manually grab the i2c adapter lock, what do > you think? > The bridge enable/disable callbacks deal with different bits of register SII902X_SYS_CTRL_DATA, and the value of register SII902X_SYS_CTRL_DATA after sii902x_i2c_bypass_deselect is the same as when sii902x_i2c_bypass_select gets triggered so basically even if we managed to get in the way of the regmap rmw (in the sense that for example sii902x_bridge_enable reads SII902X_SYS_CTRL_DATA and then we call into sii902x_i2c_bypass_select) by the time regmap_update_bits can perform the write operation the value of register SII902X_SYS_CTRL_DATA is the same as the one read by regmap, as "select xfer deselect" won't alter the final value of SII902X_SYS_CTRL_DATA and nobody can get in between. What do you think I should do? Do you think I can leave this alone and maybe add some comments or do you think I should explicitly protect access to SII902X_SYS_CTRL_DATA? Thanks, Fab Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/10] drm/sun4i: sun6i_mipi_dsi: Enable burst mode
Enable video_mode_burst bit from dsi base control register for burst mode display panels. Signed-off-by: Jagan Teki --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index b6c01891df36..b18a01361f11 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -421,6 +421,10 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi, regmap_write(dsi->regs, SUN6I_DSI_BURST_LINE_REG, SUN6I_DSI_BURST_LINE_NUM(line_num) | SUN6I_DSI_BURST_LINE_SYNC_POINT(sync_point)); + + regmap_read(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, ); + val |= SUN6I_DSI_BASIC_CTL_VIDEO_BURST; + regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, val); } static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi, -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] drm/sun4i: sun6i_mipi_dsi: Enable 2byte trail for 4-lane burst mode
For 4-lane, burst mode panels would need to enable 2byte trail_fill
along with filling trail_env in dsi base control register.
Similar reference code avialable in BSP
(in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
if (panel->lcd_dsi_lane == 4)
{
dsi_dev[sel]->dsi_basic_ctl.bits.trail_inv = 0xc;
dsi_dev[sel]->dsi_basic_ctl.bits.trail_fill = 1;
}
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index b18a01361f11..2d34e5f48d29 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -33,6 +33,8 @@
#define SUN6I_DSI_CTL_EN BIT(0)
#define SUN6I_DSI_BASIC_CTL_REG0x00c
+#define SUN6I_DSI_BASIC_CTL_TRAIL_INV(n) (((n) & 0xf) << 4)
+#define SUN6I_DSI_BASIC_CTL_TRAIL_FILL BIT(3)
#define SUN6I_DSI_BASIC_CTL_HBP_DISBIT(2)
#define SUN6I_DSI_BASIC_CTL_HSA_HSE_DISBIT(1)
#define SUN6I_DSI_BASIC_CTL_VIDEO_BURSTBIT(0)
@@ -424,6 +426,10 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
regmap_read(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, );
val |= SUN6I_DSI_BASIC_CTL_VIDEO_BURST;
+ if (device->lanes == 4) {
+ val |= SUN6I_DSI_BASIC_CTL_TRAIL_INV(0xc);
+ val |= SUN6I_DSI_BASIC_CTL_TRAIL_FILL;
+ }
regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, val);
}
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/10] [DO NOT MERGE] arm64: allwinner: a64: pine64-lts: Enable Feiyang FY07024DI26A30-D DSI panel
Feiyang FY07024DI26A30-D MIPI_DSI panel is desiged to attach with
DSI connector on pine64 boards, enable the same for pine64 LTS.
DSI panel connected via board DSI port with,
- DC1SW as AVDD supply
- DLDO2 as DVDD supply
- DLDO1 as VCC-DSI supply
- PD24 gpio for reset pin
- PH10 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
.../dts/allwinner/sun50i-a64-pine64-lts.dts | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
index 72d6961dc312..a5097cf7a8dc 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -5,9 +5,46 @@
*/
#include "sun50i-a64-sopine-baseboard.dts"
+#include
/ {
model = "Pine64 LTS";
compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
"allwinner,sun50i-a64";
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 512>;
+ default-brightness-level = <8>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PH10
*/
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "feiyang,fy07024di26a30d";
+ reg = <0>;
+ avdd-supply = <_dc1sw>;
+ dvdd-supply = <_dldo2>;
+ reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <>;
+ };
+};
+
+_pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm_pin>;
+ status = "okay";
};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/10] 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
---
.../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 02/10] drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection
Instruction loop selection would require before writing loop number registers, so enable idle, LP11 bits on loop selection register. Reference code available in BSP (in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) (dsi_dev[sel]->dsi_inst_loop_sel.dwval = 2<<(4*DSI_INST_ID_LP11) | 3<<(4*DSI_INST_ID_DLY); Signed-off-by: Jagan Teki --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index da152c21ec62..077b57ec964c 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -397,6 +397,10 @@ static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi, struct mipi_dsi_device *device = dsi->device; u16 delay; + regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_SEL_REG, +DSI_INST_ID_HSC << (4 * DSI_INST_ID_LP11) | +DSI_INST_ID_HSD << (4 * DSI_INST_ID_DLY)); + if (device->mode_flags == MIPI_DSI_MODE_VIDEO_BURST) delay = (((mode->htotal - mode->hdisplay) * 150) / ((mode->clock / 1000) * 8)) - 50; -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/sii902x: Fix EDID readback
On 2018-11-02 13:13, Fabrizio Castro wrote:
> While adding SiI9022A support to the iwg23s board, it came
> up that when the HDMI transmitter is in pass through mode the
> device is not compliant with the I2C specification anymore,
> as it requires a far bigger tbuf, due to a delay the HDMI
> transmitter is adding when relaying the STOP condition on the
> monitor i2c side of things.
>
> When not providing an appropriate delay after the STOP condition
> the i2c bus would get stuck. Also, any other traffic on the bus
> while talking to the monitor may cause the transaction to fail
> or even cause issues with the i2c bus as well.
>
> I2c-gates seemed to reach consent as a possible way to address
> these issues, and as such this patch is implementing a solution
> based on that. Since others are clearly relying on the current
> implementation of the driver, this patch won't require any DT
> changes.
>
> Since we don't want any interference during the DDC Bus
> Request/Grant procedure and while talking to the monitor, we
> have to use the adapter locking primitives rather than the
> i2c-mux locking primitives.
>
> Signed-off-by: Fabrizio Castro
> ---
> RFC->PATCH:
> * Incorporated Linus Walleij, Peter Rosin, and Mark Brown comments
>
> Thank you guys
>
> drivers/gpu/drm/bridge/sii902x.c | 264
> +--
> 1 file changed, 196 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index e59a135..4f9d9c7 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -1,4 +1,6 @@
> /*
> + * Copyright (C) 2018 Renesas Electronics
> + *
> * Copyright (C) 2016 Atmel
> * Bo Shen
> *
> @@ -21,6 +23,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -86,8 +89,68 @@ struct sii902x {
> struct drm_bridge bridge;
> struct drm_connector connector;
> struct gpio_desc *reset_gpio;
> + struct i2c_mux_core *i2cmux;
> };
>
> +static int sii902x_read_unlocked(struct i2c_client *i2c, u8 reg, u8 *val)
> +{
> + struct i2c_msg xfer[] = {
> + {
> + .addr = i2c->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = ,
> + }, {
> + .addr = i2c->addr,
> + .flags = I2C_M_RD,
> + .len = 1,
> + .buf = val,
> + }
> + };
> + unsigned char xfers = ARRAY_SIZE(xfer);
> + int ret, retries = 5;
> +
> + do {
> + ret = __i2c_transfer(i2c->adapter, xfer, xfers);
> + if (ret < 0)
> + return ret;
> + } while (ret != xfers && --retries);
> + return ret == xfers ? 0 : -1;
New in 4.19 __i2c_smbus_xfer, and I think it helps here? (untested code)
union i2c_smbus_data data;
int ret;
ret = __i2c_smbus_xfer(i2c->adapter, i2c->addr, i2c->flags,
I2C_SMBUS_READ, reg,
I2C_SMBUS_BYTE_DATA, );
if (ret < 0)
return ret;
*val = data.byte;
return 0;
> +}
> +
> +static int sii902x_write_unlocked(struct i2c_client *i2c, u8 reg, u8 val)
> +{
> + u8 data[2] = {reg, val};
> + struct i2c_msg xfer = {
> + .addr = i2c->addr,
> + .flags = 0,
> + .len = sizeof(data),
> + .buf = data,
> + };
> + int ret, retries = 5;
> +
> + do {
> + ret = __i2c_transfer(i2c->adapter, , 1);
> + if (ret < 0)
> + return ret;
> + } while (!ret && --retries);
> + return !ret ? -1 : 0;
union i2c_smbus_data data;
data.byte = val;
return __i2c_smbus_xfer(i2c->adapter, i2c->addr, i2c->flags,
I2C_SMBUS_WRITE, reg,
I2C_SMBUS_BYTE_DATA, );
> +}
> +
> +static int sii902x_update_bits_unlocked(struct i2c_client *i2c, u8 reg, u8
> mask,
> + u8 val)
> +{
> + int ret;
> + u8 status;
> +
> + ret = sii902x_read_unlocked(i2c, reg, );
> + if (ret)
> + return ret;
> + status &= ~mask;
> + status |= val & mask;
> + return sii902x_write_unlocked(i2c, reg, status);
> +}
> +
> static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> {
> return container_of(bridge, struct sii902x, bridge);
> @@ -135,41 +198,11 @@ static const struct drm_connector_funcs
> sii902x_connector_funcs = {
> static int sii902x_get_modes(struct drm_connector *connector)
> {
> struct sii902x *sii902x = connector_to_sii902x(connector);
> - struct regmap *regmap = sii902x->regmap;
> u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> - struct device *dev = >i2c->dev;
> - unsigned long timeout;
> - unsigned int
[PATCH 07/10] drm/sun4i: sun6i_mipi_dsi: Enable burst mode HBP, HSA_HSE
Horizontal back porch, sync active and sync end bits are
needed to enable for burst mode panel operations.
So, enable them via dsi base control register.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 2d34e5f48d29..feb8c54c5146 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -518,6 +518,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
u16 hbp, hfp_pkt_overhead, hfp, hsa, hblk, vblk;
size_t bytes;
u8 *buffer;
+ u32 val = 0;
/* Do all timing calculations up front to allocate buffer space */
@@ -527,6 +528,10 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
hblk = mode->hdisplay * Bpp;
hfp = 0;
vblk = 0;
+
+ regmap_read(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, );
+ val |= SUN6I_DSI_BASIC_CTL_HBP_DIS;
+ val |= SUN6I_DSI_BASIC_CTL_HSA_HSE_DIS;
} else {
/*
* A sync period is composed of a blanking packet (4 bytes +
@@ -594,7 +599,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
if (WARN_ON(!buffer))
return;
- regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, 0);
+ regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, val);
regmap_write(dsi->regs, SUN6I_DSI_SYNC_HSS_REG,
sun6i_dsi_build_sync_pkt(MIPI_DSI_H_SYNC_START,
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/10] drm/sun4i: Allwinner MIPI-DSI Burst mode support
This series support MIPI-DSI Burst mode on Allwinner platform, which is tested in burst supported panel in Pine64-LTS board. Series depends on previous A64 MIPI-DSI series[1] and all changes are available in [2] repo with WIPI-A64-DSI branch. Any inputs, Jagan. [2] https://github.com/amarula/linux-amarula [1] https://patchwork.kernel.org/cover/10657467/ Jagan Teki (10): drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection drm/sun4i: sun6i_mipi_dsi: Setup burst mode timings drm/sun4i: sun6i_mipi_dsi: Setup burst mode drm/sun4i: sun6i_mipi_dsi: Enable burst mode drm/sun4i: sun6i_mipi_dsi: Enable 2byte trail for 4-lane burst mode drm/sun4i: sun6i_mipi_dsi: Enable burst mode HBP, HSA_HSE dt-bindings: panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel [DO NOT MERGE] arm64: allwinner: a64: pine64-lts: Enable Feiyang FY07024DI26A30-D DSI panel .../display/panel/feiyang,fy07024di26a30d.txt | 20 ++ .../dts/allwinner/sun50i-a64-pine64-lts.dts | 37 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../drm/panel/panel-feiyang-fy07024di26a30d.c | 305 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 186 +++ 6 files changed, 500 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/sii902x: Fix EDID readback
On 2018-11-02 17:16, Fabrizio Castro wrote: >>> Here (and also in sii902x_i2c_bypass_deselect) you do a rmw access to the >>> SII902X_SYS_CTRL_DATA register without coordinating with regmap. Regmap is >>> also doing rmw accesses to that register in other parts of the driver. I >>> think you need to either add comment as to why that is safe (maybe other >>> things make it impossible for the two rmw accesses to cross?), or add the >>> missing coordination. >>> >> >> The other two places where SII902X_SYS_CTRL_DATA is being handled are >> sii902x_bridge_disable and sii902x_bridge_enable, I didn’t think there is >> any chance of the modes being probed while the bridge gets enabled/disabled, >> but now that you make me think about it user space may trigger the readback >> of the EDID at the most inconvenient times. Anyway, this is a good point, and >> since I don't think I am supposed to access regmap's lock from outside the >> APIs, >> I could switch to the unlocked version of update_bits from within >> sii902x_bridge_disable >> and sii902x_bridge_enable, and manually grab the i2c adapter lock, what do >> you think? >> > > The bridge enable/disable callbacks deal with different bits of register > SII902X_SYS_CTRL_DATA, and the value of register SII902X_SYS_CTRL_DATA after > sii902x_i2c_bypass_deselect is the same as when sii902x_i2c_bypass_select > gets triggered > so basically even if we managed to get in the way of the regmap rmw (in the > sense that > for example sii902x_bridge_enable reads SII902X_SYS_CTRL_DATA and then we call > into sii902x_i2c_bypass_select) by the time regmap_update_bits can perform the > write operation the value of register SII902X_SYS_CTRL_DATA is the same as > the one > read by regmap, as "select xfer deselect" won't alter the final value of > SII902X_SYS_CTRL_DATA > and nobody can get in between. > What do you think I should do? Do you think I can leave this alone and maybe > add some > comments or do you think I should explicitly protect access to > SII902X_SYS_CTRL_DATA? If the things you write about the bits are true (haven't looked closely), I wouldn't add any regmap coordination. But if I was the maintainer, I'd like a comment about this so that the next contributor has a better chance to understand the subtlety. But I'm not the maintainer, so this is not my call, but by adding the comment you also clarify the situation for the maintainer, which is something that is likely to be appreciated. Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/10] drm/sun4i: sun6i_mipi_dsi: Setup burst mode timings
Burst mode display timings are different from convectional
video mode so update the horizontal and vertical timings.
Reference code taken from BSP
(in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hsa = 0;
dsi_hbp = 0;
dsi_hact = x*dsi_pixel_bits[format]/8;
dsi_hblk = dsi_hact;
dsi_hfp = 0;
dsi_vblk = 0;
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 108 ++---
1 file changed, 60 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 077b57ec964c..4965b2c71e4c 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -479,59 +479,71 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
/* Do all timing calculations up front to allocate buffer space */
- /*
-* A sync period is composed of a blanking packet (4 bytes +
-* payload + 2 bytes) and a sync event packet (4 bytes). Its
-* minimal size is therefore 10 bytes
-*/
+ if (device->mode_flags == MIPI_DSI_MODE_VIDEO_BURST) {
+ hsa = 0;
+ hbp = 0;
+ hblk = mode->hdisplay * Bpp;
+ hfp = 0;
+ vblk = 0;
+ } else {
+ /*
+* A sync period is composed of a blanking packet (4 bytes +
+* payload + 2 bytes) and a sync event packet (4 bytes). Its
+* minimal size is therefore 10 bytes
+*/
#define HSA_PACKET_OVERHEAD10
- hsa = max((unsigned int)HSA_PACKET_OVERHEAD,
- (mode->hsync_end - mode->hsync_start) * Bpp -
HSA_PACKET_OVERHEAD);
-
- /*
-* The backporch is set using a blanking packet (4 bytes +
-* payload + 2 bytes). Its minimal size is therefore 6 bytes
-*/
+ hsa = max((unsigned int)HSA_PACKET_OVERHEAD,
+ (mode->hsync_end - mode->hsync_start) * Bpp -
+ HSA_PACKET_OVERHEAD);
+
+ /*
+* The backporch is set using a blanking packet (4 bytes +
+* payload + 2 bytes). Its minimal size is therefore 6 bytes
+*/
#define HBP_PACKET_OVERHEAD6
- hbp = max((unsigned int)HBP_PACKET_OVERHEAD,
- (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD);
-
- /*
-* hblk seems to be the line + porches length.
-* The blank is set using a blanking packet (4 bytes + 4 bytes +
-* payload + 2 bytes). So minimal size is 10 bytes
-*/
+ hbp = max((unsigned int)HBP_PACKET_OVERHEAD,
+ (mode->htotal - mode->hsync_end) * Bpp -
+ HBP_PACKET_OVERHEAD);
+
+ /*
+* hblk seems to be the line + porches length.
+* The blank is set using a blanking packet (4 bytes + 4 bytes
+* + payload + 2 bytes). So minimal size is 10 bytes
+*/
#define HBLK_PACKET_OVERHEAD 10
- hblk_max = (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp;
- hblk_max -= HBLK_PACKET_OVERHEAD;
- hblk = max_t(unsigned int, HBLK_PACKET_OVERHEAD, hblk_max);
-
- /*
-* The frontporch is set using a blanking packet (4 bytes +
-* payload + 2 bytes). Its minimal size is therefore 6 bytes
-*
-* According to BSP code, extra 10 bytes(which is hblk packet overhead)
-* is adding for hfp packet overhead since hfp depends on hblk.
-*/
+ hblk_max = (mode->htotal -
+ (mode->hsync_end - mode->hsync_start)) * Bpp;
+ hblk_max -= HBLK_PACKET_OVERHEAD;
+ hblk = max_t(unsigned int, HBLK_PACKET_OVERHEAD, hblk_max);
+
+ /*
+* The frontporch is set using a blanking packet (4 bytes +
+* payload + 2 bytes). Its minimal size is therefore 6 bytes
+*
+* According to BSP code, extra 10 bytes(which is hblk packet
+* overhead) is adding for hfp packet overhead since hfp
+* depends on hblk.
+*/
#define HFP_PACKET_OVERHEAD6
- hfp_pkt_overhead = (HFP_PACKET_OVERHEAD + HBLK_PACKET_OVERHEAD);
- hfp = max((unsigned int)hfp_pkt_overhead,
- (mode->hsync_start - mode->hdisplay) * Bpp -
- hfp_pkt_overhead);
-
- /*
-* The vertical blank is set using a blanking packet (4 bytes +
-* payload + 2 bytes). Its minimal size is therefore 6 bytes
-*/
+ hfp_pkt_overhead = (HFP_PACKET_OVERHEAD + HBLK_PACKET_OVERHEAD);
+ hfp = max((unsigned int)hfp_pkt_overhead,
+ (mode->hsync_start - mode->hdisplay) * Bpp -
+ hfp_pkt_overhead);
+
+ /*
+* The vertical blank
[PATCH 01/10] drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay
Loop N1 instruction delay for burst mode lcd panel are
computed as per BSP code.
Reference code is available in BSP
(in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_dev[sel]->dsi_inst_loop_num.bits.loop_n1=
(panel->lcd_ht-panel->lcd_x)*(150)/(panel->lcd_dclk_freq*8) - 50;
=> (((mode->htotal - mode->hdisplay) * 150) / ((mode->clock / 1000) * 8)) - 50;
So use the similar computation for loop N1 delay.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 86430efd9054..da152c21ec62 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -394,7 +394,14 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
- u16 delay = 50 - 1;
+ struct mipi_dsi_device *device = dsi->device;
+ u16 delay;
+
+ if (device->mode_flags == MIPI_DSI_MODE_VIDEO_BURST)
+ delay = (((mode->htotal - mode->hdisplay) * 150) /
+ ((mode->clock / 1000) * 8)) - 50;
+ else
+ delay = 50 - 1;
regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_NUM_REG(0),
SUN6I_DSI_INST_LOOP_NUM_N0(50 - 1) |
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108641] Interlaced dark lines in XCOM2 (UE3.5) on Aruba and Turks
https://bugs.freedesktop.org/show_bug.cgi?id=108641 Bug ID: 108641 Summary: Interlaced dark lines in XCOM2 (UE3.5) on Aruba and Turks Product: Mesa Version: 18.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: steelwin...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 142355 --> https://bugs.freedesktop.org/attachment.cgi?id=142355=edit in-game screenshot Game engine rendering outputs are interlaced with dark lines on r600. Tested on: 7660G (Aruba) and 7670M (Turks) with Mesa 18.2.4. Renderdoc captures have been uploaded here: https://www32.zippyshare.com/v/G74cEAp5/file.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108464] System fails to reboot after Ctrl-Alt-Del
https://bugs.freedesktop.org/show_bug.cgi?id=108464 --- Comment #12 from Duncan Roe --- Created attachment 142354 --> https://bugs.freedesktop.org/attachment.cgi?id=142354=edit Patch for Linux-19.0 to revert e1cb3e4 Revert commit e1cb3e4801e6896ba93d63222b1052199d2a8c9b (drm/amd/display: Convert remaining loggers off dc_logger). Reboot works again and the BUG / Oops is gone. -- 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 108139] My HDMI stopped working at Linux 4.18.8
https://bugs.freedesktop.org/show_bug.cgi?id=108139 --- Comment #4 from Duncan Roe --- commit 691f2d763d0731224439686ecf2d440df8fe910e is on branch linux-4.18.y of git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git. It was merged into branch master as part of commit 54dbe75bbf1e189982516de179147208e90b5e45 -- 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 201605] amdgpu: RX 570 reboots the PC when stressed
https://bugzilla.kernel.org/show_bug.cgi?id=201605 --- Comment #1 from fin4...@hotmail.com --- I managed to reboot with MSI Kombustor in windows 10. GPU temperatures are around 72C and reboot happens in two minutes. Is the GPU card faulty or my PSU too weak? -- 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: [v2 2/2] drm/i915: Attach colorspace property and enable modeset
Regards Shashank On 10/31/2018 5:35 PM, Uma Shankar wrote: This patch attaches the colorspace connector property to the hdmi connector. Based on colorspace change, modeset will be triggered to switch to new colorspace. Based on colorspace property value create an infoframe with appropriate colorspace. This can be used to send an infoframe packet with proper colorspace value set which will help to enable wider color gamut like BT2020 on sink. v2: Merged the changes of creating infoframe as well to this patch as per Maarten's suggestion. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 5 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index a5a2c8f..35ef70a 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, */ if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || + new_state->colorspace != old_state->colorspace || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || new_conn_state->base.content_type != old_conn_state->base.content_type || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 129b880..8a41fb3 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -486,6 +486,8 @@ static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder, else frame.avi.colorspace = HDMI_COLORSPACE_RGB; + frame.avi.extended_colorimetry = conn_state->colorspace; + We must also set the date byte 2 bits C1-C0 (colorimetry part) to indicate the use of extended colorimetry bits, so that monitor will refer to extended colorimetry data, else it wont even bother looking at it: Extended Colorimetry Information Valid (colorimetry indicated in bits EC0, EC1, and EC2) Its right now set to dafault 0-0 I guess, indicating No data We should also set it to a default value now, when we have started bothering about gamut. Regards Shashank drm_hdmi_avi_infoframe_quant_range(, adjusted_mode, crtc_state->limited_color_range ? HDMI_QUANTIZATION_RANGE_LIMITED : @@ -2125,6 +2127,9 @@ static void intel_hdmi_destroy(struct drm_connector *connector) intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); drm_connector_attach_content_type_property(connector); + drm_object_attach_property(>base, + connector->dev->mode_config.colorspace_property, + COLORIMETRY_ITU_709); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
