search for: soff

...s that you want the user data to remain valid). It may matter more for functions that don't take a buf (such as nbd_aio_trim). > +++ b/lib/rw.c Yep, definitely a mechanical conversion. > +++ b/ocaml/examples/asynch_copy.ml > @@ -48,7 +48,7 @@ let asynch_copy src dst = > if !soff < size && NBD.aio_in_flight src < max_reads_in_flight then ( > let bs = min bs (size -^ !soff) in > let buf = NBD.Buffer.alloc (Int64.to_int bs) in > - ignore (NBD.aio_pread_callback src buf !soff > + ignore (NBD.aio_pread src buf !soff >...

...BD server, with callback on completion"; diff --git a/ocaml/examples/asynch_copy.ml b/ocaml/examples/asynch_copy.ml index 7dbe976..5aa6e60 100644 --- a/ocaml/examples/asynch_copy.ml +++ b/ocaml/examples/asynch_copy.ml @@ -49,7 +49,7 @@ let asynch_copy src dst = let bs = min bs (size -^ !soff) in let buf = NBD.Buffer.alloc (Int64.to_int bs) in ignore (NBD.aio_pread_callback src buf !soff - (read_completed buf !soff)); + ~completion:(read_completed buf !soff)); soff := !soff +^ bs ); @@ -59,7 +59,8 @@ let asynch_copy src dst =...

...BD server, with callback on completion"; diff --git a/ocaml/examples/asynch_copy.ml b/ocaml/examples/asynch_copy.ml index 7dbe976..5aa6e60 100644 --- a/ocaml/examples/asynch_copy.ml +++ b/ocaml/examples/asynch_copy.ml @@ -49,7 +49,7 @@ let asynch_copy src dst = let bs = min bs (size -^ !soff) in let buf = NBD.Buffer.alloc (Int64.to_int bs) in ignore (NBD.aio_pread_callback src buf !soff - (read_completed buf !soff)); + ~completion:(read_completed buf !soff)); soff := !soff +^ bs ); @@ -59,7 +59,8 @@ let asynch_copy src dst =...

...m/engine/disp/hdagt215.c index 6f0436d..f8f2f16 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c @@ -59,7 +59,7 @@ gt215_hda_eld(NV50_DISP_MTHD_V1) ); } for (i = 0; i < size; i++) - nvkm_wr32(device, 0x61c440 + soff, (i << 8) | args->v0.data[0]); + nvkm_wr32(device, 0x61c440 + soff, (i << 8) | args->v0.data[i]); for (; i < 0x60; i++) nvkm_wr32(device, 0x61c440 + soff, (i << 8)); nvkm_mask(device, 0x61c448 + soff, 0x80000003, 0x80000003); -- 2.10.2

This is an initial implementation of HDMI 3D mode support for the nouveau kernel driver. It works on all of the hardware that I have available to test at the moment, but I am unsure as to the overall approach taken for setting HDMI InfoFrames, there's no support for g84 or gf119 disps, and the criteria for enabling stereo support for an output seems a bit iffy. The first four patches arrange

...Street, Fifth Floor, Boston, MA 02110-1301 USA + +import select +import nbd + +disk_size = 512 * 1024 * 1024 +bs = 65536 +max_reads_in_flight = 16 +bytes_read = 0 +bytes_written = 0 + +def asynch_copy (src, dst): + size = src.get_size () + + # This is our reading position in the source. + soff = 0 + + # This callback is called when any pread from the source + # has completed. + writes = [] + def read_completed (buf, offset, error): + global bytes_read + bytes_read += buf.size () + wr = (buf, offset) + writes.append (wr) + # By returning 1 he...

