All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
To: gpu-public-documentation
	<gpu-public-documentation-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: PROM vbios fetching issues
Date: Mon, 24 Mar 2014 19:59:46 +0100	[thread overview]
Message-ID: <533080A2.6020501@free.fr> (raw)

Hello,

One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM 
at boot time but, if I blacklist the module and load it myself later on, 
it always succeeds. To make things weirder, the same card works great on 
another computer.

Here is the relevant code in Nouveau to fetch the vbios from PROM:
http://code.woboq.org/linux/linux/drivers/gpu/drm/nouveau/core/subdev/bios/base.c.html#nouveau_bios_shadow_prom

The only solution I found to this problem is to try up to 16 times in a 
row to fetch the vbios using PROM. If the 16 tries yield a bad signature 
or checksum, I just give up and let it try other techniques. Here is the 
patch[1].

With this hack in place, the number of retries needed to be able to 
correctly fetch the vbios ranges from 0 to 13. I see no consistency in 
this. I tried reading the vbios 32 bits by 32 bits (instead of 8 by 8), 
disabling local IRQs and generating more activity on the PCIe port 
before fetching (and making sure the value read is always the same), all 
solutions yielded no improvement.

It could be a brownout problem but this would be the only manifestation 
of this problem. Moreover, some cards are known to have problems with
PROM[2] so mine is definitely not the only one.

I'm at a loss here, should we wait on anything before reading from PROM? 
The mmiotrace I have doesn't seem to suggest we should :s I wonder if 
you have had this issue before and what the nvkm does here.

Thanks,
Martin

[1] http://lists.freedesktop.org/archives/nouveau/2014-March/016590.html
[2] 
http://code.woboq.org/linux/linux/drivers/gpu/drm/nouveau/core/subdev/bios/base.c.html#144

             reply	other threads:[~2014-03-24 18:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24 18:59 Martin Peres [this message]
     [not found] ` <533080A2.6020501-GANU6spQydw@public.gmane.org>
2014-03-25 16:17   ` PROM vbios fetching issues Christian Zander
     [not found]     ` <20140325161720.GB8282-JA3VlGzg3tsMOYszX5p1ytBPR1lH4CV8@public.gmane.org>
2014-03-25 22:33       ` Martin Peres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533080A2.6020501@free.fr \
    --to=martin.peres-ganu6spqydw@public.gmane.org \
    --cc=gpu-public-documentation-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.