free-electrons.com Report : Visit Site

Technical data of the free-electrons.com

Geo IP provides you such as latitude, longitude and ISP (Internet Service Provider) etc. informations. Our GeoIP service found where is host free-electrons.com. Currently, hosted in France and its service provider is Online S.A.S. .

HTTP Header Analysis

HTTP Header information is a part of HTTP protocol that a user's browser sends to called Apache containing the details of what the browser wants and will accept back from the web server.

DNS

HtmlToText

skip to content bootlin formerly free electrons menu home engineering training docs community company allwinner vpu support in mainline linux status update (week 23) on the players integration side, the goals for this week covered kodi support for our beloved allwinner platforms (of course, with upstream). but first, a few words as a follow-up to last week’s work on the mb32 untiling gpu shader. a specific commit related to texture uploading on the mali400 was spotted in the mer project, fixing an issue apparently very similar to our own. alas! it didn’t help with our case and did not lead to any improvement. while the shader untiler is required for accelerated x11 display with the gpu, kodi offers direct drm/kms support (the kernel mode-setting part of the display rendering manager, that deals with on-screen display). this means that we can use the drm work from months ago for untiling the vpu buffers directly with the video engine. this is sometimes even faster than the gpu, especially for 4k contents! however, kodi is a complex piece of software that requires significant integration. its support in buildroot definitely reveals that complexity, that is gracefully abstracted by the build system. on top of that, the kodi target platform for using drm/kms, called gbm (we’ll get back to this acronym in a bit) is not supported in most build systems (buildroot included), with the exception of libreelec, that is used by the developers contributing to this kodi target. after an intense struggle, it became clear that libreelec was the only reasonable and sane way to go for supporting gbm. thanks to the huge help and incredible availability of the community of libreelec developers interested in allwinner support, it was possible to finally bootstrap a working installation (that does not interface with our vaapi backend yet): big buck bunny with kodi on the all-h3-cc, without vaapi integration yet in order to provide high performance and a pleasant experience, kodi heavily relies on the gpu, which is supported by the egl and gles interfaces. egl, in charge of the display part, has to be connected to the native windowing system of the target in use, that can be x11 or wayland/gbm. gbm, which stands for generic buffer management is an abstracted api for graphics-related memory management. it allows abstracting memory allocators such as gem (the graphics execution manager used in conjunction with drm) through a consistent and unified interface that is, as for egl and gles, independent from the system and hardware implementations. kodi uses gbm directly to allocate buffers shared between the gpu and the drm subsystem. this requires explicit cooperation from the used egl implementation, the mali blobs in our case. sadly, the blobs available for the a10/a13/a20 and a33 platform do not provide the gbm interface. still, libreelec offers support for the h3 platform and so it was selected as a primary target for setting up kodi support for the gbm target. thanks to libre computer , we received a (significant) number of boards for our development purposes, including h3 boards that were directly useful in this effort! the h264 effort has also seen some great progress this week. we finally got the first frame of big buck bunny to be decoded on monday, and gradually improved the libva-dump, cedrus-frame-test and our kernel driver to fix the bugs that were found along the way. the libvdpau-sunxi authors, and jens kuske in particular, provided some great feedback on how the reference list, decoded buffer buffers, and the video engine in general were working. we now can play a video with only i-frames without any hiccups (that we found out), and the p-frame support is slowly getting into shape. we can decode the first 4 frames of big buck bunny without any issue, and the fifth is reported as decoded, but, well, see below for yourself… obviously this will need a bit more work, and to test it with other videos and with b-frames. but this is good news! author paul kocialkowski posted on june 9, 2018 june 9, 2018 categories technical 2 comments on allwinner vpu support in mainline linux status update (week 23) linux 4.17 released, bootlin contributions drawing from mylène josserand, based on a picture from samuel blanc under cc-by-sa 4.17 was released last sunday , so it’s time for our highlight article to see daylight. as always, lwn.net did an interesting coverage of this release cycle merge window, highlighting the most important changes: the first half of the 4.17 merge window and the rest of the 4.17 merge window . for 4.17 only, bootlin contributed a total of 331 patches , which puts us at the 10th place in the ranking of most contributing companies according to both lwn and kps . also according to lwn statistics , bootlin’s engineer alexandre belloni is the 6th most active developer in terms of changesets for this release with a total of 124 commits, almost a percent of the total number. the main highlights of our contributions are: for marvell platforms: antoine ténart improved the inside-secure crypto accelerator driver by adding support for hmac(sha256) and hmac(sha224) algorithms. this driver is used on marvell armada 3700 and 7k/8k. antoine ténart and gregory clement also contributed a number of fixes to the inside-secure crypto accelerator driver, maxime chevallier added hardware offloading support for vlan filtering to the mvpp2 network driver. this driver is used on marvell armada 375 and 7k/8k. maxime chevallier also contributed a number of fixes to the mvpp2 network driver, miquèl raynal migrated boards from pxa3xx nand driver to the nand driver he developed and got merged in 4.16, gregory clement contributed a rework of the clocks representation on marvell armada 7k/8k that led to the updates of several device trees, in the mtd subsystem, both boris brezillon and miquèl raynal contributed numerous fixes, for microsemi ocelot platforms: alexandre belloni added support for microsemi ocelot soc’s reset , alexandre belloni added support for microsemi ocelot soc’s interrupt controller , alexandre belloni added basic support for microsemi ocelot: core support , soc device tree and board device tree . alexandre is therefore the maintainer of the microsemi ocelot support . for raspberrypi platforms, boris brezillon contributed the exposing of performance counters of vc4 drm driver to userspace and numerous fixes to vc4 drm driver , for allwinner platforms: quentin schulz added support for adc and battery power supply on the x-powers axp813 pmic , quentin schulz also contributed support for cpufreq for the allwinner a83t , maxime ripard added support for yuv planes in the drm driver of allwinner socs , maxime ripard contributed a few fixes and improvements to the drm driver of allwinner socs , maxime ripard also contributed a few improvements to the mmc core to be able to comply with allwinner guidelines, for rtc subsystem, alexandre belloni moved rtc_nvmem_register() out of the core so drivers can better fine-grain tune their initialization, and fixed a few issues along the way (most notably a possible race condition), for the superh architecture, thomas petazzoni contributed a few fixes for the pcie controller of the renesas sh7786 for the asoc subsystem, mylène josserand added support for the ti pcm1789 dac , bootlin engineers are not only contributors, but also maintainers of various subsystems in the linux kernel, which means they are involved in the process of reviewing, discussing and merging patches contributed to those subsystems: maxime ripard, as the allwinner platform co-maintainer, merged 97 patches from other contributors boris brezillon, as the mtd/nand maintainer, merged 87 patches from other contributors alexandre belloni, as the rtc maintainer and atmel platform co-maintainer, merged 46 patches from other contributors grégory clement, as the marvell ebu co-maintainer, merged 14 patches from other contributors here is the commit by commit detail of our contributions to 4.17: alexandre belloni (124): dt-bindings: power: reset: document ocelot-reset binding power: reset: add a driver for the microsemi ocelot reset arm: dts: armada: netgear-rn*: fix rtc node name arm: dts: at91: sam9rl: properly assign copyright rtc: documentation: correct nvmem date and version rtc: nvmem: pass nvmem_config to rtc_nvmem_register() rtc: nvmem: return error values rtc: nvmem: disallow registering nvmem more than once rtc: nvmem: allow registering the nvmem device before the rtc rtc: export rtc_nvmem_register() to drivers rtc: ds1305: call rtc_nvmem_register() rtc: ds1305: put ds1305_nvmem_cfg on the stack rtc: ds1307: call rtc_nvmem_register() rtc: ds1307: put struct nvmem_config on the stack rtc: ds1511: call rtc_nvmem_register() rtc: ds1511: put ds1511_nvmem_cfg on the stack rtc: m48t86: call rtc_nvmem_register() rtc: m48t86: put m48t86_nvmem_cfg on the stack rtc: omap: call rtc_nvmem_register() rtc: pcf85363: call rtc_nvmem_register() rtc: pcf85363: put struct nvmem_config on the stack rtc: rv8803: call rtc_nvmem_register() rtc: rv8803: put struct nvmem_config on the stack rtc: rv8803: fix possible race condition rtc: remove nvmem_config rtc: ds1343: simplify regmap initialization rtc: ds1343: switch to rtc_register_device rtc: ds1343: remove undocumented and useless sysfs files rtc: ds1343: use generic nvmem rtc: m48t59: switch to rtc_register_device rtc: m48t59: use generic nvmem rtc: sirfsoc: remove useless sirfsoc_rtc_ioctl rtc: ds1553: switch to rtc_register_device rtc: ds1553: use generic nvmem rtc: ds1553: make alarms useful rtc: cmos: fix possible race condition rtc: cmos: use generic nvmem rtc: ds1742: switch to rtc_register_device rtc: ds1742: use generic nvmem rtc: rp5c01: fix possible race condition rtc: rp5c01: use generic nvmem rtc: stk17ta8: make alarms useful rtc: stk17ta8: switch to rtc_register_device rtc: stk17ta8: fix possible race condition rtc: stk17ta8: use generic nvmem rtc: tx4939: remove arch/mips dependency rtc: tx4939: extend test coverage rtc: tx4939: switch to rtc_register_device rtc: tx4939: fix possible race condition rtc: tx4939: use generic nvmem char: rtc: remove unused rtc_control() api maintainers: rtc: update my email address rtc: ds1511: let the core handle invalid time rtc: ds1553: let the core handle invalid time rtc: cmos: let the core handle invalid time rtc: rs5c348: let the core handle invalid time rtc: stk17ta8: let the core handle invalid time rtc: stop validating rtc_time after rtc_time64_to_tm rtc: stop validating rtc_time after rtc_time_to_tm rtc: stop validating rtc_time in .read_time rtc: ab-b5ze-s3: stop validating rtc_time in .read_time rtc: cpcap: stop validating rtc_time in .read_time rtc: diasemi: stop validating rtc_time in .read_time rtc: nuc900: stop validating rtc_time in .read_time rtc: r7301: stop validating rtc_time in .read_time rtc: sc27xx: stop validating rtc_time in .read_time rtc: isl12022: remove useless indirection rtc: m41t93: stop validating rtc_time in .read_time rtc: max77686: stop validating rtc_time in .read_time rtc: omap: stop validating rtc_time in .set_time and .set_alarm rtc: spear: stop validating rtc_time in .set_time and .set_alarm rtc: tegra: stop validating rtc_time in .set_time rtc: abx80x: remove useless message rtc: pm8xxx: remove useless message rtc: rx4581: remove useless message rtc: rx8581: remove useless message arm: reorder mach-*/kconfig inclusions powerpc/time: stop validating rtc_time in .read_time powerpc/5200: dts: digsy_mtc.dts: fix rv3029 compatible char: nvram: disable on arm rtc: rk808: remove useless debug message rtc: rk808: fix possible race condition rtc: s35390a: remove useless message rtc: s35390a: stop validating rtc_time in .read_time rtc: s35390a: remove useless indirection rtc: rs5c372: remove useless message rtc: rs5c372: stop validating rtc_time in .read_time rtc: rs5c372: remove useless indirection rtc: max6900: stop validating rtc_time in .read_time rtc: max6900: remove useless indirection rtc: pcf85063: stop validating rtc_time in .read_time rtc: pcf85063: remove useless indirection rtc: m41t80: fix race conditions rtc: m41t80: remove useless indirection rtc: pcf85363: add .max_register in regmap_config rtc: pcf85363: add alarm support rtc: pcf85363: set time accurately rtc: fix rtc_time64_to_tm for 3477 rtc: isl12026: fixup nvmem registration rtc: add rtc range rtc: add useful timestamp definitions m68k/time: stop validating rtc_time in .read_time parisc: time: stop validating rtc_time in .read_time dt-bindings: add vendor prefix for microsemi corporation dt-bindings: mips: add bindings for microsemi socs mips: mscc: add ocelot dtsi mips: mscc: add ocelot pcb123 device tree mips: generic: add support for microsemi ocelot maintainers: add entry for microsemi mips socs dt-bindings: interrupt-controller: add binding for the microsemi ocelot interrupt controller irqchip: add a driver for the microsemi ocelot controller pinctrl: ocelot: fix gpio direction rtc: hctosys: ensure system time doesn’t overflow time_t rtc: mv: remove artificial limitation rtc: mrst: remove artificial limitation rtc: st-lpc: remove artificial limitation rtc: 88pm80x: remove artificial limitation rtc: 88pm860x: remove artificial limitation pwm: sun4i: properly check current state alpha: rtc: remove unused set_mmss ops alpha: rtc: stop validating rtc_time in .read_time net: phy: allow scanning busses with missing phys mips: xilfpga: stop generating useless dtb.o mips: xilfpga: actually include fdt in fitimage antoine tenart (23): maintainers: update the inside secure maintainer email crypto: inside-secure – do not overwrite the threshold value crypto: inside-secure – fix the extra cache computation crypto: inside-secure – fix the cache_len computation crypto: inside-secure – do not process request if no command was issued crypto: inside-secure – fix the invalidation step during cra_exit crypto: inside-secure – keep the requests push/pop synced crypto: inside-secure – unmap the result in the hash send error path crypto: atmel-aes – fix the keys zeroing on errors net: mvpp2: enable udp/tcp checksum over ipv6 crypto: inside-secure – move cache result dma mapping to request crypto: inside-secure – wait for the request to complete if in the backlog crypto: inside-secure – move the digest to the request context crypto: inside-secure – fix typo s/allways/always/ in a define crypto: inside-secure – fix a typo in a register name crypto: inside-secure – improve the send error path crypto: inside-secure – do not access buffers mapped to the device crypto: inside-secure – improve the skcipher token crypto: inside-secure – the context ipad/opad should use the state sz crypto: inside-secure – hmac(sha256) support crypto: inside-secure – hmac(sha224) support net: phy: sfp: fix the br,min computation crypto: inside-secure – do not use memset on mmio boris brezillon (26): drm/vc4: expose performance counters to userspace mtd: make sure the device supports erase operations in mtd_erase() mtd: nand: get rid of comments giving the file path inside the file itself mtd: nand: stop using full path when referring to files placed in the same dir mtd: nand: ams-delta: fix path to toto.c source file mtd: nand: state when references to other drivers are no longer valid mtd: nand: add missing copyright information mtd: nand: move raw nand related code to the raw/ subdir mtd: nand: add core infrastructure to deal with nand devices update boris brezillon email address mtd: onenand: get rid of comments giving the file path inside the file itself mtd: move onenand code base to drivers/mtd/nand/onenand mtd: initialize ->fail_addr early in mtd_erase() mtd: get rid of unused fields in struct erase_info mtd: stop assuming mtd_erase() is asynchronous mtd: unconditionally update ->fail_addr and ->addr in part_erase() mtd: stop updating erase_info->state and calling mtd_erase_callback() mtd: rawnand: sunxi: stop supporting ecc_hw_syndrome mode mtd: rawnand: marvell: rename ->ecc_clk into ->core_clk mtd: fsl-quadspi: remove unneeded driver.bus assignment clk: bcm2835: de-assert/assert pll reset signal when appropriate mtd: nand: fix nanddev_mtd_erase() drm/vc4: make sure vc4_bo_{inc,dec}_usecnt() calls are balanced drm/vc4: fix scaling of uni-planar formats mtd: rawnand: make sure we wait twb before polling the status reg mtd: rawnand: marvell: fix read logic for layouts with ->nchunks > 2 gregory clement (41): arm64: dts: marvell: armada-cp110: add registers clock for spi nodes arm64: dts: marvell: armada-cp110: add registers clock for i2c nodes arm64: dts: marvell: use spdx-license-identifier for armada socs arm64: dts: marvell: armada-3720-db: use spdx-license-identifier arm64: dts: marvell: armada-3720-espressobin: use spdx-license-identifier arm64: dts: marvell: armada-7040-db: use spdx-license-identifier arm64: dts: marvell: armada-8040-db: use spdx-license-identifier arm64: dts: marvell: armada-8040-mcbin: use spdx-license-identifier arm64: dts: marvell: armada-8080-db: use spdx-license-identifier arm64: dts: marvell: armada-cp110: add registers clock for sata node hwrng: omap – remove useless test before clk_disable_unprepare hwrng: omap – fix clock resource by adding a register clock arm64: dts: marvell: armada-cp110: add apb_pclk clock for the uart nodes i2c: mv64xxx: apply errata delay only in standard mode maintainers: i2c-mv64xxx: update email address for gregory clement arm64: dts: marvell: armada-cp110: add registers clock for usb host nodes arm64: dts: marvell: armada-cp110: add registers clock for xor engine nodes arm64: dts: marvell: armada-cp110: add registers clock for the trng node arm64: dts: marvell: armada-cp110: add registers clock for the crypto node arm64: dts: marvell: armada-cp110: add registers clock for the nand node arm64: dts: marvell: armada-cp110: add registers clock for the pcie nodes clk: mvebu: cp110: fix clock tree representation crypto: inside-secure – fix clock management crypto: inside-secure – improve clock initialization crypto: inside-secure – fix clock resource by adding a register clock arm: dts: armada-*.dtsi: use spdx-license-identifier for most of the armada socs arm: dts: armada-xp-98dx: use spdx-license-identifier for prestara 98d socs arm: dts: armada-*.dts: use spdx-license-identifier for most of the armada based board arm: dts: armada-370-db: use spdx-license-identifier arm: dts: armada-xp-db-dxbc2: use spdx-license-identifier arm: dts: armada-xp-db-xc3-24g4xg: use spdx-license-identifier arm: dts: armada-388-rd: use spdx-license-identifier arm: dts: armada-385-db-ap: use spdx-license-identifier arm: dts: armada-385-turris-omnia: use spdx-license-identifier arm: dts: kirkwood*.dts: use spdx-license-identifier for boards using gpl-2.0 arm: dts: kirkwood*.dts: use spdx-license-identifier for boards using gpl-2.0+/mit arm: dts: kirkwood*.dts: use spdx-license-identifier for board using gpl-2.0+ mtd: rawnand: marvell: fix clock resource by adding a register clock cpufreq: armada-37xx: fix clock leak usb: host: xhci-plat: remove useless test before clk_disable_unprepare usb: host: xhci-plat: fix clock resource by adding a register clock maxime chevallier (13): net: mvpp2: add hardware offloading for vlan filtering spi: fix scatterlist elements size in spi_map_buf net: mvpp2: simplify mac filtering function parameters net: mvpp2: add support for unicast filtering net: mvpp2: make mvpp2_prs_hw_read a parser entry init function net: mvpp2: don’t use dynamic allocs for local variables net: mvpp2: fix parser entry init boundary check net: mvpp2: fix tcam filter reserved range net: mvpp2: fix dma address mask size net: mvpp2: fix clk error path in mvpp2_probe net: mvpp2: fix clock resource by adding missing mg_core_clk arm64: dts: marvell: armada-cp110: add clocks for the xmdio node arm64: dts: marvell: armada-cp110: add mg_core_clk for ethernet node maxime ripard (36): drm/sun4i: backend: move line stride setup to buffer setup function drm/sun4i: backend: document the engine operations drm/sun4i: backend: allow a null plane pointer to retrieve the format drm/sun4i: backend: add a custom plane state drm/sun4i: engine: add a custom crtc atomic_check drm/sun4i: engine: add a vblank quirk callback drm/sun4i: engine: create an atomic_begin callback drm/sun4i: add a driver for the display frontend drm/sun4i: backend: wire in the frontend drm/sun4i: backend: add a custom atomic_check for the frontend drm/sun4i: backend: use runtime_pm variant of atomic_commit_tail drm/sun4i: backend: make sure we don’t have a commit pending drm/fourcc: add a alpha field to drm_format_info drm/atmel-hlcdc: use the alpha format field in drm_format_info drm/atmel-exynos: use the alpha format field in drm_format_info drm/rockchip: use the alpha format field in drm_format_info drm/vc4: use the alpha format field in drm_format_info drm/sun4i: backend: fix structure indentation drm/sun4i: backend: fix define typo drm/sun4i: framebuffer: add a custom atomic_check drm/sun4i: backend: move the coord function in the shared part drm/sun4i: backend: set a default zpos in our reset hook drm/sun4i: backend: add support for zpos drm/sun4i: backend: check for the number of alpha planes arm: dts: sun8i: a33 enable our display frontend drm/rcar-du: dw-hdmi: fix compilation drm/sun4i: backend: assign the pipes automatically drm/sun4i: remove the plane description structure drm/sun4i: backend: make zpos configurable drm/sun4i: backend: remove argb spoofing regmap: mmio: add function to attach a clock mmc: sunxi: move resources management to separate functions mmc: sunxi: move the reset deassertion before enabling the clocks mmc: sunxi: set our device drvdata earlier drm/sun4i: backend: check that we only have a single yuv plane drm/sun4i: backend: support yuv planes miquel raynal (41): mtd: nand: add ->setup_data_interface() support for marvell nfcv1 mtd: nand: fsmc: get rid of io_addr_[r|w] mtd: nand: fsmc: use ->exec_op() maintainers: update email address for miquel raynal mtd: nand: use marvell reworked nand controller driver with all platforms mtd: nand: remove deprecated pxa3xx_nand driver arm64: dts: marvell: use reworked nand controller driver on armada 7k arm64: dts: marvell: use reworked nand controller driver on armada 8k mtd: nand: remove useless fields from pxa3xx nand platform data dt-bindings: mtd: remove pxa3xx nand controller documentation arm: dts: pxa: use reworked nand controller driver maintainers: remove entry for deleted pxa3xx_nand driver mtd: rawnand: makes the kconfig entry clear when it comes to raw nands mtd: rawnand: rename default ->onfi_get/set_features() implementations mtd: rawnand: rename set/get features related functions mtd: rawnand: use wrappers to call onfi get/set_features mtd: rawnand: handle differently chip/controller errors about timings mtd: rawnand: mxc: remove useless checks in get/set_features functions mtd: rawnand: move calls to ->select_chip() in nand_setup_data_interface() mtd: rawnand: check onfi timings have been acked by the chip mtd: rawnand: avoid setting again the timings to mode 0 after a reset mtd: rawnand: prepare the removal of onfi/jedec parameter pages mtd: rawnand: prepare the removal of the onfi parameter page mtd: rawnand: allow vendors to declare (un)supported features mtd: rawnand: macronix: nack the support of changing timings for one chip mtd: rawnand: get rid of the jedec parameter page in nand_chip mtd: rawnand: get rid of the onfi parameter page in nand_chip mtd: rawnand: gpmi: support ->setup_data_interface() mtd: rawnand: gpmi: use core timings instead of an empirical derivation mtd: rawnand: brcmnand: fix probe function error path mtd: rawnand: cafe: fix probe function error path mtd: rawnand: davinci: fix probe function error path mtd: rawnand: denali: fix probe function error path mtd: rawnand: mxc: fix probe function error path mtd: rawnand: omap2: fix the probe function error path mtd: rawnand: sh_flctl: fix the probe function error path mtd: rawnand: tango: fix probe function error path mtd: rawnand: s3c2410: enhance the probe function error path mtd: rawnand: marvell: fix the chip-select dt parsing logic mtd: rawnand: marvell: fix command xtype in bch write hook cpufreq: armada-37xx: driver relies on cpufreq-dt mylène josserand (2): asoc: codecs: add support for pcm1789 asoc: add bindings for pcm1789 quentin schulz (17): iio: adc: axp20x_adc: put adc rate setting in a per-variant function dt-bindings: iio: adc: add binding for x-powers axp pmics adc iio: adc: axp20x_adc: make it possible to probe from dt iio: adc: axp20x_adc: add support for axp813 adc arm: dtsi: axp209: add node for adc arm: dtsi: axp22x: add node for adc arm: dtsi: axp81x: add node for adc arm: dtsi: axp81x: add battery power supply subnode arm: dtsi: sun8i: a711: enable battery power supply subnode arm: dtsi: axp81x: remove ip name from dt node name iio: adc: axp20x_adc: remove !! in favor of ternary condition arm: dts: sun8i: a83t: add cpu0 and cpu100 labels arm: dts: sun8i: a83t: add stable opp tables and cpufreq arm: dts: sun8i: a711: set regulator for each cluster of cpus power: supply: axp20x_battery: use data struct for variant specific code dt-bindings: power: supply: axp20x: add axp813 battery dt binding power: supply: axp20x_battery: add support for axp813 thomas petazzoni (8): arch/sh: add sh7786_mm_sel() function arch/sh: make the dma mapping operations observe dev->dma_pfn_offset arch/sh: pci: don’t use disabled resources arch/sh: pcie-sh7786: mark unavailable pci resource as disabled arch/sh: pcie-sh7786: exclude unusable pci mem areas arch/sh: pcie-sh7786: adjust pci mem and io regions arch/sh: pcie-sh7786: adjust the memory mapping arch/sh: pcie-sh7786: handle non-zero dma offset author quentin schulz posted on june 6, 2018 categories technical leave a comment on linux 4.17 released, bootlin contributions spi-mem: bringing some consistency to the spi memory ecosystem in this article, we would like to introduce our work on the spi-mem linux kernel framework, which will allow to re-use spi controller drivers for both spi nor devices and regular spi devices, as well as spi nand devices in the future. from spi to dual, quad and octo spi in the good old days, spi was a simple protocol, with only 3 signals shared by all devices present on the bus: miso : master in slave out mosi : master out slave in sclk : serial clock and 1 extra signal per device to select the device we want to communicate with: ss : slave select (also called cs for chip select sometimes) but then spi memories appeared. it started with small and relatively slow ones, like dataflash, eeproms and srams and progressively moved to rather large spi nors and spi nands. as usual when it comes to dealing with memories, we want to get the best performances out of them. spi bus limitations quickly became the bottleneck, so vendors decided to add more i/o lines and make the miso/mosi lines bi-directional. nowadays we see spi controllers that are supporting up to 8 i/o lines. for those who are familiar with the terms, that’s what we call dualspi , quadspi and octospi. in order to use all i/o lines when doing a master to slave or slave to master transfer, there must be some kind of contract between the slave and the master so that both of them know when they can receive or transmit data on the i/o lines and how many of them they should use. this is done through a predefined set of operations exposed by the slave that the master has to follow to enter a specific transmit or receive state. a spi memory operation is usually composed of: 1 byte opcode encoding the operation to be executed (but be prepared for 2 bytes opcode, they are coming) 0 to n address bytes whose meaning is dependent on the opcode (can be an absolute memory address or something else) 0 to n dummy bytes to leave the slave enough time to enter the specific state requested through the opcode. again, the number of dummy bytes depends on the opcode 0 to n in or out data bytes, the direction depends on the opcode note that, while this protocol tends to be used by memory devices, there’s nothing restricting it to memories, and i wouldn’t be surprised if some fpga were using the same kind of transactions for things that are not memory oriented at all. the linux spi ecosystem linux has been supporting dual and quad spi mode for quite some time already (v3.12), and spi device drivers could specify the number of i/o lanes for each spi transfer. this way, a spi memory operation could be broken out in several spi transfer each of them using a pre-defined number of i/o lanes. that worked just fine until some ip vendors decided to make their spi controllers smarter and embed some kind of high-level interface to execute spi memory operations in a single step instead of splitting it in several transfers (actually, most spi controllers are even smarter than that and allow you to directly map a spi memory in the cpu address space, but let’s keep that for a future post). at this point, we needed to give more control to the spi controller so that it could decide what to do exactly, without having to reconstruct a spi memory operation out of a group of spi transfers. at that time, the decision has been to dedicate those controllers to one single task: control spi nors (which were the only user of quad and dual mode back then), and the spi nor framework was created for this reason. due to this decision, we now have in linux a spi nor frame work which connects spi nor controller drivers to the spi nor logic on one side ( spi-nor subsystem ), and we have regular spi controller drivers which can do basic spi transfers ( spi subsystem ). however, from a hardware point of view, advanced spi controllers that provide special features for spi nor can often also do basic transfers, and therefore control regular spi devices. unfortunately, with the current split between the spi-nor and spi subsystems, if a spi controller is supported by a driver in the spi-nor subsystem, it cannot be used to communicate with regular spi devices normally managed by the spi subsystem. as a partial solution to solve this problem, the ->spi_flash_read() operation was added to struct spi_controller . this allowed regular spi controller drivers in the spi subsystem to provide an optimized way to read from a spi nor memory, which is used by the generic spi nor driver m25p80 . however, this solution is partial, as it only optimizes reading and is limited to spi nors. in the current stack, we have: the spi nor framework, which knows the protocol to talk to spi nor memories. this framework relies on an interface listed in struct spi_nor , which is implemented by: specialized spi nor controllers, which support advanced spi controllers dedicated to spi nors. the m25p80 driver, which provides the same interface, but on top of dumb/regular spi controller drivers, with the possible optimization of ->spi_flash_read() what led us to propose the spi memory interface? we’ve seen before that the spi nor case was already properly supported thanks to the spi nor framework. but nors are not the only memory devices you’ll find on a spi bus, spi nands are becoming more and more popular. peter pan proposed a framework to handle spi nand devices which was following the spi nor model: spi controllers had to implement the spi nand controller interface in order to control spi nands. but when we got more deeply involved in this development, we quickly realized how messy it would be to follow this path, because that meant forcing spi controllers to implement both the spi nor and spi nand interface if they want to be able control both kind of device. and what will happen when the trend will be at spi nvram or any other kind of storage manufacturers decide to put on a spi bus? adding yet another interface that spi controllers would again have to implement didn’t sound like a good idea. so instead, we decided to take the problem from the other end, and tried to figure out what spi nands and spi nors have in common. the instruction set is different, the behavior and constraints are different (mainly due to nor vs nand differences), but they both follow the same spi memory operation semantic when interacting with the device, the same one advanced controllers are trying to optimize. the spi memory layer is just a way for spi controller drivers to be passed high-level spi memory operations instead of letting them handle spi transfers and try to optimize them themselves. it also simplifies spi memory drivers’ life, since all they have to care about is sending spi memory operations based on the spi memory specs. no need for a complex, constantly evolving, memory dependent interface. with this new stack, both spi nor and spi nand can be supported on top of the same spi controller drivers. the m25p80 driver is modified to use the spi-mem interface instead of the limited ->spi_flash_read() interface. for now, we still have dedicated spi nor controller drivers, but the goal is to rid of them, and implement them as regular spi controllers in drivers/spi . help and contributions in this direction are very welcome! what does the spi memory api look like? the spi memory api is exposed in include/linux/spi/spi-mem.h . spi device drivers who want to use the spi memory api should declare themselves as spi_mem_driver s and implement the ->probe() and ->remove() functions. they will be passed a spi_mem object which is just a thin wrapper around a spi_device object. the reason we have a different object is because we want to be able to extend the spi_mem object and attach more information to it if required (like the type of memory, the memory organization and other kind of information advanced spi controllers might want to know). when a driver wants to execute a spi memory operation, it will fill a spi_mem_op struct and call spi_mem_exec_op() . one can also test if a spi controller is supporting a specific memory operation with spi_mem_supports_op() or try to split data transfers so that they don’t exceed the max transfer size supported by the controller with spi_mem_adjust_op_size() . now, let’s have a look at the controller side of things. an spi controller who wants to optimize spi memory operations can implement the spi_mem_ops interface which contains 3 methods that are directly matching the user api: ->exec_op() : execute the memory operation or return -enotsupp if it’s not supported ->supports_op() : just check if the memory operation is supported ->adjust_op_size() : adjust the size of the data transfer of a memory operation to cope with alignment and max fifo size constraints note that when spi_mem_ops is not implemented, the core will add generic support for this feature by creating spi messages formed of several spi transfers, just as the generic spi nor controller driver (named m25p80) was doing before. as you can see, the api is pretty straightforward, so hopefully, more spi memory drivers will be converted to use it instead of manually creating spi messages containing several spi transfers. current status a number of things have already been contributed and merged, scheduled to be part of the 4.18 linux kernel release: the spi-mem layer itself, in commit c36ff266dc82f4ae797a6f3513c6ffa344f7f1c7 . the two spi controller drivers who were implementing the ->spi_flash_read interface now implement the spi-mem interface instead: bcm-qspi and ti-qspi . the ->spi_flash_read interface is removed in commit c1f5ba70decfc2f35edcc10505e3e78fb528d212 . the m25p80 driver is modified to use the spi-mem layer in commit 4120f8d158ef904fb305b27e4a4524649faf3096 . what’s next? advanced spi controllers can do more than just optimizing the execution of spi memory operations, they can often hide all the complexity of memory accesses behind a directly-mapped iomem region, which, every time it is accessed, triggers a spi memory operation on the bus and retrieves or sends the data for you, thus behaving like a memory that would be placed on a parallel memory bus. as you can imagine, this allows for even higher throughput and less cpu time consumed for spi mem op management, but it’s also something that is hard to expose in a generic way. we have posted on the linux-mtd mailing list a proposal to support such a direct mapping capability. as detailed earlier, another challenging topic is the conversion of all spi nor controller drivers to the spi mem model so that all qspi controllers are really exposed as spi controllers and not spi nor controllers. this is likely to take a bit of time since we currently have 10 drivers in drivers/mtd/spi-nor and we’re only aware of 2 of them being converted to the spi mem approach ( fsl-quadspi and atmel-quadspi ). author boris brezillon posted on june 4, 2018 format image categories technical 1 comment on spi-mem: bringing some consistency to the spi memory ecosystem allwinner vpu support in mainline linux status update (week 22) integration with video players the work conducted this week on the video output side was focused on writing a shader for untiling the mb32 nv12-based format used by the vpu to output frames. this brought various challenges, some of which are presented below. since gles and egl are generic apis that are not tied to a particular driver implementation, it made sense to start writing the shader on an x86 intel-based device with gpu support in mesa 3d (and speed-up the development time). the first step to the process was to display the raw pixel values from the luminance plane through the shader. actually, two shaders are required: one for the vertex processor and one for the fragment (pixel) processor of the gpu. the former is in charge of applying geometrical operations to the vertices (the points that define the 3d mesh) while the latter defines the color for each rendered pixel from that mesh. in our case, the mesh is simply a rectangle that matches our window size. the tiled nv12 luminance plane is uploaded to the gpu as a 1-byte-per-pixel texture, which allows addressing each component separately. however, the coordinates for the texture are normalized by the gpu, so coordinates to retrieve texels (texture pixels) form the texture sampler are specified as decimal values. this makes it tricky to ensure that the right value is retrieved, especially given that the gpu might apply various filtering techniques (that are a really good thing to have when dealing with actual textures for 3d models, though). setting up the vertex and fragment shaders to linearly display the pixels from the tiled format results in a mangled display (as expected): thanks to the documentation made available by the linux-sunxi community , it was possible to rapidly draft a formula for getting the right texel location, that produced mitigated results: with some extra work (and quirks for ensuring that the right texel is picked on tile edges), the luminance component was finally displayed correctly: next up was the chrominance component, that required importing a second dedicated texture. first tries lead to funky-looking coloring of the frame: until the shader was corrected to end up with a good-looking picture: real trouble began when porting this work to the mali, that does not behave the same when it comes to texture uploads (and requires line-by-line upload for 1-byte-per-pixel formats). since we are aiming at dmabuf import instead of (slow) texture upload, no time was spent coping with the difference. the main issue with dmabuf import is that the usual one-byte-per-pixel format (described by the drm_format_r8 fourcc code) is simply not supported by the gpu, leaving only rgb and yuv as options, that do not directly fit the bill. we are still investigating ways to make our texture available to the gpu’s texture sampler without extra copies (or with copies that can fit our bill in terms of performance). h264 support we also worked on the h264 decoding in the kernel, and some progress was made. the libva-dump and cedrus-frame-test ports are now done, and we’ve been able to run cedrus-frame-test on 32 frames without any hiccups… unfortunately, while the vpu reports the frames as properly decoded, the contents of the output buffer is blank, which is obviously not great. since then, we have simplified the test to have a single frame decoded, and compared the register write sequence between libvdpau-sunxi and our kernel code. this has allowed us to find some bugs in the driver, but the current state is still that we can’t decode a frame. we shouldn’t be very far now though, so stay tuned for our next status update! author paul kocialkowski posted on june 1, 2018 categories technical tags allwinner , kickstarter , vpu 1 comment on allwinner vpu support in mainline linux status update (week 22) allwinner vpu support in mainline linux status update (week 21) this week’s effort was focused on getting vlc to accelerate its video output using the mali proprietary blobs. more specifically, two distinct interfaces are involved: egl , that allows interacting with the platform’s windowing system (in our case, x11) and gles , that is in charge of the rendering operations. while vlc already had support for both of these interfaces, it initially failed to create and use its gl-backed video output module with the mali gpu blobs. although everything indicated that it should have been working, the gles calls were failing while egl was setup and behaving correctly. the issue at hand was directly related to vlc using qt for its interface. because the qt build used on the development boards was targeting gl support instead of gles, it needed to import gl symbols that have the same name as gles equivalents. since qt was loaded after the video output module, it would override the matching gles symbols with gl symbols (from mesa, not the blob). with the help of thomas guillem, a few patches were crafted to fix the issue and sent out to the vlc developers. some more revisions of these patches will be needed for the fix to integrate the vlc tree, but it should land sooner or later. with vlc fixed, it was time to start looking at accelerating our pipeline with the gpu. vlc already includes gpu shaders for nv12 to rgb conversion as well as scaling and rotation, but does not have support for our tiled format. this is why we need a shader on our vaapi backend side to accelerate the untiling operation. while the shader is currently work in progress, further work is also required to properly export the resulting untiled buffer as a dmabuf handle for vlc. since the gpu blob does not support dmabuf export, we will need to implement a standalone gbm provider compatible with our drm driver, that will handle allocating surfaces (instead of the armsoc ddx that is currently used for accelerated graphics on x) and exporting dmabuf handles to them when needed. generally speaking, this will also allow standardizing and sanitizing the integration of the mali blobs with the rest of the system. stay tuned for our next update! author paul kocialkowski posted on may 25, 2018 categories technical leave a comment on allwinner vpu support in mainline linux status update (week 21) allwinner vpu support in mainline linux status update (week 20) with dmabuf support tested, it has become possible for paul to start the work on integrating a gpu-based video output pipeline with sunxi-cedrus. using the gpu should greatly improve performance when it comes to displaying the video frames. as of now, we have been using software untiling , software yuv-to-rgb colorspace conversion and software scaling. we are looking to replace these steps with gpu-based untiling, colorspace conversion and scaling. shaders are used to implement these operations: they are small programs that are compiled on-the-fly for the gpu’s very specialized instruction set. most players embed shaders (in their source form, using the gl shading language) for usual operations like colorspace conversion and scaling. however, these players are not ready to handle untiling as of now (or even be notified that the format returned by our vaapi backend is tiled). the first step in our plan is to get vlc to cooperate with the x11 flavor of the mali proprietary blobs that allwinner has released in the past so that we can use gpu support for colorspace and scaling. this is still a blocking point as of now. then, we will look into crafting a shader for untiling the vpu output frame and integrating it with our libva-cedrus vaapi backend . as a sidenote, the free software lima driver is being prepared for a first rfc series, bringing the first bits of mainline linux kernel support for mali gpus of the utgard generation. so even though work on the gpu only concerns the proprietary blob for now, the work will eventually become useful to the free software driver as well. we have also tested sunxi-cedrus on the h3 and started looking at integrating the display part (which differs from earlier socs by using a revised display engine: de2). however, since this is a strech goal of the fundraiser and that we have many other tasks left to tack among our main goals, this is by far not our priority at the moment. we finally worked more on the libva-dump and cedrus-frame-test for h264, which will hopefully allow us to test our first h264 decoding next week! stay tuned for our next progress update! author paul kocialkowski posted on may 19, 2018 categories technical leave a comment on allwinner vpu support in mainline linux status update (week 20) testing pixel formats on the raspberrypi as part of our ongoing work with the raspberrypi foundation , we’ve been working on a number of display-related topics recently. besides the work done by my colleague boris brezillon on improving the kernel side support for a number of features (such as the gpu performance counters support , memory management improvements , etc.), i’ve been working on improving the ci infrastructure for display driver testing . indeed, the current workflow is not automated at all and doesn’t allow to detect breakages in the display driver. we thus needed to improve that. to do so, we’ve relied on a board developed by google as part of the ongoing ci-effort on chromeos that is called the chamelium . the chamelium is based on an arm board powered by an altera soc+fpga platform that google extended with an extension board with video connectivity: vga, hdmi and displayport. they then developed a firmware for the fpga to allow the board to emulate a screen. a raspberrypi and the chamelium using this, you can simulate improper edids, simulate hotplug events, hdcp screens, etc. and see how the device under test reacts to that. one of the interesting things you can do with it is to dump a crc of the frame received on the display link, or a raw capture of a given number of frames. the usefulness of such a feature is obvious for a ci effort: you connect the device to test over hdmi, vga or dp to the chamelium, and then you can setup a test pattern on the device you want to test, capture the frame received on the other end, and compare the two frames. in an ideal scenario, the two are identical, and if your driver has a regression, you’ll notice as the two frames would no longer be identical. the intel-gpu-tools suite (also called i-g-t ), even though historically named with a not-so-generic name, is a standard test suite for the drm subsystem in linux. last summer, the support for the chamelium has been introduced for exactly this setup, where intel-gpu-tools would setup a test pattern, ask the chamelium for a crc of the frames it received and do the comparison. this was working fine, and after a quick test on the raspberrypi, it turned out to work on non-intel hardware out of the box. however, the test was actually quite simple: while it was testing all the resolutions exposed, it was only testing a single pixel format, and we wanted to do more in order to catch regressions in less common formats, and ideally the raspberrypi proprietary formats as well. when it comes to pixel formats, there are two main families involved: the rgb formats , sometimes prefixed with an a (for alpha, the opacity) or x (for padding), and the ycbcr family (also called abusively yuv). the former will have different values for each primary color, encoded on a number of bits following the rgb prefix. xrgb1555 for example will be a 16 bits format (1 + 5 + 5 + 5), with 1 bit of padding, and 5 bits for red, green and blue in that order. the ycbcr formats , based on the property of the human eye that it perceives better the changes in luminosity than in color and will thus store the luminance (y) and chrominance (cb and cr) in separate fields, with possibly a different number of bits. while rgb is usually preferred by computer graphics, video is very fond of the ycbcr formats since you can compress the cb and cr fields, resulting in a denser pixel format, without degrading the image quality too much. the format initially supported by intel-gpu-tools was the xrgb8888 (8 bits of padding, 8 bits for red, green and blue, in that order). the raspberrypi supports the rgb formats xrgb8888, argb8888, abgr8888, xbgr8888, rgb565, bgr565, argb1555, xrgb1555, rgb888, bgr888. like we said, i-g-t was on the contrary using only an xrgb8888 format for the test pattern. this unfortunately was based on a few assumptions, the first one being that the test pattern would be generated with cairo . however, cairo supports a very limited range of formats. on the formats supported on the raspberrypi, cairo only supported argb8888, xrgb8888 and rgb565. this was obviously not enough, but we didn’t really want to extend cairo since our goal was to be able to run the test suite on as many devices as possible. one option would have been to update the version of cairo in use to support a larger number of formats, but that was not considered to be the most appropriate solution. we thus evaluated our options, and it turned out pixman supports most of the rgb formats, and it was already a dependency of intel-gpu-tools . so in a patch series that we submitted recently to the intel-gpu-tools project, we: create an api to allow the core i-g-t functions that handle the buffers to let us simply map the underlying drm buffer in order to access it, without having to use cairo and its limited pixel format support rework the code a bit to be able to use cairo when relevant, and then fallback to pixman if the format isn’t supported. pixman list of formats supported isn’t ideal either, especially in the ycbcr family, but we focused on rgb first. in order to allow for additional fallbacks, we hid it behind an api so that it’s transparent to the users create a custom pattern solely for the chamelium test, which was needed to deal with the difference of sampling size for each color component glue those functions into the chamelium test suite and add one sub-test for each format, so that we can detect both regressions in handling the format itself, but also regressions in the list of formats exposed add a vc4 test suite , extended with chamelium based tests all this work has then be submitted to the intel-gpu-tools mailing list for review, and while the development was done on a raspberrypi, it should benefit the whole community. author maxime ripard posted on may 18, 2018 may 18, 2018 categories technical leave a comment on testing pixel formats on the raspberrypi allwinner vpu support in mainline linux status update (week 19) this week has seen considerably less advancement than the ones before it due to bank holidays in france. nevertheless, we managed to prepare and send v3 of the sunxi-cedrus linux kernel driver on monday. while this new version contains several incremental improvements, a number of tasks (described in the series’ cover letter) have yet to be completed before the driver can be merged in mainline linux. maxime continued to work on the h264 support. the big part of the kernel has been done, and he then moved on to convert libva-dump to be able to dump also h264 buffers. most of that part has been done as well, so the next item will be to convert cedrus-frame-test to be able to test h264 frames, and see where that takes us. paul kept working on dmabuf support, which is now refined and ready both on the kernel side and on the userspace side with cedrus-frame-test . there is now a single dmabuf handle used per buffer plane (instead of per-plane) which allows having all components of the frame displayed correctly. because there is now as many buffers for display as there are for decoding, it is necessary to register framebuffers associated with each imported buffer and cycle the framebuffers in multi-buffering page-flipping. to tackle this, we have started implementing atomic modesetting in cedrus-frame-test, allowing to set the framebuffer to use per-plane. finally, some attention was given to the integration of our video decoding pipeline with the mali gpu, especially to target kodi support. stay tuned for our next update! author paul kocialkowski posted on may 11, 2018 categories technical leave a comment on allwinner vpu support in mainline linux status update (week 19) allwinner vpu support in mainline linux status update (week 18) this week, paul continued working on dmabuf support and succeeded at exporting a buffer allocated by the sunxi-cedrus driver on the v4l2 side and importing it on the drm side via dmabuf. although dmabuf support is still a work in progress in cedrus-frame-test and beyond the current level of support we have with gstreamer, the kernel side of things should be ready. another excerpt of the big buck bunny video, in 1080p test coverage was also improved this week, with significantly more mpeg2 videos tested (including a standard dvd) in different resolutions up to 1080p. some feedback from the community was also received and a first issue report will need to be investigated. regarding platform support, initial testing of the a13 was undertaken. although the vpu driver works apparently just as well on the a13 as already-tested platforms, the drm driver adaptation (on the display side) for untiling vpu output buffers appears to be broken and will need to be further investigated. in other news, a new version of the media request api has been submitted without the rfc tag (after 12 previous iterations). while we’ve been testing this new version along the course of its development, we are also taking the occasion to rebase our sunxi-cedrus vpu driver on top of this new version and take the received feedback into account. maxime continued the work on h264, and almost finished a first draft for the kernel driver side. most of the code should be there now, the next steps are going to be making sure that no parts are missing and starting to test with cedrus-frame-test! author paul kocialkowski posted on may 4, 2018 may 5, 2018 categories technical leave a comment on allwinner vpu support in mainline linux status update (week 18) allwinner vpu support in mainline linux status update (week 17) this week started off with numerous reviews received on the patchset introducing the sunxi-cedrus vpu driver . lots of constructive comments, questions and improvements were discussed, which will help improve the driver for the next iteration of the series. changes to other drivers will also have to be implemented, in particular to the sram controller found on allwinner platforms, which needs to handle access to the sram by the vpu. maxime worked on refactoring needed to ease the support for the h264, rebasing on the latest version submitted upstream and making sure that everything still works fine. he eventually pushed them in our 4.17 branch on github, and will now focus on landing h264 support itself. the work carried out by paul this week was focused on the libva-cedrus vaapi backend , which supports the sunxi-cedrus kernel driver on the userspace side. the backend is used by vlc (when it is configured to use vaapi for video decoding) to play mpeg2 videos such as the ones available from the linaro sample media . libva-cedrus was significantly improved over the week, with around 80 commits featuring a major cleanup of the code that includes, along with other changes: coding style harmonization proper error checking and reporting instead of assertions the removal of the unsupported mpeg4 code the introduction of dedicated v4l2 helpers based on those developed for cedrus-frame-test the reorganization of v4l2 source and destination buffers management, where both are now tied to a specific surface and kept in sync the update of the definitions to match the latest patchset the implementation of the final rendering at picture end time this work significantly improved the compatibility with vlc, which was previously dropping several frames. with these changes, vlc is now properly showing the decoded videos playing close to 25 fps when there is no software scaling involved. the performance is not as good with vlc as it is with cedrus-frame-test, which uses a dedicated drm plane directly while vlc and libva-cedrus use the software untiling code and buffer copies to display each frame. vlc playing the big buck bunny video with libva-cedrus some attention was also given to gstreamer over the week. although compatibility with our vaapi backend and display pipeline is not there yet, the vaapi backend rewrite allowed moving forward and gstreamer now displays the first decoded frame. while the operations for decoding the frames are correctly scheduled, they are only requested to be displayed sporadically, with no effect on the screen. this issue will need to be further investigated before a basic decoding pipeline can be used with gstreamer, with a video output either to a regular x window or to a drm plane directly. mpv was also tested out this week, without much success in coordinating the rendering and display parts involved with the vaapi pipeline. thus, mpv support will also require more investigation before it can be properly supported. while we initially decided to focus on gstreamer for implementing dmabuf buffer sharing between the vpu and the display engine, cedrus-frame-test (the standalone userspace implementation supporting the sunxi-cedrus vpu driver) allows us to directly work on implementing dmabuf support. so even though gstreamer does not work with libva-cedrus at this point, dmabuf support was started in a dedicated branch of the cedrus-frame-test repository . dmabuf is currently failing on the kernel side, when validating the page number of the requested dma buffer. in this area as well, further investigation and work will be needed. in the meantime, the sunxi-cedrus page on the linux-sunxi wiki was updated with the latest status of sunxi-cedrus support, instructions to build and install libva-cedrus and cedrus-frame-test as well as configure vlc for decoding mpeg2 videos. feedback and test reports are welcome, especially regarding videos that are not decoded properly and show visual artifacts. the community around sunxi-cedrus hangs out on the #linux-sunxi and #cedrus channels of the freenode irc network, so it is the best place to ask questions and discuss all things related to sunxi-cedrus! stay tuned for next week’s progress report! author paul kocialkowski posted on april 27, 2018 april 27, 2018 categories technical leave a comment on allwinner vpu support in mainline linux status update (week 17) posts navigation page 1 page 2 … page 35 next page search for: search next training sessions dates embedded linux linux kernel buildroot yocto / openembedded useful links version française newsletter quick news (twitter) quick news (google+) news and discussions (linkedin) follow new articles recent articles allwinner vpu support in mainline linux status update (week 23) linux 4.17 released, bootlin contributions spi-mem: bringing some consistency to the spi memory ecosystem allwinner vpu support in mainline linux status update (week 22) allwinner vpu support in mainline linux status update (week 21) allwinner vpu support in mainline linux status update (week 20) testing pixel formats on the raspberrypi allwinner vpu support in mainline linux status update (week 19) allwinner vpu support in mainline linux status update (week 18) allwinner vpu support in mainline linux status update (week 17) home engineering training docs community company bootlin privacy policy proudly powered by wordpress

