01:36 <junari> electricworry: I build the package using makepkg and PKGBUILD, specifying local storage of the source files. The build is fast, as the compilation only affects the modified files. After that, the compiled package is sent to the device and installed via pacman -U

01:50 <dlan> junari: btw, do you plan to work on EMAC1 of A523/527 for mainline? your patch actually works

02:22 <junari> dlan: don't have much time to prepare that for mainline

02:27 <junari> So far there has been no review of the code that was sent for the thermal system, so I don't see the need to move forward with it

02:34 <junari> Where do you keep the code? I don't have radxa but would like to add it to my linux branch for manjaro. It would be nice to add the tested part

03:10 <dlan> only tested locally.. need to refactor before push out

03:29 <junari> If you want to get into finalizing the patch for emac1 and sending it to mainline, no problem. Most of my work was testing and porting allwinner code and adapting dtsi nodes for mainline

04:05 <dlan> there is no problem with current patch which will break emac0, since they share 'sram register space', need to do same as emac0 to use regmap interface

04:07 <dlan> I haven't decided to work it in near future, a little bit busy now..

04:07 <dlan> s/no problem/one problem/

14:10 <apritzel> dlan: junari: so I am not sure massaging this BSP driver is a good way forward for EMAC1 support. Does that build on the stmmac driver in any way? Can someone point me to some code?

14:12 <apritzel> because this pretty much looks like the descriptors: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h#n449

14:21 <apritzel> which aligns with what wens already hinted at: that the code might be already there, we just need to use / activate it?

14:24 <junari> apritzel: https://gitlab.manjaro.org/iuncuim/linux/-/blob/master/1209-net-drivers-stmmac-add-initial-support-for-a523-emac.patch?ref_type=heads

15:05 <apritzel> junari: thanks, so that doesn't look too bad, that's actually mostly platform glue, the actual MAC code is entirely using the existing stmmac code. But the platform code needs some adjustments

15:16 <MasterR3C0RD> apritzel: Sorry for the lag on signing off the patch, and again thank you for the cleanup. Should still be around for any questions if they come up

15:35 <apritzel> MasterR3C0RD: no worries, and thanks for the reply and the line!

15:39 <apritzel> junari: I am pretty sure the whole emac_25m code can go. Despite its name, that's the clock for the PHY, fed out on a SoC pin, allowing to save the 25MHz crystal you typically need

15:40 <apritzel> and I actually wonder: if the vast majority of that code is platform glue, which it probably shares with dwmac-sun8i, can't we just integrate both?

17:09 <Lightsword> apritzel, is emac_25m related to the emac1 phy pwm clock?

17:21 <apritzel> Lightsword: they can serve the same purpose: provide a clock to some out-of-SoC component. emac_25m is a dedicated and fixed 25MHz clock, which the PWM clock is more variable

17:22 <apritzel> I think the H6 and earlier didn't have emac_25m, hence the re-purposing of the PWM clock

17:23 <Lightsword> apritzel, something weird I noticed is that apparently the AC200 can be configured to accept 24MHz or 27MHz clocks while the AC300 can do 24MHz, 25MHz or 27MHz AFAICT

17:24 <Lightsword> those pwm patches for the h616 don't have working bypass support btw, was trying to fix it but it's a bit confusing how best to handle it especially when it comes to getting the code that reads back the clock settings working correctly

19:08 <apritzel> Lightsword: have you looked at pwm-sun4i.c and its bypass detection? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pwm/pwm-sun4i.c#n169

19:09 <Lightsword> apritzel, ah, no I hadn't, should that implementation be basically the same?

19:13 <apritzel> I guess so? But the code needs to be adjusted, to more explicitly check for 24 MHz @ 50%, as the new PWM can also have a higher input clock

19:14 <apritzel> so I think what this means is that it's OK to do those explicit checks, even though they don't seem to be very elegant

20:25 <macromorgan> so has anyone looked at the PWM on the H616 series? Based on the documents it's almost like I'm forced to conclude that there's no PWM0 or PWM5... there's a PWM1_inverse, a PWM1, a PWM2, a PWM3, a PWM4, and a PWM4_inverse. I say these "inverse" because I can still actually get the output of *something* for PWM0, it just so happens to be the opposite of PWM1

20:27 <apritzel> macromorgan: there *is* PWM0 and PWM5, there are just no pins for them on the H616

20:27 <macromorgan> there's also a missing clk_src_bypass_to_pwm0 or pwm5 in the register sheet

20:27 <apritzel> but the T507 manual mentions them, and in fact PWM5 is connected to an internal pin going to the AC200/AC300

20:28 <macromorgan> okay, I'll just asume the H616 register docs might be wrong or incomplete?

20:28 <macromorgan> honestly not even sure what the clock bypass is needed for

20:28 <macromorgan> just want to make sure I'm doing this right is all

20:28 <apritzel> well, they just cover what's usable on the H616, and since there is no pin for PWM0, it's not mentioned

20:28 <macromorgan> fair enough

20:29 <apritzel> but it's the same die as the T507, so the registers are there

20:29 <macromorgan> since I don't have an H700 document I guess that's what I get for trying to "read between the lines"

