[Bug 108994] Cannot install version 18.40 due to dependency issues
https://bugs.freedesktop.org/show_bug.cgi?id=108994 Bug ID: 108994 Summary: Cannot install version 18.40 due to dependency issues Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: ma...@users.sourceforge.net I'm using the amgpu-pro drivers in Ubuntu 16.04, version 17.50. I tried upgrading to the 18.40, but I get the following errors: Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: amdgpu : Depends: libllvm6.0-amdgpu (= 1:6.0-697810) but it is not going to be installed Depends: libxatracker2-amdgpu (= 1:18.1.0-697810) but it is not going to be installed Depends: libegl1-amdgpu-mesa (= 1:18.1.0-697810) but 1:17.2.4-511655 is to be installed Depends: libegl1-amdgpu-mesa-drivers (= 1:18.1.0-697810) but it is not going to be installed Depends: libwayland-amdgpu-egl1-mesa (= 1:18.1.0-697810) but 1:17.2.4-511655 is to be installed Depends: libgl1-amdgpu-mesa-glx (= 1:18.1.0-697810) but it is not going to be installed Depends: libgl1-amdgpu-mesa-dri (= 1:18.1.0-697810) but 1:17.2.4-511655 is to be installed Depends: libosmesa6-amdgpu (= 1:18.1.0-697810) but it is not going to be installed Depends: mesa-amdgpu-va-drivers (= 1:18.1.0-697810) but it is not going to be installed Depends: mesa-amdgpu-vdpau-drivers (= 1:18.1.0-697810) but 1:17.2.4-511655 is to be installed Depends: mesa-amdgpu-omx-drivers (= 1:18.1.0-697810) but 1:17.2.4-511655 is to be installed amdgpu-lib32 : Depends: libllvm6.0-amdgpu:i386 (= 1:6.0-697810) Depends: libxatracker2-amdgpu:i386 (= 1:18.1.0-697810) Depends: libegl1-amdgpu-mesa:i386 (= 1:18.1.0-697810) Depends: libegl1-amdgpu-mesa-drivers:i386 (= 1:18.1.0-697810) Depends: libwayland-amdgpu-egl1-mesa:i386 (= 1:18.1.0-697810) Depends: libgl1-amdgpu-mesa-glx:i386 (= 1:18.1.0-697810) Depends: libgl1-amdgpu-mesa-dri:i386 (= 1:18.1.0-697810) Depends: libosmesa6-amdgpu:i386 (= 1:18.1.0-697810) Depends: mesa-amdgpu-va-drivers:i386 (= 1:18.1.0-697810) Depends: mesa-amdgpu-vdpau-drivers:i386 (= 1:18.1.0-697810) E: Unable to correct problems, you have held broken packages. -- 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 201727] Hardware Error reported on Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=201727 Michal Herko (misko.he...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #11 from Michal Herko (misko.he...@gmail.com) --- The bug is no more present on v4.20-rc5. -- 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 v1.1 3/5] drm: rcar-du: Disable unused DPAD outputs
DU channels are routed to DPAD outputs in an SoC-dependent way. The
routing can be fixed (e.g. DU3 to DPAD0 on H3) or configurable (e.g. DU0
or DU1 to DPAD0 on D3/E3). The hardware offers no option to disconnect
DPAD outputs, which are thus always driven by a DU channel.
On SoCs that have less DU channels than DU outputs, such as D3 and E3,
the DPAD output is always driven when all channels are in use by other
outputs (such as the internal LVDS and HDMI encoders). This creates an
unwanted clone on the DPAD output.
However, the parallel output of the DU channels routed to DPAD can be
set to fixed levels in the DU channels themselves through the DOFLR
group register. Use this to turn the DPAD on or off by driving fixed
signals at the output of any DU channel not routed to a DPAD output.
This doesn't affect the DU output signals going to other outputs.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v1:
- Renamed rcar_du_group_set_output_levels() to
rcar_du_group_set_dpad_levels()
- Clarify that fixed DPAD outputs are low-level
---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 43 +
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 7e440f61977f..9eee47969e77 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -287,6 +287,47 @@ int rcar_du_set_dpad0_vsp1_routing(struct rcar_du_device
*rcdu)
return 0;
}
+static void rcar_du_group_set_dpad_levels(struct rcar_du_group *rgrp)
+{
+ static const u32 doflr_values[2] = {
+ DOFLR_HSYCFL0 | DOFLR_VSYCFL0 | DOFLR_ODDFL0 |
+ DOFLR_DISPFL0 | DOFLR_CDEFL0 | DOFLR_RGBFL0,
+ DOFLR_HSYCFL1 | DOFLR_VSYCFL1 | DOFLR_ODDFL1 |
+ DOFLR_DISPFL1 | DOFLR_CDEFL1 | DOFLR_RGBFL1,
+ };
+ static const u32 dpad_mask = BIT(RCAR_DU_OUTPUT_DPAD1)
+ | BIT(RCAR_DU_OUTPUT_DPAD0);
+ struct rcar_du_device *rcdu = rgrp->dev;
+ u32 doflr = DOFLR_CODE;
+ unsigned int i;
+
+ if (rcdu->info->gen < 2)
+ return;
+
+ /*
+* The DPAD outputs can't be controlled directly. However, the parallel
+* output of the DU channels routed to DPAD can be set to fixed levels
+* through the DOFLR group register. Use this to turn the DPAD on or off
+* by driving fixed low-level signals at the output of any DU channel
+* not routed to a DPAD output. This doesn't affect the DU output
+* signals going to other outputs, such as the internal LVDS and HDMI
+* encoders.
+*/
+
+ for (i = 0; i < rgrp->num_crtcs; ++i) {
+ struct rcar_du_crtc_state *rstate;
+ struct rcar_du_crtc *rcrtc;
+
+ rcrtc = >crtcs[rgrp->index * 2 + i];
+ rstate = to_rcar_crtc_state(rcrtc->crtc.state);
+
+ if (!(rstate->outputs & dpad_mask))
+ doflr |= doflr_values[i];
+ }
+
+ rcar_du_group_write(rgrp, DOFLR, doflr);
+}
+
int rcar_du_group_set_routing(struct rcar_du_group *rgrp)
{
struct rcar_du_device *rcdu = rgrp->dev;
@@ -306,5 +347,7 @@ int rcar_du_group_set_routing(struct rcar_du_group *rgrp)
rcar_du_group_write(rgrp, DORCR, dorcr);
+ rcar_du_group_set_dpad_levels(rgrp);
+
return rcar_du_set_dpad0_vsp1_routing(rgrp->dev);
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108990] [CI][DRMTIP] igt@pm_rpm@basic-rte - incomplete
https://bugs.freedesktop.org/show_bug.cgi?id=108990 Bug ID: 108990 Summary: [CI][DRMTIP] igt@pm_rpm@basic-rte - incomplete Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: lakshminarayana.vu...@intel.com https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5287/fi-icl-u3/igt@pm_...@basic-rte.html No errors or failures are noticed in dmesg. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5287/fi-icl-u3/run0.log Subtest basic-pci-d3-state: SUCCESS (0.663s) [232/301] (591s left) pm_rpm (basic-rte) FATAL: command execution failed java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2681) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3156) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:862) at java.io.ObjectInputStream.(ObjectInputStream.java:358) at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:49) at hudson.remoting.Command.readFrom(Command.java:140) at hudson.remoting.Command.readFrom(Command.java:126) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:36) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:63) Caused: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:77) Caused: java.io.IOException: Backing channel 'fi-icl-u3' is disconnected. at hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.java:214) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:283) at com.sun.proxy.$Proxy64.isAlive(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:1144) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:1136) at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:155) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:109) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) at hudson.model.Run.execute(Run.java:1810) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) FATAL: Unable to delete script file /tmp/jenkins8370736686212609305.sh java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2681) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3156) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:862) at java.io.ObjectInputStream.(ObjectInputStream.java:358) at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:49) at hudson.remoting.Command.readFrom(Command.java:140) at hudson.remoting.Command.readFrom(Command.java:126) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:36) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:63) Caused: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:77) Caused: hudson.remoting.ChannelClosedException: Channel "unknown": Remote call on fi-icl-u3 failed. The channel is closing down or has closed down at hudson.remoting.Channel.call(Channel.java:948) at hudson.FilePath.act(FilePath.java:1070) at hudson.FilePath.act(FilePath.java:1059) at hudson.FilePath.delete(FilePath.java:1563) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:123) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at
Re: [PATCH 2/5] drm: rcar-du: Move CRTC outputs bitmask to private CRTC state
Hi Kieran,
On Friday, 7 December 2018 14:34:58 EET Kieran Bingham wrote:
> On 25/11/2018 14:40, Laurent Pinchart wrote:
> > The rcar_du_crtc outputs field stores a bitmask of the outputs driven by
> > the CRTC. This changes based on the configuration requested by
> > userspace, and is used for the sole purpose of configuring the hardware.
> > The field thus belongs to the CRTC state. Move it to the
> > rcar_du_crtc_state structure.
> >
> > As a result the rcar_du_crtc_route_output() function loses most of its
> > purpose. In order to remove it, move dpad0_source calculation to
> > rcar_du_atomic_commit_tail(), until the field gets moved to a state
> > structure. In order to simplify the rcar_du_group_set_routing()
> > implementation, we also store the DPAD1 source in a new dpad1_source
> > field which will move to a state structure with dpad0_source.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> that was a fairly tough read - but aside from one comment near the
> bottom regarding initialising dpad0 which I'm sure you can handle
> correctly, and another comment which I think we could improve things
> outside of this patch:
>
> Reviewed-by: Kieran Bingham
>
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 42 +++
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 7 ++--
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +
> > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 10 --
> > drivers/gpu/drm/rcar-du/rcar_du_group.c | 4 +--
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22
> > 6 files changed, 47 insertions(+), 39 deletions(-)
>
> +8 ... It's a good job you bought -13 lines in the previous patch ;)
>
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 90dacab67be5..40b7f17159b0
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -22,6 +22,7 @@
> >
> > #include "rcar_du_crtc.h"
> > #include "rcar_du_drv.h"
> > +#include "rcar_du_encoder.h"
> > #include "rcar_du_kms.h"
> > #include "rcar_du_plane.h"
> > #include "rcar_du_regs.h"
> > @@ -316,26 +317,6 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> > rcar_du_crtc_write(rcrtc, DEWR, mode->hdisplay);
> > }
> >
> > -void rcar_du_crtc_route_output(struct drm_crtc *crtc,
> > - enum rcar_du_output output)
> > -{
> > - struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > - struct rcar_du_device *rcdu = rcrtc->group->dev;
> > -
> > - /*
> > -* Store the route from the CRTC output to the DU output. The DU will
be
> > -* configured when starting the CRTC.
> > -*/
> > - rcrtc->outputs |= BIT(output);
> > -
> > - /*
> > -* Store RGB routing to DPAD0, the hardware will be configured when
> > -* starting the CRTC.
> > -*/
> > - if (output == RCAR_DU_OUTPUT_DPAD0)
> > - rcdu->dpad0_source = rcrtc->index;
> > -}
> > -
> > static unsigned int plane_zpos(struct rcar_du_plane *plane)
> > {
> > return plane->plane.state->normalized_zpos;
> > @@ -655,6 +636,24 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc
> > *rcrtc)
> > * CRTC Functions
> > */
> >
> > +static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
> > +struct drm_crtc_state *state)
> > +{
> > + struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
> > + struct drm_encoder *encoder;
> > +
> > + /* Store the routes from the CRTC output to the DU outputs. */
> > + rstate->outputs = 0;
> > +
> > + drm_for_each_encoder_mask(encoder, crtc->dev, state->encoder_mask) {
> > + struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
> > +
> > + rstate->outputs |= BIT(renc->output);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static void rcar_du_crtc_atomic_enable(struct drm_crtc *crtc,
> >struct drm_crtc_state *old_state)
> > {
> > @@ -678,8 +677,6 @@ static void rcar_du_crtc_atomic_disable(struct
> > drm_crtc *crtc,
> > crtc->state->event = NULL;
> > }
> > spin_unlock_irq(>dev->event_lock);
> > -
> > - rcrtc->outputs = 0;
> > }
> >
> > static void rcar_du_crtc_atomic_begin(struct drm_crtc *crtc,
> > @@ -755,6 +752,7 @@ enum drm_mode_status rcar_du_crtc_mode_valid(struct
> > drm_crtc *crtc,
> > }
> >
> > static const struct drm_crtc_helper_funcs crtc_helper_funcs = {
> > + .atomic_check = rcar_du_crtc_atomic_check,
> > .atomic_begin = rcar_du_crtc_atomic_begin,
> > .atomic_flush = rcar_du_crtc_atomic_flush,
> > .atomic_enable = rcar_du_crtc_atomic_enable,
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index 59ac6e7d22c9..ec47f164e69b
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > @@ -37,7 +37,6 @@ struct rcar_du_vsp;
> > *
Re: [PATCH v2 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Hi,
On 07-12-18 15:18, Andy Shevchenko 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.
+ /* byte 0 aka PMIC Flag is reserved */
+ i2c_client_address = get_unaligned_le16(data + 1);
+ reg_address = get_unaligned_le32(data + 3);
+ value = get_unaligned_le32(data + 7);
+ mask= get_unaligned_le32(data + 11);
+
+ if (i2c_client_address > 255 || reg_address > 255) {
Hmm... I would rather like to see hexadecimal for addresses and decimal for
something like countable value for data.
Ok, fixed for v3.
Regards,
Hans
+ pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+ __func__, i2c_client_address, reg_address);
+ return;
+ }
+
+ address = (i2c_client_address << 8) | reg_address;
+ regmap_update_bits(regmap, address, mask, value);
+}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108997] RX460: Some Resolution-Refresh Combinations Unavailable when Connected via DisplayPort
https://bugs.freedesktop.org/show_bug.cgi?id=108997 --- Comment #2 from Mingcong Bai --- Created attachment 142766 --> https://bugs.freedesktop.org/attachment.cgi?id=142766=edit EDID Dump (from Xorg.0.log) -- 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 108997] RX460: Some Resolution-Refresh Combinations Unavailable when Connected via DisplayPort
https://bugs.freedesktop.org/show_bug.cgi?id=108997 --- Comment #3 from Mingcong Bai --- The EDID data (obtained from Xorg.0.log output and attached above) also suggests that such mode is possible (unless I misunderstood something). mingcongbai@NetVista [ / ] $ cat edid.bin | edid-decode EDID version: 1.2 Manufacturer: SAM Model 4db9 Serial Number 1346842937 Analog display, Input voltage level: 0.7/0.3 V Sync: Separate Composite SyncOnGreen Serration Maximum image size: 36 cm x 27 cm Gamma: 2.28 DPMS levels: Standby Suspend Off RGB color display First detailed timing is preferred timing Supports GTF timings within operating range Display x,y Chromaticity: Red: 0.6376, 0.3251 Green: 0.2763, 0.5957 Blue: 0.1425, 0.0664 White: 0.2832, 0.2978 Established timings supported: 720x400@70Hz 9:5 HorFreq: 31469 Hz Clock: 28.320 MHz 720x400@88Hz 9:5 HorFreq: 39500 Hz Clock: 35.500 MHz 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz 640x480@67Hz 4:3 HorFreq: 35000 Hz Clock: 30.240 MHz 640x480@72Hz 4:3 HorFreq: 37900 Hz Clock: 31.500 MHz 640x480@75Hz 4:3 HorFreq: 37500 Hz Clock: 31.500 MHz 800x600@56Hz 4:3 HorFreq: 35200 Hz Clock: 36.000 MHz 800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz 800x600@72Hz 4:3 HorFreq: 48100 Hz Clock: 50.000 MHz 800x600@75Hz 4:3 HorFreq: 46900 Hz Clock: 49.500 MHz 832x624@75Hz 4:3 HorFreq: 49726 Hz Clock: 57.284 MHz 1280x768i@87Hz 5:3 HorFreq: 35522 Hz Clock: 44.900 MHz 1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz 1024x768@70Hz 4:3 HorFreq: 56500 Hz Clock: 75.000 MHz 1024x768@75Hz 4:3 HorFreq: 6 Hz Clock: 78.750 MHz 1280x1024@75Hz 5:4 HorFreq: 8 Hz Clock: 135.000 MHz 1152x870@75Hz 192:145 HorFreq: 67500 Hz Clock: 108.000 MHz Standard timings supported: 640x480@85Hz 4:3 HorFreq: 43300 Hz Clock: 36.000 MHz 800x600@85Hz 4:3 HorFreq: 53700 Hz Clock: 56.250 MHz 1024x768@85Hz 4:3 HorFreq: 68700 Hz Clock: 94.500 MHz 1280x1024@85Hz 5:4 HorFreq: 91100 Hz Clock: 157.500 MHz 1600x1200@75Hz 4:3 HorFreq: 93800 Hz Clock: 202.500 MHz 1024x768@100Hz 4:3 Detailed mode: Clock 157.500 MHz, 352 mm x 264 mm 1280 1344 1504 1728 hborder 0 1024 1025 1028 1072 vborder 0 +hsync +vsync VertFreq: 85 Hz, HorFreq: 91145 Hz Monitor ranges (GTF): 50-160Hz V, 30-96kHz H, max dotclock 210MHz Monitor name: S/M 900SL Serial number: H3NN105750 Checksum: 0xe0 (valid) -- 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 101978] [bisected] war thunder performance reduced by ~28%
https://bugs.freedesktop.org/show_bug.cgi?id=101978 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #13 from Timothy Arceri --- (In reply to Konstantin A. Lepikhov from comment #12) > Just tested w/ 4.19.8 + Mesa 18.3.0 on R9 Fury and latest WT client - > everything became even worse, missing textures, white screen, so the game > now is totally unplayable. But I know they have problems with nvidia as > well, and their vulkan never worked on my box (black screen on focus). > > So no progress so far. These are all different issues from the original bug report and are probably game bugs if Nvidia is also having issues. As per comment 11 I'm closing this bug (using INVALID for lack of a better option). Any new issues should have new bug reports opened for them. -- 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 108997] RX460: Some Resolution-Refresh Combinations Unavailable when Connected via DisplayPort
https://bugs.freedesktop.org/show_bug.cgi?id=108997 Bug ID: 108997 Summary: RX460: Some Resolution-Refresh Combinations Unavailable when Connected via DisplayPort Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jeff...@aosc.io - Xorg Server version: 1.20.3 - XRandR version: 1.5.0 - Xf86-Video-AMDGPU version: 18.0.1 - Kernel parameters: root=UUID=dfd3d587-145e-4c01-af04-a3e24c59e95c rw quiet rw rd.auto rd.auto=1 splash vfio-pci.ids=10de:1c03,1022:145f,1022:1457 modprobe.blacklist=nouveau iommu=pt amd_iommu=on kvm-amd.avic=1 kvm-amd.nested=1 clocksource=tsc kvm.ignore_msrs=1 pcie_acs_override=multifunction rd.driver.pre=vfio-pci video=efifb:off Xorg.conf: Section "Device" Identifier "Device 0" Driver "amdgpu" VendorName "Advanced Micro Devices, Inc." BusID "PCI:34:0:0" Option "IgnoreEDID""true" Option "UseEDID" "false" EndSection Section "Monitor" Identifier "Monitor 0" VendorName "SAMSUNG" ModelName "900SL" Option "UseEDID" "false" Option "UseEDIDFreqs" "false" Option "DDC" "false" HorizSync 30.0 - 96.0 VertRefresh 50.0 - 100.0 Modeline"1600x1200_76.00" 207.50 1600 1720 1888 2176 1200 1203 1207 1256 -hsync +vsync Option "PreferredMode" "1600x1200_76.00" EndSection While connecting my XFX Radeon RX460 Slim to a Samsung 900SL CRT monitor via a DisplayPort to VGA converter cable, 1600x1200@76Hz is not available, despite the factory specs... 1600 x 1200 / 76 Hz 1600 x 1200 / 70 Hz 1600 x 1200 / 65 Hz 1280 x 1024 / 89 Hz 1024 x 768 / 119 Hz 800 x 600 / 152 Hz 640 x 480 / 160 Hz When attempting to create a new custom mode... mingcongbai@NetVista [ / ] $ cvt 1600 1200 76 # 1600x1200 75.92 Hz (CVT) hsync: 95.36 kHz; pclk: 207.50 MHz Modeline "1600x1200_76.00" 207.50 1600 1720 1888 2176 1200 1203 1207 1256 -hsync +vsync mingcongbai@NetVista [ / ] $ xrandr --newmode "1600x1200_76.00" 207.50 1600 1720 1888 2176 1200 1203 1207 1256 -hsync +vsync mingcongbai@NetVista [ / ] $ xrandr --addmode DisplayPort-0 "1600x1200_76.00" mingcongbai@NetVista [ / ] $ xrandr --output DisplayPort-0 --mode "1600x1200_76.00" xrandr: Configure crtc 0 failed I have an NVIDIA GeForce GTX1060 passed through to a Windows 10 VM, connected via a DisplayPort to VGA, and VGA to BNC 5-pin connector, in this case, 1600x1200 is available and displays a correct image. I have also tried to connect the RX460 with the DP-VGA-BNC cable, which yielded the same result. -- 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 2/2] drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags
Hi Tomi, On Wednesday, 5 December 2018 12:42:12 EET Tomi Valkeinen wrote: > On 05/12/18 10:49, Laurent Pinchart wrote: > > From: Laurent Pinchart > > > > The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and > > DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the > > new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and > > new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them > > through the code. > > > > This effectively changes the value of the .sampling_edge bridge timings > > field in the dumb-vga-dac driver. This is safe to do as no driver > > consumes these values yet. > > When to use which? The idea is to use the flags that correspond to the side corresponding to the code. A bridge driver, in its input_bus_flags, would use the sample flags. A display controller driver would likely use the drive flags. If we later extend drm_bridge to handle polarities on the source side of the bridge, the drive flags should be used there. It also makes sense to follow the perspective described in datasheets and hardware registers. If an internal encoder is documented using the driving perspective for its input signals, usage of the drive flags is likely best. In a nutshell, use the flags that result in the simplest possible code. > Looking at the omap drivers, you use the DRIVE variant. But if the > encoder/panel is describing what it wants as input, shouldn't it use the > SAMPLE variant? I have to confess I haven't paid much attention to the omapdrm/displays/ drivers as we're in the process of removing them, but I think you're right there. For the SDI encoder, the datasheet documents polarities from a drive perspective, so I've kept that. For the DSI encoder there's no documented polarities, so I used the drive perspective there as well to remain consistent. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags
Hi Stefan, (Maxime, there's a question for you below) On Wednesday, 5 December 2018 14:21:56 EET Stefan Agner wrote: > On 05.12.2018 11:42, Tomi Valkeinen wrote: > > On 05/12/18 10:49, Laurent Pinchart wrote: > >> From: Laurent Pinchart > >> > >> The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and > >> DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the > >> new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and > >> new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them > >> through the code. > >> > >> This effectively changes the value of the .sampling_edge bridge timings > >> field in the dumb-vga-dac driver. This is safe to do as no driver > >> consumes these values yet. > > > > When to use which? > > I guess whatever works best, e.g. if a display controller uses the > sample perspective, to describe its register, I would use the matching > defines. > > > Looking at the omap drivers, you use the DRIVE variant. But if the > > encoder/panel is describing what it wants as input, shouldn't it use the > > SAMPLE variant? > > If it is fine to use either one in display controllers or displays, I > guess that is fine. I'd rather prefer a mechanical change right now, and > do logical fixes on a per case basis. However, in this patch the > dumb-vga-dac.c case already breaks that rule. Maybe it should be a > separate patch? If that's preferred I'll submit a v3 with this patch split in two. Maxime ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] omapdrm: drm_bridge and drm_panel support
Hello everybody, This patch series hooks up support for drm_bridge and drm_panel in the omapdrm driver. Before anyone rejoices too fast, I have to warn that removal of the omapdrm internal display drivers will still require a significant effort, even without considering DSI: - The omapdrm internal display drivers need to be ported to drm_bridge and drm_panel. This is the easy part of remaining transition, with 6 non-trivial panels, 2 simple bridges, and 2 connectors. - Several OMAP-based system split tasks associated with connectors across multiple hardware components. For instance an HDMI can have modes retrieval (from EDID) implemented by the HDMI encoder bridge, while hot-plug detection is implemented through a signal of the HDMI companion chip connected to a GPIO of the SoC. The drm_bridge infrastructure doesn't support this, and will need to be extended. - DRM doesn't have connector drivers to handle the connector DT nodes. While connectors are mostly passive components, the DDC and HPD signals can be wired directly from the connector to the SoC, in which case they're described in connector DT node. Several bridge drivers look up the DDC bus from the linked connector DT node, but this is a layering violation and should be implemented properly using connector drivers. These limitations aside, the series still removes three omapdrm-specific drivers. The series start with adding support for the OSD070T1718-19TS panel to the panel-simple driver (1/6). The panel is used by the AM57xx EVM. The corresponding DT node contains panel timings, and I still believe that we should parse those timings instead of hardcoding them in C code, but I've set that issue aside for now to move forward. The next two patches hook up support for drm_bridge (2/6) and drm_panel (3/6) in the omapdrm driver. This is the bulk of the changes from this series, please refer to individual patches for more information. The next patch (4/6) then adds a whitelist mechanism to control addition of the "omapdss," prefix to the compatible string of the omapdrm encoders, panels and connectors. This is used to selectively switch components from the omap_dss_device framework to drm_panel and drm_bridge. Finally the last two patches remove the omapdrm-specific TFP410 encoder and DVI connector drivers (5/6) and DPI panel driver (6/6), replaced respectively by the ti-tftp410 drm_bridge driver and the panel-simple drm_panel driver. The series is based on the "[PATCH 0/5] drm: ti-tfp410 improvements" series, itself based on top of the "[PATCH v2 0/2] Clarify display info PIXDATA bus flags" series. For convenience I have pushed the result to git://linuxtv.org/pinchartl/media.git omapdrm/bridge/next All patches have been tested on the OMAP3 Beagleboard-xM (for TFP410), the OMAP4 Pandaboard (for regressions) and the AM57xx EVM (for the panel). Laurent Pinchart (6): drm/panel: simple: Add OSD070T1718-19TS panel support drm/omap: Add support for drm_bridge drm/omap: Add support for drm_panel drm/omap: Whitelist DT nodes to fixup with omapdss, prefix drm/omap: Remove TFP410 and DVI connector drivers drm/omap: Remove panel-dpi driver drivers/gpu/drm/omapdrm/displays/Kconfig | 17 - drivers/gpu/drm/omapdrm/displays/Makefile | 3 - .../gpu/drm/omapdrm/displays/connector-dvi.c | 292 -- .../gpu/drm/omapdrm/displays/encoder-tfp410.c | 141 - drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 197 drivers/gpu/drm/omapdrm/dss/base.c| 49 ++- .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 18 +- drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 + drivers/gpu/drm/omapdrm/dss/output.c | 26 +- drivers/gpu/drm/omapdrm/omap_connector.c | 25 +- drivers/gpu/drm/omapdrm/omap_connector.h | 1 - drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +- drivers/gpu/drm/omapdrm/omap_drv.c| 82 +++-- drivers/gpu/drm/omapdrm/omap_encoder.c| 109 --- drivers/gpu/drm/panel/panel-simple.c | 29 ++ 15 files changed, 260 insertions(+), 733 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/displays/connector-dvi.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-dpi.c -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/omap: Whitelist DT nodes to fixup with omapdss, prefix
The omapdss driver patches DT at runtime to prepend an "omapdss," prefix
to the compatible string of all encoders, panels and connectors. This
mechanism ensures they get bound to the omapdss-specific drivers instead
of generic drivers.
Now that we have drm_bridge support in omapdrm, we need to selectively
disable this mechanism. Add a whitelist of compatible strings to patch,
and fill it with all the devices we support. They will be removed one by
one once corresponding drm_bridge drivers become available and get
successfully tested with omapdrm.
The omapdss components load check code is updated accordingly to ignore
devices managed by external bridge drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c| 20 +++---
.../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 21 ++-
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
b/drivers/gpu/drm/omapdrm/dss/base.c
index 51347a08b151..9ceba54a3292 100644
--- a/drivers/gpu/drm/omapdrm/dss/base.c
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -303,6 +303,7 @@ struct omapdss_comp_node {
struct list_head list;
struct device_node *node;
bool dss_core_component;
+ const char *compat;
};
static bool omapdss_list_contains(const struct device_node *node)
@@ -320,13 +321,20 @@ static bool omapdss_list_contains(const struct
device_node *node)
static void omapdss_walk_device(struct device *dev, struct device_node *node,
bool dss_core)
{
+ struct omapdss_comp_node *comp;
struct device_node *n;
- struct omapdss_comp_node *comp = devm_kzalloc(dev, sizeof(*comp),
- GFP_KERNEL);
+ const char *compat;
+ int ret;
+
+ ret = of_property_read_string(node, "compatible", );
+ if (ret < 0)
+ return;
+ comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
if (comp) {
comp->node = node;
comp->dss_core_component = dss_core;
+ comp->compat = compat;
list_add(>list, _comp_list);
}
@@ -366,12 +374,8 @@ void omapdss_gather_components(struct device *dev)
omapdss_walk_device(dev, dev->of_node, true);
- for_each_available_child_of_node(dev->of_node, child) {
- if (!of_find_property(child, "compatible", NULL))
- continue;
-
+ for_each_available_child_of_node(dev->of_node, child)
omapdss_walk_device(dev, child, true);
- }
}
EXPORT_SYMBOL(omapdss_gather_components);
@@ -379,6 +383,8 @@ static bool omapdss_component_is_loaded(struct
omapdss_comp_node *comp)
{
if (comp->dss_core_component)
return true;
+ if (!strstarts(comp->compat, "omapdss,"))
+ return true;
if (omapdss_device_is_registered(comp->node))
return true;
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
index 3bfb95d230e0..309b7b453e98 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
@@ -184,6 +184,25 @@ static const struct of_device_id omapdss_of_match[]
__initconst = {
{},
};
+static const struct of_device_id omapdss_of_fixups_whitelist[] __initconst = {
+ { .compatible = "composite-video-connector" },
+ { .compatible = "dvi-connector" },
+ { .compatible = "hdmi-connector" },
+ { .compatible = "lgphilips,lb035q02" },
+ { .compatible = "nec,nl8048hl11" },
+ { .compatible = "panel-dpi" },
+ { .compatible = "panel-dsi-cm" },
+ { .compatible = "sharp,ls037v7dw01" },
+ { .compatible = "sony,acx565akm" },
+ { .compatible = "svideo-connector" },
+ { .compatible = "ti,opa362" },
+ { .compatible = "ti,tfp410" },
+ { .compatible = "ti,tpd12s015" },
+ { .compatible = "toppoly,td028ttec1" },
+ { .compatible = "tpo,td028ttec1" },
+ { .compatible = "tpo,td043mtea1" },
+};
+
static int __init omapdss_boot_init(void)
{
struct device_node *dss, *child;
@@ -210,7 +229,7 @@ static int __init omapdss_boot_init(void)
n = list_first_entry(_conv_list, struct dss_conv_node,
list);
- if (!n->root)
+ if (of_match_node(omapdss_of_fixups_whitelist, n->node))
omapdss_omapify_node(n->node);
list_del(>list);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/omap: Add support for drm_bridge
Hook up drm_bridge support in the omapdrm driver. Despite the recent
extensive preparation work, this is a rather intrusive change, as the
management of outputs needs to be adapted through the driver to handle
both omap_dss_device and drm_bridge.
Connector creation is skipped when using a drm_bridge, as the bridge
creates the connector internally. This creates issues with systems that
split connector operations (such as modes retrieval and hot-plug
detection) across different bridges. These systems can't be supported
using drm_bridge for now (their support through the omap_dss_device
infrastructure is not affected), this will be fixed in subsequent
changes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 27 -
drivers/gpu/drm/omapdrm/dss/omapdss.h| 1 +
drivers/gpu/drm/omapdrm/dss/output.c | 21 +--
drivers/gpu/drm/omapdrm/omap_connector.c | 16 +++--
drivers/gpu/drm/omapdrm/omap_connector.h | 1 -
drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.c | 69 +++--
drivers/gpu/drm/omapdrm/omap_encoder.c | 77 ++--
8 files changed, 148 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
b/drivers/gpu/drm/omapdrm/dss/base.c
index d14abde3c5f0..fd624a2e9e63 100644
--- a/drivers/gpu/drm/omapdrm/dss/base.c
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "dss.h"
#include "omapdss.h"
@@ -156,7 +157,7 @@ struct omap_dss_device *omapdss_device_next_output(struct
omap_dss_device *from)
goto done;
}
- if (dssdev->id && dssdev->next)
+ if (dssdev->id && (dssdev->next || dssdev->bridge))
goto done;
}
@@ -184,7 +185,18 @@ int omapdss_device_connect(struct dss_device *dss,
{
int ret;
- dev_dbg(dst->dev, "connect\n");
+ dev_dbg(>pdev->dev, "connect(%s, %s)\n",
+ src ? dev_name(src->dev) : "NULL",
+ dst ? dev_name(dst->dev) : "NULL");
+
+ if (!dst) {
+ /*
+* The destination is NULL when the source is connected to a
+* bridge instead of a DSS device. Stop here, we will attach the
+* bridge later when we will have a DRM encoder.
+*/
+ return src && src->bridge ? 0 : -EINVAL;
+ }
if (omapdss_device_is_connected(dst))
return -EBUSY;
@@ -204,7 +216,16 @@ EXPORT_SYMBOL_GPL(omapdss_device_connect);
void omapdss_device_disconnect(struct omap_dss_device *src,
struct omap_dss_device *dst)
{
- dev_dbg(dst->dev, "disconnect\n");
+ struct dss_device *dss = src ? src->dss : dst->dss;
+
+ dev_dbg(>pdev->dev, "disconnect(%s, %s)\n",
+ src ? dev_name(src->dev) : "NULL",
+ dst ? dev_name(dst->dev) : "NULL");
+
+ if (!dst) {
+ WARN_ON(!src->bridge);
+ return;
+ }
if (!dst->id && !omapdss_device_is_connected(dst)) {
WARN_ON(dst->output_type);
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 33648445f50b..e1657f2a2e51 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -410,6 +410,7 @@ struct omap_dss_device {
struct dss_device *dss;
struct omap_dss_device *next;
+ struct drm_bridge *bridge;
struct list_head list;
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
b/drivers/gpu/drm/omapdrm/dss/output.c
index 0ac400a521f3..c8230a3fabca 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -20,25 +20,34 @@
#include
#include
#include
+#include
#include "dss.h"
#include "omapdss.h"
int omapdss_device_init_output(struct omap_dss_device *out)
{
- out->next = omapdss_of_find_connected_device(out->dev->of_node, 0);
- if (IS_ERR(out->next)) {
- if (PTR_ERR(out->next) != -EPROBE_DEFER)
- dev_err(out->dev, "failed to find video sink\n");
- return PTR_ERR(out->next);
+ struct device_node *remote_node;
+
+ remote_node = of_graph_get_remote_node(out->dev->of_node, 0, 0);
+ if (!remote_node) {
+ dev_dbg(out->dev, "failed to find video sink\n");
+ return 0;
}
+ out->next = omapdss_find_device_by_node(remote_node);
+ out->bridge = of_drm_find_bridge(remote_node);
+
+ of_node_put(remote_node);
+
if (out->next && out->output_type != out->next->type) {
dev_err(out->dev, "output type and display type don't match\n");
+ omapdss_device_put(out->next);
+ out->next = NULL;
return -EINVAL;
}
- return 0;
+ return
[PATCH 3/6] drm/omap: Add support for drm_panel
Hook up drm_panel support in the omapdrm driver. The change is
relatively simply as the way has been paved by drm_bridge support
already. In addition to looking up, attaching to and detaching from the
panel, we only need to add panel support in the connector .get_modes()
handler, take connector bus flags (set by the panel) into account, and
enable/disable the panel in the encoder enable/disable operations
handlers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 12 +
drivers/gpu/drm/omapdrm/dss/omapdss.h| 1 +
drivers/gpu/drm/omapdrm/dss/output.c | 7 +-
drivers/gpu/drm/omapdrm/omap_connector.c | 9 +++
drivers/gpu/drm/omapdrm/omap_drv.c | 15 ++-
drivers/gpu/drm/omapdrm/omap_encoder.c | 32 +---
6 files changed, 60 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
b/drivers/gpu/drm/omapdrm/dss/base.c
index fd624a2e9e63..51347a08b151 100644
--- a/drivers/gpu/drm/omapdrm/dss/base.c
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -157,7 +157,8 @@ struct omap_dss_device *omapdss_device_next_output(struct
omap_dss_device *from)
goto done;
}
- if (dssdev->id && (dssdev->next || dssdev->bridge))
+ if (dssdev->id &&
+ (dssdev->next || dssdev->bridge || dssdev->panel))
goto done;
}
@@ -192,10 +193,11 @@ int omapdss_device_connect(struct dss_device *dss,
if (!dst) {
/*
* The destination is NULL when the source is connected to a
-* bridge instead of a DSS device. Stop here, we will attach the
-* bridge later when we will have a DRM encoder.
+* bridge or panel instead of a DSS device. Stop here, we will
+* attach the bridge or panel later when we will have a DRM
+* encoder.
*/
- return src && src->bridge ? 0 : -EINVAL;
+ return src && (src->bridge || src->panel) ? 0 : -EINVAL;
}
if (omapdss_device_is_connected(dst))
@@ -223,7 +225,7 @@ void omapdss_device_disconnect(struct omap_dss_device *src,
dst ? dev_name(dst->dev) : "NULL");
if (!dst) {
- WARN_ON(!src->bridge);
+ WARN_ON(!src->bridge && !src->panel);
return;
}
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index e1657f2a2e51..f8a2aeb73c6b 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -411,6 +411,7 @@ struct omap_dss_device {
struct dss_device *dss;
struct omap_dss_device *next;
struct drm_bridge *bridge;
+ struct drm_panel *panel;
struct list_head list;
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
b/drivers/gpu/drm/omapdrm/dss/output.c
index c8230a3fabca..b209c3645ed3 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -22,6 +22,8 @@
#include
#include
+#include
+
#include "dss.h"
#include "omapdss.h"
@@ -37,6 +39,9 @@ int omapdss_device_init_output(struct omap_dss_device *out)
out->next = omapdss_find_device_by_node(remote_node);
out->bridge = of_drm_find_bridge(remote_node);
+ out->panel = of_drm_find_panel(remote_node);
+ if (IS_ERR(out->panel))
+ out->panel = NULL;
of_node_put(remote_node);
@@ -47,7 +52,7 @@ int omapdss_device_init_output(struct omap_dss_device *out)
return -EINVAL;
}
- return out->next || out->bridge ? 0 : -EPROBE_DEFER;
+ return out->next || out->bridge || out->panel ? 0 : -EPROBE_DEFER;
}
EXPORT_SYMBOL(omapdss_device_init_output);
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index f528baa80114..2da16f00cfae 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "omap_drv.h"
@@ -211,6 +212,7 @@ static int omap_connector_get_modes_edid(struct
drm_connector *connector,
static int omap_connector_get_modes(struct drm_connector *connector)
{
+ struct omap_connector *omap_connector = to_omap_connector(connector);
struct omap_dss_device *dssdev;
DBG("%s", connector->name);
@@ -233,6 +235,13 @@ static int omap_connector_get_modes(struct drm_connector
*connector)
if (dssdev)
return dssdev->ops->get_modes(dssdev, connector);
+ /*
+* Otherwise if the display pipeline uses a drm_panel, we delegate the
+* operation to the panel API.
+*/
+ if (omap_connector->output->panel)
+ return drm_panel_get_modes(omap_connector->output->panel);
+
/*
* We can't retrieve modes,
[PATCH 5/6] drm/omap: Remove TFP410 and DVI connector drivers
Those components are supported by the drm_bridge infrastructure, remove
the omapdrm-specific driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/Kconfig | 11 -
drivers/gpu/drm/omapdrm/displays/Makefile | 2 -
.../gpu/drm/omapdrm/displays/connector-dvi.c | 292 --
.../gpu/drm/omapdrm/displays/encoder-tfp410.c | 141 -
.../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 2 -
5 files changed, 448 deletions(-)
delete mode 100644 drivers/gpu/drm/omapdrm/displays/connector-dvi.c
delete mode 100644 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig
b/drivers/gpu/drm/omapdrm/displays/Kconfig
index a349cb61961e..38d066ac966e 100644
--- a/drivers/gpu/drm/omapdrm/displays/Kconfig
+++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
@@ -6,23 +6,12 @@ config DRM_OMAP_ENCODER_OPA362
Driver for OPA362 external analog TV amplifier controlled
through a GPIO.
-config DRM_OMAP_ENCODER_TFP410
-tristate "TFP410 DPI to DVI Encoder"
- help
- Driver for TFP410 DPI to DVI encoder.
-
config DRM_OMAP_ENCODER_TPD12S015
tristate "TPD12S015 HDMI ESD protection and level shifter"
help
Driver for TPD12S015, which offers HDMI ESD protection and level
shifting.
-config DRM_OMAP_CONNECTOR_DVI
-tristate "DVI Connector"
- depends on I2C
- help
- Driver for a generic DVI connector.
-
config DRM_OMAP_CONNECTOR_HDMI
tristate "HDMI Connector"
help
diff --git a/drivers/gpu/drm/omapdrm/displays/Makefile
b/drivers/gpu/drm/omapdrm/displays/Makefile
index d99659e1381b..da1d5321ef50 100644
--- a/drivers/gpu/drm/omapdrm/displays/Makefile
+++ b/drivers/gpu/drm/omapdrm/displays/Makefile
@@ -1,8 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_OMAP_ENCODER_OPA362) += encoder-opa362.o
-obj-$(CONFIG_DRM_OMAP_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DRM_OMAP_ENCODER_TPD12S015) += encoder-tpd12s015.o
-obj-$(CONFIG_DRM_OMAP_CONNECTOR_DVI) += connector-dvi.o
obj-$(CONFIG_DRM_OMAP_CONNECTOR_HDMI) += connector-hdmi.o
obj-$(CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
obj-$(CONFIG_DRM_OMAP_PANEL_DPI) += panel-dpi.o
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
deleted file mode 100644
index bf5ee50ce5fe..
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ /dev/null
@@ -1,292 +0,0 @@
-/*
- * Generic DVI Connector driver
- *
- * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
- * Author: Tomi Valkeinen
- *
- * 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 published by
- * the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "../dss/omapdss.h"
-
-struct panel_drv_data {
- struct omap_dss_device dssdev;
-
- struct i2c_adapter *i2c_adapter;
-
- struct gpio_desc *hpd_gpio;
-
- void (*hpd_cb)(void *cb_data, enum drm_connector_status status);
- void *hpd_cb_data;
- bool hpd_enabled;
- /* mutex for hpd fields above */
- struct mutex hpd_lock;
-};
-
-#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
-
-static int dvic_connect(struct omap_dss_device *src,
- struct omap_dss_device *dst)
-{
- return 0;
-}
-
-static void dvic_disconnect(struct omap_dss_device *src,
- struct omap_dss_device *dst)
-{
-}
-
-static int dvic_ddc_read(struct i2c_adapter *adapter,
- unsigned char *buf, u16 count, u8 offset)
-{
- int r, retries;
-
- for (retries = 3; retries > 0; retries--) {
- struct i2c_msg msgs[] = {
- {
- .addr = DDC_ADDR,
- .flags = 0,
- .len= 1,
- .buf= ,
- }, {
- .addr = DDC_ADDR,
- .flags = I2C_M_RD,
- .len= count,
- .buf= buf,
- }
- };
-
- r = i2c_transfer(adapter, msgs, 2);
- if (r == 2)
- return 0;
-
- if (r != -EAGAIN)
- break;
- }
-
- return r < 0 ? r : -EIO;
-}
-
-static int dvic_read_edid(struct omap_dss_device *dssdev,
- u8 *edid, int len)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- int r, l, bytes_read;
-
- l = min(EDID_LENGTH, len);
- r = dvic_ddc_read(ddata->i2c_adapter, edid, l, 0);
- if (r)
- return r;
-
- bytes_read = l;
-
- /* if there are
[PATCH 6/6] drm/omap: Remove panel-dpi driver
Panels are now supported through the drm_panel infrastructure, remove
the omapdrm-specific driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/Kconfig | 6 -
drivers/gpu/drm/omapdrm/displays/Makefile | 1 -
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 197 --
.../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 1 -
4 files changed, 205 deletions(-)
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-dpi.c
diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig
b/drivers/gpu/drm/omapdrm/displays/Kconfig
index 38d066ac966e..7b0bcb494b5c 100644
--- a/drivers/gpu/drm/omapdrm/displays/Kconfig
+++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
@@ -22,12 +22,6 @@ config DRM_OMAP_CONNECTOR_ANALOG_TV
help
Driver for a generic analog TV connector.
-config DRM_OMAP_PANEL_DPI
- tristate "Generic DPI panel"
- depends on BACKLIGHT_CLASS_DEVICE
- help
- Driver for generic DPI panels.
-
config DRM_OMAP_PANEL_DSI_CM
tristate "Generic DSI Command Mode Panel"
depends on BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/gpu/drm/omapdrm/displays/Makefile
b/drivers/gpu/drm/omapdrm/displays/Makefile
index da1d5321ef50..1db34d4fed64 100644
--- a/drivers/gpu/drm/omapdrm/displays/Makefile
+++ b/drivers/gpu/drm/omapdrm/displays/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_DRM_OMAP_ENCODER_OPA362) += encoder-opa362.o
obj-$(CONFIG_DRM_OMAP_ENCODER_TPD12S015) += encoder-tpd12s015.o
obj-$(CONFIG_DRM_OMAP_CONNECTOR_HDMI) += connector-hdmi.o
obj-$(CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
-obj-$(CONFIG_DRM_OMAP_PANEL_DPI) += panel-dpi.o
obj-$(CONFIG_DRM_OMAP_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DRM_OMAP_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_OMAP_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
deleted file mode 100644
index 3b3570cb0d9a..
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ /dev/null
@@ -1,197 +0,0 @@
-/*
- * Generic MIPI DPI Panel Driver
- *
- * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
- * Author: Tomi Valkeinen
- *
- * 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 published by
- * the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "../dss/omapdss.h"
-
-struct panel_drv_data {
- struct omap_dss_device dssdev;
-
- struct videomode vm;
-
- struct backlight_device *backlight;
-
- struct gpio_desc *enable_gpio;
- struct regulator *vcc_supply;
-};
-
-#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
-
-static int panel_dpi_connect(struct omap_dss_device *src,
-struct omap_dss_device *dst)
-{
- return 0;
-}
-
-static void panel_dpi_disconnect(struct omap_dss_device *src,
-struct omap_dss_device *dst)
-{
-}
-
-static void panel_dpi_enable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- int r;
-
- r = regulator_enable(ddata->vcc_supply);
- if (r)
- return;
-
- gpiod_set_value_cansleep(ddata->enable_gpio, 1);
- backlight_enable(ddata->backlight);
-}
-
-static void panel_dpi_disable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
-
- backlight_disable(ddata->backlight);
-
- gpiod_set_value_cansleep(ddata->enable_gpio, 0);
- regulator_disable(ddata->vcc_supply);
-}
-
-static int panel_dpi_get_modes(struct omap_dss_device *dssdev,
- struct drm_connector *connector)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
-
- return omapdss_display_get_modes(connector, >vm);
-}
-
-static const struct omap_dss_device_ops panel_dpi_ops = {
- .connect= panel_dpi_connect,
- .disconnect = panel_dpi_disconnect,
-
- .enable = panel_dpi_enable,
- .disable= panel_dpi_disable,
-
- .get_modes = panel_dpi_get_modes,
-};
-
-static int panel_dpi_probe_of(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct device_node *node = pdev->dev.of_node;
- int r;
- struct display_timing timing;
- struct gpio_desc *gpio;
-
- gpio = devm_gpiod_get_optional(>dev, "enable", GPIOD_OUT_LOW);
- if (IS_ERR(gpio))
- return PTR_ERR(gpio);
-
- ddata->enable_gpio = gpio;
-
- /*
-* Many different panels are supported by this driver and there are
-* probably very different needs for their reset pins in regards to
-* timing and order relative to the
[PATCH 1/6] drm/panel: simple: Add OSD070T1718-19TS panel support
Add support for the OSD070T1718-19TS 7" 800x480 panel from One Stop
Displays to the panel-simple driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index af6c84a726ef..723a560ba683 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1984,6 +1984,32 @@ static const struct panel_desc ortustech_com43h4m85ulc =
{
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
};
+static const struct drm_display_mode osddisplays_osd070t1718_19ts_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 210,
+ .hsync_end = 800 + 210 + 30,
+ .htotal = 800 + 210 + 30 + 16,
+ .vdisplay = 480,
+ .vsync_start = 480 + 22,
+ .vsync_end = 480 + 22 + 13,
+ .vtotal = 480 + 22 + 13 + 10,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc osddisplays_osd070t1718_19ts = {
+ .modes = _osd070t1718_19ts_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+};
+
static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -2658,6 +2684,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ortustech,com43h4m85ulc",
.data = _com43h4m85ulc,
+ }, {
+ .compatible = "osddisplays,osd070t1718-19ts",
+ .data = _osd070t1718_19ts,
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = _40,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108985] Visual Novel "The Fruit of Grisaia" has flickering glitches
https://bugs.freedesktop.org/show_bug.cgi?id=108985 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Timothy Arceri --- (In reply to Fabian Maurer from comment #0) > System the bug was tested on: > - Arch Linux 64bit > - Linux 4.19.08, AMDGPU driver > - Mesa 17.2.0-devel (git-ccf9669cc1) / Mesa 17.0.5 > - Radeon R9 285 > - KDE Plasma 5 with OpenGL compositor and regular X session Please test with a more recent version of Mesa before reporting bugs, otherwise you are just wasting the time of developers (we already have limited resources). You have an extremely odd setup, cutting edge Kernel with obsolete Mesa versions (almost 2 years old). Please retest with Mesa git or at the very least Mesa 18.3. -- 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 200531] amdgpu: *ERROR* REG_WAIT timeout when a display is put to sleep
https://bugzilla.kernel.org/show_bug.cgi?id=200531 --- Comment #11 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- 4.18 is EOL now, I'm currently on 4.20-rc. This problem doesn't occur on 4.20, and on 4.19 too. Should I close this bug as obsolete? -- 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 108997] RX460: Some Resolution-Refresh Combinations Unavailable when Connected via DisplayPort
https://bugs.freedesktop.org/show_bug.cgi?id=108997 --- Comment #1 from Mingcong Bai --- I'm able to get the full 1600x1200@76Hz image with an active HDMI to VGA adapter. The image is a bit ghosted, but it's probably just the converter. -- 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 108997] RX460: Some Resolution-Refresh Combinations Unavailable when Connected via DisplayPort
https://bugs.freedesktop.org/show_bug.cgi?id=108997 --- Comment #5 from Mingcong Bai --- Created attachment 142767 --> https://bugs.freedesktop.org/attachment.cgi?id=142767=edit Kernel Configuration - 4.19.0 -- 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
linux-next: manual merge of the drm-msm tree with the drm tree
Hi all,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c
between commit:
c97ea6a61b5e ("drm: msm: adreno: Use PTR_ERR_OR_ZERO rather than
if(IS_ERR(...)) +PTR_ERR")
from the drm tree and commits:
dadb36b7ec42 ("drm/msm: Add a common function to free kernel buffer objects")
7799a98edd80 ("drm/msm: Add a name field for gem objects")
from the drm-msm tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpuTUQT6F7SS.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/29] drm/omap: Simplify OF lookup of DSS devices
Hi,
On Wed, Dec 05, 2018 at 05:00:21PM +0200, Laurent Pinchart wrote:
> Now that the direction of OF graph walk has been reversed, there's no
> need to lookup devices by port as we have no sink device connected
> through multiple sink ports. Simplify OF lookup of the DSS devices to
> look them up by node only.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/base.c| 5 +--
> drivers/gpu/drm/omapdrm/dss/dss-of.c | 60 ---
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +-
> 3 files changed, 10 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 36f2d41c9935..4d7f999c8e29 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -112,13 +112,12 @@ void omapdss_device_put(struct omap_dss_device *dssdev)
> }
> EXPORT_SYMBOL(omapdss_device_put);
>
> -struct omap_dss_device *omapdss_find_device_by_port(struct device_node *src,
> - unsigned int port)
> +struct omap_dss_device *omapdss_find_device_by_node(struct device_node *node)
> {
> struct omap_dss_device *dssdev;
>
> list_for_each_entry(dssdev, _devices_list, list) {
> - if (dssdev->dev->of_node == src && dssdev->of_ports & BIT(port))
> + if (dssdev->dev->of_node == node)
> return omapdss_device_get(dssdev);
> }
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> index 0422597ac6b0..b2094055c5fc 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> @@ -12,71 +12,25 @@
> * more details.
> */
>
> -#include
> #include
> -#include
> #include
> #include
> -#include
>
> #include "omapdss.h"
>
> -static struct device_node *
> -dss_of_port_get_parent_device(struct device_node *port)
> -{
> - struct device_node *np;
> - int i;
> -
> - if (!port)
> - return NULL;
> -
> - np = of_get_parent(port);
> -
> - for (i = 0; i < 2 && np; ++i) {
> - struct property *prop;
> -
> - prop = of_find_property(np, "compatible", NULL);
> -
> - if (prop)
> - return np;
> -
> - np = of_get_next_parent(np);
> - }
> -
> - return NULL;
> -}
> -
> struct omap_dss_device *
> omapdss_of_find_connected_device(struct device_node *node, unsigned int port)
> {
> - struct device_node *src_node;
> - struct device_node *src_port;
> - struct device_node *ep;
> - struct omap_dss_device *src;
> - u32 port_number = 0;
> + struct device_node *remote_node;
> + struct omap_dss_device *dssdev;
>
> - /* Get the endpoint... */
> - ep = of_graph_get_endpoint_by_regs(node, port, 0);
> - if (!ep)
> + remote_node = of_graph_get_remote_node(node, port, 0);
> + if (!remote_node)
> return NULL;
>
> - /* ... and its remote port... */
> - src_port = of_graph_get_remote_port(ep);
> - of_node_put(ep);
> - if (!src_port)
> - return NULL;
> -
> - /* ... and the remote port's number and parent... */
> - of_property_read_u32(src_port, "reg", _number);
> - src_node = dss_of_port_get_parent_device(src_port);
> - of_node_put(src_port);
> - if (!src_node)
> - return ERR_PTR(-EINVAL);
> -
> - /* ... and finally the connected device. */
> - src = omapdss_find_device_by_port(src_node, port_number);
> - of_node_put(src_node);
> + dssdev = omapdss_find_device_by_node(remote_node);
> + of_node_put(remote_node);
>
> - return src ? src : ERR_PTR(-EPROBE_DEFER);
> + return dssdev ? dssdev : ERR_PTR(-EPROBE_DEFER);
> }
> EXPORT_SYMBOL_GPL(omapdss_of_find_connected_device);
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index d990009ddbbd..d51cb181e2cc 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -481,8 +481,7 @@ void omapdss_device_register(struct omap_dss_device
> *dssdev);
> void omapdss_device_unregister(struct omap_dss_device *dssdev);
> struct omap_dss_device *omapdss_device_get(struct omap_dss_device *dssdev);
> void omapdss_device_put(struct omap_dss_device *dssdev);
> -struct omap_dss_device *omapdss_find_device_by_port(struct device_node *src,
> - unsigned int port);
> +struct omap_dss_device *omapdss_find_device_by_node(struct device_node
> *node);
> struct omap_dss_device *omapdss_device_get_next(struct omap_dss_device *from,
> enum omap_dss_device_type type);
> int omapdss_device_connect(struct dss_device *dss,
> --
> Regards,
>
> Laurent Pinchart
>
> ___
>
[Bug 108997] RX460: Some Resolution-Refresh Combinations Unavailable when Connected via DisplayPort
https://bugs.freedesktop.org/show_bug.cgi?id=108997 --- Comment #4 from Mingcong Bai --- Using the same cable, the NVIDIA GeForce GTX1060 using proprietary driver version 410.66 is able to drive 1600x1200@76Hz with no issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH -next] drm/amdgpu: remove set but not used variable 'grbm_soft_reset'
> -Original Message-
> From: YueHaibing
> Sent: Saturday, December 08, 2018 11:01 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; airl...@linux.ie; Liu, Leo ;
> Gao, Likun ; Panariti, David
> ; S, Shirish ; Zhu, Rex
> ; Grodzovsky, Andrey
> Cc: YueHaibing ; amd-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; kernel-
> janit...@vger.kernel.org
> Subject: [PATCH -next] drm/amdgpu: remove set but not used variable
> 'grbm_soft_reset'
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function
> 'gfx_v8_0_pre_soft_reset':
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:4950:27: warning:
> variable 'srbm_soft_reset' set but not used [-Wunused-but-set-variable]
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function
> 'gfx_v8_0_post_soft_reset':
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:5054:27: warning:
> variable 'srbm_soft_reset' set but not used [-Wunused-but-set-variable]
>
> It never used since introduction in commit d31a501ead7f ("drm/amdgpu: add
> pre_soft_reset ip func") and e4ae0fc33631 ("drm/amdgpu: implement
> gfx8 post_soft_reset")
>
> Signed-off-by: YueHaibing
Reviewed-by: Chunming Zhou
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 1454fc3..8c1ba79 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -4947,14 +4947,13 @@ static bool gfx_v8_0_check_soft_reset(void
> *handle) static int gfx_v8_0_pre_soft_reset(void *handle) {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> - u32 grbm_soft_reset = 0, srbm_soft_reset = 0;
> + u32 grbm_soft_reset = 0;
>
> if ((!adev->gfx.grbm_soft_reset) &&
> (!adev->gfx.srbm_soft_reset))
> return 0;
>
> grbm_soft_reset = adev->gfx.grbm_soft_reset;
> - srbm_soft_reset = adev->gfx.srbm_soft_reset;
>
> /* stop the rlc */
> adev->gfx.rlc.funcs->stop(adev);
> @@ -5051,14 +5050,13 @@ static int gfx_v8_0_soft_reset(void *handle)
> static int gfx_v8_0_post_soft_reset(void *handle) {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> - u32 grbm_soft_reset = 0, srbm_soft_reset = 0;
> + u32 grbm_soft_reset = 0;
>
> if ((!adev->gfx.grbm_soft_reset) &&
> (!adev->gfx.srbm_soft_reset))
> return 0;
>
> grbm_soft_reset = adev->gfx.grbm_soft_reset;
> - srbm_soft_reset = adev->gfx.srbm_soft_reset;
>
> if (REG_GET_FIELD(grbm_soft_reset, GRBM_SOFT_RESET,
> SOFT_RESET_CP) ||
> REG_GET_FIELD(grbm_soft_reset, GRBM_SOFT_RESET,
> SOFT_RESET_CPF) ||
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 Timothy Arceri changed: What|Removed |Added CC||t_arc...@yahoo.com.au --- Comment #5 from Timothy Arceri --- Can somebody try to get an apitrace of the issue [1]? Thanks. [1] https://github.com/apitrace/apitrace/wiki/Steam -- 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 04/29] drm/omap: Use atomic suspend/resume helpers
Hi Sebastian,
On Sunday, 9 December 2018 23:53:09 EET Sebastian Reichel wrote:
> Hi,
>
> On Wed, Dec 05, 2018 at 04:59:57PM +0200, Laurent Pinchart wrote:
> > Instead of rolling out custom suspend/resume implementations based on
> > state information stored in the driver's data structures, use the atomic
> > suspend/resume helpers that rely on a DRM atomic state object.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
>
> Documentation/gpu/todo.rst says, that this should be converted to
> drm_mode_config_helper_suspend, but at least it's no longer open
> coded after your change.
Good point. I'll fix this in the next version. Thank you for pointing it out.
> Reviewed-by: Sebastian Reichel
>
> > drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 --
> > drivers/gpu/drm/omapdrm/omap_drv.c| 52 +--
> > drivers/gpu/drm/omapdrm/omap_drv.h| 2 ++
> > 3 files changed, 11 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> > b/drivers/gpu/drm/omapdrm/dss/omapdss.h index d3b576e6edf5..149a0f09adbc
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> > +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> > @@ -432,9 +432,6 @@ struct omap_dss_device {
> >
> > unsigned long ops_flags;
> > unsigned long bus_flags;
> >
> > - /* helper variable for driver suspend/resume */
> > - bool activate_after_resume;
> > -
> >
> > enum omap_display_caps caps;
> >
> > enum omap_dss_display_state state;
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> > b/drivers/gpu/drm/omapdrm/omap_drv.c index 5e67d58cbc28..66c4cedb5539
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> > @@ -685,52 +685,21 @@ static int pdev_remove(struct platform_device *pdev)
> >
> > }
> >
> > #ifdef CONFIG_PM_SLEEP
> >
> > -static int omap_drm_suspend_all_displays(struct drm_device *ddev)
> > -{
> > - struct omap_drm_private *priv = ddev->dev_private;
> > - int i;
> > -
> > - for (i = 0; i < priv->num_pipes; i++) {
> > - struct omap_dss_device *display = priv->pipes[i].display;
> > -
> > - if (display->state == OMAP_DSS_DISPLAY_ACTIVE) {
> > - display->ops->disable(display);
> > - display->activate_after_resume = true;
> > - } else {
> > - display->activate_after_resume = false;
> > - }
> > - }
> > -
> > - return 0;
> > -}
> > -
> > -static int omap_drm_resume_all_displays(struct drm_device *ddev)
> > -{
> > - struct omap_drm_private *priv = ddev->dev_private;
> > - int i;
> > -
> > - for (i = 0; i < priv->num_pipes; i++) {
> > - struct omap_dss_device *display = priv->pipes[i].display;
> > -
> > - if (display->activate_after_resume) {
> > - display->ops->enable(display);
> > - display->activate_after_resume = false;
> > - }
> > - }
> > -
> > - return 0;
> > -}
> > -
> >
> > static int omap_drm_suspend(struct device *dev)
> > {
> >
> > struct omap_drm_private *priv = dev_get_drvdata(dev);
> > struct drm_device *drm_dev = priv->ddev;
> >
> > + struct drm_atomic_state *state;
> >
> > drm_kms_helper_poll_disable(drm_dev);
> >
> > - drm_modeset_lock_all(drm_dev);
> > - omap_drm_suspend_all_displays(drm_dev);
> > - drm_modeset_unlock_all(drm_dev);
> > + state = drm_atomic_helper_suspend(drm_dev);
> > + if (IS_ERR(state)) {
> > + drm_kms_helper_poll_enable(drm_dev);
> > + return PTR_ERR(state);
> > + }
> > +
> > + priv->suspend_state = state;
> >
> > return 0;
> >
> > }
> >
> > @@ -740,10 +709,7 @@ static int omap_drm_resume(struct device *dev)
> >
> > struct omap_drm_private *priv = dev_get_drvdata(dev);
> > struct drm_device *drm_dev = priv->ddev;
> >
> > - drm_modeset_lock_all(drm_dev);
> > - omap_drm_resume_all_displays(drm_dev);
> > - drm_modeset_unlock_all(drm_dev);
> > -
> > + drm_atomic_helper_resume(drm_dev, priv->suspend_state);
> >
> > drm_kms_helper_poll_enable(drm_dev);
> >
> > return omap_gem_resume(drm_dev);
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> > b/drivers/gpu/drm/omapdrm/omap_drv.h index bd7f2c227a25..788aa9f7e6df
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> > +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> > @@ -73,6 +73,8 @@ struct omap_drm_private {
> >
> > struct workqueue_struct *wq;
> >
> > + struct drm_atomic_state *suspend_state;
> > +
> >
> > /* lock for obj_list below */
> > struct mutex list_lock;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD
Hi Inki, On 10.12.2018 03:25, Inki Dae wrote: > Hi Andrzej, > > 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글: >> Hi Inki, >> >> This small patchset adds dynamic zpos support for DECON and FIMD. > This patch will allow user space to change zpos. However, DECON and FIMD > devices have fixed priority of HW overlays. > This would mean that zpos change by user space doesn't guarantee correct HW > overlay priority. > > Why do you want to support mutable zpos? Practically you have patches which proves it works, you can see that changing zpos value results in adequate change in displayed image. Conceptually it is just a matter of disconnecting hardware windows present in DECON and FIMD from DRM planes which are software entities. You can reason about it this way: - drm plane is a framebuffer plus informations how it should be transformed/displayed on DECON/FIMD, - hw window in DECON/FIMD is just a channel through which plane is send to the display. DECON and FIMD has fixed hw windows order - windows with lower numbers are displayed below windows with higher number. To display planes in given z-order you just need to send them via windows with appropriate index - farthest plane should go always via win0, closer one via win1, ..., till the last plane. So for example if you have three planes and want to display them in following order (first one farthest, last one closest): plane2, plane1, plane3 you should map them to planes as follow: plane2 -> win0, plane1 -> win1, plane3 -> win2 then for example plane2 is disabled, we will have following mapping: plane1 -> win0, plane3 -> win1, win2 - disabled then if you change zorder of planes to: plane3, plane1: plane3 -> win0, plane1 -> win1 As you see there is no relation between plane number and window number, but window number is equal to plane's position in zpos-ordered list of planes and this is exact value of normalized_zpos field in drm_plane_state. I hope this extended explanation will clarify things. Regards Andrzej > > Thanks, > Inki Dae > >> It was tested on tm2 and trats2. >> >> Regards >> Andrzej >> >> >> Andrzej Hajda (3): >> drm/exynos/decon5433: add dynamic zpos support >> drm/exynos/fimd: create local helper for disabling hardware window >> drm/exynos/fimd: add dynamic zpos support >> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 23 +- >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 --- >> 2 files changed, 29 insertions(+), 36 deletions(-) >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/29] drm/omap: Move DISPC timing checks to CRTC .mode_valid() operation
Hi Sebastian,
On Monday, 10 December 2018 00:07:55 EET Sebastian Reichel wrote:
> On Wed, Dec 05, 2018 at 05:00:15PM +0200, Laurent Pinchart wrote:
> > The DISPC timings checks relate to the CRTC, but they're performed in
> > the encoder and connector .atomic_check() and .mode_valid() operations.
> > Move them to the CRTC .mode_valid() operation.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
>
> Reviewed-by: Sebastian Reichel
>
> This should also fix the issue with DSI in a less ugly way:
>
> https://lists.freedesktop.org/archives/dri-devel/2018-November/196622.html
Should I add the
Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly")
tag to this patch ?
> > drivers/gpu/drm/omapdrm/omap_connector.c | 6 --
> > drivers/gpu/drm/omapdrm/omap_crtc.c | 9 +
> > drivers/gpu/drm/omapdrm/omap_encoder.c | 6 --
> > 3 files changed, 9 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
> > b/drivers/gpu/drm/omapdrm/omap_connector.c index
> > 8db1f2fbcf43..dd1e0f2e8ffc 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> > @@ -245,8 +245,6 @@ static int omap_connector_mode_valid(struct
> > drm_connector *connector,>
> > struct drm_display_mode *mode)
> >
> > {
> >
> > struct omap_connector *omap_connector = to_omap_connector(connector);
> >
> > - enum omap_channel channel = omap_connector->output->dispc_channel;
> > - struct omap_drm_private *priv = connector->dev->dev_private;
> >
> > struct omap_dss_device *dssdev;
> > struct videomode vm = {0};
> > struct drm_device *dev = connector->dev;
> >
> > @@ -256,10 +254,6 @@ static int omap_connector_mode_valid(struct
> > drm_connector *connector,>
> > drm_display_mode_to_videomode(mode, );
> > mode->vrefresh = drm_mode_vrefresh(mode);
> >
> > - r = priv->dispc_ops->mgr_check_timings(priv->dispc, channel, );
> > - if (r)
> > - goto done;
> > -
> >
> > for (dssdev = omap_connector->output; dssdev; dssdev = dssdev->next) {
> >
> > if (!dssdev->ops->check_timings)
> >
> > continue;
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> > b/drivers/gpu/drm/omapdrm/omap_crtc.c index caffc547ef97..51036e6fca1c
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> > @@ -391,6 +391,15 @@ static enum drm_mode_status
> > omap_crtc_mode_valid(struct drm_crtc *crtc,>
> > const struct drm_display_mode *mode)
> >
> > {
> >
> > struct omap_drm_private *priv = crtc->dev->dev_private;
> >
> > + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> > + struct videomode vm = {0};
> > + int r;
> > +
> > + drm_display_mode_to_videomode(mode, );
> > + r = priv->dispc_ops->mgr_check_timings(priv->dispc, omap_crtc->channel,
> > + );
> > + if (r)
> > + return r;
> >
> > /* Check for bandwidth limit */
> > if (priv->max_bandwidth) {
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
> > b/drivers/gpu/drm/omapdrm/omap_encoder.c index 79ee927cd905..7d01df6fa723
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
> > @@ -198,19 +198,13 @@ static int omap_encoder_atomic_check(struct
> > drm_encoder *encoder,>
> > struct drm_connector_state *conn_state)
> >
> > {
> >
> > struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> >
> > - enum omap_channel channel = omap_encoder->output->dispc_channel;
> >
> > struct drm_device *dev = encoder->dev;
> >
> > - struct omap_drm_private *priv = dev->dev_private;
> >
> > struct omap_dss_device *dssdev;
> > struct videomode vm = { 0 };
> > int ret;
> >
> > drm_display_mode_to_videomode(_state->mode, );
> >
> > - ret = priv->dispc_ops->mgr_check_timings(priv->dispc, channel, );
> > - if (ret)
> > - goto done;
> > -
> >
> > for (dssdev = omap_encoder->output; dssdev; dssdev = dssdev->next) {
> >
> > if (!dssdev->ops->check_timings)
> >
> > continue;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1.1 09/29] drm/omap: Reverse direction of the DSS device enable/disable operations
The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.
Reconcile the omapdrm and omapdss drivers with the DRM bridge and panel
model by reversing the direction of the DSS device .enable() and
.disable() operations. This completes the move to the DRM bridge model,
with the notable exception of the DSI pipelines that will require more
work.
We also adapt the omapdss shutdown handler dss_shutdown() to shut down
all active pipelines starting from the pipeline output device instead of
the display device.
As a consequence the for_each_dss_display() macro isn't used and can be
removed, and the omapdss_device_get_next() function underlying the macro
can be simplified to search for output devices only.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Shutdown pipelines starting at the output device
---
.../omapdrm/displays/connector-analog-tv.c| 21 --
.../gpu/drm/omapdrm/displays/connector-dvi.c | 21 --
.../gpu/drm/omapdrm/displays/connector-hdmi.c | 21 --
.../gpu/drm/omapdrm/displays/encoder-opa362.c | 25 +--
.../gpu/drm/omapdrm/displays/encoder-tfp410.c | 21 +-
.../drm/omapdrm/displays/encoder-tpd12s015.c | 35 -
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 18 +
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 22 ++
.../displays/panel-lgphilips-lb035q02.c | 16 +---
.../omapdrm/displays/panel-nec-nl8048hl11.c | 16 +---
.../displays/panel-sharp-ls037v7dw01.c| 32
.../omapdrm/displays/panel-sony-acx565akm.c | 18 +
.../omapdrm/displays/panel-tpo-td028ttec1.c | 25 ++-
.../omapdrm/displays/panel-tpo-td043mtea1.c | 17 +
drivers/gpu/drm/omapdrm/dss/base.c| 73 +++
drivers/gpu/drm/omapdrm/dss/dpi.c | 5 +-
drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +-
drivers/gpu/drm/omapdrm/dss/dss.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +--
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 12 +--
drivers/gpu/drm/omapdrm/dss/omapdss.h | 20 +++--
drivers/gpu/drm/omapdrm/dss/sdi.c | 8 +-
drivers/gpu/drm/omapdrm/dss/venc.c| 12 +--
drivers/gpu/drm/omapdrm/omap_encoder.c| 49 ++---
24 files changed, 171 insertions(+), 337 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 2b5b77627cfb..1503563117f3 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -35,26 +35,9 @@ static void tvc_disconnect(struct omap_dss_device *src,
{
}
-static int tvc_enable(struct omap_dss_device *dssdev)
-{
- struct omap_dss_device *src = dssdev->src;
-
- return src->ops->enable(src);
-}
-
-static void tvc_disable(struct omap_dss_device *dssdev)
-{
- struct omap_dss_device *src = dssdev->src;
-
- src->ops->disable(src);
-}
-
static const struct omap_dss_device_ops tvc_ops = {
.connect= tvc_connect,
.disconnect = tvc_disconnect,
-
- .enable = tvc_enable,
- .disable= tvc_disable,
};
static int tvc_probe(struct platform_device *pdev)
@@ -85,13 +68,9 @@ static int tvc_probe(struct platform_device *pdev)
static int __exit tvc_remove(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct omap_dss_device *dssdev = >dssdev;
omapdss_device_unregister(>dssdev);
- if (omapdss_device_is_enabled(dssdev))
- tvc_disable(dssdev);
-
return 0;
}
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index a1784e263835..bf5ee50ce5fe 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -46,20 +46,6 @@ static void dvic_disconnect(struct omap_dss_device *src,
{
}
-static int dvic_enable(struct omap_dss_device *dssdev)
-{
- struct omap_dss_device *src = dssdev->src;
-
- return src->ops->enable(src);
-}
-
-static void dvic_disable(struct omap_dss_device *dssdev)
-{
- struct omap_dss_device *src = dssdev->src;
-
- src->ops->disable(src);
-}
-
static int dvic_ddc_read(struct i2c_adapter *adapter,
unsigned char *buf, u16 count, u8 offset)
{
@@ -163,9 +149,6 @@ static const struct omap_dss_device_ops dvic_ops = {
.connect= dvic_connect,
.disconnect = dvic_disconnect,
- .enable = dvic_enable,
- .disable= dvic_disable,
-
.read_edid = dvic_read_edid,
.detect = dvic_detect,
@@ -275,13 +258,9 @@ static int
[GIT PULL] mediatek drm fixes for 4.20
Hi, Dave: Here is one fix. Regards, CK The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git a0071bc455da for you to fetch changes up to a0071bc455da7b830b9517058933a83eb6cc902a: drm/mediatek: Only try to attach bridge if there is one (2018-12-03 11:08:22 +0800) Nicolas Boichat (1): drm/mediatek: Only try to attach bridge if there is one drivers/gpu/drm/mediatek/mtk_dsi.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/exynos: add support for dynamic zpos in DECON and FIMD
Hi Andrzej, 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글: > Hi Inki, > > This small patchset adds dynamic zpos support for DECON and FIMD. This patch will allow user space to change zpos. However, DECON and FIMD devices have fixed priority of HW overlays. This would mean that zpos change by user space doesn't guarantee correct HW overlay priority. Why do you want to support mutable zpos? Thanks, Inki Dae > It was tested on tm2 and trats2. > > Regards > Andrzej > > > Andrzej Hajda (3): > drm/exynos/decon5433: add dynamic zpos support > drm/exynos/fimd: create local helper for disabling hardware window > drm/exynos/fimd: add dynamic zpos support > > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 23 +- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 --- > 2 files changed, 29 insertions(+), 36 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108979] Graphical glitch of popupping missing texture on Mesa version >18.0.5 (Padoka Stable + Unstable/Oibaf/ubuntu-x-swat PPAs)
https://bugs.freedesktop.org/show_bug.cgi?id=108979 --- Comment #3 from Timothy Arceri --- I'm not sure what I'm meant to be looking for in the video. Can you be more specific? Maybe capture a screenshot of the exact issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm_rockchip: rk3066_hdmi: No driver support for vblank timestamp query.
Hi Johan,
It looks like VOP on RK3066 is not officially supported by upstream, so
what you're seeing is not a bug, it's just expected behavior, because
nobody had the time (or need) to enable support for your hardware yet.
I added all the people that may be potentially thinking to add support for
this SoC, but they have no obligation to do so. If you are in an urgent
need, I think you may have more luck asking your hardware or SoC vendor
directly.
Best regards,
Tomasz
On Sat, Dec 1, 2018 at 3:53 AM Johan Jonker wrote:
> Hi,
>
> This is about a TV stick called MK808.
> Enabled VOP an HDMI for rk3066.
> Able to see pinguins at boot.
>
> Found similar bug reports for rk3399.
>
> http://lists.infradead.org/pipermail/linux-rockchip/2018-April/020426.html
> http://lists.infradead.org/pipermail/linux-rockchip/2018-April/020427.html
> http://lists.infradead.org/pipermail/linux-rockchip/2018-April/020428.html
>
>
> This patch doesn't seem to work for me.
>
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1601,6 +1601,8 @@ static void vop_unbind(struct device *dev, struct
> device *master, void *data)
> {
> struct vop *vop = dev_get_drvdata(dev);
>
> + // Pair with the initial disable_irq()
> + enable_irq(vop->irq);
>
> Compared to rk3399 the rk3066 doesn't seem to have iommu.
>
> [0.383273] rockchip-drm display-subsystem:
> [drm:rockchip_drm_platform_probe] no iommu attached for /vop@1010c000,
> using non-iommu buffers
>
> Bugs as usual:
>
>
> [4.730057] rockchip-vop 1010c000.vop: [drm:vop_crtc_atomic_flush]
> *ERROR* VOP vblank IRQ stuck for 10 ms
>
> [ 596.422383] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [CRTC:30:crtc-0] flip_done timed out
>
> [ 606.661508] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [CONNECTOR:33:HDMI-A-1] flip_done timed out
>
> [ 616.901899] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
> [PLANE:28:plane-0] flip_done timed out
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5, amdgpu error
https://bugs.freedesktop.org/show_bug.cgi?id=108992 Bug ID: 108992 Summary: Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5, amdgpu error Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: christian.frank@googlemail.com Created attachment 142765 --> https://bugs.freedesktop.org/attachment.cgi?id=142765=edit amdgpu error message Hi, i upgraded from mainline kernel 4.19.7 to 4.20-rc5. Sadly using that kernel the system freezes when it tries to show gdm. OS: Ubuntu 18.04.1 Kernel: Linux version 4.20.0-042000rc5-generic (kernel@gloin) (gcc version 8.2.0 (Ubuntu 8.2.0-10ubuntu1)) #201812030721 SMP Mon Dec 3 12:23:24 UTC 2018 Command line: BOOT_IMAGE=/boot/vmlinuz-4.20.0-042000rc5-generic root=UUID=1381a98d-77fd-481f-9cdb-115b30829bd8 ro ivrs_ioapic[32]=00:14.0 ivrs_ioapic[33]=00:00.1 vt.handoff=1 Mesa is at version 18.2.2 (X-Swat ppa) Firmware files: ll /lib/firmware/amdgpu/rav* -rw-r--r-- 1 root root 33280 Nov 6 21:32 /lib/firmware/amdgpu/raven_asd.bin -rw-r--r-- 1 root root 9344 Nov 6 21:32 /lib/firmware/amdgpu/raven_ce.bin -rw-r--r-- 1 root root316 Apr 25 2018 /lib/firmware/amdgpu/raven_gpu_info.bin -rw-r--r-- 1 root root 17536 Nov 6 21:32 /lib/firmware/amdgpu/raven_me.bin -rw-r--r-- 1 root root 263808 Nov 6 21:32 /lib/firmware/amdgpu/raven_mec2.bin -rw-r--r-- 1 root root 263808 Nov 6 21:32 /lib/firmware/amdgpu/raven_mec.bin -rw-r--r-- 1 root root 21632 Nov 6 21:32 /lib/firmware/amdgpu/raven_pfp.bin -rw-r--r-- 1 root root 26948 Nov 6 21:32 /lib/firmware/amdgpu/raven_rlc.bin -rw-r--r-- 1 root root 17408 Nov 6 21:32 /lib/firmware/amdgpu/raven_sdma.bin -rw-r--r-- 1 root root 341728 Apr 25 2018 /lib/firmware/amdgpu/raven_vcn.bin christian@christian-ThinkPad-E585:~$ apt-cache show linux-firmware Package: linux-firmware Architecture: all Version: 1.173.2 Error-Log from journalctl: Dez 09 16:26:20 christian-ThinkPad-E585 set-cpufreq[874]: Setting ondemand scheduler for all CPUs Dez 09 16:26:20 christian-ThinkPad-E585 kernel: gmc_v9_0_process_interrupt: 28 callbacks suppressed Dez 09 16:26:20 christian-ThinkPad-E585 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0 ring:158 vmid:1 pasid:32768, for process gnome-shell pid 1102 thread g Dez 09 16:26:20 christian-ThinkPad-E585 kernel: amdgpu :05:00.0: in page starting at address 0x80010002 from 18 Dez 09 16:26:20 christian-ThinkPad-E585 kernel: amdgpu :05:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x0010013C Dez 09 16:26:20 christian-ThinkPad-E585 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0 ring:158 vmid:1 pasid:32768, for process gnome-shell pid 1102 thread g Dez 09 16:26:20 christian-ThinkPad-E585 kernel: amdgpu :05:00.0: in page starting at address 0x80010002 from 18 Dez 09 16:26:20 christian-ThinkPad-E585 kernel: amdgpu :05:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x0010013C ez 09 16:26:20 christian-ThinkPad-E585 kernel: [Hardware Error]: Deferred error, no action required. Dez 09 16:26:20 christian-ThinkPad-E585 kernel: [Hardware Error]: CPU:0 (17:11:0) MC20_STATUS[-|-|MiscV|-|AddrV|Deferred|-|SyndV Dez 09 16:26:20 christian-ThinkPad-E585 systemd-journald[378]: Missed 68239 kernel messages Dez 09 16:26:20 christian-ThinkPad-E585 kernel: [Hardware Error]: Deferred error, no action required. Dez 09 16:26:20 christian-ThinkPad-E585 systemd-journald[378]: Missed 6630 kernel messages Dez 09 16:26:20 christian-ThinkPad-E585 kernel: [Hardware Error]: Coherent Slave Extended Error Code: 1 Dez 09 16:26:20 christian-ThinkPad-E585 systemd-journald[378]: Missed 7875 kernel messages I attached an .txt file showing more of the error messages. I also have seen freezes with 4.19.7 with a similar error message, but this happens very rarely. With 4.20-rc5 the issue happens every time gdm tries to start, which makes the system unusable. If you need any other info, please ping me. Many thanks ! Christian -- 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 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5, amdgpu error
https://bugs.freedesktop.org/show_bug.cgi?id=108992 chris changed: What|Removed |Added Version|XOrg git|unspecified -- 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 201843] Micro-stuttering each second on amdgpu only on 2560x1440
https://bugzilla.kernel.org/show_bug.cgi?id=201843 Oleg Chernovskiy (kairl...@yandex.ru) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #4 from Oleg Chernovskiy (kairl...@yandex.ru) --- Did an upgrade to 4.20 (Alex Deucher branch), Mesa 19 and this is indeed resolved. Apologies to the previous commenter. -- 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 108987] [CI][DRMTIP]igt@perf@short-reads - incomplete
https://bugs.freedesktop.org/show_bug.cgi?id=108987 Bug ID: 108987 Summary: [CI][DRMTIP]igt@perf@short-reads - incomplete Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: lakshminarayana.vu...@intel.com https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_150/fi-hsw-4770/igt@perf@short-reads.htmlErr Err: Starting subtest: short-reads Subtest short-reads: SUCCESS (0.040s) Dmesg: <6> [226.130737] Console: switching to colour dummy device 80x25 <6> [226.130782] [IGT] perf: executing <6> [226.134982] [IGT] perf: starting subtest short-reads <7> [226.144119] [drm:i915_perf_open_ioctl [i915]] OA Buffer initialized, gtt offset = 0x100, vaddr = 95bba7dc <5> [226.175031] [drm] Skipping spurious, invalid OA report <5> [226.175034] [drm] Skipping spurious, invalid OA report <5> [226.175035] [drm] Skipping spurious, invalid OA report <5> [226.175036] [drm] Skipping spurious, invalid OA report <5> [226.175037] [drm] Skipping spurious, invalid OA report <5> [226.175039] [drm] Skipping spurious, invalid OA report <5> [226.175040] [drm] Skipping spurious, invalid OA report <5> [226.175041] [drm] Skipping spurious, invalid OA report <5> [226.175042] [drm] Skipping spurious, invalid OA report <5> [226.175043] [drm] Skipping spurious, invalid OA report <5> [226.175324] [drm] 54 spurious OA report notices suppressed due to ratelimiting <6> [226.175547] [IGT] perf: exiting, ret=0 <6> [226.219085] Console: switching to colour frame buffer device 128x48 https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_150/fi-hsw-4770/run16.log Started CI_IGT_test #2617848 Started from command line by qa-reports [EnvInject] - Loading node environment variables. Building remotely on fi-hsw-4770 (CIIGT PATCHWORK TRYBOT WATCHDOG CIDRM) in workspace /opt/jenkins/workspace/CI_IGT_test Set build name. New build name is 'drmtip_150/fi-hsw-4770/16' [CI_IGT_test] $ /bin/bash -xe /tmp/jenkins284263013698976.sh + set +x hsw-4770 4.20.0-rc4-ge556a1602bef-drmtip_150+ logdir drmtip_150/fi-hsw-4770 /opt/scripts/dut/deploy_igt.sh: drmtip_150 IGT_4730 Testlist: shards/x0016 Timestamp 1543386592 Initializing watchdogs /dev/watchdog0 [01/79] (1080s left) gem_ctx_isolation (vcs0-dirty-switch) Subtest vcs0-dirty-switch: SKIP [02/79] (1080s left) gem_exec_parse (cmd-crossing-page) Starting subtest: cmd-crossing-page Subtest cmd-crossing-page: SUCCESS (0.001s) [03/79] (1080s left) kms_frontbuffer_tracking (psr-2p-scndscrn-cur-indfb-move) Starting subtest: psr-2p-scndscrn-cur-indfb-move Subtest psr-2p-scndscrn-cur-indfb-move: SKIP (0.000s) [04/79] (1080s left) kms_chamelium (dp-crc-single) Subtest dp-crc-single: SKIP [05/79] (1080s left) syncobj_wait (wait-any-interrupted) Starting subtest: wait-any-interrupted Subtest wait-any-interrupted: SUCCESS (0.104s) [06/79] (1080s left) prime_busy (wait-hang-blt) Starting subtest: wait-hang-blt Subtest wait-hang-blt: SUCCESS (13.633s) [07/79] (1066s left) kms_frontbuffer_tracking (fbc-1p-primscrn-cur-indfb-draw-mmap-gtt) Starting subtest: fbc-1p-primscrn-cur-indfb-draw-mmap-gtt Subtest fbc-1p-primscrn-cur-indfb-draw-mmap-gtt: SUCCESS (1.351s) [08/79] (1064s left) kms_universal_plane (cursor-fb-leak-pipe-e) Subtest cursor-fb-leak-pipe-E: SKIP [09/79] (1064s left) gem_caching (writes) Starting subtest: writes Subtest writes: SUCCESS (1.942s) [10/79] (1062s left) kms_frontbuffer_tracking (fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt) Starting subtest: fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt Subtest fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt: SKIP (0.000s) [11/79] (1062s left) gem_bad_reloc (negative-reloc-lut-bsd) Starting subtest: negative-reloc-lut-bsd Subtest negative-reloc-lut-bsd: SUCCESS (0.000s) [12/79] (1062s left) kms_chamelium (hdmi-crc-xrgb) Subtest hdmi-crc-xrgb: SKIP [13/79] (1062s left) gem_set_tiling_vs_blt (tiled-to-untiled) Starting subtest: tiled-to-untiled Subtest tiled-to-untiled: SUCCESS (0.317s) [14/79] (1062s left) gem_ctx_isolation (bcs0-dirty-switch) Subtest bcs0-dirty-switch: SKIP [15/79] (1061s left) kms_flip (single-buffer-flip-vs-dpms-off-vs-modeset-interruptible) Starting subtest: single-buffer-flip-vs-dpms-off-vs-modeset-interruptible Subtest single-buffer-flip-vs-dpms-off-vs-modeset-interruptible: SUCCESS (2.058s) [16/79] (1059s left) kms_psr (cursor_mmap_cpu) Subtest cursor_mmap_cpu: SKIP [17/79] (1059s left) perf_pmu (other-init-3) Starting subtest: other-init-3 Subtest other-init-3: SUCCESS (0.000s) [18/79] (1059s left) gem_wait (await-default) Starting subtest: await-default Subtest await-default: SUCCESS (1.016s) [19/79] (1058s left) prime_vgem (wait-bsd2) Starting subtest: wait-bsd2 Subtest wait-bsd2: SKIP (0.000s) [20/79] (1058s left) gem_exec_schedule (wide-bsd1) Subtest wide-bsd1: SKIP [21/79] (1058s left) kms_plane_scaling
