<apritzel>
acmeplus, macromorgan, tokyovigilante: the H616 THS patches have reached mainline a few hours ago, which should conclude the sunxi related patches queued for 6.9-rc1
<apritzel>
it compiled and ran without issues for me, so you can rebase your patches on top of latest mainline, even though it is typically not recommended doing so during the merge window
ftg has quit [Read error: Connection reset by peer]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<tokyovigilante>
thanks apritzel for the heads up. Saw the THS patches landed, I have tried the cpufreq patches on top but the modules aren't loading for me based on my DT
<tokyovigilante>
re the 32K clock, is this something we're stuck with or can we work around if there is no crystal on the board?
<tokyovigilante>
To be fair the vendor BSP seems to have reasonably stable wifi/BT
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
gamiee is now known as Guest3242
gamiee has joined #linux-sunxi
Guest3242 has quit []
gamiee_ has joined #linux-sunxi
<tokyovigilante>
1512 MHz, 0.6614 nanosec clock - from the vendor BSP, so seems to be able to make the full 1.5GHz
apritzel has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
<gamiee>
testing the bridge...
<gamiee_>
ok works :D
<apritzel>
tokyovigilante: acmeplus sent the cpufreq table from the BSP kernel yesterday, and it looks different from the existing one
<apritzel>
but I already integrated that into the patch, so you should get the full 1.5 GHz
<apritzel>
tokyovigilante: re the 32K clock: the SoC can generate this internally, but this needs some calibration step to be accurate, which we apparently miss in the mainline driver
<apritzel>
I guess the BSP kernel does it correctly
junari has joined #linux-sunxi
<electricworry>
apritzel: Thanks for the H616 THS announcement. It's nice to see the register code is in the kernel now instead of needing to be in the bootloader.
<electricworry>
Since I'm a newbie, I can see in the mainline patches that in the DT bindings the property allwinner,sram is only true if allwinner,sun50i-h616-ths is contained. Further, I can see sunxi_sram_regmap_accessible_reg() allows access to offset 0x0 of what I presume is syscon@3000000?
<electricworry>
However, where or what actually calls to set the register to 0? That I can't find.
<apritzel>
electricworry: in sun8i_thermal.c sun8i_ths_get_sram_regmap() follows the allwinner,sram property to get the regmap that exposes that register
<apritzel>
and then right at the beginning of sun50i_h6_thermal_init() we clear that
<apritzel>
it's admittedly a lot of code and hoops to jump through just to clear a single bit, but blame AW for designing this in such a hacked up way ;-)
szemzoa_ has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
<electricworry>
Thanks, I'm starting to see it. No blame to apportion :) I don't know what's good or bad design and just need to understand driver implementation better :)
Schimsalabim has quit [reticulum.oftc.net helix.oftc.net]
bauen1 has quit [reticulum.oftc.net helix.oftc.net]
Danct12 has quit [reticulum.oftc.net helix.oftc.net]
hexdump01 has quit [reticulum.oftc.net helix.oftc.net]
hramrach has quit [reticulum.oftc.net helix.oftc.net]
juri_ has quit [reticulum.oftc.net helix.oftc.net]
diego71 has quit [reticulum.oftc.net helix.oftc.net]
vpeter has quit [reticulum.oftc.net helix.oftc.net]
Skippythekangoo has quit [reticulum.oftc.net helix.oftc.net]
szemzoa has quit [reticulum.oftc.net helix.oftc.net]
igraltist has quit [reticulum.oftc.net helix.oftc.net]
libv has quit [reticulum.oftc.net helix.oftc.net]
libv has joined #linux-sunxi
<electricworry>
So if sunxi_sram_regmap_accessible_reg() is accessed via a function pointer .writeable_reg on a `struct regman_config`, where is the glue that actually causes that to be called when sun8i_ths_get_sram_regmap() calls dev_get_regmap()?
igraltist has joined #linux-sunxi
bauen1 has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
vpeter has joined #linux-sunxi
diego71 has joined #linux-sunxi
juri_ has joined #linux-sunxi
hramrach has joined #linux-sunxi
dsimic is now known as Guest3302
dsimic has joined #linux-sunxi
Skippythekangoo has joined #linux-sunxi
Guest3302 has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<apritzel>
that's deep in linux device model: each device has a list of resources, a regmap is one of them
<apritzel>
so you get the struct device pointer of the SRAM device by using the DT phandle lookup, then ask for the associated regmap
<apritzel>
once you have the regmap pointer, you can use the generic regmap API
KREYREN_oftc has quit [Remote host closed the connection]
<apritzel>
and down in that rabbit hole it's probably regmap_readable() in drivers/base/regmap/regmap.c that eventually triggers the callback
<apritzel>
(or rather the respective writeable version)
<electricworry>
apritzel: thanks for taking the time to explain. I'll save this conversation so I understand better as I presume this is knowledge that's not really explained in guides.
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<wens>
jernej: the patch is from smaeul , but I'll try to get to it over the weekend
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
warpme has quit []
junari_ has quit [Remote host closed the connection]
warpme has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
warpme has quit []
nickAA has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<apritzel>
electricworry: sorry if I lost you ;-), but this *is* quite complex in the kernel, with all the abstractions, piled up over decades. You should keep it high level, initially, to keep your sanity
<apritzel>
electricworry: for now: we use the phandle in the DT to get to the SRAM device, which kindly exports parts of its registers via a regmap, so we can poke our bit in there
nickA has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
nickA has quit []
<electricworry>
Thanks apritzel. I don't expect to learn all of this quickly. I've been learning for months on and off and I've realised it's not something to learn in a weekend.
Daanct12 is now known as Danct12
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
bauen1_ has quit [Remote host closed the connection]