- Feb 13, 2010
I just want to test if windows move faster ;^) .
Yes, SD access is soooo sloooow !
Yes, SD access is soooo sloooow !
You normally almost never have to modprobe a module (unless you first removed it manually) since the kernel will automatically load it when it detects a compatible device. The reason is hasn't is probably that it's missing from Device Tree.modprobe etnaviv
=> [30257.923139] driver_register 'etnaviv-gpu'
=> [30257.928086] driver_register 'etnaviv'
What next? I didn't found any info for testing 2D part of this driver.
No I haven't.
How would the GC320 help with that? It's a blitting engine. If you want video decoding acceleration you need IVA-HD working, which is going to be non-trivial...I'm interested in this 'cause I'd like to see video acceleration soon, I'm sick of having a high cpu usage when watching.
I think etnaviv is the good module for GC320, but it might need user space software.I think, slaeshjag is right, that the build in kernel module etnaviv is not the right kernel module for 2D.
In particular this January 2016 commit looks promising (for those using X11 on a GC320). From a quick browse it seems to split a package in two (one for etnaviv and one for the proprietary driver) and it seems
I'm not sure, but maybe bltsville has two options: ticpu for software rendering and gcbv for the proprietary driver, so does not work with the free driver (Etnaviv)I will check bltsville again, but i looked at before and found no samples/tools for it, so i checked alternatives.
the exfat stuff is in the regular debian repository. Only anything specific to the pyra is put into the Pyra debian repository.What is the URL for the Pyra's debian repo? I want to see if the packages for making and mounting exfat partitions are in there.
Oh, thanks!the exfat stuff is in the regular debian repository. Only anything specific to the pyra is put into the Pyra debian repository.
You can't just modprobe a kernel driver and have it magically work. The kernel will load it but it will have no idea what it is for and it is left unused. Unlike USB or PCI devices which can be detected and recognized based on standardized embedded identification, there is no standard way to even detect let alone identify a platform device. These need to be described in Device Tree:I have it now, but unfortunately changes nothing, I don't even see it in Xorg log.
This shows the kernel will use this driver if it finds a DT node with compatible="marvell,dove-gpu-subsystem" or compatible="fsl,imx-gpu-subsystem". This immediately raises the question why the driver uses different identifiers for these two particular instances of a GC core (e.g. platform-specific quirks?) and whether a third one needs to be added for our use case. I have not inspected the driver but this will need to be done.alias: of:N*T*Cmarvell,dove-gpu-subsystem
I'm not so much worried about the userspace part as I am about kernel components it will undoubtedly require to load firmware blobs onto and otherwise interact with the hardware subsystems. But who knows, maybe it turns out to be relatively painlessWhat's wrong with TI's GStreamer implementation?
As far as I can see the code for everything is available under a custom (but quite open) license. It looks like they are using the M4s to manage IVA-HD, which of course requires some firmware (both available as source code and binaries).it will undoubtedly require to load firmware blobs onto and otherwise interact with the hardware subsystems. But who knows, maybe it turns out to be relatively painless
Wow, so accelerated video is pretty much a given?As far as I can see the code for everything is available under a custom (but quite open) license. It looks like they are using the M4s to manage IVA-HD, which of course requires some firmware (both available as source code and binaries).
However, it looks like it expects the firmware to be already loaded, which is kind of annoying if one wants to use the M4s for something else.