From: Ben Skeggs <skeggsb@gmail.com>
To: Pierre Moreau <pierre.morrow@free.fr>,
nouveau@lists.freedesktop.org, bskeggs@redhat.com
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3] pci: Handle 5-bit and 8-bit tag field
Date: Wed, 30 Sep 2015 07:01:06 +1000 [thread overview]
Message-ID: <560AFC12.5050800@gmail.com> (raw)
In-Reply-To: <1442435210-21276-1-git-send-email-pierre.morrow@free.fr>
On 09/17/2015 06:26 AM, Pierre Moreau wrote:
> If the hardware supports extended tag field (8-bit ones), then
> enabled it. This is usually done by the VBIOS, but not on some MBPs
> (see fdo#86537). In case extended tag field is not supported, 5-bit
> tag field is used which limits the possible values to 32.
> Apparently bits 7:0 of 0x8841c stores some number of outstanding
> requests, so cap it to 32 if extended tag is unsupported.
>
> Fixes: fdo#86537
>
> v2: Restrict changes to chipsets >= 0x84 v3: * Add nvkm_pci_mask to
> pci.h * Mask bit 8 before setting it
>
> Signed-off-by: Pierre Moreau <pierre.morrow@free.fr> ---
> drm/nouveau/include/nvkm/subdev/pci.h | 1 +
> drm/nouveau/nvkm/subdev/pci/base.c | 25
> +++++++++++++++++++++++++ 2 files changed, 26 insertions(+)
>
> diff --git a/drm/nouveau/include/nvkm/subdev/pci.h
> b/drm/nouveau/include/nvkm/subdev/pci.h index 5b3c054..774ca66
> 100644 --- a/drm/nouveau/include/nvkm/subdev/pci.h +++
> b/drm/nouveau/include/nvkm/subdev/pci.h @@ -24,6 +24,7 @@ struct
> nvkm_pci { u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr); void
> nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data); void
> nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data); +u32
> nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 add); void
> nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
>
> int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
> diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
> b/drm/nouveau/nvkm/subdev/pci/base.c index d1c148e..cb2835b 100644
> --- a/drm/nouveau/nvkm/subdev/pci/base.c +++
> b/drm/nouveau/nvkm/subdev/pci/base.c @@ -46,6 +46,14 @@
> nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
> pci->func->wr32(pci, addr, data); }
>
> +u32 +nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32
> add) +{ + u32 data = pci->func->rd32(pci, addr); +
> pci->func->wr32(pci, addr, (data & ~mask) | add); + return data;
> +} + void nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow) {
> @@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev) if
> (ret) return ret;
>
> + if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) { + /*
> Tag field is 8-bit long, regardless of EXT_TAG. + * However, if
> EXT_TAG is disabled, only the lower 5 bits of the tag + * field
> should be used, limiting the number of request to 32. + * + *
> Apparently, 0x041c stores some limit on the number of requests +
> * possible, so if EXT_TAG is disabled, limit that requests number
> to + * 32 + * + * Fixes fdo#86537 + */ + if
> (nvkm_pci_rd32(pci, 0x007c) & 0x00000020) + nvkm_pci_mask(pci,
> 0x0080, 0x00000100, 0x00000100); + else + nvkm_pci_mask(pci,
> 0x041c, 0x00000060, 0x00000000); + }
Please introduce a .init() to nvkm_pci_func(), and implement a g84.c
that handles this (gf100.c can use g84_pci_init() from there).
The check for PCI-E is redundant too, all these boards are PCI-E.
Other than the above nit-picking, looks fine.
Thanks,
Ben.
> + pci->irq = pdev->irq; return ret; }
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2015-09-29 21:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-16 20:26 [PATCH v3] pci: Handle 5-bit and 8-bit tag field Pierre Moreau
[not found] ` <1442435210-21276-1-git-send-email-pierre.morrow-GANU6spQydw@public.gmane.org>
2015-09-26 8:42 ` Pierre Moreau
2015-09-29 21:01 ` Ben Skeggs [this message]
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=560AFC12.5050800@gmail.com \
--to=skeggsb@gmail.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=nouveau@lists.freedesktop.org \
--cc=pierre.morrow@free.fr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox