dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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