jacklsw has quit [Read error: Connection reset by peer]
___nick___ has joined #riscv
___nick___ has quit [Client Quit]
prabhakarlad has quit [Quit: Client closed]
atishp[m][m] has joined #riscv
___nick___ has joined #riscv
<drewfustini>
atishp[m][m]: great that you joined
<atishp[m][m]>
👌. I am not sure what "RISC-V" channel I joined earlier
<atishp[m][m]>
it has bunch of folks joined through telegram though
<drewfustini>
Maybe it was the old one on Freenode. I think it was last year a lot of people migrated over here. And at least over the past few months there has been good discussion of kernel patches in here with heiko, emil, palmer, connor and others.
prabhakarlad has joined #riscv
<drewfustini>
This channel is a nice supplement to my reading of linux-riscv list
<palmer>
atishp[m][m]: IIRC you were in the Matrix channel that wasn't bridged to IRC
<drewfustini>
interesting, is that active too?
<palmer>
IDK, the only thing I have in Matrix is an IRC bridge ;)
<drewfustini>
the only place I look at for risc-v is this channel and the mailing list
<palmer>
there's a lot of mailing lists, depending on what you're interested in
<atishp[m][m]>
it is active too but not a lot of topics that are interesting for me
<drewfustini>
but in terms of chat, is there anything other than this channel that is active?
<drewfustini>
I rarely look at the RISC-V International slack. I don't think people talk about linux, u-boot or opensbi on there anyways
<palmer>
this is probably your best bet for chat
<drewfustini>
thanks
<drewfustini>
Btw, I am running to into a problem with timers on a RISC-V SoC (BooM-based RV64GC in S-mode). riscv_clocksource is already running okay from timer-riscv.c. I am trying to bring-up the dw-apb-uart timers (there are eight, but I start with enabling just one). When I did, the that kernel boot freezes towards the end.
<jrtc27>
conchuod: the basic problem is freebsd's device enumeration model is that device drivers list the parent devices they can be a child of, whereas linux doesn't, and so when things like syscon-power don't document where they reside the driver ends up just listing the ones it sees in the wild\
<jrtc27>
which, in this case, was just simple-bus
<jrtc27>
(and it gets particularly fun because simple-mfd and syscon have their own drivers in freebsd, so even if they're also compatible with simple-bus they need to be listed explicitly for devices that can be beneath those too)
<drewfustini>
and dw_apb_timer_of.c also uses 300
<drewfustini>
It's hard coded in both so I believe I need to patch one. For my internal purposes, I changed dw_apb_timer driver to use 100 and thus the riscv_clocksource wins (which is what I want)
<drewfustini>
but I am having a hard time thinking about what a proper upstream solution would be
<drewfustini>
maybe this is the first situation in which dw_apb_timer_of.c and timer-riscv.c are used on the same system?
<drewfustini>
anyways, I was curious if anyone had thoughts on why timer-riscv.c chooses a rating of 300. I could bump it up to say 400 to avoid the conflict with dw_apb_timer. Any thoughts on if that is incorrect?
<drewfustini>
I could send a rfc to solicit comments but i thought I would check what the channel thinks
KombuchaKip has quit [Quit: Leaving.]
KombuchaKip has joined #riscv
<palmer>
drewfustini: you should just send a patch, IIRC those numbers are arbitrary
<palmer>
looks like they're documented in include/linux/clocksource.h, they're not entirely arbitrary
<palmer>
though they kind of are, there's a lot between 300 and 399 ;)
<palmer>
maybe the right answer here is to have some user-settable interface for this? how good the SBI timers are is going to depend on the system and firmware, so it's kind of a tossup
<jrtc27>
it should still *work* though
<jrtc27>
and arguably using S-mode-visible hardware is better than slow-as-anything firmware calls
<drewfustini>
Thanks for the insight. It does feel like the sort of thing that should be configurable rather than hardcoded in the driver as it think it is hard for those assumption to always be right. I think it would depend on the SoC implementation whether dw-apb-timer or sbi timer is better.
<drewfustini>
jrtc27: interesting, so maybe it is doing that right so to speak. In truth, the reason I wanted to keep SBI timer as the clocksource for the tick is that I'm still trying to validate the the the dw-apb-timer peripheral works correctly.
<drewfustini>
so this maybe be more of a bring-up time issue rather than something that will always be the case for this SoC
<drewfustini>
in terms of overhead, is an ECALL happening every time the timer is reloaded to cause the next s-mode timer interrupt to occur? In other words, does that mean that which timer-riscv.c acts as the clocksource for the tick, that there is an ECALL needed to cause the next tick to happen?
<jrtc27>
yes
<jrtc27>
Sstc fixes this
<jrtc27>
to not be absurd
<jrtc27>
(I'll never understand how anyone thought this was a good idea...)
<drewfustini>
Ah, so yes, I can see what that is not preferable is the their is a working timer peripheral
<drewfustini>
so really the problem is that I need to finish the validating that the dw-apb-timer is working correctly on this SoC. It does seem that it should in fact be the preferred clocksource once I figure out how to configure it properly. There are 8 instances so using one for the clocksource is not much of a waste.
<drewfustini>
thanks!
<drewfustini>
*if the there is a working timer peripheral [..]
<palmer>
ya, I think that's the way to go: the SBI/rdtime stuff is a mess, so if there's another clock source that works then it's likely the way to go
<palmer>
that said, we should probably have some way of setting this for users
<drewfustini>
thanks, so the hack to change the rating will suffice while I figure out how the configura the dw-apb-timer peripheral correctly, and post-bring-up, the first instance of dw-timer-apb should be the clocksource
<drewfustini>
> that said, we should probably have some way of setting this for users
<drewfustini>
that is an interesting idea, I will solicit some feedback on that from the appropriate list... I think Daniel Lezcano maintains that.
<drewfustini>
until this week, I had never noticed there is a rating for clocksources, and I was surprised I couldn't change it with DT, sysfs or module param.
<palmer>
for bringup just hacking things together is the way to go, it's always a mess to start
<palmer>
I think a kernel command-line argument is usually the way this is done, but DT seems reasonable too
<drewfustini>
I guess it depends on whether it is ruled to be a description of the hardware or not
<palmer>
ya, it's kind of a grey area
<palmer>
probably best to sort it out on the lists, though
<drewfustini>
yeah, good idea
<palmer>
even something as simple as a "sbi-clock=off" or "sbi-clock=always" on the command-line might be good enough, I have to do that sort of stuff on even some of my Intel machines for old kernels
<drewfustini>
yeah, that seems reasonable
brazuca has joined #riscv
<conchuod>
jrtc27: not 100% I follow you.. Are you talking about having it as a subnode to the syscon or about at top level?
<conchuod>
sounds like you're talking about the subnode case or generally
<conchuod>
re this channel: it wasn't easy for me to find it via google even after I knew it existed (but have been out of the irc loop since before the freenode incident)
BootLayer has quit [Quit: Leaving]
Andre_H has joined #riscv
jmdaemon has joined #riscv
<conchuod>
palmer: idk if you ever check github notifs, but I sent a PR against riscv-systems-ci to just make some stuff easier to run for me. it's in my -next pipelines now :)
<palmer>
thanks, I'm not sure I even get GH notifications -- most repos I have there are just playgrounds, but I guess that's one that's actually the upstream
<conchuod>
Ye I never check mine either for similar reasons
<conchuod>
I had to try god knows how many different branches to get one that rv32 ran with no errors for.
<conchuod>
master, for-next, linux-5.19.y all had issues of some sory
<palmer>
ya, that's made a bunch of headeches
<palmer>
looks like gcc-11 broke new kernels and gcc-12 broke old kernels around the same time, it's made bisecting any failures a huge PITA
<conchuod>
All my stuffs on gcc 11 still (well and clang 15), I think gcc 12 has issues across the board
<conchuod>
dt_binding_check is really fragile too (so I made that not fail your CI...)
aburgess_ has quit [Remote host closed the connection]
aburgess_ has joined #riscv
ZipCPU has quit [Ping timeout: 268 seconds]
mechaniputer has quit [Quit: leaving]
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #riscv
strlst has quit [Quit: Lost terminal]
pbsds has quit [Ping timeout: 268 seconds]
Xav101 has joined #riscv
brazuca has quit [Quit: Client closed]
indy has quit [Ping timeout: 268 seconds]
brazuca has joined #riscv
pbsds has joined #riscv
ffcc has quit [Remote host closed the connection]
indy has joined #riscv
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #riscv
raym has quit [Remote host closed the connection]
brazuca has quit [Quit: Client closed]
raym has joined #riscv
xav has joined #riscv
Xav101 has quit [Ping timeout: 252 seconds]
<smaeul_>
there already is a clocksource= kernel parameter and a sysfs interface (/sys/devices/system/clocksource/clocksource0/current_clocksource) for users to choose one at runtime