<somlo>
it's just another way to read the clock frequency from DTS (instead of looking up the CPU clock, which I was -- rightfully, IMHO -- told is super hacky and not generalizable) ?
<shorne>
I was trying to do ... dyndbg="file litex-mmc.c +p"... maybe it should be litex-mmc.dyndbg="+p"?
<somlo>
shorne: dev_err_probe() should complain about the clock regardless of debug level
<shorne>
yeah, I am getting nothing
<somlo>
and for the rest, I just add `pr_err()` or `pr_warn()` statements if I want to get it to print things while debugging -- low tech, but works :)
<shorne>
[ 6.340000] probe of e0005000.mmc returned -517 after 315 usecs
<shorne>
[ 6.350000] platform e0005000.mmc: Added to deferred list
<shorne>
[ 6.360000] initcall litex_mmc_driver_init+0x0/0x30 returned 0 after 22269 usecs
<shorne>
the dev_info statement I added to probe doesn't print
<shorne>
the above probe statements are printed because I added dyndbg=\"file dd.c +p\"
<somlo>
go for pr_warn(), that one's less conditional on a crap-ton of policy...
<shorne>
Ill just to go lo tech
<somlo>
517 is EPROBE_DEFER
<somlo>
be interesting to confirm/deny it's from PTR_ERR(clk) or somewhere else...
<shorne>
I think somewhere else, I added printk's and it never gets to if (IS_ERR(clk)) it looks like
<somlo>
the only other spot it could be then is devm_add_action_or_reset()
<somlo>
that's the only callee-generated return error code before devm_clk_get()
<somlo>
but devm_add_action (which is the thing doing the work) never returns anything other than ENOMEM or 0 (in drivers/base/devres.c)
<somlo>
can you get a pr_warn("got here\n") at the beginning of the probe, right before mmc_alloc_host() ?
<somlo>
I think terminating with \n is important too, otherwise things don't get flushed out to the terminal reliably (distant foggy memory of me banging my head against the wall wondering where my debug printouts went, and why they're not happening when they ought to)
<shorne>
[ 10.030000] probe of e0005000.mmc returned -517 after 8197 usecs
<shorne>
[ 10.040000] platform e0005000.mmc: Added to deferred list
<shorne>
[ 10.040000] initcall deferred_probe_initcall+0x0/0xb8 returned 0 after 83937 usecs
<somlo>
ok, so it's from PTR_ERR(clk), as you suspected
<shorne>
I think the platform probe framework is looking at the device tree and seeing the dependency and then deferring the probe before calling probe
<shorne>
I could be wrong
<shorne>
but need to figure out how to get this "generic" clock dependency satisfied in mor1kx
<somlo>
now the question is why does it think it doesn't have the dependency satisfied, since there's clearly a clock in the DT
<somlo>
and more mysteriously, why on earth does it work on litex+rocket (I hate not knowing why things do work) :D
<shorne>
I think (guessing) its because this fixed-rate clock is part of the COMMON_CLK stuff. I think arch/openrisc does not support it
<shorne>
maybe riscv / linux uses a generic clock modules. OpenRISC has a special clock
<somlo>
then we need to find an alternative way to specify a dummy clock whose frequency we parse in litex_mmc_probe() that works everywhere
<somlo>
and we thought searching for the CPU's clock frequency was a hack :)
<shorne>
yeah, I need to go
<shorne>
thanks for helping looking
<shorne>
Ill look at this later
<somlo>
hey, let me know if there's anything I can do to help -- I'll try to teach myself some more DT magic in the mean time
nelgau has quit [Remote host closed the connection]
nelgau has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
nelgau has quit [Remote host closed the connection]
ilia__s has quit [Ping timeout: 268 seconds]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
_whitelogger has joined #litex
<geertu>
shorne: somlo: .probe() is not called if device links knows the clock referenced from the DT clocks property is not there.
geertu has quit [Quit: GPU insanity]
geertu has joined #litex
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
geertu has quit [*.net *.split]
nelgau has quit [*.net *.split]
lexano has quit [*.net *.split]
Peanut has quit [*.net *.split]
Melkhior has quit [*.net *.split]
david-sawatzke[m has quit [*.net *.split]
bluecmd has quit [*.net *.split]
leons has quit [*.net *.split]
jryans has quit [*.net *.split]
willcode4[m] has quit [*.net *.split]
_franck_ has quit [*.net *.split]
shenki has quit [*.net *.split]
oter has quit [*.net *.split]
x56 has quit [*.net *.split]
esden has quit [*.net *.split]
tucanae47_ has quit [*.net *.split]
mupuf has quit [*.net *.split]
CarlosEDP has quit [*.net *.split]
Crofton[m] has quit [*.net *.split]
mntmn has quit [*.net *.split]
G33KatWork has quit [*.net *.split]
mithro has quit [*.net *.split]
keesj has quit [*.net *.split]
_florent_ has quit [*.net *.split]
Degi has quit [*.net *.split]
tnt has quit [*.net *.split]
zyp has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
kgugala has quit [*.net *.split]
promach[m] has quit [*.net *.split]
Stary has quit [*.net *.split]
novenary has quit [*.net *.split]
benh has quit [*.net *.split]
toshywoshy has quit [*.net *.split]
jevinskie[m] has quit [*.net *.split]
CarlFK has quit [*.net *.split]
lambda has quit [*.net *.split]
key2 has quit [*.net *.split]
eigenform has quit [*.net *.split]
vup has quit [*.net *.split]
anuejn has quit [*.net *.split]
mikolajw has quit [*.net *.split]
r4d10n[m]1 has quit [*.net *.split]
shoragan has quit [*.net *.split]
pavelow has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
sorear has quit [*.net *.split]
dcallagh has quit [*.net *.split]
DerekKozel[m] has quit [*.net *.split]
nrossi[m] has quit [*.net *.split]
shoragan[m] has quit [*.net *.split]
gatecat has quit [*.net *.split]
shorne has quit [*.net *.split]
tumbleweed has quit [*.net *.split]
felix_ has quit [*.net *.split]
hexagon5un has quit [*.net *.split]
vomoniyi[m] has quit [*.net *.split]
Las[m] has quit [*.net *.split]
a3f has quit [*.net *.split]
amstan has quit [*.net *.split]
sajattack[m] has quit [*.net *.split]
somlo has quit [*.net *.split]
hexagon5un has joined #litex
bluecmd has joined #litex
nelgau has joined #litex
geertu has joined #litex
gatecat has joined #litex
felix_ has joined #litex
lexano has joined #litex
tnt has joined #litex
Peanut has joined #litex
jevinskie[m] has joined #litex
mikolajw has joined #litex
r4d10n[m]1 has joined #litex
nrossi[m] has joined #litex
CarlFK has joined #litex
a3f has joined #litex
Crofton[m] has joined #litex
Las[m] has joined #litex
amstan has joined #litex
promach[m] has joined #litex
DerekKozel[m] has joined #litex
CarlosEDP has joined #litex
vomoniyi[m] has joined #litex
david-sawatzke[m has joined #litex
shoragan[m] has joined #litex
dcallagh has joined #litex
sajattack[m] has joined #litex
mupuf has joined #litex
Melkhior has joined #litex
jryans has joined #litex
mithro has joined #litex
G33KatWork has joined #litex
_franck_ has joined #litex
kgugala has joined #litex
toshywoshy has joined #litex
zyp has joined #litex
keesj has joined #litex
RaYmAn has joined #litex
oter has joined #litex
shoragan has joined #litex
benh has joined #litex
Stary has joined #litex
vup has joined #litex
eigenform has joined #litex
key2 has joined #litex
novenary has joined #litex
anuejn has joined #litex
willcode4[m] has joined #litex
Degi has joined #litex
esden has joined #litex
tucanae47_ has joined #litex
x56 has joined #litex
shenki has joined #litex
lambda has joined #litex
shorne has joined #litex
pavelow has joined #litex
sorear has joined #litex
kbeckmann has joined #litex
tumbleweed has joined #litex
somlo has joined #litex
leons has joined #litex
_florent_ has joined #litex
mntmn has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #litex
nelgau has quit [Remote host closed the connection]
essele has joined #litex
<Wolfvak>
can't you enable COMMON_CLK in menuconfig? according to the Kconfig, the only condition for it not to appear is if HAVE_LEGACY_CLK is enabled, which it only is by some few old SoCs (arm, m68k, sh)
<a3f>
geertu: in that case, shorne should be able to set fw_devlink=off and the probe should be entered, right?
<geertu>
a3f: yep
<geertu>
But the issue with of_match_ptr() suggests he does not have CONFIG_OF=y neither?
<somlo>
geertu: what do you mean by "not there" (re mmc and referenced clock)? It's not *really* there on litex+rocket either, it's just a dummy entry whose frequency I need to parse...
<somlo>
*dummy DTS entry, that is
<geertu>
somlo: If the target clock referenced by the clocks property has not been instantiated yet.
<somlo>
geertu: sorry for being thick here, but by my understanding of what you're saying it shouldn't have worked on litex+rocket or vexriscv either
<geertu>
somlo: openrisc does not select COMMON_CLK
<somlo>
oh, so that's a kernel .config thing, then
<geertu>
With COMMON_CLK, drivers/clk/clk-fixed-rate.c:CLK_OF_DECLARE(fixed_clk, "fixed-clock", of_fixed_clk_setup) takes care of instantiating the fixed rate clock
<geertu>
Actually Kconfig
<somlo>
ok, that makes sense. So then we need a simpler, less dependency-encumbered way to specify a clock frequency for the mmc DT node
<geertu>
IMHO OpenRISC should just switch to CCF, like all other modern architectures
<somlo>
wondering what the sequencing of that vs. upstreamability of litex_mmc should be :)
<geertu>
Then we no longer need things like
<geertu>
anyOf:
<geertu>
- required: [ clock-frequency ]
<geertu>
- required: [ clocks ]
<geertu>
in Documentation/devicetree/bindings/serial/8250.yaml
<geertu>
Although it's probably too late to kill all of that, due to legacy ("real") OF on PPC etc.
<somlo>
ah, so that's a hint for me (and/or shorne) to do something kludgy in the short term :D
<geertu>
You could do like of_platform_serial_setup() for 16550. And repeat that for any future driver that uses clocks :-(
<geertu>
shorne: just select COMMON_CLK and be happy?
<somlo>
shorne: and if that won't be an option for you, let's chat about it on the LiteSDCard review thread on lkml -- if we're going to modify or add alternative ways to specify the sd_clock source in DT
<geertu>
If you want to share drivers across architectures, you really want to use COMMON_CLK
<somlo>
geertu: as it is right now, I should add `depends on COMMON_CLK` to the litesdcard Kconfig entry, though...
<geertu>
somlo: I think so
<geertu>
technically, depends on HAVE_CLK should do, as there are non-CCF clock implementations. But if you use OF and clocks, you must use CCF for clocks.
<geertu>
(and OpenRISC uses OF, and currently no clocks)
FabM has quit [Ping timeout: 240 seconds]
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
essele_ has joined #litex
essele has quit [Read error: Connection reset by peer]
nelgau has joined #litex
FabM has quit [Ping timeout: 268 seconds]
<shorne>
geertu: selecting COMMON_CLK is not enough. I think because arch/openrisc does not call of_clk_init(NULL); and other things to support the common_clk framework.
<shorne>
probably we would want: depends on ((PPC_MICROWATT || LITEX) && OF && COMMON_CLK) || COMPILE_TEST
<shorne>
I will reply on the list, I am thinking I should just add support for common_clk to arch/openrisc
<somlo>
shorne: how about "((PPC_MICROWATT || LITEX) && OF && HAVE_CLK) || COMPILE_TEST" ?
<somlo>
I think COMMON_CLK is one of the ways to satisfy HAVE_CLK (per geertu, earlier)
<shorne>
I see, it should work
<shorne>
now I also see there is HAVE_LEGACY_CLK
<somlo>
yeah, that I think would also satisfy HAVE_CLK
<somlo>
I'll make this change and line it up for v12, but probably I'll wait for any more feedback (and for news on how enabling common_clk support works out for you eventually)
nelgau has quit [Remote host closed the connection]
nelgau has joined #litex
<shorne>
I got it to work
<somlo>
\o/
<shorne>
I did the common_clk init in arch/openrisc/kernel/time.c
<shorne>
Ill reply on v11
<somlo>
awesome!
<somlo>
how about the BE memcpy_from_io() thing?
<somlo>
i.e., is litex_mmc (v11 + depends_on HAVE_CLK) working OK on openrisc?
<shorne>
it seems to just work the whole system boots and works
<shorne>
any specific test case?
<somlo>
ok, good to hear (I sort-of expected that after digging into the inner workings of memcpy_fromio)
<somlo>
nothing fancy, if it even recognizes the card and you can ls on it, we should be good
<somlo>
if it were scrambling the endianness of the 4x32-bit response register, we'd know :)