essele has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
essele has joined #litex
essele has quit [Ping timeout: 256 seconds]
essele has joined #litex
essele has quit [Ping timeout: 240 seconds]
Martoni has joined #litex
essele has joined #litex
essele has quit [Ping timeout: 240 seconds]
essele has joined #litex
essele has quit [Ping timeout: 256 seconds]
essele has joined #litex
Martoni has quit [Ping timeout: 240 seconds]
essele has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shorne>
somlo: I am trying to bring up the new litex mmc driver now. It doesn't seem to work. Maybe related to litex_sys_clk which doesnt exist in openrisc. Ill try to see what can be done.
<somlo>
shorne: look at litex commits b4fb3ea9 and d108d2ad for the relevant DTS updates the driver ended up relying on during review
<shorne>
somlo: thanks, I am using the latest litex and generated what looks like a correct dts.. tracing the boot process it seems I am never getting to litex_mmc_probe
<shorne>
[ 5.640000] initcall litex_mmc_driver_init+0x0/0x30 returned 0 after 2016 usecs
<somlo>
btw, I also had to drop the `of_match_ptr()` wrapper from around `litex_match` -- can that have anything to do with it?
<shorne>
that doesn't tell much, but I also added a dev_info(dev, "Initializing litex mmc"); to the top of litex_mmc_probe
<shorne>
yeah, it could be... I saw that change, let me see
<shorne>
I am adding back of_match_ptr to see if it helps
<shorne>
hmm, I don't think it will, of_match_ptr is just #define of_match_ptr(_ptr) (_ptr)
<somlo>
oh, it's a no-op
<somlo>
sorry it broke for you, hopefully we can figure out why
<somlo>
somewhat orthogonally, I'm going to push out v11 in a few minutes, a few additional bits of polish to the sources (unlikely to make a difference for the better in your case, though, sadly)
<shorne>
Yeah, Ill figure it out.
<shorne>
I am just debugging/printffing/tracing the init process to see where its going wrong
nelgau has joined #litex
<somlo>
wondering if publishing all the intermediate versions (which I've kept as separate branches) in litex-hub/linux could be of any help to you, to do a "meta-bisect" of sorts ?
<somlo>
you could of course just `git-am` them from all the emails, but that'd be more of a PITA
<somlo>
but yeah, it'd be interesting to know how come it's failing to even call into litex_mmc_probe() for you
<shorne>
yeah, likely something simple, I may have to meta-bisect it but that may be a last resort
<somlo>
there's only 10 revisions, so about 3 or 4 places to try :)
<somlo>
that used to be four litex_read32()'s, but it seemed like memcpy_fromio() doesn't play weird endianness swaps on BE the way readl() does (so that I have to undo that with another le32_to_cpu in _read_litex_subregister()
<somlo>
and it'd be nice to have a successful test on BE just as a sanity check
<somlo>
I also had to do some changes to the Kconfig wizardry, but I don't think there's more to it beyond whether you get the option to select the driver or not during build, and you obviously are building it, so that wouldn't likely be it either
<shorne>
ok, the BE thing might be interesting, that always gives us issues
<shorne>
[ 6.360000] probe of e0005000.mmc returned -517 after 293 usecs
<a3f>
shorne: clock missing? might be a good occasion to use dev_err_probe, so /sys/kernel/debug/devices_deferred can give some useful info on what deferred the probe indefinitely
<shorne>
I think the probe is being called, for some reason these dev_info logger statements are not being outputted
<a3f>
Do you have dev_info first thing in the function or later on?
<shorne>
first thing, I think I need to enabled dynamic debug
<a3f>
hmm, perhaps driver core tries to request some resource for you? I saw that with power domains, I think. if they are not yet loaded, they defer probe even before it runs
<somlo>
shorne: what's your `sys_clk` entry in DTS look like?