search for: pclk

some chipset have working engine reclocking, but broken memory reclocking like Fermi. We should for now, add the functionality to allow partly reclocking for those. Allthough this doesn't give as much performance as one might wish, it is till noticeable and may improve performance enough to be noted. Karol Herbst (2): clk: seperate engine and memory reclock toggles clk: allow engine

...roto = 0x2; } diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c b/drm/nouveau/nvkm/engine/disp/gf119.c index 186fd3a..8691b68 100644 --- a/drm/nouveau/nvkm/engine/disp/gf119.c +++ b/drm/nouveau/nvkm/engine/disp/gf119.c @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 pclk, u32 *conf) switch (outp->info.type) { case DCB_OUTPUT_TMDS: *conf = (ctrl & 0x00000f00) >> 8; - if (pclk >= 165000) + if (pclk >= 165000 && outp->info.duallink_possible) *conf |= 0x0100; break; case DCB_OUTPUT_LVDS: diff --git a/drm/nouveau/nvkm/engi...

I originally set up this monitor with an analogue lead. Everything seemed fine, so I didn't check xorg.conf at all. Then I bought a digital lead, and since then the monitor blinks. Running system-config-display identifies it as a 1280 x 1084 CRT monitor. It is an LCD monitor. That model is not on the drop-down list, so assuming that a specific driver wasn't available for it, I

...uveau/nvkm/engine/disp/gf119.c b/drm/nouveau/nvkm/engine/disp/gf119.c >> index 186fd3a..8691b68 100644 >> --- a/drm/nouveau/nvkm/engine/disp/gf119.c >> +++ b/drm/nouveau/nvkm/engine/disp/gf119.c >> @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 pclk, u32 *conf) >> switch (outp->info.type) { >> case DCB_OUTPUT_TMDS: >> *conf = (ctrl & 0x00000f00) >> 8; >> - if (pclk >= 165000) >> + if (pclk >= 165000 && outp->info.duallink_possible) &gt...

> > > For security, I will release this pointer only on error paths in this function. > > Do you tend to release objects (which are referenced by pointers)? > I just found that clk is referenced by pclk in this function. When clk is freed, pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not release clk in this function and there is no bug here. Thank you for reminding me! Regards, Dinghao

...f --git a/drm/nouveau/nvkm/engine/disp/gf119.c b/drm/nouveau/nvkm/engine/disp/gf119.c > index 186fd3a..8691b68 100644 > --- a/drm/nouveau/nvkm/engine/disp/gf119.c > +++ b/drm/nouveau/nvkm/engine/disp/gf119.c > @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 pclk, u32 *conf) > switch (outp->info.type) { > case DCB_OUTPUT_TMDS: > *conf = (ctrl & 0x00000f00) >> 8; > - if (pclk >= 165000) > + if (pclk >= 165000 && outp->info.duallink_possible) > *conf |= 0x0100; I think it might be more robust to key...

These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 1920x1200 at 60. This still needs testing on other graphics cards and with dual link DVI. There is no

.../gm20b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c index b284e949f732..a5aeba74d3b7 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c @@ -1039,7 +1039,7 @@ gm20b_clk_new(struct nvkm_device *device, int index, struct nvkm_clk **pclk) ret = gk20a_clk_ctor(device, index, &gm20b_clk, clk_params, &clk->base); if (ret) - return ret; + goto out_free; /* * NAPLL can only work with max_u, clamp the m range so @@ -1067,8 +1067,8 @@ gm20b_clk_new(struct nvkm_device *device, int index, struct nvkm_clk **p...

> > I just found that clk is referenced by pclk in this function. When clk is freed, > > pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not release clk > > in this function and there is no bug here. > > Can there be a need to release a clock object after a failed gk20a_clk_ctor() call? > I think this ma...

Although memory reclocking seems to be completely broken on my GF119, we can at least allow users to enable reclocking for the core clock. Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> --- drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c b/drm/nouveau/nvkm/subdev/fb/ramgf100.c

These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 1920x1200 at 60. This still needs testing on other graphics cards and with dual link DVI. There is no

...re/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index 8b42f45..7ffe2f3 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c @@ -1107,6 +1107,7 @@ nv50_disp_intr_unk20_2(struct nv50_disp_priv *priv, int head) u32 pclk = nv_rd32(priv, 0x610ad0 + (head * 0x540)) & 0x3fffff; u32 hval, hreg = 0x614200 + (head * 0x800); u32 oval, oreg; + u32 mask; u32 conf = exec_clkcmp(priv, head, 0xff, pclk, &outp); if (conf != ~0) { if (outp.location == 0 && outp.type == DCB_OUTPUT_DP) { @@ -1133,6 +1134...

...roto = 0x2; } diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c b/drm/nouveau/nvkm/engine/disp/gf119.c index 186fd3a..f031466 100644 --- a/drm/nouveau/nvkm/engine/disp/gf119.c +++ b/drm/nouveau/nvkm/engine/disp/gf119.c @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 pclk, u32 *conf) switch (outp->info.type) { case DCB_OUTPUT_TMDS: *conf = (ctrl & 0x00000f00) >> 8; - if (pclk >= 165000) + if (*conf == 5) *conf |= 0x0100; break; case DCB_OUTPUT_LVDS: diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c b/drm/nouveau/nvkm/engine/disp/nv50...

...roto = 0x2; } diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c b/drm/nouveau/nvkm/engine/disp/gf119.c index 186fd3a..f031466 100644 --- a/drm/nouveau/nvkm/engine/disp/gf119.c +++ b/drm/nouveau/nvkm/engine/disp/gf119.c @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 pclk, u32 *conf) switch (outp->info.type) { case DCB_OUTPUT_TMDS: *conf = (ctrl & 0x00000f00) >> 8; - if (pclk >= 165000) + if (*conf == 5) *conf |= 0x0100; break; case DCB_OUTPUT_LVDS: diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c b/drm/nouveau/nvkm/engine/disp/nv50...

...#39;t be necessary. If a subdev constructor fails, and > returns a pointer, the core will call the destructor to clean things > up. > I'm not familiar with the behavior of the caller of gm20b_clk_new(). If the subdev constructor fails, the core will check the pointer (here is "pclk"), then it's ok and there is no bug (Do you mean this?). If the core executes error handling code only according to the error code, there may be a memory leak bug (the caller cannot know if -ENOMEM comes from the failure of kzalloc or gk20a_clk_ctor). If the core always calls the destr...

...ddr + 0x00, 0x00000010, 0x00000010); + if (bypass_state) + nvkm_mask(device, addr + 0x00, 0x00000010, 0x00000010); /* Enable sync mode */ nvkm_mask(device, addr + 0x00, 0x00000004, 0x00000004); @@ -476,5 +479,5 @@ gf100_clk_new(struct nvkm_device *device, int index, struct nvkm_clk **pclk) return -ENOMEM; *pclk = &clk->base; - return nvkm_clk_ctor(&gf100_clk, device, index, false, &clk->base); + return nvkm_clk_ctor(&gf100_clk, device, index, true, &clk->base); } diff --git a/drm/nouveau/nvkm/subdev/clk/gk104.c b/drm/nouveau/nvkm/subdev/clk/gk104...

...ion(-) diff --git a/drm/nouveau/nvkm/subdev/clk/gf100.c b/drm/nouveau/nvkm/subdev/clk/gf100.c index ad93350..2ce902f 100644 --- a/drm/nouveau/nvkm/subdev/clk/gf100.c +++ b/drm/nouveau/nvkm/subdev/clk/gf100.c @@ -535,6 +535,6 @@ gf100_clk_new(struct nvkm_device *device, int index, struct nvkm_clk **pclk) return -ENOMEM; *pclk = &clk->base; - return nvkm_clk_ctor(&gf100_clk, device, index, false, false, + return nvkm_clk_ctor(&gf100_clk, device, index, true, false, &clk->base); } -- 2.7.0

...pu/drm/mcde/mcde_dsi.c > index bb6528b01cd0..6dca5344c0b3 100644 > --- a/drivers/gpu/drm/mcde/mcde_dsi.c > +++ b/drivers/gpu/drm/mcde/mcde_dsi.c > @@ -538,7 +538,7 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d, > */ > /* (ps/s) / (pixels/s) = ps/pixels */ > pclk = DIV_ROUND_UP_ULL(1000000000000, > - (mode->vrefresh * mode->htotal * mode->vtotal)); > + (drm_mode_vrefresh(mode) * mode->htotal * mode->vtotal)); > dev_dbg(d->dev, "picoseconds between two pixels: %llu\n", > pclk); > This just caught my ey...

> I just found that clk is referenced by pclk in this function. When clk is freed, > pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not release clk > in this function and there is no bug here. Can there be a need to release a clock object after a failed gk20a_clk_ctor() call? Regards, Markus

...pu/drm/nouveau/nvkm/subdev/clk/gm20b.c > index b284e949f732..a5aeba74d3b7 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c > @@ -1039,7 +1039,7 @@ gm20b_clk_new(struct nvkm_device *device, int index, struct nvkm_clk **pclk) > ret = gk20a_clk_ctor(device, index, &gm20b_clk, clk_params, > &clk->base); > if (ret) > - return ret; > + goto out_free; > > /* > * NAPLL can only work with max_u, clamp t...