[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #7 from Marcus Moeller marcus.moel...@gmx.ch --- Shouln't this be fixed in nouveau instead of moving to another driver? Or is this just a suggestion for a workaround? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #8 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to Marcus Moeller from comment #7) Shouln't this be fixed in nouveau instead of moving to another driver? Or is this just a suggestion for a workaround? The fix in nouveau will be remove glamor integration and fail to load for GM107+. But we haven't fully decided on that *quite* yet. And I have an EXA impl in the works for GM107, so perhaps we'll use that. TBD. The problem that you're seeing is with glamor, and they changed the way font rendering was done in X 1.17, which is why I'm suggesting you use that. Separate from that, nouveau's integration with glamor is totally fubar'd and should be removed, as per the above, but that has nothing to do with any misrendering you might see. For example perhaps you might observe the lack of a GLX_ARB_create_context_profile. This is a symptom of DRI2 support basically missing, which is going to cause major problems. Since nouveau's integration with glamor would be no different from modesetting's integration with glamor, might as well just use that directly... [There are one or two things nouveau can still do that modesetting can't, but those differences are in the process of being eliminated.] -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 poma pomidorabelis...@gmail.com changed: What|Removed |Added Attachment #116671|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #5 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to Marcus Moeller from comment #3) It still appears in Kernel 4.1 final. Updating Xorg to 1.17 and switching to the modesetting X ddx (instead of the nouveau X ddx) should fix this. The reason you're seeing this in 4.1 and not 4.0 is that 4.1 finally has acceleration enabled by default for GM107. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #6 from poma pomidorabelis...@gmail.com --- /etc/X11/xorg.conf.d/00-modesetting.conf Section Device Identifier video0 Driver modesetting EndSection -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #3 from Marcus Moeller marcus.moel...@gmx.ch --- It still appears in Kernel 4.1 final. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #4 from Marcus Moeller marcus.moel...@gmx.ch --- Created attachment 116671 -- https://bugs.freedesktop.org/attachment.cgi?id=116671action=edit Screencast showing the behavior -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 6/6] platform: recognize GM20B
Allow the platform driver to recognize GM20B.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drm/nouveau/nouveau_platform.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c
index dcfbbfaf1739..7a39d449fefa 100644
--- a/drm/nouveau/nouveau_platform.c
+++ b/drm/nouveau/nouveau_platform.c
@@ -252,6 +252,7 @@ static int nouveau_platform_remove(struct platform_device
*pdev)
#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id nouveau_platform_match[] = {
{ .compatible = nvidia,gk20a },
+ { .compatible = nvidia,gm20b },
{ }
};
--
2.4.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 5/6] device: recognize GM20B
Recognize GM20B and assign the right engines and subdevs. Signed-off-by: Alexandre Courbot acour...@nvidia.com --- drm/nouveau/nvkm/engine/device/gm100.c | 20 1 file changed, 20 insertions(+) diff --git a/drm/nouveau/nvkm/engine/device/gm100.c b/drm/nouveau/nvkm/engine/device/gm100.c index 70abf1ec7c98..a51b3ce50f36 100644 --- a/drm/nouveau/nvkm/engine/device/gm100.c +++ b/drm/nouveau/nvkm/engine/device/gm100.c @@ -181,6 +181,26 @@ gm100_identify(struct nvkm_device *device) device-oclass[NVDEV_ENGINE_MSPPP ] = gf100_msppp_oclass; #endif break; + case 0x12b: + device-cname = GM20B; + + device-oclass[NVDEV_SUBDEV_MC ] = gk20a_mc_oclass; + device-oclass[NVDEV_SUBDEV_MMU] = gf100_mmu_oclass; + device-oclass[NVDEV_SUBDEV_BUS] = gf100_bus_oclass; + device-oclass[NVDEV_SUBDEV_FUSE ] = gm107_fuse_oclass; + device-oclass[NVDEV_SUBDEV_TIMER ] = gk20a_timer_oclass; + device-oclass[NVDEV_SUBDEV_FB ] = gk20a_fb_oclass; + device-oclass[NVDEV_SUBDEV_LTC] = gm107_ltc_oclass; + device-oclass[NVDEV_SUBDEV_IBUS ] = gk20a_ibus_oclass; + device-oclass[NVDEV_SUBDEV_INSTMEM] = gk20a_instmem_oclass; + device-oclass[NVDEV_SUBDEV_MMU] = gf100_mmu_oclass; + device-oclass[NVDEV_SUBDEV_BAR] = gk20a_bar_oclass; + device-oclass[NVDEV_ENGINE_DMAOBJ ] = gf110_dmaeng_oclass; + device-oclass[NVDEV_ENGINE_FIFO ] = gm20b_fifo_oclass; + device-oclass[NVDEV_ENGINE_SW ] = gf100_sw_oclass; + device-oclass[NVDEV_ENGINE_GR ] = gm20b_gr_oclass; + device-oclass[NVDEV_ENGINE_CE2] = gm204_ce2_oclass; + break; default: nv_fatal(device, unknown Maxwell chipset\n); return -EINVAL; -- 2.4.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 1/6] gr: use NVIDIA-provided external firmwares
NVIDIA will officially start providing GR firmwares through
linux-firmware for GPUs that require it. Change the GR firmware lookup
function to use these files.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drm/nouveau/nvkm/engine/gr/gf100.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c
b/drm/nouveau/nvkm/engine/gr/gf100.c
index ca11ddb6ed46..454080339572 100644
--- a/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -1550,18 +1550,25 @@ gf100_gr_ctor_fw(struct gf100_gr_priv *priv, const char
*fwname,
{
struct nvkm_device *device = nv_device(priv);
const struct firmware *fw;
- char f[32];
+ char f[64];
+ char cname[16];
int ret;
+ int i;
+
+ /* Convert device name to lowercase */
+ strncpy(cname, device-cname, sizeof(cname));
+ cname[sizeof(cname) - 1] = '\0';
+ i = strlen(cname);
+ while (i) {
+ --i;
+ cname[i] = tolower(cname[i]);
+ }
- snprintf(f, sizeof(f), nouveau/nv%02x_%s, device-chipset, fwname);
+ snprintf(f, sizeof(f), nvidia/%s/%s.bin, cname, fwname);
ret = request_firmware(fw, f, nv_device_base(device));
if (ret) {
- snprintf(f, sizeof(f), nouveau/%s, fwname);
- ret = request_firmware(fw, f, nv_device_base(device));
- if (ret) {
- nv_error(priv, failed to load %s\n, fwname);
- return ret;
- }
+ nv_error(priv, failed to load %s\n, fwname);
+ return ret;
}
fuc-size = fw-size;
@@ -1615,10 +1622,10 @@ gf100_gr_ctor(struct nvkm_object *parent, struct
nvkm_object *engine,
if (use_ext_fw) {
nv_info(priv, using external firmware\n);
- if (gf100_gr_ctor_fw(priv, fuc409c, priv-fuc409c) ||
- gf100_gr_ctor_fw(priv, fuc409d, priv-fuc409d) ||
- gf100_gr_ctor_fw(priv, fuc41ac, priv-fuc41ac) ||
- gf100_gr_ctor_fw(priv, fuc41ad, priv-fuc41ad))
+ if (gf100_gr_ctor_fw(priv, fecs_inst, priv-fuc409c) ||
+ gf100_gr_ctor_fw(priv, fecs_data, priv-fuc409d) ||
+ gf100_gr_ctor_fw(priv, gpccs_inst, priv-fuc41ac) ||
+ gf100_gr_ctor_fw(priv, gpccs_data, priv-fuc41ad))
return -ENODEV;
priv-firmware = true;
}
--
2.4.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [RFC PATCH 5/8] nv50: prevent NULL pointer dereference with pipe_query functions
On 23.06.2015 06:02, Samuel Pitoiset wrote: On 06/22/2015 10:52 PM, Ilia Mirkin wrote: If query_create fails, why would any of these functions get called? Because the HUD doesn't check if query_create() fails and it calls other pipe_query functions with NULL pointer instead of a valid query object. Could the HUD code be fixed instead? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 0/6] Improve GK20A support, introduce GM20B, firmware paths
Second version of this patchset. Not many changes since first version - I hope this means the changes are not too controversial. Changes since v1: - Removed lookup for previous FW files in nouveau/ - Went back to using request_firmware() since we only try to load one file Original cover letter follows: GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support for it, based on a rework of the already-supported GK20A. It also introduces support for NVIDIA-provided firmware files, which is why I have added a few NVIDIA people who are relevant to this discussion. The first patch adds support for loading the FECS and GPCCS firmwares from firmware files officially released by NVIDIA. As you know such firmwares will soon become a necessity for newer GPUs because some falcons will require signed firmware to operate. In addition there is no reverse-engineered version of the GK20A firmwares yet, so since an external file is needed anyway, it may as well be provided officially. NVIDIA plans to release firmwares as one file per binary to keep things simple. The layout will be nvidia/gpu/firmware.bin, so for GK20A FECS/GPCCS we have: nvidia/gk20a/fecs_inst.bin (aka fuc409c) nvidia/gk20a/fecs_data.bin (aka fuc409d) nvidia/gk20a/gpccs_inst.bin (aka fuc41ac) nvidia/gk20a/gpccs_data.bin (aka fuc41ad) All firmware files listed in this patchset are clean for release, and I am just waiting for a community ack of the layout to send a patch to linux-firmware. The second patch reworks existing GK20A support to make it closer to what our nvgpu driver does. Support so far was heavily based on GK104, which somehow made me feel uneasy - and quite scared after I looked more closely at what nvgpu does. In particular the GK104 MMIO bundles differed significantly from what nvgpu does. This change aligns things and (probably less significant, but still safer) reorders the initialization sequence to match the one of nvgpu. You will note that the MMIO bundles now come as firmware files of their own. I am not sure the community will be pleased with an increase of firmware files, however the rationale for this is as follows: - These initialization sequences are related to the firmwares, so it makes sense to distribute them under the same medium - If NVIDIA needs to update the firmwares for some reason, it can atomically update the MMIO bundles and provide a coherent set, instead of having to introduce versioning into the firmware and driver - For IP reasons, I as an NVIDIA employee cannot extract these register sequences and link them into Nouveau - These are just a bunch of register address/value pairs anyway The new firmware files introduced are: nvidia/gk20a/sw_nonctx.bin (gr_pack_mmio) nvidia/gk20a/sw_ctx.bin (grctx_pack_hub, grctx_pack_gpc, grctx_pack_zcull, grctx_pack_tpc, grctx_pack_ppc) nvidia/gk20a/sw_bundle_init.bin (grctx_pack_icmd) nvidia/gk20a/sw_method_init.bin (grctx_pack_mthd) Third patch is trivial and adds the GM20B FIFO device. Fourth patch adds GM20B GR based on the reworked GK20A support. GM20B will rely on the same firmware files as GK20A (also clean for release). Note that this is not full support yet for released devices, which will require secure boot. This will be my focus once this patchset is merged (Deepak got a working version, but there is still a lot of work to do on it before it is upstreamable). The last two patches recognize GM20B at the device and platform level. Nothing really exciting. I hope the addition of firmware files will not become too controversial. If it does, I have good arguments to support it. ;) Besides the GK20A rework that probably few people care about, the point is the addition of a basic layout for the firmwares that NVIDIA will officially release to finally support secure boot, and I would like to make sure we get this right. Alexandre Courbot (6): gr: use NVIDIA-provided external firmwares gr/gk20a: use same initialization sequence as nvgpu fifo: add GM20B fifo gr: add GM20B support device: recognize GM20B platform: recognize GM20B drm/nouveau/include/nvkm/engine/fifo.h | 1 + drm/nouveau/include/nvkm/engine/gr.h | 1 + drm/nouveau/nouveau_platform.c | 1 + drm/nouveau/nvkm/engine/device/gm100.c | 20 ++ drm/nouveau/nvkm/engine/fifo/Kbuild| 1 + drm/nouveau/nvkm/engine/fifo/gk104.h | 4 + drm/nouveau/nvkm/engine/fifo/gm204.c | 2 +- drm/nouveau/nvkm/engine/fifo/gm20b.c | 34 drm/nouveau/nvkm/engine/gr/Kbuild | 2 + drm/nouveau/nvkm/engine/gr/ctxgf100.h | 7 + drm/nouveau/nvkm/engine/gr/ctxgk20a.c | 65 +-- drm/nouveau/nvkm/engine/gr/ctxgm107.c | 2 +- drm/nouveau/nvkm/engine/gr/ctxgm204.c | 4 +- drm/nouveau/nvkm/engine/gr/ctxgm20b.c | 110 +++ drm/nouveau/nvkm/engine/gr/gf100.c | 35 ++-- drm/nouveau/nvkm/engine/gr/gf100.h | 18 ++ drm/nouveau/nvkm/engine/gr/gk20a.c | 336 +++--
Re: [Nouveau] [Mesa-dev] [RFC PATCH 5/8] nv50: prevent NULL pointer dereference with pipe_query functions
On 06/23/2015 08:57 AM, Michel Dänzer wrote: On 23.06.2015 06:02, Samuel Pitoiset wrote: On 06/22/2015 10:52 PM, Ilia Mirkin wrote: If query_create fails, why would any of these functions get called? Because the HUD doesn't check if query_create() fails and it calls other pipe_query functions with NULL pointer instead of a valid query object. Could the HUD code be fixed instead? It's definitely possible, and probably the best solution instead of preventing NULL pointer dereference in the underlying drivers. I'll make a patch. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
