search for: dotclock

...; > well we are just updating a RAM, the resolution just limits how > > > much data we are sending, the clock limits the speed on the > > > bus over to the RAM on the other side. > > > > IMO even in command mode mode->clock should probably be the actual > > dotclock used by the display. If there's another clock for the bus > > speed/etc. it should be stored somewhere else. > > Good point. For the DSI panels we have the field hs_rate > for the HS clock in struct mipi_dsi_device which is based > on exactly this reasoning. And that is what...

...h rate on the actual display is asymmetric because > well we are just updating a RAM, the resolution just limits how > much data we are sending, the clock limits the speed on the > bus over to the RAM on the other side. IMO even in command mode mode->clock should probably be the actual dotclock used by the display. If there's another clock for the bus speed/etc. it should be stored somewhere else. -- Ville Syrj?l? Intel

...is asymmetric because > > well we are just updating a RAM, the resolution just limits how > > much data we are sending, the clock limits the speed on the > > bus over to the RAM on the other side. > > IMO even in command mode mode->clock should probably be the actual > dotclock used by the display. If there's another clock for the bus > speed/etc. it should be stored somewhere else. Good point. For the DSI panels we have the field hs_rate for the HS clock in struct mipi_dsi_device which is based on exactly this reasoning. And that is what I actually use for settin...

...pdating a RAM, the resolution just limits how > > > > much data we are sending, the clock limits the speed on the > > > > bus over to the RAM on the other side. > > > > > > IMO even in command mode mode->clock should probably be the actual > > > dotclock used by the display. If there's another clock for the bus > > > speed/etc. it should be stored somewhere else. > > > > Good point. For the DSI panels we have the field hs_rate > > for the HS clock in struct mipi_dsi_device which is based > > on exactly this reas...

...ing 320x240 mode 16 The last number is the status of the mode, wich acording to "drm_modes.h" (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/drm/drm_modes.h?id=refs/tags/v3.16.3): MODE_CLOCK_LOW, /* clock required is too low */ I assume it means the dotclock, or pixel clock (6.000 MHz) is too low for the GPU? The thing is, on X i can use xrandr to set the same mode (or with the same clock, or any clock i tried): xrandr --newmode "320x240" 6 320 328 360 400 240 243 247 253 +HSync -VSync xrandr --addmode DVI-I-1 320x240 xrandr --output D...

...cription file > /home/luser/mail/.subscriptions: Operation not permitted > > .subscriptions doesn't exist either as a file or a directory in the named > directories. > > Is there a "filter" against dot-files being opened within the bowels of dovecot? You can disable dotclock altogether, but I don't think this is what you meant. You can use locking method "dotlock_try" rather than "dotlock" -- the former will ignore quota/permissions problems and plow on. (It still logs it.) You could also align luser's mail folder group with with luser'...

...um drm_mode_status ret; > > > > if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace) > > return MODE_NO_INTERLACE; > > > > max_clock = outp->dp.link_nr * outp->dp.link_bw; > > - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, > > - outp->dp.downstream_ports); > > - if (ds_clock) > > - max_clock = min(max_clock, ds_clock); > > - > > - clock = mode->clock * (connector->display_info.bpc * 3) / 10; > > - ret = nouveau_conn_mode_clock_valid(mode, min_cloc...

https://bugs.freedesktop.org/show_bug.cgi?id=40747 Summary: The new nouveau kernel module fails to use my monitor's native resolution Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

...ags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace) return MODE_NO_INTERLACE; + if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKING) + clock *= 2; + max_clock = outp->dp.link_nr * outp->dp.link_bw; ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, outp->dp.downstream_ports); @@ -245,9 +247,13 @@ nv50_dp_mode_valid(struct drm_connector *connector, max_clock = min(max_clock, ds_clock); clock = mode->clock * (connector->display_info.bpc * 3) / 10; - ret = nouveau_conn_mode_clock_valid(mode, min_clock,...

Just a backport of the two patches for v5.9 that you'll want to apply. The first one was Cc'd to stable, but I forgot to Cc the second one as well. Lyude Paul (2): drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid() drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid() drivers/gpu/drm/nouveau/nouveau_connector.c | 36 ++++++---------------

...-300MB mbox INBOXes on an ext3 filesystem formatted in 2005. I am very nervous about converting them to Maildir at this point. If I could get someone (or something) to the site and replace it with something much more suitable, I could have these people join the 21st Century. > You can disable dotclock altogether, but I don't think this is what you > meant. You can use locking method "dotlock_try" rather than "dotlock" > -- the former will ignore quota/permissions problems and plow on. > (It still logs it.) You could also align luser's mail folder group with...

I have an i810 chipset and am trying to set a custom mode. X is not taking that mode. Has anyone else run into this situation? How do I get X to take the mode on an i810 driver. Jerry

...o.bpc here as well. > enum drm_mode_status ret; > > if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace) > return MODE_NO_INTERLACE; > > max_clock = outp->dp.link_nr * outp->dp.link_bw; > - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, > - outp->dp.downstream_ports); > - if (ds_clock) > - max_clock = min(max_clock, ds_clock); > - > - clock = mode->clock * (connector->display_info.bpc * 3) / 10; > - ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock, > - &...

...gt; > > > > if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace) > > > return MODE_NO_INTERLACE; > > > > > > max_clock = outp->dp.link_nr * outp->dp.link_bw; > > > - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, > > > - outp->dp.downstream_ports); > > > - if (ds_clock) > > > - max_clock = min(max_clock, ds_clock); > > > - > > > - clock = mode->clock * (connector->display_info.bpc * 3) / 10; > > > - ret = nouveau_conn_m...

...lock, ds_clock, clock; + const u8 bpp = 18; /* 6 bpc */ enum drm_mode_status ret; if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace) return MODE_NO_INTERLACE; max_clock = outp->dp.link_nr * outp->dp.link_bw; - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, - outp->dp.downstream_ports); - if (ds_clock) - max_clock = min(max_clock, ds_clock); - - clock = mode->clock * (connector->display_info.bpc * 3) / 10; - ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock, - &clock); + clock = mode->cloc...

...1051,14 @@ static enum drm_mode_status nv50_mstc_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) { - return MODE_OK; + struct nv50_mstc *mstc = nv50_mstc(connector); + struct nouveau_encoder *outp = mstc->mstm->outp; + + /* TODO: calculate the PBN from the dotclock and validate against the + * MSTB's max possible PBN + */ + + return nv50_dp_mode_valid(connector, outp, mode, NULL); } static int diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 97a84daf8eab..3a3e1533d3e7 100644 --- a/drivers/g...

...1080 1084 1089 1125 vborder 0 +hsync +vsync Detailed mode: Clock 74.250 MHz, 1085 mm x 610 mm 1280 1390 1430 1650 hborder 0 720 725 730 750 vborder 0 +hsync +vsync Monitor name: SONY Monitor ranges (GTF): 48-62Hz V, 14-70kHz H, max dotclock 300MHz Has 1 extension blocks Checksum: 0x7f (valid) CEA extension block Extension version: 3 73 bytes of CEA data Video data block VIC 93 3840x2160 at 24Hz VIC 94 3840x2160 at 25Hz VIC 95 3840x2160 at 30Hz VIC 98 4096x2160 at 24Hz VIC 31 1920x1080 at 50Hz VIC...

Now that we've added the hooks that we've needed for this and used them in i915, let's add one more hook (which I could use some feedback on, I'm not sure if it's worth maybe just reworking how we do mode pruning in nouveau instead...) and start using this in our mst ->mode_valid callback to filter out impossible to set modes on MST connectors. Lyude Paul (2):

...t more information to debug for flip timing checks igt/gem_mmap_gtt: Document the "expected" behaviour igt/kms_setmode: Clear all connectors before starting the test igt/kms_flip: Calibrate timestamp errors igt/kms_setmode: Test that the vblank interval matches the dotclock igt: drop gem_storedw_loop from BAT intel-ci: CI is missing any wait tests in BAT igt/gem_ctx_create: Exercise allocating as many contexts as we can igt/kms_flip: Mark frame_time() as coming from the mode igt/kms_flip: Use the computed vblank interval for TS checking...

On 05/04/2017 04:00 AM, Pierre Moreau wrote: > Hello, > > Acceleration for Pascal cards is coming in Linux 4.12, support for Pascal cards > in xorg-video-nouveau is in 1.0.15, and if I remember correctly, on the > Mesa-side, you will need >=17.0. Thanks - I suspected it was too new. I'm finding the monitor capabilities miss identified even if I use an older card - I'm