search for: val16

...gned int src_linelength, - unsigned int lines, - bool swap) +static void drm_fb_xrgb8888_to_rgb565_line(u16 *dbuf, u32 *sbuf, + unsigned int pixels, + bool swab) { - unsigned int linepixels = src_linelength / sizeof(u32); - unsigned int x, y; - u32 *sbuf; - u16 *dbuf, val16; + unsigned int x; + u16 val16; - /* - * The cma memory is write-combined so reads are uncached. - * Speed up by fetching one line at a time. - */ - sbuf = kmalloc(src_linelength, GFP_KERNEL); - if (!sbuf) - return; - - for (y = 0; y < lines; y++) { - memcpy(sbuf, src, src_linelength); -...

...ar), cap->bar); + pci_write_config_dword(dev, cfg + VPCI_FIELD(length), length); + pci_write_config_dword(dev, cfg + VPCI_FIELD(offset), offset); + return 0; +} + +static u32 viommu_cread(struct pci_dev *dev, int cfg, + struct viommu_cap_config *cap, u32 length, u32 offset) +{ + u8 val8; + u16 val16; + u32 val32; + int out = cfg + sizeof(struct virtio_pci_cap); + + if (viommu_switch_pci_cfg(dev, cfg, cap, length, offset)) + return 0; + + switch (length) { + case 1: + pci_read_config_byte(dev, out, &val8); + return val8; + case 2: + pci_read_config_word(dev, out, &val16); + return...

...course. The problem: ------------ The problem appears to be that introducing HPR looks like a good idea, but it gives problems when FullFP16 is not supported. This is best illustrated with this existing test which is a simple upconvert of f16 to f32: define float @test_extend32(half* %addr) { %val16 = load half, half* %addr %val32 = fpext half %val16 to float ret float %val32 } It should generate this code:: ldrh r0, [r0] ; integer half word load vmov s0, r0 vcvtb.f32.f16 s0, s0 vmov r0, s0 bx lr when we don't have the...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

...course. The problem: ------------ The problem appears to be that introducing HPR looks like a good idea, but it gives problems when FullFP16 is not supported. This is best illustrated with this existing test which is a simple upconvert of f16 to f32: define float @test_extend32(half* %addr) { %val16 = load half, half* %addr %val32 = fpext half %val16 to float ret float %val32 } It should generate this code:: ldrh r0, [r0] ; integer half word load vmov s0, r0 vcvtb.f32.f16 s0, s0 vmov r0, s0 bx lr when we don't have the...

...ev, cfg + VPCI_FIELD(length), length); > + pci_write_config_dword(dev, cfg + VPCI_FIELD(offset), offset); > + return 0; > +} > + > +static u32 viommu_cread(struct pci_dev *dev, int cfg, > + struct viommu_cap_config *cap, u32 length, u32 offset) > +{ > + u8 val8; > + u16 val16; > + u32 val32; > + int out = cfg + sizeof(struct virtio_pci_cap); > + > + if (viommu_switch_pci_cfg(dev, cfg, cap, length, offset)) > + return 0; > + > + switch (length) { > + case 1: > + pci_read_config_byte(dev, out, &val8); > + return val8; > + case 2: &g...

1. Fixed the va_end() thing. Thanks for the clarification. 2. I've redone the mapping matrix so it only either handles floats or int16 explicitly. please let me know if you'd like another functionality, but my thoughts on this were to keep the val16 handled entirely inside multistream API. 3. endianness fixed. thank you! 4. Removed those pointers, accidentally left them in but they were functionally useless. Attached a new patch with those changes. On Tue, Oct 10, 2017 at 12:19 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi...

Hi Drew, On 10/10/17 02:29 PM, Drew Allen wrote: > 2) Someone on this list might know better than I do on that one, but for > the new _ctl_va_list() calls, I believe the convention is for va_start() > and va_end() to appear in the caller rather than in in the va_list() > function itself. > > *My understanding is that it's impossible to pass ellipsis to another >

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

...07:09 PM, Drew Allen wrote: > 1. Fixed the va_end() thing. Thanks for the clarification. > 2. I've redone the mapping matrix so it only either handles floats or > int16 explicitly. please let me know if you'd like another > functionality, but my thoughts on this were to keep the val16 handled > entirely inside multistream API. > 3. endianness fixed. thank you! > 4. Removed those pointers, accidentally left them in but they were > functionally useless. > > Attached a new patch with those changes. > > On Tue, Oct 10, 2017 at 12:19 PM Jean-Marc Valin <j...