<macromorgan>
first attempt at pwm driver not working, I will keep at it
Net147_ has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
chewitt has joined #linux-sunxi
vickycq has joined #linux-sunxi
vickycq_ has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
koty0f has quit [Ping timeout: 480 seconds]
koty0f has joined #linux-sunxi
koty0f has quit [Ping timeout: 480 seconds]
koty0f has joined #linux-sunxi
koty0f has quit [Remote host closed the connection]
koty0f has joined #linux-sunxi
koty0f has quit []
apritzel has quit [Ping timeout: 480 seconds]
electricworry_ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
Robot_ has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
gamiee has joined #linux-sunxi
gamiee__ has quit []
gamiee_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
Robot_ has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<mkf>
hi, can you see this message?
<gamiee>
mkf : pong, yes we can see it.
<mkf>
cool.
<mkf>
a friend of mine has a x96q, which has h313 (and axp313?), is there any linux distros for that model?
codekipper_ has joined #linux-sunxi
warpme has quit []
codekipper_ has quit [Remote host closed the connection]
warpme has joined #linux-sunxi
<apritzel>
mkf: you wouldn't need a specific *distro* for a certain board, all you need is a devicetree and a U-Boot defconfig
<apritzel>
there is nothing in mainline for that box, and I read there are different versions, with different DRAM settings, and even (fake?) versions with Rockchip or Amlogic SoC
<apritzel>
it seems like warpme has played with those boxes before?
<mkf>
nothing in mainline for that box or that SoC?
<apritzel>
for that box, specifically. We just mainlined the DT for the Tanix TX1, which is also H313+AXP313
<mkf>
neat. what does that axp313 do btw?
<apritzel>
so it should not be that hard to fix it, but it takes time and experience
<apritzel>
the AXP313 is a PMIC: Power Management IC. It creates different voltages, like for the CPU, GPU, the SD card, etc
<apritzel>
it's crucial to know the model of the PMIC and its configuration, to get a board running
<mkf>
is it the part where h313 differs with h616?
<apritzel>
the H313 is apparently just a worse version (bin) of the H616, rated at slower clock speeds
<apritzel>
it's apparently cheaper as well
<mkf>
so in theory they should be compatible?
<mkf>
other than that axp313 thingi
dsimic is now known as Guest5565
dsimic has joined #linux-sunxi
Guest5565 has quit [Ping timeout: 480 seconds]
warpme has quit []
<apritzel>
mkf: it's a bit tricky. In reality all those TV boxes are indeed quite similar, and you probably have some success with using an image from some related box
<apritzel>
but on the other hand it's also dangerous, as the voltages for instance could be different, and it will not end well if you push 3.3V on a 1.8V device
<apritzel>
though that seems to be rare, as most companies either copy from each other or from some Allwinner reference design
<apritzel>
and the H313 and the H616 seem to be fully compatible, at least we haven't seen any problems
<apritzel>
I believe they are even pin-compatible, as some companies started to chip H313 chips, due to some H616 shortage
<apritzel>
mkf: the proper way to enable that box would be to investigate the running stock firmware, and maybe search in a firmware update image for information
<apritzel>
then create a devicetree and a U-Boot defconfig based on that
warpme has joined #linux-sunxi
<warpme>
mkf: if you have energy/motivation to try ArchLinux arm on x96-q - pls try: https://github.com/warpme/miniarch/releases In case of any problems - as always - UART log from boot process will be really helpful to move forward....
<warpme>
currently 6.9rc7 runs well for me on my 3 variants of x96q. I just finished bumping-up to gcc14 + glibc2.39 and soon i'll return to publish changes on github....
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
<macromorgan>
okay, got pwm working on the H616... wonder if it's too late to submit with the rest of the changes?
<Jookia>
macromorgan: how'd you do it :D
<Jookia>
you could probably post in the thread or something
<macromorgan>
I'm going to post my code shortly, I'm modifying the documentation and validating it
<Jookia>
i'm writing a PWM driver for the D1 for u-boot
<macromorgan>
I emailed yesterday asking them to change the clock name from apb0 to just apb, since for the H616 we use apb1
<apritzel>
macromorgan: too late for what? Linux v6.10?
<macromorgan>
the patch that's pending
<macromorgan>
I know 6.10 is already out the door pretty much (from a maintainer perspective)
<macromorgan>
the one change that I kind of "would really like" is to just change the clock name from apb0 to just apb though, the rest I can do on top
<apritzel>
do you mean the R329/D1 PWM driver?
<macromorgan>
yes
<apritzel>
I don't think that patch is going anywhere? which version are you talking about, anyway?
<macromorgan>
v8
<macromorgan>
basically take the r329 pwm driver, remove the clock gating, alter the register offsets a bit and you have an H616 pwm driver
<apritzel>
v8 is abandoned since end of January, and there were comment on that version anyway
<Jookia>
abandoned? is there a v9?
<macromorgan>
okay... I guess I won't be getting any comments on my post yesterday :-p
<apritzel>
no, but there was no activity since
<apritzel>
and I don't know if the original author will still pick this up anyway
<macromorgan>
damn
<Jookia>
i have some suspicions about the correctness of that pwm driver...
<macromorgan>
well I'm not smart enough to answer the question in regards to "order of setting pwms affecting accuracy"
<apritzel>
why damn? gives us time to rework and fix it
<macromorgan>
I mean the outstanding question I don't know the answer to
<apritzel>
jernej and I already checked and the comments are easy to address
<macromorgan>
okay
<Jookia>
macromorgan: i have an answer to that
<macromorgan>
well I am about to post my efforts... we can debate picking up with the v8 or starting anew if the author won't continue
<apritzel>
so the short answer is: this patch series needs some touching anyway, and we can as well re-post that, and extend the driver to cover the H6
<macromorgan>
it's essentially the V8 patches with H616 bolted on top
<macromorgan>
yes, I'll rebase U-Boot again and check it out
<macromorgan>
so quick question (this might be a way to solve the "runtime differentiation problem" aside from poking GPIOs like you suggest). I have an i2c chip I'm 99% sure is an eeprom but no idea what the chip is... is there a standard way to figure it out?
<macromorgan>
address is 3c I think
<apritzel>
in Linux there is an "i2c-tools" package, which contains i2cdetect and other low level tools to poke an I2C device
<apritzel>
or you use the "i2c" command in U-Boot, with a similar scope
<apritzel>
I2C might be a bit more nasty, since ideally we would do the detection in the SPL, so U-Boot proper gets to see the right DT already
<macromorgan>
right... if I know what I'm dealing with I think I can ping it in U-Boot just the same.
<macromorgan>
It's just weird because there's this mystery device on every single Anbernic device I own (like 20+ at this point) and I've never figured out what it is.
<macromorgan>
note I'm not alledging some nefarious back door or anything... it's almost certainly an i2c eeprom of some kind
<Jookia>
macromorgan: you can send it i2c NOR eeprom commands
<apritzel>
I2c eeproms should be visible on the PCB, there are not exactly tiny
<apritzel>
macromorgan: also, are you sure it's not the H616 internal AC300 chip?
<macromorgan>
okay let me hook up the i2c bus again and try some arbitrary commands
<macromorgan>
what address is that one at?
<macromorgan>
that's on bank A right? This device is explicitly on the i2c3 bus (I think, I will have to go back and look again)
<apritzel>
0x10 at i2c3
<Jookia>
probably just adding an at24 dt entry and enabling u-boot eeprom stuff would work
<Jookia>
or linux
<apritzel>
there are lines on PA going to that chip, but there is an I2C control interface, connected to I2C3 at PB17/18
<apritzel>
well, those are the H6 details anyway, not sure about the H616, specifically
<macromorgan>
checking
<apritzel>
macromorgan: so I feel like we have to split the patch up, at the minimum to give Aleksandr credit for his driver. We might want to add some pieces of code "in foresight" to his patch, but the bulk should stay
<apritzel>
macromorgan: when you said "... this mystery device on every single Anbernic device ...": does this include the Rockchip ones? This would then indeed point to some EEPROM
<macromorgan>
yes, it is also on the Rockchip ones
<macromorgan>
right, I just modified that patch. We can possibly go back and take his as-is (but rename the clocks), then put my changes on top
<Jookia>
there's always time to add more patches on
<Jookia>
unless the patches is absolutely broken then it's probably best to start with the original patch that we've all tested apply changes on top of that
<Jookia>
though changing apb0 to apb might be good foresight, i'm not sure though - i think maybe adding apb0 OR apb1 as values could be a better idea. you never know if the next chip will support both as clock inputs
<macromorgan>
okay, found it again, it's at 0x3c like all the rockchip boards
<apritzel>
but apb0/apb1/apb is just a name in the DT, isn't it? The actual clock comes through the DT reference anyways
<Jookia>
yeah but what if the pwm in future supports selecting apb0 or apb1
<apritzel>
then we will address this at this point
<apritzel>
experience shows it's not wise trying to anticipate hardware changes - unless they are obvious (like the number of channels)
<Jookia>
ah ok
<apritzel>
btw: has anyone actually tested this driver on a T113 or D1?
<macromorgan>
no idea, but I did test it on an H616 :-)
<Jookia>
yes
<Jookia>
i gave the patchset a tested-by even
<apritzel>
Jookia: but you also said there is something fishy or it's not quite right?
<Jookia>
well
<Jookia>
so i haven't reviewed v8 but i have been writing my own driver
<Jookia>
and some of the logic doesn't line up
<apritzel>
have you tested both channels in a pair, at the same time?
<Jookia>
no, but i know that's kinda broken
<Jookia>
just from reading the code
<Jookia>
in my u-boot code i am setting the channels in pairs whenever one changes
<Jookia>
but i find the kernel patch hard to follow
junari has quit [Remote host closed the connection]
<Jookia>
like it has 'SUN20I_PWM_CLK_DIV_M_MAX' which does ... something
<apritzel>
yeah, it's not an easy read
junari has joined #linux-sunxi
<apritzel>
which might be due to the PWM device being nasty, with this pairing
<Jookia>
the driver doesn't really account for pairing
<Jookia>
when i have a u-boot driver ready maybe we can compare them
<Jookia>
the main gotcha of this PWM setup is that the actual number of cycles is ENTIRE + 1, and the signal goes active once CYCLES > ENTIRE
<apritzel>
have you looked at the previous PWM drivers? My hunch is this hasn't changed ...
<Jookia>
no i haven't, is that a normal pwm thing? :)
<apritzel>
dunno, but maybe "normal" for AW ;-)
<Jookia>
anyway the solution i have is to have ENTIRE never be over 65535
<Jookia>
but the kernel driver seems to do something different that i can't understand
<Jookia>
oh i just read v8
<Jookia>
'/* for N cycles, PPRx.PWM_ENTIRE_CYCLE = (N-1) */'
<Jookia>
i think i might be on v6 or something in my local git
<Jookia>
the SUN20I_PWM_MAGIC seems a little unecessary
<Jookia>
i don't know, the code just seems a little too complex for my small brain
<Jookia>
but maybe my code will turn out like this, who knows