20:29 <apritzel> I think T507 is the closest to the H700 you can get

20:30 <apritzel> yeah, somewhat. From my experience, T507 is the most complete package of the die, so consider this a superset of the H616

20:31 <apritzel> "clock bypass" refers to bypassing the duty-cycle generator, so the output waveform is the same as the input clock waveform (with I guess 50% duty cycle)

20:33 <apritzel> macromorgan: which isn't terribly interesting for classic PWM use cases, but can be used to have somewhat high clock rate on output pins, as is used for clocking the internal PHYs already

20:33 <macromorgan> okay

20:44 <apritzel> macromorgan: I just checked, the T507 and H700 come in the exact same package, so chances are they are just relabelled versions of other, the T version maybe extra qualified for automotive

21:33 <macromorgan> right... I'm just going to include in the notes what I'm reading about no channel 0 or 5.

21:37 <apritzel> macromorgan: are you preparing a v2 series, based on Alexandr's D1 series? Any chance we can merge this, Uwe already hinted at that a while ago: https://lore.kernel.org/linux-sunxi/d5mr73yc7l6w6uvgqb4ymyc5267do4zirnnorkpi5s6qa5vckk@owayit4mexk2/

21:38 <macromorgan> yes, I'm working within the series for the D1 right now

21:38 <macromorgan> the real major change between the two is that the register offsets are different and the gating register for the H616 is part of the clock control register rather than a seperate gating register

21:38 <macromorgan> otherwise it's identical

21:39 <apritzel> I know, I looked at that ages ago, and figured the same

21:39 <apritzel> there is one more difference: the H616 register layout limits the channels to 8, not 16, but that's really a nit

21:39 <apritzel> and just a heads up: I am just about to review the D1 patch ...

21:41 <macromorgan> okay

21:41 <macromorgan> right, the H616 technically only has 6 anyway (well 4 for the H616, 6 for the T507 and H700)

21:43 <apritzel> I don't think we should be too stingy with that number, really, the driver can happily address 4 pairs/ 8 channels. If people deliberately access a wrong one, it's their fault, I'd say

21:45 <macromorgan> the D1 series accepts a devicetree value of allwinner,npwms and hard limits the max to 16

21:45 <macromorgan> though honestly I'm shocked that someone so far hasn't yelled and said "put the limit in the driver and not the devicetree"

21:46 <macromorgan> I'm not saying anything because I want it upstreamed :-P

21:47 <apritzel> there is a check, but it's a toothless tiger, since it just warns. I have just written a comment on this

21:47 <apritzel> yeah, don't worry, I am doing ;-)

21:50 <apritzel> macromorgan: just looking at the A523: that implements all 16 channels, it seems

21:50 <macromorgan> overachiever

21:51 <apritzel> well, it also puts a question mark on this default value of 8

21:51 <macromorgan> personally I think it should be in the driver data, but that's just me

21:51 <apritzel> don't understand as well why we are so specific: the register layout sets a limit, the driver and binding should just describe that

21:52 <apritzel> macromorgan: but then you would need different compatible strings for each chip, which sounds pointless, as it's essentially the same IP, just configured differently

21:56 <macromorgan> sort of, if the register layout *and* npwms is the same you'd just need a fallback string

21:56 <macromorgan> but yeah otherwise you'd need different strings

21:59 <apritzel> which forward looking is a pain, because you need to touch the driver for every new variant, and just to add that number

21:59 <apritzel> if you leave that to the DT, it would even work with older kernels

22:08 <macromorgan> okay

22:08 <Lightsword> macromorgan, I have a branch here with some of the PWM h616 patches from the LKML https://github.com/jameshilliard/linux-h616/commits/pwm/

22:11 <macromorgan> hehe... that looks almost identical to what I've got so far

22:12 <apritzel> ... but I think the consensus on patch 5/5 is that the approach is not right?

22:14 <Lightsword> macromorgan, does yours have bypass mode working?

22:14 <macromorgan> not yet, I'm still modifying things

22:15 <macromorgan> I have to take my kids to gymnastics in a bit, so I likely won't be finished until tomorow, and even then that'll just be a compile test and to see if I can make an LED breathe

22:15 <Lightsword> macromorgan, have a branch pushed somewhere?

22:17 <apritzel> there is no rush really, clearly the v6.16 train has left already, so we have another like 4 weeks till -rc1 as the next best posting opportunity

22:19 <apritzel> and combining the two series in this rather naive way will not fly (but you probably know this)

22:21 <Lightsword> apritzel, all these different WIP patch sets doing similar things is def confusing

22:22 <Lightsword> I think on my boards the pwm's are also used for controlling fans or something

22:23 <apritzel> yes, it's a bit of a mess, but I think we can make this right

22:24 <apritzel> and LEDs and fans are the actual users of PWMs, normally. This bypassing PHY clock is just a typical Allwinner hack ...

22:24 <apritzel> just saw that the V853 uses the same IP, but with 12 channels

22:32 <macromorgan> I just want it for a backlight and maybe a haptic motor

22:41 <apritzel> PWM is genuinely useful, and be it for fading LEDs ;-)