search for: 0x0000ff00

...ax values of each of these, also where these or some of these hex numbers? I tried this on redhat 7.3 so there may have been some updates, but this is one of the tests I did. [root@RL1 root]# tc filter add dev eth0 protocol ip parent 1:0 prio 10 u32 ht fffe:: match ip dst 10.2.0.0/16 hashkey mask 0x0000ff00 at 16 link 2: Illegal "ht" So I assume that that FFFE:: is too large so I found that tc filter add dev eth0 protocol ip parent 1:0 prio 10 u32 ht fff:: match ip dst 10.2.0.0/16 hashkey mask 0x0000ff00 at 16 link 7: so it works with fff I guess does this mean its an 24 bit number? Would t...

...r, _mem)); -/* base-2 logarithm */ -#define __L2(_x) (((_x) & 0x00000002) ? 1 : 0) -#define __L4(_x) (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x)) -#define __L8(_x) (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x)) -#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x)) -#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x)) - void __dummy__(void) { OFFSET(UREGS_sp, struct cpu_user_regs, sp); diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c index b6...

...X3_TEXTURED_TRIANGLE_FOG_COLOR 0x00000310 -#define NV03_DX3_TEXTURED_TRIANGLE_FOG_COLOR_B_SHIFT 0 -#define NV03_DX3_TEXTURED_TRIANGLE_FOG_COLOR_B_MASK 0x000000ff -#define NV03_DX3_TEXTURED_TRIANGLE_FOG_COLOR_G_SHIFT 8 -#define NV03_DX3_TEXTURED_TRIANGLE_FOG_COLOR_G_MASK 0x0000ff00 -#define NV03_DX3_TEXTURED_TRIANGLE_FOG_COLOR_R_SHIFT 16 -#define NV03_DX3_TEXTURED_TRIANGLE_FOG_COLOR_R_MASK 0x00ff0000 -#define NV03_DX3_TEXTURED_TRIANGLE_CONTROL_OUT 0x00000314 -#define NV03_DX3_TEXTURED_TRIANGLE_CONTROL_OUT_INTERPOLATOR_SHIFT 0 -#define NV03_DX3_TEXTURED...

..._x) (((_x) & 0x000000f0) ? __RD4((_x)>>4)<<4 : __RD4(_x)) ^ /usr/src/linux-headers-4.2.0-1-common/include/xen/interface/io/ring.h:18:66: note: in expansion of macro '__RD8' #define __RD16(_x) (((_x) & 0x0000ff00) ? __RD8((_x)>>8)<<8 : __RD8(_x)) ^ /usr/src/linux-headers-4.2.0-1-common/include/xen/interface/io/ring.h:19:66: note: in expansion of macro '__RD16' #define __RD32(_x) (((_x) & 0xffff0000) ? __RD16((_x)&g...

...panic.c @@ -209,6 +209,14 @@ static u32 convert_xrgb8888_to_argb2101010(u32 pix) return GENMASK(31, 30) /* set alpha bits */ | pix | ((pix >> 8) & 0x00300C03); } +static u32 convert_xrgb8888_to_abgr2101010(u32 pix) +{ + pix = ((pix & 0x00FF0000) >> 14) | + ((pix & 0x0000FF00) << 4) | + ((pix & 0x000000FF) << 22); + return GENMASK(31, 30) /* set alpha bits */ | pix | ((pix >> 8) & 0x00300C03); +} + /* * convert_from_xrgb8888 - convert one pixel from xrgb8888 to the desired format * @color: input color, in xrgb8888 format @@ -242,6 +2...

I forgot to ask a few more. Is there a relation between the hashtable ID /(parent,handle) so that if I used 2: for a hash table I could or couldn''t use 2: for a (parent,handle)ID? I also noticed that you type the hashtables like 2:2: can you have more levels with this? like 2:2:2:1: ? and I guess the same question with the parent/handles. thanks again. -- When dealing with a slow

...(((_x) & 0x000000f0) ? __RD4((_x)>>4)<<4 : __RD4(_x)) ^~~~~ /usr/src/linux-headers-4.12.0-1-common/include/xen/interface/io/ring.h:18:66: note: in expansion of macro '__RD8' #define __RD16(_x) (((_x) & 0x0000ff00) ? __RD8((_x)>>8)<<8 : __RD8(_x)) ^~~~~ /usr/src/linux-headers-4.12.0-1-common/include/xen/interface/io/ring.h:19:66: note: in expansion of macro '__RD16' #define __RD32(_x) (((_x) & 0xffff0000) ? __RD16((...

...u32 convert_xrgb8888_to_argb2101010(u32 pix) > return GENMASK(31, 30) /* set alpha bits */ | pix | ((pix >> 8) & 0x00300C03); > } > > +static u32 convert_xrgb8888_to_abgr2101010(u32 pix) > +{ > + pix = ((pix & 0x00FF0000) >> 14) | > + ((pix & 0x0000FF00) << 4) | > + ((pix & 0x000000FF) << 22); > + return GENMASK(31, 30) /* set alpha bits */ | pix | ((pix >> 8) & 0x00300C03); > +} Maybe we can move this format conversion helper and the others in the driver to drivers/gpu/drm/drm_format_helper.c ? > + &g...

