search for: 297mhz

On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: > v2: clean up left over comments > don't overwrite hdmimhz parameter > cap to 297MHz > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/dispnv50/disp.c | 5 +++++ > drm/nouveau/nouveau_connector.c | 15 ++++++++++----- > drm/nouveau/nouveau_encoder.h | 4 ++++ > 3 files changed, 19 insertions(+), 5 deletions(-) > >...

Hello, Various HDMI versions enable higher and higher pixel clocks. However individual GPUs are not required to support the maximum pixel clock supported by the spec in order to be compliant. It appears that some GPUs max out at 225MHz while others at 297MHz (while others still, I assume, are limited to 165MHz, esp among the older ones). We've been unable to find this in the VBIOS (I had a thought that it was in the table pointed to by the 'T' table, but we have a counterexample to that). Could you suggest a way to find this information ei...

...resampled to 16K and written out as .WAV files by NCH's Switch software. (It's hard to get good wideband audio samples...) For decode, I run the command "time speexdec sample.spx", and then take sum of the "user" and "sys" times the speed of the processor (297MHz), and divide it by the "real" (or clock) time. That should give me the average processing power requirements. (And the number is matched by the results of "top".) For encode, I run the command "time speexenc sample.wav - > /dev/null". Since it consumes 99% of th...

On Fri, Aug 3, 2018 at 4:08 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: >> v2: clean up left over comments >> don't overwrite hdmimhz parameter >> cap to 297MHz >> >> Signed-off-by: Karol Herbst <kherbst at redhat.com> >> --- >> drm/nouveau/dispnv50/disp.c | 5 +++++ >> drm/nouveau/nouveau_connector.c | 15 ++++++++++----- >> drm/nouveau/nouveau_encoder.h | 4 ++++ >> 3 files changed, 19 insertions(+...

v2: clean up left over comments don't overwrite hdmimhz parameter cap to 297MHz Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/dispnv50/disp.c | 5 +++++ drm/nouveau/nouveau_connector.c | 15 ++++++++++----- drm/nouveau/nouveau_encoder.h | 4 ++++ 3 files changed, 19 insertions(+), 5 deletions(-) diff --git a/drm/nouveau/dispnv50/disp.c b/...

...or = nouveau_connector(connector); > + struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder; > struct nouveau_drm *drm = nouveau_drm(connector->dev); > struct dcb_output *dcb = nv_connector->detected_encoder->dcb; > > + /* cap to 297MHz until we figure out HDMI 2.0 */ > + if (nv_encoder->tmds.max_mhz) > + return nv_encoder->tmds.max_mhz * 1000; > + > if (hdmi) { > if (nouveau_hdmimhz > 0) > return nouveau_hdmimhz * 1000; > diff --git...

small update to my last version I sent out. Patches 3-6 are optional and should only improve detecting the max clocks for HDMI and DP, but they didn't underwent big testing and I am a bit concerned, that it might break detecting the DP limits on some boards. Karol Herbst (6): kms/nv50: move nv50_mstm out of the dp union in nouveau_encoder kms/nv50: reject interlaced modes if the hardware

https://bugs.freedesktop.org/show_bug.cgi?id=91236 Bug ID: 91236 Summary: [NVC3] Passive DP to HDMI adapter cannot use pixel clocks greater than 165 MHz Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

...hdmi) { struct nouveau_connector *nv_connector = nouveau_connector(connector); + struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder; struct nouveau_drm *drm = nouveau_drm(connector->dev); struct dcb_output *dcb = nv_connector->detected_encoder->dcb; + /* cap to 297MHz until we figure out HDMI 2.0 */ + if (nv_encoder->tmds.max_mhz) + return nv_encoder->tmds.max_mhz * 1000; + if (hdmi) { if (nouveau_hdmimhz > 0) return nouveau_hdmimhz * 1000; diff --git a/drm/nouveau/nouveau_encoder.h b/drm/nouveau/nouveau_encoder.h index f74af5ce..fbef9dc0 1006...

...00 drm/nouveau/disp: take sink support into account for exposing 594mhz which went into v4.20, but it could also have been commit 1a0c96c075bb4517d4ce4fb6750ee0a3cf38714c Author: Ilia Mirkin <imirkin at alum.mit.edu> Date: Tue Nov 3 21:00:11 2015 -0500 drm/nouveau/kms: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler which went into v4.5 and lines up with your timeline better, but seems like it shouldn't be handing out those high frequencies to HDMI connectors on tesla... Cheers, -ilia

On 05/06/2017 12:38 PM, Ilia Mirkin wrote: > The information comes from the EDID blob supplied by the monitor. > Presumably hwinfo has a primitive EDID parser, which is where that > information comes from. A more complete EDID parser is available at > > https://cgit.freedesktop.org/xorg/app/edid-decode/ > > For example, > > $ ./src/edid-decode/edid-decode

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>

Video and input drivers Subgroups and projects on gitlab does not list modesetting DDX, presumably because it's not packaged separately from the server. Where's the right place to report a modesetting DDX bug that manifests only on an NVidia GPU? Directly against the server https://gitlab.freedesktop.org/xorg/xserver? Here are some particulars: How can I tell whether this should be

This is mainly for dropping interlaced modes on DP connectors if the GPU would otherwise display garbage or EVO timesout. It also adds experimental detection of the HDMI clock limit we currently hard limit depending on the GPU generation. Starting with GF110 GPUs, we can retrieve the limit directly from the GPU and may make the hdmimhz parameter obsolete. Testing this series with 2560x1440 or

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actual possible. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de> Signed-off-by: Ilia

...013] [drm] nouveau 0000:02:00.0: 2: core 400MHz shader 800MHz memory 300MHz voltage 1050mV fanspeed 100% [ 2.965015] [drm] nouveau 0000:02:00.0: 3: core 602MHz shader 1204MHz memory 800MHz voltage 1180mV fanspeed 100% [ 2.965017] [drm] nouveau 0000:02:00.0: c: core 399MHz shader 810MHz memory 297MHz voltage 1180mV [ 3.010759] [drm] nouveau 0000:02:00.0: MM: using CRYPT for buffer copies [ 3.084261] [drm] nouveau 0000:02:00.0: allocated 1600x1200 fb: 0x2c0000, bo ffff880134e45000 [ 3.103452] drm: registered panic notifier [ 3.103457] [drm] Initialized nouveau 1.0.0 20120316 for 0000...

https://bugs.freedesktop.org/show_bug.cgi?id=93405 Bug ID: 93405 Summary: nouveau: Xorg crashes sooner or later in 3840x2160 mode Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: