[Nouveau] (no subject)
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.gh13...@intel.com> References: <20200219203544.31013-1-ville.syrj...@linux.intel.com> <20200219203544.31013-5-ville.syrj...@linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.com> <20200225112114.ga13...@intel.com> <3ca785f2-9032-aaf9-0965-8657d3111...@samsung.com> <20200225154506.gf13...@intel.com> <20200225192720.gg13...@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä > wrote: > > > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples. > > That's impressive :D > > > Unfortunately it found a lot of strange stuff: > > I will answer for the weirdness I caused. > > I have long suspected that a whole bunch of the "simple" displays > are not simple but contains a display controller and memory. > That means that the speed over the link to the display and > actual refresh 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 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä wrote: > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > I have long suspected that a whole bunch of the "simple" displays > > are not simple but contains a display controller and memory. > > That means that the speed over the link to the display and > > actual refresh 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. 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 setting the HS clock. The problem is however that we in many cases have so substandard documentation of these panels that we have absolutely no idea about the dotclock. Maybe we should just set it to 0 in these cases? Yours, Linus Walleij ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä > wrote: > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > I have long suspected that a whole bunch of the "simple" displays > > > are not simple but contains a display controller and memory. > > > That means that the speed over the link to the display and > > > actual refresh 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. > > 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 > setting the HS clock. > > The problem is however that we in many cases have so > substandard documentation of these panels that we have > absolutely no idea about the dotclock. Maybe we should > just set it to 0 in these cases? Don't you always have a TE interrupt or something like that available? Could just measure it from that if no better information is available? -- Ville Syrjälä Intel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
wrote:
> On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > wrote:
> > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> >
> > > > I have long suspected that a whole bunch of the "simple" displays
> > > > are not simple but contains a display controller and memory.
> > > > That means that the speed over the link to the display and
> > > > actual refresh 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.
> >
> > 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
> > setting the HS clock.
> >
> > The problem is however that we in many cases have so
> > substandard documentation of these panels that we have
> > absolutely no idea about the dotclock. Maybe we should
> > just set it to 0 in these cases?
>
> Don't you always have a TE interrupt or something like that
> available? Could just measure it from that if no better
> information is available?
Yes and I did exactly that, so that is why this comment is in
the driver:
static const struct drm_display_mode sony_acx424akp_cmd_mode = {
(...)
/*
* Some desired refresh rate, experiments at the maximum "pixel"
* clock speed (HS clock 420 MHz) yields around 117Hz.
*/
.vrefresh = 60,
I got a review comment at the time saying 117 Hz was weird.
We didn't reach a proper conclusion on this:
https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=l...@mail.gmail.com/
Thierry wasn't sure if 60Hz was good or not, so I just had to
go with something.
We could calculate the resulting pixel clock for ~117 Hz with
this resolution and put that in the clock field but ... don't know
what is the best?
Yours,
Linus Walleij
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
> wrote:
> > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > > wrote:
> > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> > >
> > > > > I have long suspected that a whole bunch of the "simple" displays
> > > > > are not simple but contains a display controller and memory.
> > > > > That means that the speed over the link to the display and
> > > > > actual refresh 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.
> > >
> > > 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
> > > setting the HS clock.
> > >
> > > The problem is however that we in many cases have so
> > > substandard documentation of these panels that we have
> > > absolutely no idea about the dotclock. Maybe we should
> > > just set it to 0 in these cases?
> >
> > Don't you always have a TE interrupt or something like that
> > available? Could just measure it from that if no better
> > information is available?
>
> Yes and I did exactly that, so that is why this comment is in
> the driver:
>
> static const struct drm_display_mode sony_acx424akp_cmd_mode = {
> (...)
> /*
> * Some desired refresh rate, experiments at the maximum "pixel"
> * clock speed (HS clock 420 MHz) yields around 117Hz.
> */
> .vrefresh = 60,
>
> I got a review comment at the time saying 117 Hz was weird.
> We didn't reach a proper conclusion on this:
> https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=l...@mail.gmail.com/
>
> Thierry wasn't sure if 60Hz was good or not, so I just had to
> go with something.
>
> We could calculate the resulting pixel clock for ~117 Hz with
> this resolution and put that in the clock field but ... don't know
> what is the best?
I would vote for that approach.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
On 13/09/2014 17:32, Ilia Mirkin wrote: What problem are you trying to solve? Perhaps you can start by describing the symptoms, providing logs, etc? Ilia, That's the third time he contacts us to fix "bugs" without giving any details. He then refuses to answer back. He is either a troll or desperately trying to push patches with his name on it. In any case, this patch is utterly wrong as the ifs are not even conditions, they are assignments. Asd, please stop wasting our time and try trolling somewhere else. If you are not a troll, then answer us before sending another patch! Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (no subject)
What problem are you trying to solve? Perhaps you can start by describing the symptoms, providing logs, etc? On Sat, Sep 13, 2014 at 11:24 AM, asd wrote: > Hi > On NV_40 on driver is sent instructions from NVE0 series > not right > I inspected register 9012c with nvtools > and appear instructions to start unneeded engines > NVE0_CHANNEL_IND_ENGINE_PPP > NVE0_CHANNEL_IND_ENGINE_BSP > NVE0_CHANNEL_IND_ENGINE_ENC > > I put one barrier but not start dri. > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] (no subject)
___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] (no subject)
Hi
On NV_40 on driver is sent instructions from NVE0 series
not right
I inspected register 9012c with nvtools
and appear instructions to start unneeded engines
NVE0_CHANNEL_IND_ENGINE_PPP
NVE0_CHANNEL_IND_ENGINE_BSP
NVE0_CHANNEL_IND_ENGINE_ENC
I put one barrier but not start dri.
Index: master_local/drivers/gpu/drm/nouveau/nouveau_abi16.c
===
--- master_local.orig/drivers/gpu/drm/nouveau/nouveau_abi16.c 2014-08-01 00:51:43.0 +0300
+++ master_local/drivers/gpu/drm/nouveau/nouveau_abi16.c 2014-09-13 17:16:19.881489054 +0300
@@ -252,7 +252,12 @@
device = nv_device(abi16->device);
imem = nouveau_instmem(device);
pfb= nouveau_fb(device);
-
+ printk(KERN_INFO "fb_ctxdma_handle %x\n", init->fb_ctxdma_handle);
+ printk(KERN_INFO "tt_ctxdma_handle %x\n", init->tt_ctxdma_handle);
+ printk(KERN_INFO "channel %x\n", init->channel);
+ printk(KERN_INFO "pushbuf_domains %x\n", init->pushbuf_domains);
+ printk(KERN_INFO "notifier_handle %x\n", init->notifier_handle);
+ printk(KERN_INFO "nr_subchan %x\n", init->nr_subchan);
/* hack to allow channel engine type specification on kepler */
if (device->card_type >= NV_E0) {
if (init->fb_ctxdma_handle != ~0)
@@ -265,6 +270,18 @@
if (init->fb_ctxdma_handle == NVE0_CHANNEL_IND_ENGINE_GR)
init->tt_ctxdma_handle = 1;
}
+
+ if (device->card_type < NV_50) {
+ if (init->fb_ctxdma_handle = 0x0008)
+ return nouveau_abi16_put(abi16, -EINVAL);
+
+ if (init->fb_ctxdma_handle = 0x0004)
+ return nouveau_abi16_put(abi16, -EINVAL);
+
+ if (init->fb_ctxdma_handle = 0x0040)
+ return nouveau_abi16_put(abi16, -EINVAL);
+ }
+
if (init->fb_ctxdma_handle == ~0 || init->tt_ctxdma_handle == ~0)
return nouveau_abi16_put(abi16, -EINVAL);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] (no subject)
Hi, This is my work in documenting EVO. I did some RE to fill missing gaps. Best regards, Maxim Levitsky ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] (no subject)
Sorry, forgot to add nouveau_pms.h ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] (no subject)
I have noticed when I install Google earth, since nouveau got involved in Ubuntu, the embedded pictures have not opened. Two different machines both Nvidia. From what I have found on the Internet, there seems to be a few of us out there. Please help... I am trying to be a loyal Ubuntoian. Both machines do have windows also... to use. Rod ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