...44 --- a/drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c @@ -36,6 +36,8 @@ nva3_hda_eld(struct nv50_disp_priv *priv, int or, u8 *data, u32 size) if (data && data[0]) { for (i = 0; i < size; i++) nv_wr32(priv, 0x61c440 + soff, (i << 8) | data[i]); + for (; i < 0x60; i++) + nv_wr32(priv, 0x61c440 + soff, (i << 8)); nv_mask(priv, 0x61c448 + soff, 0x80000003, 0x80000003); } else if (data) { diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/hdanvd0.c b/drivers/gpu/drm/nouveau/core/engine/disp/hd...

This applies on top of the OClosure v2 series posted a few minutes ago. Rich.

...nouveau/core/engine/disp/hdminva3.c index f065fc2..db8c6fd 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c @@ -55,6 +55,10 @@ nva3_hdmi_ctrl(struct nv50_disp_priv *priv, int head, int or, u32 data) nv_wr32(priv, 0x61c510 + soff, 0x00000000); nv_mask(priv, 0x61c500 + soff, 0x00000001, 0x00000001); + nv_mask(priv, 0x61c5d0 + soff, 0x00070001, 0x00010001); /* SPARE, HW_CTS */ + nv_mask(priv, 0x61c568 + soff, 0x00010101, 0x00000000); /* ACR_CTRL, ?? */ + nv_mask(priv, 0x61c578 + soff, 0x80000000, 0x80000000); /* ACR_0441_...

v1 was here: https://www.redhat.com/archives/libguestfs/2019-August/msg00103.html In v2 I've made several changes: - Fix Python callbacks so if they don't return something which is int-like, we assume they mean to return 0. - Add nbd.Buffer free() method. Read commit message in patch 2 to see what this is about. - Fixed the asynch copy test to deal with the unbelievably

...d722e 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c @@ -1142,7 +1142,7 @@ nv50_disp_intr_unk20_2(struct nv50_disp_priv *priv, int head) if (conf != ~0) { if (outp.location == 0 && outp.type == DCB_OUTPUT_DP) { u32 soff = (ffs(outp.or) - 1) * 0x08; - u32 ctrl = nv_rd32(priv, 0x610798 + soff); + u32 ctrl = nv_rd32(priv, 0x610794 + soff); u32 datarate; switch ((ctrl & 0x000f0000) >> 16) { -- 1.8.3.2

v1 was here: https://www.redhat.com/archives/libguestfs/2019-August/msg00168.html I pushed uncontroversial patches 1-4 v2: - The implementation of OClosure (new patch 1) in Python is fixed. - Patch 2 (old patch 5) is unchanged. - I added a new API for removing debug callbacks. I think this approach has some advantages over using OClosure. - I didn't yet do any work on changing the

Basically the same as this patch series, but for Python: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html plus adding the 590 asynch test at the end. Rich.

...extent, .fn_user_data = extent_user_data, diff --git a/ocaml/examples/asynch_copy.ml b/ocaml/examples/asynch_copy.ml index 5aa6e60..8057118 100644 --- a/ocaml/examples/asynch_copy.ml +++ b/ocaml/examples/asynch_copy.ml @@ -48,7 +48,7 @@ let asynch_copy src dst = if !soff < size && NBD.aio_in_flight src < max_reads_in_flight then ( let bs = min bs (size -^ !soff) in let buf = NBD.Buffer.alloc (Int64.to_int bs) in - ignore (NBD.aio_pread_callback src buf !soff + ignore (NBD.aio_pread src buf !soff ~completion:(re...

Patches 1-4 are basically uncontroversial, straightforward refactoring and IMHO we should just push them. Possibly 1-3 should be squashed together, but I posted them separately so they are easier to review. Patches 5 and 6 together implement OClosure. Patch 5 adds the feature and is simple to understand. Patch 6 changes the Closure completion callbacks into OClosure, but because it doesn't

...rm/nouveau/nvkm/engine/disp/hdmigm200.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c @@ -27,10 +27,10 @@ void gm200_hdmi_scdc(struct nvkm_ior *ior, int head, u8 scdc) { struct nvkm_device *device = ior->disp->engine.subdev.device; - const u32 hoff = head * 0x800; + const u32 soff = nv50_ior_base(ior); const u32 ctrl = scdc & 0x3; - nvkm_mask(device, 0x61c5bc + hoff, 0x00000003, ctrl); + nvkm_mask(device, 0x61c5bc + soff, 0x00000003, ctrl); ior->tmds.high_speed = !!(scdc & 0x2); } -- 2.25.1

...rm/nouveau/nvkm/engine/disp/hdmigm200.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c @@ -27,10 +27,10 @@ void gm200_hdmi_scdc(struct nvkm_ior *ior, int head, u8 scdc) { struct nvkm_device *device = ior->disp->engine.subdev.device; - const u32 hoff = head * 0x800; + const u32 soff = nv50_ior_base(ior); const u32 ctrl = scdc & 0x3; - nvkm_mask(device, 0x61c5bc + hoff, 0x00000003, ctrl); + nvkm_mask(device, 0x61c5bc + soff, 0x00000003, ctrl); ior->tmds.high_speed = !!(scdc & 0x2); } -- 2.25.1

This doesn't yet work. However it does make me more convinced than ever that we really need to sort out persistent buffer lifetimes in the library (similar to what we did for closures). Rich.

This is the beginnings of HDMI 2.0 support. All of the "extra" features are left out, such as 12/16bpc, YUV420, etc. I've verified that with this code, a GP108 (GT1030) can switch between 4k at 60 and 1920x1080 at 60 on a LG 4K TV. Further, I've verified via i2c tools, that the SCDC writes really do happen. I suspect that the patch for keeping track of the high-speed TMDS

This is a combination of these two earlier series: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html https://www.redhat.com/archives/libguestfs/2019-August/msg00240.html plus changes to allow .callback = NULL / .free != NULL, and to reduce the complexity of freeing callbacks. Although it's rather long there's nothing complex here. We might consider squashing some