URL analysis for free-electrons.com

https://bootlin.com/blog/allwinner-vpu-support-in-mainline-linux-status-update-week-19/
https://bootlin.com/blog/allwinner-vpu-support-in-mainline-linux-status-update-week-20/#respond
https://bootlin.com/blog/allwinner-vpu-support-in-mainline-linux-status-update-week-23/
https://bootlin.com/blog/author/maxime/
https://bootlin.com/docs/
https://bootlin.com/blog/linux-4-17-released-bootlin-contributions/#respond
https://bootlin.com/engineering/
https://bootlin.com/page/35/
https://bootlin.com/company/
https://bootlin.com/company/staff/boris-brezillon/
https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor
https://bootlin.com/blog/tag/vpu/
https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/
https://bootlin.com/wp-content/uploads/2018/06/glsl-untiler-chroma-wip.png
https://bootlin.com/blog/allwinner-vpu-support-in-mainline-linux-status-update-week-21/#respond

Whois Information

Whois is a protocol that is access to registering information. You can reach when the website was registered, when it will be expire, what is contact details of the site with the following informations. In a nutshell, it includes these informations;

Domain Name: FREE-ELECTRONS.COM
Registry Domain ID: 115195350_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.gandi.net
Registrar URL: http://www.gandi.net
Updated Date: 2017-01-25T13:36:19Z
Creation Date: 2004-03-26T12:12:56Z
Registry Expiry Date: 2018-03-26T11:12:56Z
Registrar: Gandi SAS
Registrar IANA ID: 81
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +33.170377661
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: A.DNS.GANDI.NET
Name Server: B.DNS.GANDI.NET
Name Server: C.DNS.GANDI.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2017-08-06T23:02:25Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.

  REGISTRAR Gandi SAS

SERVERS

  SERVER com.whois-servers.net

  ARGS domain =free-electrons.com

  PORT 43

  TYPE domain

DOMAIN

  NAME free-electrons.com

  CHANGED 2017-01-25

  CREATED 2004-03-26

STATUS
clientTransferProhibited https://icann.org/epp#clientTransferProhibited

NSERVER

  A.DNS.GANDI.NET 173.246.98.1

  B.DNS.GANDI.NET 213.167.229.1

  C.DNS.GANDI.NET 217.70.179.1

  REGISTERED yes

Mistakes

The following list shows you to spelling mistakes possible of the internet users for the website searched .