search for: init_reserved

Hi Ewan, I''m almost ready to integrate some PPC-specific stuff into xend, and I was wondering if you had a plan for how that should work. First example: the device tree data structure we talked about a few weeks ago. We will need to pass the config data to PPC code, probably in XendDomainInfo.initDomain(), and then pass the resulting data structure into libxc''s xc_linux_load()

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function parameter or member 'init' not described in 'init_reserved' drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: expecting prototype for INIT_DONE(). Prototype was for init_done() instead [Snipped ~140 lines for brevity] Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at r...

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function parameter or member 'init' not described in 'init_reserved' drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: expecting prototype for INIT_DONE(). Prototype was for init_done() instead [Snipped ~140 lines for brevity] Signed-off-by: Lee Jones <lee at kernel.org> --- Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Karol Herbst <...

NVIDIA GPUs include a common scripting language (devinit) that can be interpreted by a number of "engines", e.g. within a kernel-mode software driver, the VGA BIOS or an on-board small microcontroller which provides certain security assertions (the 'PMU'). This system allows a GPU programming sequence to be shared by multiple entities that would not otherwise be able to execute

--- drivers/gpu/drm/nouveau/nouveau_bios.c | 47 ++++++++++++++----------------- 1 files changed, 21 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 5eec5ed..04ac564 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -181,43 +181,42 @@ struct methods { const char

...+ trace("\tR[0x%06x] = 0x%08x\n", addr, data); + } + } +} + static struct nvbios_init_opcode { void (*exec)(struct nvbios_init *); } init_opcode[] = { @@ -2268,6 +2294,7 @@ static struct nvbios_init_opcode { [0x9a] = { init_i2c_long_if }, [0xa9] = { init_gpio_ne }, [0xaa] = { init_reserved }, + [0xaf] = { init_zm_reg_set_loop }, }; #define init_opcode_nr (sizeof(init_opcode) / sizeof(init_opcode[0])) -- 2.5.5

...s/gpu/drm/nouveau/nvkm/subdev/bios/init.c @@ -21,6 +21,7 @@ * * Authors: Ben Skeggs */ +#include <linux/kernel.h> #include <subdev/bios.h> #include <subdev/bios/bit.h> #include <subdev/bios/bmp.h> @@ -2271,7 +2272,7 @@ static struct nvbios_init_opcode { [0xaa] = { init_reserved }, }; -#define init_opcode_nr (sizeof(init_opcode) / sizeof(init_opcode[0])) +#define init_opcode_nr (ARRAY_SIZE(init_opcode)) int nvbios_exec(struct nvbios_init *init)

...oslog(lvl, fmt, args...) do { \ nvkm_printk(init->subdev, lvl, info, "0x%08x[%c]: "fmt, \ init->offset, init_exec(init) ? \ @@ -2271,8 +2273,6 @@ static struct nvbios_init_opcode { [0xaa] = { init_reserved }, }; -#define init_opcode_nr (sizeof(init_opcode) / sizeof(init_opcode[0])) - int nvbios_exec(struct nvbios_init *init) { @@ -2281,7 +2281,8 @@ nvbios_exec(struct nvbios_init *init) init->nested++; while (init->offset) { u8 opcode = nvbios_rd08(bios, init->offset); - if (opc...

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (15): drm/xlnx/zynqmp_disp: Use correct kerneldoc formatting in zynqmp_disp drm/xlnx/zynqmp_dp: Fix function name zynqmp_dp_link_train() -> zynqmp_dp_train() drm/vkms/vkms_composer: Fix a few different kerneldoc formatting

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: amd-gfx at lists.freedesktop.org Cc: Ben Skeggs <bskeggs at redhat.com> Cc: "Christian K?nig" <christian.koenig at amd.com> Cc: Daniel Vetter <daniel at ffwll.ch>

Following a series of three patches, two of which have been sitting in my tree for a while, the third is the result of some inspection of an NV134 BIOS that seems to use the 0xaf upcode to upload training patterns. Please test! Roy Ps. Sorry they come from yet another e-mail address. My previous provider, eclipso, actively blocks users of git send-email. Inquiries fall on deaf ears, hence I

...oslog(lvl, fmt, args...) do { \ nvkm_printk(init->subdev, lvl, info, "0x%08x[%c]: "fmt, \ init->offset, init_exec(init) ? \ @@ -2271,8 +2273,6 @@ static struct nvbios_init_opcode { [0xaa] = { init_reserved }, }; -#define init_opcode_nr (sizeof(init_opcode) / sizeof(init_opcode[0])) - int nvbios_exec(struct nvbios_init *init) { @@ -2281,7 +2281,8 @@ nvbios_exec(struct nvbios_init *init) init->nested++; while (init->offset) { u8 opcode = nvbios_rd08(bios, init->offset); - if (opc...

Hi everyone, Using ARRAY_SIZE improves the code readability. I used coccinelle (I made a change to the array_size.cocci file [1]) to find several places where ARRAY_SIZE could be used instead of other macros or sizeof division. I tried to divide the changes into a patch per subsystem (excepted for staging). If one of the patch should be split into several patches, let me know. In order to reduce

...-ROUTINE AT 0xE66A (II) NOUVEAU(0): 0xE66A: [ (0x6E) - INIT_NV_REG ] (II) NOUVEAU(0): 0xE66A: Reg: 0x00680524, Mask: 0xFFFFFF0F, Data: 0x00000000 (II) NOUVEAU(0): Read: Reg: 0x00680524, Data: 0x00000020 (II) NOUVEAU(0): Write: Reg: 0x00680524, Data: 0x00000000 (II) NOUVEAU(0): 0xE677: [ (0x92) - INIT_RESERVED ] (II) NOUVEAU(0): 0xE678: [ (0x6E) - INIT_NV_REG ] (II) NOUVEAU(0): 0xE678: Reg: 0x001020FB, Mask: 0xFFFFFF7F, Data: 0x00000080 (EE) NOUVEAU(0): ========== misaligned reg 0x001020FB ========== (EE) NOUVEAU(0): ========== misaligned reg 0x001020FB ========== (II) NOUVEAU(0): 0xE685: [ (0x71) - INIT...