<ssvb>
and it could be relatively easily expanded to generate the whole u-boot defconfig and dts
<ssvb>
the main idea (as you can see in the wiki page) is that the conversion script also tries to 'grade' the quality of the conversion results and highlights them with different colors
<MoeIcenowy>
hmm
<ssvb>
and provides annotations in comments about what is suspicious and needs to be checked by the user
<MoeIcenowy>
of course these can be done in productive script by adding "FIXME"
<ssvb>
the hardship in trying to do all of this labor manually probably rewards you with a better understanding about how the hardware actually works and improves the quality of your contribution :-)
<MoeIcenowy>
I now have the feeling that can be told by a Chinese proverb
<MoeIcenowy>
"The angels fights, and the people got hurt"
<wens>
vishnup: not getting what you're asking
<wens>
vishnup: regulator contraints in the dts are there to keep outputs from going over voltage
<vishnup>
wens: I'm retrying to add axp81x. just don't want to blow up my board in experiments.
<mripard>
ssvb: yeah, what could go wrong by massively converting poorly-written files to another format when those files can fry your board.
<MoeIcenowy>
mripard: This is not the reason for not providing manuals and documents
<vishnup>
wens: as I understand axp20x.c has constraints which will avoid over-voltage,and what we write in dts is what voltage we want for particular regulator.
<vishnup>
isn't it true?
<wens>
vishnup: the values in axp20x-regulator.c are the min/max values or "valid range" for the regulator
<wens>
they have nothing to do with your board constaints, which you define in the dts
naobsd has joined #linux-sunxi
<wens>
what you write in the dts is what the consumer can take, i.e. the recommended operating parameters
vishnup has quit [Ping timeout: 250 seconds]
viccuad has quit [Ping timeout: 245 seconds]
vishnup has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
premoboss has joined #linux-sunxi
<ssvb>
mripard: well, that's rather weak argument, considering how sloppy the default clock frequencies and voltages are handled in U-Boot
<ssvb>
and you can still have to potentially deal with the guys copy-pasting stuff from other dts files without understanding what this means
vishnu_ has joined #linux-sunxi
premoboss has quit [Client Quit]
<vishnu_>
wens: Thanks, that helps me understand more.
<mripard>
MoeIcenowy: tag, you're it.
<ssvb>
mripard: and this is open source, I just offered to do some work for free, and you promised to harass the potential users
<mripard>
harass, really?
<ssvb>
mripard: when we discussed dts patches the last time, you acted pretty obnoxious and demonstrated poor comprehension skills
<MoeIcenowy>
mripard: ?
<mripard>
I'm sorry you feel like I'm a jerk, and a dumb one
avph has joined #linux-sunxi
<MoeIcenowy>
To many users and developers
<MoeIcenowy>
stock scripts is the best info srv
<MoeIcenowy>
src
<libv>
MoeIcenowy: which is why collecting them, together with other valuable device information, is such an important point in our new device howto
<mripard>
ssvb: and I stand by what I said, I won't merge a DT that has not been tested on some real hardware. I really don't see what's unreasonable about that, but feel free to educate me
<MoeIcenowy>
mripard, ssvb: Above anything, proper document is still important
<MoeIcenowy>
for examplr
<MoeIcenowy>
example
<MoeIcenowy>
you'd provide description to the options
<mripard>
and I really don't see the point of supporting poorly every board out there. I'm more enclined to first support a few ones as good as we can, and then merge new boards. I know a lot of people here feel differently, so I try to get in the way as less as possible, but we actually end up these days with no device properly supported, and everyone reviewing yet-another-board, ending up in no progress whats
<mripard>
oever.
<mripard>
MoeIcenowy: you have that description in Documentation/devicetree/bindings already
<vishnu_>
wens: I'm able to see atleast power button interrupt from axp81x :). your patches are very helpful adding support .
<wens>
:)
<MoeIcenowy>
mripard: I even get difficult to convert fex pin "power2" to uboot config pin
<ssvb>
MoeIcenowy: and you can also compare fex files for some boards with u-boot defconfigs for the same boards
<ssvb>
MoeIcenowy: you have an advantage over all of us: you are new here :-) so you can actually spot problems in the documentation, while it is more difficult for the other people who are already familiar with this stuff
<MoeIcenowy>
:-)
<MoeIcenowy>
I may do this tomorrow
<MoeIcenowy>
as my dorm's power supply is broken
KotCzarny has quit [Ping timeout: 272 seconds]
domidumont has quit [Read error: Connection reset by peer]
nove has joined #linux-sunxi
Seppoz has joined #linux-sunxi
arossdotme has joined #linux-sunxi
<nove>
MoeIcenowy: samsung, freescale, mediatek, qualcom and rockchip, have in mainline kernel or are doing a V4L2 mem2mem driver for respective (VPU, Video Codec) hardware (what ever is called)
vagrantc has joined #linux-sunxi
<nove>
MoeIcenowy: i don't see any reason why, sunxi should be any different
<vagrantc>
ssvb: thanks for the link to your branch for the H3 support ... unfortunately, ehci-platform wouldn't build so i had to disable the reset-control and ehci patch ... which effectively disabled USB i think
<vagrantc>
no ethernet yet, either :(
<vagrantc>
i wonder if the ehci patches just break when compiling as a module, but might work as a built-in ... if i can get USB to work on it, i can at least use a USB ethernet adapter
<ssvb>
vagrantc: how does it break?
<ssvb>
vagrantc,
<ssvb>
I'm pretty sure that it compiled fine for me
<ssvb>
vagrantc: can you try an unmodified sunxi_defconfig?
<ssvb>
vagrantc: have you tried to compile it as built-in?
<vagrantc>
not yet, that was my next plan
<vagrantc>
i could also just try dropping in the sunxi_defconfig
* ssvb
uses this kernel to boot over NFS, so compiling USB support as modules (or anything else critical for networking) makes little sense
<ssvb>
maybe you have found a bug, or maybe there was a more recent revision of this patch
<vagrantc>
yeah, your patch is simply weeks old! :)
<vagrantc>
or, branch
<ssvb>
it's not my patch, that's the stuff scavenged from the mailing lists :)
<ssvb>
I don't know how these patches are routed into the mainline kernel and from which tree they are going to be merged, so let's just wait for the first 4.5 release candidate
vishnu_ has quit [Ping timeout: 260 seconds]
vishnup has quit [Ping timeout: 260 seconds]
<vagrantc>
for the short-term, if building the modules in works for me, that's fine.
<vagrantc>
ssvb: but your branch got me pretty far along, so thanks! :)
FlorianH has quit [Ping timeout: 255 seconds]
apritzel has quit [Ping timeout: 246 seconds]
_massi has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
FlorianH has joined #linux-sunxi
FlorianH has quit [Ping timeout: 260 seconds]
viccuad has joined #linux-sunxi
Andy-D has joined #linux-sunxi
domidumont has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
IgorPec2 has quit [Ping timeout: 246 seconds]
gzamboni has quit [Read error: No route to host]
mawe242 has joined #linux-sunxi
<vagrantc>
well, including usb support as a built-in at least compiles
* vagrantc
tests if it works
Netlynx has quit [Quit: Leaving]
gzamboni has joined #linux-sunxi
viccuad has quit [Read error: Connection reset by peer]
bonbons has joined #linux-sunxi
<ssvb>
vagrantc: and?
<vagrantc>
ssvb: might be working as a built-in
* vagrantc
rummages around for devices to plug in
<vagrantc>
yup, recognizes usb ethernet
<ssvb>
great!
<vagrantc>
dunno if the usb ethernet works, but it sees it
<vagrantc>
so, apparently, there's something with the reset/ehci patches that break compiling as modules
<vagrantc>
i presume the ERROR: "of_reset_control_get_by_index" [drivers/usb/host/ehci-platform.ko] undefined! ... indicates that of_reset_control_get_by_index isn't available to modules
* vagrantc
tries an SSD plugged into the sata port
<ssvb>
vagrantc: it looks like just one module wants to access a symbol from another which is not getting exported properly
<ssvb>
that's a reportedly a rather slow USB-to-SATA-bridge, unless Orange Pi Plus2 got a better one
viccuad has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
pietrushnic has quit [Ping timeout: 264 seconds]
<jelle>
you really need a powered usb hub for these boards right?
pietrushnic has joined #linux-sunxi
yann|work has joined #linux-sunxi
<vagrantc>
gah. ever since i plugged in the sata device, it only boots from flash, not u-boot on my microSD
<vagrantc>
even after unplugging the sata
<vagrantc>
ok, writing a few zeros to the eMMC(?) seems to have fixed it
* vagrantc
wonders if the built-in usb sata is slow enough that using an external USB-SATA device wouldn't be faster
<KotCzarny>
do a test?
<vagrantc>
of course
<vagrantc>
it seems "dd if=/dev/zero of=/dev/sda1 bs=10240k count=10" does 14.7MB/s
<vagrantc>
and "sudo dd if=/dev/sda1 of=/dev/null bs=10240k count=10" does 32.1MB/s
<KotCzarny>
um, do: time (dd ...something.. ; sync)
<KotCzarny>
otherwise you wont count the mem buffered blocks
<vagrantc>
i thought sync only affected filesystems, not raw block devices
<KotCzarny>
afair doing sync after dd returns still writes quite a bit of data
<KotCzarny>
and as long you dont do o_direct, you still go through the cache
bpi-user has joined #linux-sunxi
<vagrantc>
the sync manpage suggests it only affects filesystems
<vagrantc>
results are virtually identical ... only minr fractions of a MB/s different
<KotCzarny>
oh.
jinzo has quit [Quit: Leaving]
<vagrantc>
i suspect dd to a file from a mounted filesystem would be very different, of course... or maybe the sync manpage isn't correct
* vagrantc
shrugs
<vagrantc>
i'm just looking for ballpark figures anyways
<KotCzarny>
ahm, right
<vagrantc>
is it definitely way faster/slower
bpi-user has quit [Quit: Page closed]
<vagrantc>
well, i think i have a kernel that's usable enough for now, eagerly awaiting H3 support getting merged into 4.5 :)
<vagrantc>
would be nice to figure out the USB module issue
<jelle>
linux hdegoede's branch also works nice on my orange pi pc
<vagrantc>
ssvb's branch was a small enough set that i could apply it onto debian's kernel build.
* vagrantc
eyes up the cubieboard4 for another round of wrangling
ricardocrudo has quit [Ping timeout: 265 seconds]
mawe242 has quit [Ping timeout: 240 seconds]
Ntemis has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
mawe242 has joined #linux-sunxi
<mawe242>
mripard, quick question about the A10/A20 SPI patch series I've been working on: when I update the series and include the clock control fixes (which you said should be CCed to -stable), do I send the whole series to all recipients, or each patch separately to the recipients relevant for only the single patch?
IgorPec has joined #linux-sunxi
yann|work has quit [Ping timeout: 260 seconds]
<mawe242>
or as it's a rather generic question about kernel development, maybe someone else here can help me?
destroyedlolo has joined #linux-sunxi
<destroyedlolo>
Hello
<destroyedlolo>
Can someone give me the usage of "autotp" section of fex file ?
<destroyedlolo>
I didn't find anything on the Internet :(
<KotCzarny>
what device it is?
<KotCzarny>
also, have you tried bin2fex'ing random fexes?