paulk-collins has quit [Remote host closed the connection]
paulk-collins has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
paulk-leonov has joined #linux-sunxi
paulk-leonov has quit [Client Quit]
paulk-aldrin is now known as paulk-leonov
paulk-leonov is now known as paulk-gagarine
paulk-gagarine is now known as paulk-armstrong
paulk-armstrong is now known as paulk-aldrin
paulk-leonov has joined #linux-sunxi
paulk-leonov has quit [Remote host closed the connection]
hero100 has quit [Ping timeout: 260 seconds]
pekka10 has quit [Quit: WeeChat 1.2]
pekka10 has joined #linux-sunxi
hero100 has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
tgaz has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Equilibrium 4.2.0, revision: 42021, sources date: 20120701, built on: 2013-10-21 12:25:22 UTC 42021 http://www.kvirc.net/]
Andy-D has quit [Ping timeout: 244 seconds]
premoboss has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Netlynx has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 244 seconds]
vishnup has quit [Ping timeout: 244 seconds]
laga has joined #linux-sunxi
<laga>
hey there. I am trying to use interrupts with pins PC22/PC21 on my a20-olinuxino-lime2. poll never reads even though the the value does change and I have configured the 'edge' file.
<laga>
are interrupts for gpio on the a20 working at all?
Andy-D has quit [Ping timeout: 252 seconds]
Andy-D has joined #linux-sunxi
vishnup has joined #linux-sunxi
Andy-D has quit [Ping timeout: 276 seconds]
IgorPec has joined #linux-sunxi
vishnup has quit [Ping timeout: 244 seconds]
<plaes>
laga: which kernel?
<plaes>
there were some issues that were fixed recently
<longsleep>
willmore: It seems like that - they are listed in the specs under basic information.
IgorPec has joined #linux-sunxi
<willmore>
wikipedia says: Extensions All mandatory: Thumb-2, NEON, Jazelle, VFPv4-D16, VFPv4
<longsleep>
willmore: thanks for confirming
<willmore>
The optional bits are crc, crypto, and lse
* willmore
is not an authoritative source of ARM information.
<willmore>
YMMV, some restictions apply, not available in all areas, results may not be typical...
<lvrp16>
:D
hulu1522 has quit [Remote host closed the connection]
doppo has quit [Ping timeout: 246 seconds]
doppo has joined #linux-sunxi
<lvrp16>
ask a professional before use, keep out of reach of children, in case of overdose, get help or contact arm right away
<willmore>
Thanks, there was file I remember reading back in the early 90's that was all of those warnings in one big blob. It was a hilarious read.
tomboy64 is now known as o_O
o_O is now known as Guest84403
Guest84403 is now known as tomboy64
<lvrp16>
reminds me of this from philosophy class
<lvrp16>
Determinism Safety Advisory: Every citizen be advised that despite the possibility that his or her acts are all entirely predetermined by the blind mechanical nature of the universe and are therefore unavoidable and inescapable, he or she will still incur a legal responsibility and liability for any torts, violations, misdemeanors, or felonies he or she
<lvrp16>
commits.
<willmore>
Yep. ;)
fdcx has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
mosterta|2 has joined #linux-sunxi
The_Loko has quit [Ping timeout: 268 seconds]
fdcx has quit [Ping timeout: 260 seconds]
<apritzel>
the Cortex-A53 TRM is the authority here, chapter 1.5 lists the configuration options
<apritzel>
and sorry to say, but NEON and VFP are optional
<apritzel>
(although I believe both are bundled, so it's either both or none)
<willmore>
apritzel, they left them out of the A32 core as well, IIRC, but then again they left out AARCH64, too. Thanks for the clarification. I did warn I wasn't authoritative. :)
vishnup has quit [Ping timeout: 248 seconds]
<apritzel>
as said it is optional in the _integration_, so it's up to the SoC vendor to integrate it or not
<longsleep>
apritzel: oh thats crap, so the kernel should add the features to cpuinfo
<apritzel>
so far I am not aware of any A53 SoC which leaves fp out
<apritzel>
longsleep: so what's wrong with "fp asimd"? ;-)
<longsleep>
well, nothing but i have code checking for neon, vfpm edsp
<longsleep>
vfp
<longsleep>
no m
<apritzel>
in compat mode you should get the old names
<ssvb>
apritzel: there is "A1.5 Floating-point and Advanced SIMD support" section in the ARMv8 architecture reference manual
<apritzel>
ssvb: sure, what's the problem?
<longsleep>
apritzel: ah thats good - is there a reference table somewhere for those names?
<ssvb>
there is no problem, it just says that floating-point and Advanced SIMD support is mandatory
<ssvb>
at least for "standard operating systems with rich application environments"
<apritzel>
ssvb: do you have the latest edition?
<apritzel>
I remember there was some discussion about that lately
<ssvb>
I guess, somebody might use the A53 core in some very specialized equipment and configure it without NEON and VFP
<apritzel>
indeed, it is mandatory for A57, for instance
<apritzel>
off to the playground ...
avph has quit [Ping timeout: 246 seconds]
<ssvb>
I think this particular wording in the manual means that NEON is mandatory for the operating systems designed to be able to run user applications, such as Android, Linux, Windows, etc.
<longsleep>
ssvb: i am looling into sources for xf86-video-fbturbo, it does not do much on a53 as it does not detect the cpu features
<ssvb>
longsleep: yes, exactly, it should behave more or less in the same way as xf86-video-fbdev at the moment
<longsleep>
ssvb: you have checks in there of edsp, vfp, neon and iwmmxt, and no check for a53 arm part number, i wonder what is the best way to support a53 in the detection or what would happen if i just add the detection
<ssvb>
longsleep: on 32-bit systems it should use VFP for uncached memory readback by default if the core type is not detected
<longsleep>
ssvb: well i also have the problem that there is no /dev/g2d - could you give me a hint what that device is, where its supposed to come from?
avph has joined #linux-sunxi
<ssvb>
longsleep: there is probably no G2D hardware in A64, I have just checked the A64 SDK kernel sources and seems like we have some simplified hardware instead of G2D and SUNXI_TRANSFORM driver is used for it
<ssvb>
responsible for doing conversion between different pixel formats and rotation
<longsleep>
ssvb: ok, do you think it still could make sense to explore possible speedups via fbturbe even without G2D?
<ssvb>
G2D is only one of the optional features
<longsleep>
ssvb: ok good so i will see where it goes then thanks
fernet_pipino has joined #linux-sunxi
<fernet_pipino>
hi
<fernet_pipino>
i have a problem.
fernet_pipino has quit [Quit: Konversation terminated!]
<ssvb>
longsleep: btw, the kernel reports different /proc/cpuinfo for 32-bit and 64-bit applications
<plaes>
o_O Orangefs?
<ssvb>
that's a cool name, at least much better than a lot of others
<ssvb>
in terms of being googlable
<plaes>
:D
<plaes>
ls -l fs/ |grep ^dr |wc -l ; -> 75
apritzel has quit [Ping timeout: 244 seconds]
<ssvb>
I mean, good luck searching on the Internet for "fat" or "fuse" :)
<KotCzarny>
ssvb: fat32/ exfat, etc
<KotCzarny>
fatfs would work too
Netlynx has quit [Quit: Leaving]
<KotCzarny>
also, orangefs bears meaning of tragic code/design quality ;)
<ssvb>
reference?
dlan has joined #linux-sunxi
<KotCzarny>
none, just anegdotical similarity to orange pi products
<KotCzarny>
(naming wise)
<plaes>
:D
<plaes>
waiting for raspberryfs
<willmore>
It'll have a mythical foundation to support it.
<apritzel>
longsleep: why would you need to check for an A53 explicitly in a driver?
<apritzel>
if there is a feature you need, then the driver should check for that feature, not for a particular core
<apritzel>
also I think HWCAP is the way to check for features for ARM userland applications
<apritzel>
/proc/cpuinfo is in fact very handy, but not really the way to check for things
<apritzel>
newer kernels will support the architectural cpuid registers from EL0, those are then trapped by the kernel and filled with the proper values
<longsleep>
apritzel: also some lines below it converts the cpuinfo data to some human readable string, currently resulting in "Unkown", i was looking into this to see what can be done on that and found the feature detection code
iamfrankenstein has quit [Quit: iamfrankenstein]
iamfrankenstein has joined #linux-sunxi
<apritzel>
yeah, I know that many things out there parse cpuinfo, because it's apparently easy or convenient
<apritzel>
thought they shouldn't, HWCAP is meant for this
<apritzel>
anyway, is this the only issue fbturbo has with arm64?
<longsleep>
apritzel: well, without the checks fixed it does not do much but it works
<longsleep>
apritzel: currently looking into getting mali_drm, miserably failing with the version from the BSP
<longsleep>
the mali_drm source code includes drm_sman.h but thats not included in the kernel tree, did not have the passion yet to investigate where it did go or when it did appear
<longsleep>
i figured that i could try a newer mali_drm driver first, the one from the BSP is 20100520 ...
avph has quit [Ping timeout: 246 seconds]
<longsleep>
thats the oldest one still available on arm.com
avph has joined #linux-sunxi
<apritzel>
longsleep: have you checked back with mripard_? AFAIK he was working on getting the mali driver to work on newer kernels
avph has quit [Ping timeout: 246 seconds]
<longsleep>
apritzel: nope, just started reading on this. The mali driver works already but the fbturbo also has a check for mali_drm which i currently cannot build
paulk-aldrin has quit [Remote host closed the connection]
<apritzel>
fixing fbturbo's cpu feature detection is easy, though: cpuinfo->has_arm_vfp |= find_feature(val, "fp");
avph has joined #linux-sunxi
<apritzel>
just about to code a proper hwcap based detection