...01010(u32 pix) >> return GENMASK(31, 30) /* set alpha bits */ | pix | ((pix >> 8) & 0x00300C03); >> } >> >> +static u32 convert_xrgb8888_to_abgr2101010(u32 pix) >> +{ >> + pix = ((pix & 0x00FF0000) >> 14) | >> + ((pix & 0x0000FF00) << 4) | >> + ((pix & 0x000000FF) << 22); >> + return GENMASK(31, 30) /* set alpha bits */ | pix | ((pix >> 8) & 0x00300C03); >> +} > > Maybe we can move this format conversion helper and the others in the > driver to drivers/gpu/drm/drm_f...

...= GETU32(cipherKey + 8); + rk[3] = GETU32(cipherKey + 12); + if (keyBits == 128) { + for (;;) { + temp = rk[3]; + rk[4] = rk[0] ^ + (Te4[(temp >> 16) & 0xff] & 0xff000000) ^ + (Te4[(temp >> 8) & 0xff] & 0x00ff0000) ^ + (Te4[(temp ) & 0xff] & 0x0000ff00) ^ + (Te4[(temp >> 24) ] & 0x000000ff) ^ + rcon[i]; + rk[5] = rk[1] ^ rk[4]; + rk[6] = rk[2] ^ rk[5]; + rk[7] = rk[3] ^ rk[6]; + if (++i == 10) { + return 10; + } + rk += 4; + } } - - /* note that the affine byte transformation matrix in */ - /* rijndael sp...

...UVEAU_GEM_TILE_NONCONTIG); > - if (!nouveau_cli_uvmm(cli) || internal) { > - /* for BO noVM allocs, don't assign kinds */ > - if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) { > - nvbo->kind = (tile_flags & 0x0000ff00) >> 8; > - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { > - kfree(nvbo); > - return ERR_PTR(-EINVAL); > - } > > - nvbo->comp = mmu->kind[nvb...

...UVEAU_GEM_TILE_NONCONTIG); > - if (!nouveau_cli_uvmm(cli) || internal) { > - /* for BO noVM allocs, don't assign kinds */ > - if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) { > - nvbo->kind = (tile_flags & 0x0000ff00) >> 8; > - if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) { > - kfree(nvbo); > - return ERR_PTR(-EINVAL); > - } > > - nvbo->comp = mmu->kind[nvb...

...im now that there’s no coverage for the tree pattern, > but it is failing to match the patterns we use in our tests, one of > which looks like this: > > define i32 @test_tree(i32 %x) { > > %byte0 = and i32 %x, 255 ; 0x000000ff > > %byte1 = and i32 %x, 65280 ; 0x0000ff00 > > %byte2 = and i32 %x, 16711680 ; 0x00ff0000 > > %byte3 = and i32 %x, 4278190080 ; 0xff000000 > > %tmp0 = shl i32 %byte0, 8 > > %tmp1 = lshr i32 %byte1, 8 > > %tmp2 = shl i32 %byte2, 8 > > %tmp3 = lshr i32 %byte3, 8 > > %or0 = or i32 %tmp0...

...@@ -96,6 +96,7 @@ struct drm_nouveau_setparam { #define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1) #define NOUVEAU_GEM_DOMAIN_GART (1 << 2) #define NOUVEAU_GEM_DOMAIN_MAPPABLE (1 << 3) +#define NOUVEAU_GEM_DOMAIN_COHERENT (1 << 4) #define NOUVEAU_GEM_TILE_LAYOUT_MASK 0x0000ff00 #define NOUVEAU_GEM_TILE_16BPP 0x00000001 diff --git a/nouveau/abi16.c b/nouveau/abi16.c index 538f3a730dbe..4ca0bfbaf592 100644 --- a/nouveau/abi16.c +++ b/nouveau/abi16.c @@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment, if (bo->flags & NOUVEAU_BO_MAP)...

...signed int x; - sbuf = kmalloc(src_linelength, GFP_KERNEL); - if (!sbuf) - return; - - for (y = 0; y < lines; y++) { - memcpy(sbuf, src, src_linelength); - dbuf = dst; - for (x = 0; x < linepixels; x++) { - *dbuf++ = (sbuf[x] & 0x000000FF) >> 0; - *dbuf++ = (sbuf[x] & 0x0000FF00) >> 8; - *dbuf++ = (sbuf[x] & 0x00FF0000) >> 16; - } - src += src_pitch; - dst += dst_pitch; + for (x = 0; x < pixels; x++) { + *dbuf++ = (sbuf[x] & 0x000000FF) >> 0; + *dbuf++ = (sbuf[x] & 0x0000FF00) >> 8; + *dbuf++ = (sbuf[x] & 0x00FF0000) &g...

...@@ -96,6 +96,7 @@ struct drm_nouveau_setparam { #define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1) #define NOUVEAU_GEM_DOMAIN_GART (1 << 2) #define NOUVEAU_GEM_DOMAIN_MAPPABLE (1 << 3) +#define NOUVEAU_GEM_DOMAIN_COHERENT (1 << 4) #define NOUVEAU_GEM_TILE_LAYOUT_MASK 0x0000ff00 #define NOUVEAU_GEM_TILE_16BPP 0x00000001 diff --git a/nouveau/abi16.c b/nouveau/abi16.c index ae13821bc0cc..d2d1d0d1942d 100644 --- a/nouveau/abi16.c +++ b/nouveau/abi16.c @@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment, if (bo->flags & NOUVEAU_BO_MAP)...

...GEM_DOMAIN_VRAM (1 << 1) #define NOUVEAU_GEM_DOMAIN_GART (1 << 2) #define NOUVEAU_GEM_DOMAIN_MAPPABLE (1 << 3) +#define NOUVEAU_GEM_DOMAIN_COHERENT (1 << 4) #define NOUVEAU_GEM_TILE_COMP 0x00030000 /* nv50-only */ #define NOUVEAU_GEM_TILE_LAYOUT_MASK 0x0000ff00 diff --git a/drm/nouveau/nouveau_gem.c b/drm/nouveau/nouveau_gem.c index 7c077fced1d1..0e690bf19fc9 100644 --- a/drm/nouveau/nouveau_gem.c +++ b/drm/nouveau/nouveau_gem.c @@ -189,6 +189,9 @@ nouveau_gem_new(struct drm_device *dev, int size, int align, uint32_t domain, if (!flags || domain & N...

...ne __RD8(_x) (((_x) & 0x000000f0) ? __RD4((_x)>>4)<<4 : __RD4(_x)) ^ /usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:18:66: note: in expansion of macro ?__RD8? #define __RD16(_x) (((_x) & 0x0000ff00) ? __RD8((_x)>>8)<<8 : __RD8(_x)) ^ /usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:19:66: note: in expansion of macro ?__RD16? #define __RD32(_x) (((_x) & 0xffff0000) ? __RD16((_x)>>16)...

The attached patch does the cosmetic renouveau.xml changes I proposed. I'm about to reply myself with some other patches to update libdrm and then fix the API break up. -------------- next part -------------- A non-text attachment was scrubbed... Name: rename_some_nv10tcl_methods.patch Type: text/x-diff Size: 2507 bytes Desc: not available Url :

...ion possible? where ht 800 links to 3: for the 3rd Octet in the IP and then 3: links to 4: for the fourth Octet? tc filter add dev eth0 parent 1:0 prio 10 handle 3: protocol ip u32 divisor 256 tc filter add dev eth0 protocol ip parent 1:0 prio 10 u32 ht 800:: match ip dst 10.1.0.0/16 hashkey mask 0x0000ff00 at 16 link 3: tc filter add dev eth0 parent 1:0 prio 10 handle 4: protocol ip u32 divisor 256 tc filter add dev eth0 protocol ip parent 1:0 prio 10 u32 ht 3:01: match ip dst 10.1.1.0/24 hashkey mask 0x000000ff at 16 link 4: I''m not sure how the Hashtable works I looked at the code that...