Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
libv has joined #linux-sunxi
mpmc has quit [Ping timeout: 250 seconds]
mpmc has joined #linux-sunxi
mpmc has quit [Ping timeout: 276 seconds]
mpmc has joined #linux-sunxi
ninolein has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
libv has joined #linux-sunxi
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
luoyi_ has joined #linux-sunxi
<luoyi_> wens: but my hdmi port can't get anything to display. do I need some other driver ?
perr has joined #linux-sunxi
perr has quit [Quit: Leaving]
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
<wens> luoyi_: right, i meant it's not usable
<luoyi_> wens: and does the dram display driver may help us to get hdmi work right ?
Nacho has joined #linux-sunxi
Nacho_ has quit [Ping timeout: 260 seconds]
<wens> luoyi_: you mean drm driver
<luoyi_> yes. drm driver. sorry for the typo
<wens> i don't know if the license issue with the hdmi driver was fixed or not
<luoyi_> the standalone tarball is ok . but dts file is missing
<luoyi_> what's your mean of the 'hdmi license issue' ? does allwinner refuse the community to build such driver for them ?
<luoyi_> http://linux-sunxi.org/GPL_Violations this page says something about the hdmi license
<wens> luoyi_: their hdmi driver does not have a clear license, preventing us from reusing it
pg12 has quit [Ping timeout: 265 seconds]
pg12 has joined #linux-sunxi
pg12 has quit [Ping timeout: 276 seconds]
pg12 has joined #linux-sunxi
perr has quit [Quit: Leaving]
fire219 has quit [Read error: Connection reset by peer]
<MoeIcenowy> H3 HDMI driver is licenseless
<MoeIcenowy> and A64 is even worse -- blob
<DaQatz> Arm is blobs everywhere sadly
<MoeIcenowy> but allwinner is beyond what the law accepts
<MoeIcenowy> they contain blobs in their "GPLed" kernel source code
merbanan has quit [Ping timeout: 252 seconds]
merbanan has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
mpmc has quit [Ping timeout: 250 seconds]
mpmc has joined #linux-sunxi
Putti has joined #linux-sunxi
Putti has quit [Ping timeout: 276 seconds]
reinforce has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
dearfibonacci has quit [Ping timeout: 250 seconds]
Sakami has quit [Ping timeout: 240 seconds]
Sakami has joined #linux-sunxi
BenG83 has joined #linux-sunxi
speakman has joined #linux-sunxi
speakman has joined #linux-sunxi
speakman has quit [Changing host]
lemonzest has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
foxx__ has joined #linux-sunxi
foxx__ is now known as foxx_
jernej has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
OverCR has joined #linux-sunxi
Mr__Anderson has quit [Ping timeout: 258 seconds]
jstein_ has joined #linux-sunxi
<jernej> MoeIcenowy: From what I can tell, A64 HDMI driver is the same as H3s with this additional function for CEC: http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect&goto=findpost&ptid=647&pid=10914&fromuid=198504
jstein_ is now known as jstein
<wens> jernej: that's not the problem
<jernej> I know, I wish Allwinner would release docs for HDMI
<jernej> but it seems that they want to hide sources even more
<jernej> for example, sun8iw6 HDMI source is even more obfuscated, they transformed binary blob to byte array
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
<jelle> :S
<jernej> and they are calling functions inside this byte array
<jernej> but funny thing is, when FriendlyARM released their H3 kernel sources
<jernej> this file is nice C code...
<MoeIcenowy> jernej: Thanks!
<MoeIcenowy> jernej: it't the usual things to happen on Allwinner SoCs
<MoeIcenowy> in the former A23/33 SDKs
<MoeIcenowy> the gsl_point_id library of gslx680new driver is blob
<MoeIcenowy> but in A64
<MoeIcenowy> it's source code
<MoeIcenowy> (although ugly, but not obfuscated
<jernej> ok, I didn't mean nice in nicely formated, but as in readable :)
<jernej> can someone explain to me if it is ok to use "confidential" datasheets found on forums, etc. to write drivers? For example, H3 datasheet is still marked as confidential and Allwinner didn't publish it yet...
<MoeIcenowy> In the allwinner things, datasheet means nothing
<MoeIcenowy> for driver you need user manual
<MoeIcenowy> and H3 user manual is not even leaked.
<MoeIcenowy> jernej: But I will soon try to use the H3 HDMI out-of-tree semi-mainlined driver on A64
<KotCzarny> hmm, licenseless doesnt equal copyleft?
<MoeIcenowy> KotCzarny: Theoritically licenseless code in a kernel source tree can be seen as copyleft...
<MoeIcenowy> But we don't dare to assert it
ricardocrudo has joined #linux-sunxi
<KotCzarny> they are ignoring gpl totally, so what could be the consequence of treating it as such?
<KotCzarny> who could make any legal action in such case?
<KotCzarny> arm?
<MoeIcenowy> Everyone cannot do things
bonbons has joined #linux-sunxi
Netlynx has joined #linux-sunxi
apritzel has joined #linux-sunxi
dearfibonacci has quit [Quit: Leaving]
paulk-collins has joined #linux-sunxi
<jernej> KotCzarny: I read that GPL licence can be enforced only by the owner of the code. In this case I'm not sure who that is.
dearfibonacci has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
dearfibonacci has quit [Quit: Leaving]
Mr__Anderson has quit [Quit: Leaving.]
|Jeroen| has quit [Quit: dada]
leberus has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
montjoie has quit [Ping timeout: 244 seconds]
montjoie has joined #linux-sunxi
IgorPec9 has joined #linux-sunxi
<MoeIcenowy> apritzel: If the A64 SPL is mainlined
<MoeIcenowy> how can we place ATF?
<MoeIcenowy> (As I remembered someone have succeeded to apply the H3 dram code to A64
<apritzel> MoeIcenowy: I have some code to load a U-Boot FIT image from SPL
<apritzel> worked well when I tried it
<MoeIcenowy> apritzel: where's them?
<apritzel> on my hard disk ;-)
<MoeIcenowy> apritzel: with a modified mainline SPL?
<MoeIcenowy> (I remembered you have a SPL with libdram
<apritzel> the version I have tried is with libdram SPL still
<apritzel> but the FIT loading part is totally independent from that
<apritzel> so should work well with jemk's DRAM code as well
<MoeIcenowy> yes
<apritzel> I used mkimage for combine U-Boot and ATF into a FIT image and put that right behind the SPL on a SD card
<apritzel> and that worked like a charm
<apritzel> I also added a kernel and initrd into the same FIT image and put that on a 16MB NOR flash
<apritzel> and could boot from it as well
IgorPec10 has joined #linux-sunxi
IgorPec9 has quit [Ping timeout: 258 seconds]
kaspter has quit [Ping timeout: 265 seconds]
<MoeIcenowy> apritzel: oh
<MoeIcenowy> can you just push these code?
IgorPec10 has quit [Ping timeout: 240 seconds]
dearfibonacci has joined #linux-sunxi
<montjoie> apritzel: successsfully tested your A64 patchs with emac, do you want some Tested-By ?
IgorPec has joined #linux-sunxi
<apritzel> montjoie: sure, thanks!
<apritzel> montjoie: btw: I was seeing that with the "upstream" A64 firmware we end up with a 200 MHz AHB2 clock, whereas the recommended speed is 300 MHz (the BSP package uses this as well)
<apritzel> AHB2 is used by the EMAC, so there is some hope for faster transfer rates ...
|Jeroen| has joined #linux-sunxi
<MoeIcenowy> apritzel: how will you implement AXP support in ATF?
<MoeIcenowy> (AXP contains 3 power sources, include one battery fuel gauge, and regulators, and a key, and some GPIOs
<apritzel> battery fuel gauge sounds like a sensor to me
<apritzel> what are the GPIOs used for?
<apritzel> also I am not sure we need to expose everything that the AXP provides to Linux
<MoeIcenowy> apritzel: GPIOs can be regulators
<MoeIcenowy> or to power LEDs
<MoeIcenowy> (for example, CHIP uses a axp gpio to power a led
<BenG83> the charge LED output needs a bit set to one
<MoeIcenowy> yes
<MoeIcenowy> apritzel: A64 tablets may use many of the functions.
<wens> LEDs, VBUS enable pins, VBUS detection pins
<MoeIcenowy> at least, regulators, power key, battery fuel gauge
<wens> apritzel: fuel gauge falls in the power supply class in Linux
<MoeIcenowy> (the fuel gauge is a lot of ADCs
<MoeIcenowy> and a power value indicator
<apritzel> still sounds like a sensor
<MoeIcenowy> axp contains logic to compute the percentage of the battery
<wens> there's also the battery charger, which might want to interact with the fuel gauge
<MoeIcenowy> apritzel: It's lot of sensors, and a compute logic
<apritzel> but again why should Linux be bothered with this?
<KotCzarny> why not?
<apritzel> if the AXP all does it on its own?
<MoeIcenowy> apritzel: all the functions will fall in the kernel
<MoeIcenowy> apritzel: yes
<MoeIcenowy> AXP is a complicated thing
<KotCzarny> sometimes its better to know voltage/amperage
<MoeIcenowy> we have never driven up a full AXP in mainline now.
<apritzel> KotCzarny: know voltage/current -> sensor
<MoeIcenowy> AXP have even some NVRAM
<MoeIcenowy> although very little
<BenG83> tablets might have a well defined battery, but SBCs with battery connectors mayb have different batteries
<KotCzarny> apritzel, ok, what was the question again?
<MoeIcenowy> (although I think no application will use that
<MoeIcenowy> tablets might have a well defined battery, but SBCs with battery connectors mayb have different batteries
<MoeIcenowy> I agree with this sentence
<MoeIcenowy> (So I wanted to push a axp20x_battery driver which uses the default OCV shipped in AXP
<apritzel> the question is: why do we need to expose all of those gory details to Linux?
<MoeIcenowy> apritzel: At least all the functions will be needed in some way.
<apritzel> if someone connects a charger, I expect the battery to be charged
<MoeIcenowy> (except the NVRAM, which is too small
<apritzel> why should Linux play a role in here?
<MoeIcenowy> apritzel: but I will be worried
<MoeIcenowy> if I cannot know the battery value
<KotCzarny> also, axp209 battery charging logic is BRAIN DEAD
<apritzel> you can know the value: it's a sensor
<apritzel> SCPI provides a sensor interface
<KotCzarny> my bpi-r1 is constantly charging the battery
<KotCzarny> with low amp, but still, its sure way to kill the battery
<MoeIcenowy> apritzel: it can deal with all kinds of sensor?
<apritzel> I will provide a sample implementation for the THS temperature sensor later
<MoeIcenowy> apritzel: and can we directly make some of the sensors to be a power supply driver?
<BenG83> the BSP kernel for A64 uses some dts entries to define all the charger settings and battery parameters atm, but I only logged on charge/discharge cycle so far, not sure if it works properly
mosajjal has joined #linux-sunxi
<MoeIcenowy> (and we will need to feed the OCV value to the chip, when the battery is fixed
<MoeIcenowy> (will we just hardcode the OCV value into ATF?
<MoeIcenowy> (Thus we will need an ATF per tablet
dearfibonacci has quit [Quit: Leaving]
<wens> MoeIcenowy: scpi sensors has an hwmon driver
<MoeIcenowy> wens: yes... hwmon driver is suitable for a thermal sensor
<MoeIcenowy> but I don't think it's suitable for a bettery
<MoeIcenowy> battery
<BenG83> the AXP and the battery probably should be abstracted like a normal laptop smart battery, it´s just a special case where they don´t form a single unit and some more parameters are needed?
<MoeIcenowy> BenG83: in laptops, battery is dealt with ACPI
<MoeIcenowy> but we cannot implement an ACPI now
dearfibonacci has joined #linux-sunxi
<BenG83> mmh
<MoeIcenowy> SCPI is now only a Juno-oriented interface...
<MoeIcenowy> it can suite a ITX-sized motherboard
<MoeIcenowy> but I cannot imagine it will suite a Q8 tablet
<apritzel> SCPI defines temperate, voltage, current, power, energy classes for sensors
<apritzel> so for reading those values, we should be covered
<MoeIcenowy> apritzel: yes... regulators, power supply can now be supplied with SCPI
<MoeIcenowy> how about GPIOs (or we may need a pinctrl, as one GPIO is muxed with LDO, and another is muxed with a ADC)
<MoeIcenowy> and PEK (which can have a keyboard driver)
popolon has joined #linux-sunxi
<apritzel> if those GPIO are used for controlling power domains, we could use either SCPI's regulator or power domain abstraction
<MoeIcenowy> apritzel: the board vendor can control the GPIOs' usage
<MoeIcenowy> they can vary among boards
petr has quit [Remote host closed the connection]
<MoeIcenowy> and the Power LED can be also used as a generic LDE
<MoeIcenowy> LED
<BenG83> I enabled the charger led on one of my Pine64 images by hacking a register write in the ATF
<BenG83> Android images already had that somehow
<BenG83> seems to work according to the datasheet
<MoeIcenowy> BenG83: how do you wire the LED?
<MoeIcenowy> (I now found that a dt is much more flexible than an ATF...
<MoeIcenowy> (for dt we can have overlays
petr has joined #linux-sunxi
<BenG83> LED is already wired on the Pine board
<MoeIcenowy> (but for ATF we can only have hardcoded logics... and it may vary from board to board...
<MoeIcenowy> BenG83: which one?
<MoeIcenowy> the red one?
<BenG83> no that one is fixed to PSOUT
<MoeIcenowy> (My Pine do not have a battery
<BenG83> the two free led spots
<BenG83> one is wired to the CHRGLED of the PMIC
<BenG83> and the other is just PL7 on the A64
<MoeIcenowy> PL7... so it cannot be used in mainline now...
<apritzel> MoeIcenowy: if those GPIOs are board specific, then controlling it in firmware sounds like a good fit
<BenG83> CHGLED is a dedicated LED control output
<MoeIcenowy> apritzel: they can be not board specific
<MoeIcenowy> for example
<MoeIcenowy> I have no battery for my Pine
<MoeIcenowy> then I can use the CHGLED as a generic LED
<MoeIcenowy> which can flash as heartbeat, mmc0 indicator, wifi indicator, etc
<MoeIcenowy> apritzel: do you have axp803 datasheet? see reg 0x32
<MoeIcenowy> bit3 is called "CHGLED pin control", it can switch the LED from two modes: one is manual controlling, the other is automatic controlling by charger
<MoeIcenowy> for BenG83 he may need a automatically controlled CHGLED as he has a battery
<MoeIcenowy> for me I need a manual controlled LED as I have no battery
perr has quit [Quit: Leaving]
<apritzel> MoeIcenowy: frankly: if I have to trade control of a single LED for a well defined firmware interface, I am happy to abandon this specific LED usage
<apritzel> or find another firmware interface to control it
<apritzel> for instance we can have a vendor specific smc call for the LED, if you like
<MoeIcenowy> apritzel: but I think the firmware interface is not so well-defined
<MoeIcenowy> It contains still too many vendor-specified things
<MoeIcenowy> (Or the full ARM platform is not so well-defined
<apritzel> so let's change that ;-)
<MoeIcenowy> (To be honest, I think an well defined interface which cannot support a full system is meaning
<MoeIcenowy> (So I think we should either choose a fully kernel-side thing, or an ACPI-based solution...
mosajjal has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<MoeIcenowy> (but you do not like ACPI...
<apritzel> if you look at the whole Allwinner design, then you see that every R_* peripheral is meant to be driven by the arisc only
mosajjal has joined #linux-sunxi
<MoeIcenowy> apritzel: eh...
<MoeIcenowy> but we cannot support ARISC well now...
<apritzel> for me arisc translates into firmware
<MoeIcenowy> and for now firmwares do not contain all proper frameworks
<MoeIcenowy> but I can get all the clocks and regulators to work in 3 days with a kernel driver
<apritzel> and the kernel driver lands where?
<apritzel> if Ubuntu 14.04?
<apritzel> *in*
<apritzel> or even 16.04?
<MoeIcenowy> Ubuntu 14.04 will not support it... it's too old
<apritzel> it's LTS
<MoeIcenowy> oh... I do not know well about Ubuntu LTS
<MoeIcenowy> will Ubuntu LTS have its kernel updated?
<apritzel> the point is: if you write the driver _now_, it will end up in distributions much later
<apritzel> whereas for firmware the cycle could be much quicker
<apritzel> for instance: Ubuntu LTS release is every two years, the next one is 18.04 in 18 months
<MoeIcenowy> so maybe ACPI is better
<apritzel> and many distributions base on that
<MoeIcenowy> with ACPI we may be able to even support newer devices
<MoeIcenowy> with older kernels
<apritzel> why do we need ACPI for a single LED?
<MoeIcenowy> if no newer IP cores are needed
<MoeIcenowy> apritzel: I do not means a single LED, I mean the full system
<apritzel> dream on ;-)
<MoeIcenowy> As you seen, Windows on ARM can use fully ACPI to driver the system
<MoeIcenowy> and get a PC-like experience
<apritzel> ACPI _sounds_ nice, but in reality is a nightmare, especially on ARM
<MoeIcenowy> apritzel: I think SCPI is also so...
<MoeIcenowy> SCPI also _sounds_ nice
<MoeIcenowy> but in reality it will be another nightmare
<apritzel> why's that? SCPI and ACPI are totally different beasts, really
<MoeIcenowy> but their common part is
<MoeIcenowy> it's a firmware interface which wants to hide some thing which is SoC-dependent
<apritzel> not hide, but abstract, but yes
<apritzel> but ACPI is much more fixed, and also overly complicated
<apritzel> have you checked out the spec?
<MoeIcenowy> yes ACPI is too complex
<MoeIcenowy> and too heavy for an ARM system
<apritzel> so
<MoeIcenowy> and thus not suitable for personal sunxi developers
<apritzel> also it does not even remotely cover what we need
<apritzel> for instance clocks
<MoeIcenowy> juno's design is consisted of many fixed clocks
<MoeIcenowy> but A64's design is consisted of many adjustable clocks
<MoeIcenowy> it's the first difference
<apritzel> not really
<apritzel> those clocks are adjustable, yes
<MoeIcenowy> and there's no any experience to use SCPI to share kernel between different SoCs
<apritzel> but actually they are not meant to be
<MoeIcenowy> maybe after H5 is released, we will have a chance to check the value of SCPI
<apritzel> H5 is a good example
<apritzel> it will probably share a lot with the A64, but not everything
<apritzel> so we hack the firmware in a week
<apritzel> and use an existing Linux kernel
<MoeIcenowy> but at least currently we're making a brand new wheel...
<apritzel> mission accomplished
<apritzel> why a brand new wheel?
<apritzel> SCPI is already supported by Linux
<apritzel> so we just piggy back on this
<MoeIcenowy> but there's no such a ATF mature enough to drive all R_* peripherals
<MoeIcenowy> so we're not making SoC implementations now
<MoeIcenowy> we're making frameworks now
<apritzel> I still don't get why you depend so much on frameworks
<apritzel> that's an implementation detail
<apritzel> we can go with a much simpler implementation right now
<apritzel> and we keep the same interface when we make the implementation more flexible
<MoeIcenowy> yes...
<apritzel> but frankly: this part of ATF just connects the smc interface to the clocks
<apritzel> there is no further interaction within ATF
<MoeIcenowy> yes...
<wens> fyi at least for ubuntu you can install newer kernels with LTS,
<apritzel> in contrast to Linux, which connects a generic clock framework to other subsystems
<MoeIcenowy> maybe we're now trying to re-create a sunxi-ng driver in the ATF...
<MoeIcenowy> and a axp2xx mfd driver
<apritzel> MoeIcenowy: but sunxi-ng is still SoC specific, unfortunately
mosajjal has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<MoeIcenowy> apritzel: yes ATF is also SoC specific
<apritzel> because it's firmware
<MoeIcenowy> ATF may be even board-specified
<MoeIcenowy> specific
<apritzel> yes
<apritzel> my PC's firmware is also board specific, so what?
<MoeIcenowy> and then board porting will be only able to be done by experienced users
<apritzel> the point is: I don't need a Lenovo enabled kernel to run Linux on it
<apritzel> MoeIcenowy: how many people on the planet really understand the common clock framework, really?
<MoeIcenowy> as the board vendor will care nothing about our ATF
<apritzel> and I don't care about the board vendor ;-)
<MoeIcenowy> apritzel: I do not know the internal
<MoeIcenowy> but I can use it.
<apritzel> see?
<MoeIcenowy> I can use it in my DT
<apritzel> really, I expect adapting the ATF clock driver to a new SoC to be really simple
<MoeIcenowy> but board adapting will be more difficult
<apritzel> why?
<MoeIcenowy> currently, board adapting can be without C work
<MoeIcenowy> only DT work
<apritzel> no
<MoeIcenowy> however, if board details will be integrated into ATF
<apritzel> you need a pinctrl driver
<apritzel> you need a sunxi-ng driver
<apritzel> all Linux code
<MoeIcenowy> apritzel: they're shared between all board of an SoC
<MoeIcenowy> I do not need to change it
<apritzel> the BPi-M64 ran out of the box with the Pine64 ATF
<MoeIcenowy> I need to only modify arch/arm64/boot/dts/allwinner/Makefile and write arch/arm64/boot/dts/allwinner/sun50i-a64-newboard.dts now
<MoeIcenowy> with the traditional kernel driver
<apritzel> so?
<MoeIcenowy> even if you device is a tablet
<apritzel> I don't see how that changes with ATF
<MoeIcenowy> BPI-M64 is too closed to Pine64
<apritzel> ATF really drives the SoC, not so much the board
<apritzel> it exposes all the SoC clocks to DT
<MoeIcenowy> yes
<apritzel> so you just change your DT, as before
<MoeIcenowy> thus... can we now split the SoC-related codes and board-related codes?
<MoeIcenowy> we may have tablet boards
<apritzel> sure, but as you mentioned in the moment we don't have different boards
Maakuth has left #linux-sunxi [#linux-sunxi]
<MoeIcenowy> yes
<MoeIcenowy> now we have only Pine64 and BPI-M64
<MoeIcenowy> But I have seen an A64 tablet on Taobao now
<apritzel> so I don't dare to predict what other board to differently
<MoeIcenowy> and A64 OTT boxes
<hp197> ola
<hp197> In the Mainline Effort page
<MoeIcenowy> You may cannot understand the Chinese
<hp197> Does cpufreq falls under Touch/Thermal/GPADC or shoudl cpufreq its own column in the table?
<MoeIcenowy> but you can at least know what this thing is
<MoeIcenowy> oh it have an en version
<dearfibonacci> Hello. Anyone here experienced with A20 olimex Micro arm pc?
jernej has quit [Ping timeout: 240 seconds]
<apritzel> apritzel: frankly, most of the ATF functionality we have at the moment is about the SoC
<apritzel> MoeIcenowy: I meant ;-)
<MoeIcenowy> yes...
<MoeIcenowy> maybe we should mean for the "A64 + AXP803" combine
<apritzel> and you will still need a board specific U-Boot port anyway
<apritzel> afaik A64 and AXP803 are closely coupled
<MoeIcenowy> yes
<apritzel> so chances are we will always see both together
<MoeIcenowy> we won't expect an A64 without AXP803
<KotCzarny> or just ignore all those things and just let common driver act as a glue for all axp chips?
<MoeIcenowy> just like we cannot see an A33 without AXP233
<wens> shit always happens, like some vendor did an A80 board without the normal PMICs...
<MoeIcenowy> wens: oh such shits
<hp197> ^ could be abbrevated to: "shit always happens, like the A80"
<wens> hp197: sad, but true
<wens> hp197: cpufreq is a separate item
<hp197> ok, then we might need to add it now the driver is changed to cpufreq-dt
<apritzel> KotCzarny: that's the idea of putting AXP support into ATF: on the Linux side it's a bunch of SCPI regulators
<apritzel> KotCzarny: all described in DT
dearfibonacci has quit [Quit: Leaving]
<hp197> Last weekend I couldn't get it running out of the box on A20 - 4.8.0
dearfibonacci has joined #linux-sunxi
<wens> apritzel: so we just need some stable numbering between ATF and whatever DT consumer?
<MoeIcenowy> wens: nope, dt can work in older versions
<MoeIcenowy> without kernel change
<hp197> apritzel: Do you have time to fire up a A20 and confirm broken cpufreq on 4.8?
<MoeIcenowy> if we have really no newer IP cores
<MoeIcenowy> but currently
<MoeIcenowy> all allwinner SoCs come with slightly changed IP cores
<apritzel> wens: actually not even a stable numbering
<apritzel> as long as the DT describes what ATF provides
<MoeIcenowy> and things like USB PHY and MMC is worst
<apritzel> which could be achieved by letting ATF modify the DT
<MoeIcenowy> (maybe Display is also a bad thing... mripard cannot not even make sun4i-drm work on sun8iw5
<MoeIcenowy> now
<MoeIcenowy> work correctly *
<wens> apritzel: that sounds complicated
<apritzel> wens: not if ATF (or firmware in general) actually provides the DT
orly_owl has quit [Quit: leaving]
<apritzel> as it's actually meant to be
<apritzel> this "the .dts live in the kernel tree" was and is a kludge
<apritzel> to have some reliable place to store them and to avoid vendors going astray with their bindings
<apritzel> some vendors actually don't update their DTs in the kernel tree, but just in the firmware
<MoeIcenowy> yes, the DT can be provided by not the kernel but a good vendor
<apritzel> which is fine as long as it still works
<MoeIcenowy> apritzel: allwinner is also an example for a dt-in-firmware ;-)
<apritzel> MoeIcenowy: You mean in the BSP U-Boot?
<apritzel> I actually like that approach
<MoeIcenowy> apritzel: yes
orly_owl has joined #linux-sunxi
<MoeIcenowy> but the embedded dt is a sh*t
<apritzel> only that they totally destroyed the idea by using non-standard bindings
<MoeIcenowy> apritzel: yes
<apritzel> which is broken by design
<MoeIcenowy> Allwinner now cares only about Android.
<MoeIcenowy> withoug longsleep, I will think we cannot even get fully-usable BSP Linux images
<apritzel> oh, isn't Android and Linux the same? ;-)
<BenG83> I just ran an Android image on longsleep´s kernel, thanks to jonsmirl
<longsleep> without me what?
<longsleep> well i am here, but everything i do/did is freely available to everyone and only based on publicly available stuff
<longsleep> so everyone can replicate everything :)
<MoeIcenowy> longsleep: I think without you Linux on Pine64 will become a disaster
<MoeIcenowy> longsleep: but you did it.
<MoeIcenowy> this kind of things should be done by Allwinner or Pine.
<MoeIcenowy> but they're both sh*t vendors
<longsleep> MoeIcenowy: well i am fairly certain that someone else would have created working images if i hadn't done it - i just came first
<MoeIcenowy> but we should admit that Allwinner is a vendor which did little
<MoeIcenowy> makes all of us OEM for ourselve
<apritzel> I think the big mistake was to advertise Linux support on Pine64
<MoeIcenowy> ourselves
<apritzel> or A64 in general
<apritzel> when there really wasn't any
<longsleep> apritzel: yes
<BenG83> they overdid the marketing campaign for the Pine by a long stretch
<MoeIcenowy> apritzel: yes
<apritzel> I agree that longsleep saved Pine64's ass ;-)
<BenG83> ^
<longsleep> well i only wanted the hardware in any case, and works pretty awesome for exactly the purpose i wanted it in the first place (compiling armhf and arm64)
<MoeIcenowy> and now apritzel is trying to become another vendor for A64
<MoeIcenowy> (not only apritzel
<MoeIcenowy> (all the coders in linux-sunxi are all vendor workers
<apritzel> MoeIcenowy: Imagine: there was a time when vendors didn't care about Linux support at all ...
<apritzel> apparently Allwinner does not do at the moment
<BenG83> but my impression is that linux-sunxi is pretty unique for mainlining efforts for ARM SoC?
<apritzel> so the community takes over
<BenG83> I was looking at linux-exynos and others and they seemed pretty dead
<MoeIcenowy> BenG83: the real vendor replaced the community vendor
<BenG83> ther was something happening with Rockchip iirc
<MoeIcenowy> BenG83: rockchip coders are now active in LAMKL
<MoeIcenowy> LAKML
<MoeIcenowy> have you seen anyone with @allwinnertech.com in LAKML?
<wens> i don't really believe in the "new DTs work for older kernels" thing
<wens> at least not until the platform is mature with all major drivers
<huawei> BenG83, linux-exynos seemed dead because samsung did everything =_=|||
<BenG83> that sounds like a good thing then?
<MoeIcenowy> 'linux-exynos seemed dead because samsung did everything' +1
<BenG83> btw does anyone have a Pine64 with GbE issues?
<Wizzup> Well, that's not exactly true
<Wizzup> There are still some things to do be done, but many things are indeed already done
<BenG83> I got 4 boards now and I can´t replicated any of the reported issues
<BenG83> *replicate
<Wizzup> The wiki is in a sore state though (linux-exynos)
<Wizzup> back later :)
<hp197> My bet is that Allwinner doesnt care much atm
<hp197> They can say their cpu supports linux (because of 3.x kernel)
<hp197> and they dont have to invest into mainline
<apritzel> hp197: they only care about Android, because that's their market
<hp197> apritzel: true, but eventually they still need to support Android 5 or higher in upcomming CPU's
<apritzel> to some degree this is Google to blame, really
<hp197> So sooner or later they will need to have (what is now) mainline support
<apritzel> because Android != mainline
<hp197> hmm, I see.. Thought Android 5 was 4.x kernel...
<hp197> :(
<hp197> 5.x Lollipop |21, 22 |3.16.1
<hp197> 6.0 Marshmallow |23 |3.18.10
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<apritzel> hp197: well, that's the base version, still
<apritzel> plus tons of patches
<apritzel> so any device vendor does not gain anything by supporting mainline Linux, if popular Androids are based on ancient kernels plus Android patches
<MoeIcenowy> but android will keep old kernel's support
<BenG83> my Nexus 5X is still running on 3.10.73 with Android 6.0
|Jeroen| has quit [Quit: dada]
<MoeIcenowy> BenG83: So does my Mi4c
<MoeIcenowy> (Seems that all 808 come with 3.10
<huawei> BenG83, so des my P8
<MoeIcenowy> huawei: so huawei ;-)
<hp197> But 3.10 Allwinner code isn't directly interchangeable to 3.16 kernel (otherwise we would have already seen Alwinner Android devices running Lollipop), So in near future Allwinner should go fixing their stuff agasin
<hp197> What?!.. Google allows to upgrade major with old kernel?!
<MoeIcenowy> hp197: you know it finally.
<hp197> Damn.... They should change policy....
cnxsoft has quit [Remote host closed the connection]
* hp197 is speachless
cnxsoft has joined #linux-sunxi
<KotCzarny> 'speechless'
<hp197> peachless :p
<KotCzarny> preachless :P
<huawei> hp197, if Google's policy doesn't allow upgrade witho old kernel, most of vendor will never upgrade major Android version
\\Mr_C\\ has joined #linux-sunxi
<wens> hehe
<apritzel> huawei: and so most vendors will not upgrade their Linux kernel ;-)
<wens> isn't google pushing vendors to upgrade recently?
<wens> or was it the FCC?
<MoeIcenowy> google is now focusing on hardening of 4.1+ kernel
<MoeIcenowy> but we cannot pray the vendor for updated BSPs
jernej has joined #linux-sunxi
<huawei> apritzel, quite contradictory
dearfibonacci has quit [Quit: Leaving]
<MoeIcenowy> we started from the discussion of SCPI
<hp197> anyway....
<MoeIcenowy> and ended with complaining with Allwinner
<hp197> apritzel: Do you have some spare time to fire up a A20?
<hp197> From what I can remember it cpufreq worked before (4.4 or 4.5), but seems to be broken in recent
<hp197> and I would like to have confirmation that it is broken, before I put it up on the wiki
<hp197> Without a deep investigation but my first impression is: I see they changed to cpufreq-dt and the temp handles in the devicetree are in place for cpu0, so it is a bit unclear why it doesnt like it
<huawei> hp197, yes, cpufreq broke in my cubietruck, fedora 23 with 4.6 kernel
<hp197> huawei: Thanks
<hp197> Will also check somewhere this week the older kernels to confirm it worked before
<huawei> hp197, also /proc/cpuinfo have not show the cpu freq infomation
<hp197> But im quiet sure it did...
keh has quit [Ping timeout: 264 seconds]
<wens> how is it broken?
<huawei> hp197, however, my old kernel have been deleted because /boot approach full....
<hp197> it is broken as in, there is no cpu freq info, so no userland cpu freq scheduling
<wens> funny... my cubietruck works fine with 4.7-rc3 (vanilla)
<huawei> hp197, i found this message in dmesg
<huawei> [ 0.057468] /cpus/cpu@0 missing clock-frequency property
<wens> that is not related to cpufreq
<wens> that the cpu topology stuff for arm
<hp197> huawei: I got that message as well, while it was there in the device tree
<apritzel> that message is in since the dawn of time, I think
<wens> it has absolutely nothing to do with cpufreq
<hp197> ok, unrelated then :p
<apritzel> because the ePAPR demands this property, AFAIK
<wens> it's just a kind of "compute capacity" indicator
<wens> apritzel: arm64 doesn't have it, does it/
<apritzel> yeah, at least there isn't such a message, IIRC
<apritzel> the problem is that nobody knows which frequency to put in there
<KotCzarny> all of them!
<hp197> but another indication that cpufreq isnt loaded (for me) is that this is missing
<hp197> /sys/devices/system/cpu/cpu0/cpufreq
<hp197> There is no directory cpufreq for cpu0
FergusL has quit [Read error: Connection reset by peer]
<hp197> huawei: Do you have cpufreq-dt as module or compiled in?
<NiteHawk> that "missing clock-frequency" has been around for a long time; and it didn't cause harm - there was even a nice patch by mripard that (more or less) took care of that, but it never made it into mainline
cnxsoft has quit [Quit: cnxsoft]
vagrantc has joined #linux-sunxi
<huawei> hp197, yeah, i just try to load this module but...nothing
<hp197> ok
<hp197> wens: Do you have it as module or compiled in?
<hp197> huawei: That is also what I say, no message at all (no fault and/or detection)
IgorPec has quit [Ping timeout: 276 seconds]
FergusL has joined #linux-sunxi
<hp197> huawei: What about: cat /boot/config-`uname -r` | grep CONFIG_INPUT_AXP20X_PEK
<hp197> Is that a module for you as well?
<huawei> hp197, yeh
<hp197> Hmm, that might be the culprint after googling...
<hp197> tkaiser had this problem before
jernej has quit [Ping timeout: 240 seconds]
IgorPec10 has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
<wens> hp197: compiled in
reinforce has quit [Quit: Leaving.]
<hp197> I'll build a kernel this evening with compiled in drivers to see if this changes anything
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec10 has quit [Ping timeout: 244 seconds]
<wens> hmm, mips64 based $5 IoT board...
reinforce has joined #linux-sunxi
Netlynx has quit [Remote host closed the connection]
<apritzel> wens: mips64 sounds good, IoT and $5 don't ...
<apritzel> wens: where is it?
OverCR has quit [Quit: Leaving.]
<apritzel> but that's not MIPS64, isn't it?
<apritzel> MIPS24K ...
florianH has joined #linux-sunxi
<KotCzarny> well, 2x32bit is 64, right
<wens> hmm, seems i was mislead
<wens> misled
lemonzest has quit [Ping timeout: 258 seconds]
lemonzest has joined #linux-sunxi
<montjoie> anyone with a bpim2+ running a mainline kernel with EMAC ? I got only 330Mbit/s
lemonzest has quit [Max SendQ exceeded]
lemonzest has joined #linux-sunxi
IgorPec has quit [K-Lined]
<KotCzarny> lol, igorpec got a kline?
<willmore> KotCzarny, :P
lemonzest has quit [Quit: Leaving]
<montjoie> anyone with a H3 running a mainline kernel with gigabit EMAC ? (and with iperf stat)
* vagrantc was running 4.7-rc7, on an orangepi plus2, but it proved too unstable so swithed back to 4.4-rc6 + random patches
perr has quit [Quit: Leaving]
OneSploit has joined #linux-sunxi
OneSploit has quit [Changing host]
OneSploit has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
paulk-collins has quit [Remote host closed the connection]
paulk-collins has joined #linux-sunxi
pg12 has quit [Ping timeout: 276 seconds]
pg12 has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein1 has quit [Read error: Connection reset by peer]
pg12 has quit [Ping timeout: 240 seconds]
jstein_ has joined #linux-sunxi
pg12 has joined #linux-sunxi
jstein_ is now known as jstein
Guest_0955 has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
OverCR has joined #linux-sunxi
tyler-baker has quit [Changing host]
tyler-baker has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein1 has quit [Ping timeout: 265 seconds]
foxx_ has quit [Ping timeout: 244 seconds]
aalm has joined #linux-sunxi
fire219 has joined #linux-sunxi
fire219 has quit [Changing host]
fire219 has joined #linux-sunxi
OneSploit has quit [Ping timeout: 252 seconds]
bonbons has quit [Quit: Leaving]
Putti has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<Wizzup> Is it possible to measure power consumption of a lime2 on mainline?
<KotCzarny> a20? there was a patch in armbian
<KotCzarny> i assume it has axp209, right?
<Wizzup> is that only for battery?
<Wizzup> I guess not
Mr__Anderson has quit [Quit: Leaving.]
mzki has quit [Quit: leaving]
Putti has quit [Ping timeout: 250 seconds]
jstein has quit [Remote host closed the connection]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
mwcampbell has joined #linux-sunxi
<mwcampbell> Where can I find documentation about G2D?
<mwcampbell> I mean, where can I find documentation about what capabilities G2D provides and how it works? Not just how to use it with Xorg.
BenG83 has quit [Quit: Leaving]
fire219 has quit [Read error: Connection reset by peer]
fire219 has joined #linux-sunxi
fire219 has quit [Changing host]
fire219 has joined #linux-sunxi
paulk-collins has quit [Quit: Leaving]
OverCR has quit [Quit: Leaving.]
popolon has quit [Quit: WeeChat 1.4]
perr has joined #linux-sunxi