rajkosto has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
tuxd3v has joined #linux-sunxi
Luke-Jr has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<tuxd3v>
does any one knows any board that supports bluetooth5.0+ ??
tuxd3v has quit [Remote host closed the connection]
tuxd3v has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
aggi_ has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
aggi_ has quit []
aggi has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
tuxd3v has quit [Ping timeout: 480 seconds]
KotCzarny has joined #linux-sunxi
aggi has quit [Quit: connection closed.]
aggi has joined #linux-sunxi
pmp-p is now known as Guest2530
pmp-p has joined #linux-sunxi
Guest2530 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
apritzel has joined #linux-sunxi
digetx has quit [Ping timeout: 480 seconds]
tuxd3v has joined #linux-sunxi
<apritzel>
jernej: smaeul: so do I get this right that clock consumers have to keep track of the clock's status? So they must never disable an already disabled clock, for instance?
<jernej>
correct, enable/disable, prepare/unprepare calls need to be balanced in all cases
<apritzel>
so is there some solution when a device just wants to start with a clean slate, so with a disabled clock, for instance?
<apritzel>
looking at the generic PHY at the moment
<jernej>
clock core disables all clocks by default, unless marked as critical
<jernej>
by default -> at boot
<apritzel>
ah, that's a good point
<apritzel>
the of_mdio PHY part starts with resetting the PHY, and I add the clk_disable_unprepare() right next to it
<jernej>
clocks are refcounted, so if you call clk_disable_unprepare() before clk_prepare_enable(), you'll get warning in dmesg
<apritzel>
exactly what I am seeing
<apritzel>
needs some thinking, since I think resets are more forgiving in this respect
<jernej>
why would you want to disable clock anyway?
<jernej>
it shouldn't cause any issue if it is enabled beforehand
<apritzel>
the generic PHY just has this mdio_device_reset(int value) function, where it toggles the reset line
digetx has joined #linux-sunxi
<apritzel>
and I just enable/disable the PHY clock (which is the AC200 EPHY clock gate in my case) in this very function
<apritzel>
but the code starts with mdio_device_reset(1), to start with a clean slate
<jernej>
I see
<apritzel>
there are not too many callers of that function, though, I could just handle the clock separately
<apritzel>
I just didn't want to change too much of the generic OF PHY code
<jernej>
yeah, semantic isn't compatible, probably best to handle it separately
<apritzel>
jernej: many thanks, that answers my question!
<jernej>
np
<jernej>
well, I'm not completely sure how reset framework behaves
<jernej>
I spent much more time with clocks than resets. Resets just work, while clocks are completely different story :)
<apritzel>
jernej: from a quick reading it looks like resets differentiate between shared and exclusive
<apritzel>
shared apparently mimics the clocks refcounting behaviour, but exclusive might not
<apritzel>
and the PHY code uses reset_control_get_optional_exclusive()
<apritzel>
jernej: yup, splitting that off solves this problem, and looks even cleaner
tuxd3v has quit [Ping timeout: 480 seconds]
<apritzel>
still one issue when the PHY gets the clock: "refcount_t: addition on 0; use-after-free."
juri__ has quit [Remote host closed the connection]
juri_ has joined #linux-sunxi
<apritzel>
so something when it ties the clk_hw (my generic regmap gate clock) into struct clk for the device
<apritzel>
jernej: does that ring a bell? I re-use most of the clk-gate.c code, and registration works if I fake it to use one of those MMIO clocks
<jernej>
apritzel: no, I don't remember ever seeing that message
juri_ has quit [Remote host closed the connection]
juri_ has joined #linux-sunxi
<apritzel>
ok, thanks, debugging ...
cnxsoft has quit [Ping timeout: 480 seconds]
Hypfer has joined #linux-sunxi
gsz has quit [Quit: leaving]
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
ftg has joined #linux-sunxi
digetx has quit [Read error: No route to host]
digetx has joined #linux-sunxi
tuxd3v has joined #linux-sunxi
<gamiee>
hi smaeul, please, is there any vision of adding to crust feature to able to disable some of it's features, like IR or CEC wake up (from userspace, or u-boot) ?
<smaeul>
gamiee: I don't have anything specific planned, but I am open to it. It has been a recurring request -- probably would be good to track on github
<smaeul>
the blocker has always been how to pass the information to crust
tllim has joined #linux-sunxi
tllim has quit []
<gamiee>
smaeul: one of my first ideas was to use PCSI and SCPI
<gamiee>
(note, my target SoC is H3)
<gamiee>
so on every boot, I would send message via custom PCSI command to u-boot, and from u-boot to crust via SCPI.
<smaeul>
that should work
<gamiee>
or second idea, it would be configured by u-boot on first boot by custom commands in boot.scr
<gamiee>
But both of those ideas seems to be impossible to upstream to kernel nor u-boot.
<smaeul>
the PSCI (technically "SMCCC") method should be upstreamable if Allwinner delegates some subset of its SiP range to us
<gamiee>
but I guess this is not realistic, or ?
<smaeul>
I don't know. it's something we need for other uses as well, such as reading the SID when in secure mode
<gamiee>
actually, that would be handy too, since I use SID in my project, and eventually would like to move it to secure mode to enable encryption etc.
<gamiee>
I would like try to do this, although, I will definitely need some help, and mainly to find out the best way to do this (so it is also upstreamable).
<gamiee>
Since this is for my business product, I have some money reserved to support this effort. (it's not much due product is in early stages, but should be helpful)
<smaeul>
I think apritzel would be on board if we get some response from Allwinner
<gamiee>
I tried to get in touch with Allwinner few years ago, and even for business inquiry, I never got any reply (only from their partners), so no idea how to get in touch with anyone from AW :/
<smaeul>
yeah, I only know of a couple people involved with D1 upstreaming, and the email addresses from source code headers :)
<gamiee>
In case we will not receive reply from AW, is there any other way of doing this? Or just off-tree patch with not fully proper implementation?
<smaeul>
we could allocate from the end of the SiP range, sort of like the de-facto GNU extensions to ELF
<smaeul>
IIRC AW doesn't even use right function ID range for their blob anyway
<gamiee>
hmm, okay! One more question, in terms of user-space, what would be best way of implementing this, so user-space apps can enable / disable settings in Crust or get data from SID ?
<smaeul>
I recommend using the existing API when possible, so that would be Linux's generic wakeup source API
<smaeul>
just throwing out ideas here: 1) have a DT node for the firmware driver, like 'wakeup: wakeup { compatible = "allwinner,smccc-wakeup-service"; }'
<smaeul>
2) link the IR and HDMI devices to that node with a property giving an "ID" that gets passed over the SMCCC/SCPI comand, like 'hdmi { allwinner,wakeup-source = <&wakeup 1>; }'
<smaeul>
then provide some function from the firmware driver (that can be called by the IR/HDMI driver) to register a wakeup source using that property
<smaeul>
that would provide enable/disable using the existing sysfs API. extra data like IR key configuration could maybe come from somewhere else in sysfs
JohnDoe_71Rus has quit []
gamiee2 has joined #linux-sunxi
<apritzel>
smaeul: I haven't thought much about this, but why does this need to use SMCCC, so go via EL3? You communicate via msgbox and shared memory, right?
<smaeul>
apritzel: because SRAM A2 is secure-only
<apritzel>
ah, that's where the shmem region is located?
Luke-Jr has quit [Ping timeout: 480 seconds]
<smaeul>
yeah, AR100 cannot access SRAM A1 on some SoCs. SCPI shmem could be put in DRAM, since SCPI only needs to work while the system is awake, but 1) DT bindings assume SRAM, and 2) it would be an ABI break
<apritzel>
smaeul: yeah, that's fine, I guess, it is what it is
<smaeul>
on the other hand msgbox is nonsecure-only, so Linux could send between 4 and 16-byte messages via msgbox only
<apritzel>
the question is how dynamic this must be, as in: at Linux runtime?
<smaeul>
which is a bit of a vulnerability that Linux could ring the secure SCPI doorbell
<apritzel>
which doorbell, the one on the AR100 side?
<smaeul>
the msgbox channel, which is used as a doorbell for SCPI
<apritzel>
in my experiments I could only send between the A53s and the ARISC, never between the A53s
<apritzel>
but I guess I am misunderstanding something ...
<smaeul>
there are two SCPI channels, one "secure" and one "nonsecure".
<smaeul>
since msgbox is wholly nonsecure, nonsecure world can send a message in the msgbox channel associated with the "secure" SCPI channel
<smaeul>
allowing it to replay secure SCPI messages
<smaeul>
or DoS the secure world from another CPU by racing to consume the response msgbox message
<gamiee>
In case of H3, there is SCPI channel between u-boot and ARISC, correct ?
<smaeul>
yes, for 32-bit SoCs, U-Boot's secure monitor is the PSCI server / SCPI client
<smaeul>
"secure" SCPI client, to be specific
<smaeul>
both crust and TF-A/U-Boot do polling anyway, so one thought I had and implemented was using a well-known SRAM A2 address for doorbell as well, which nonsecure world can't touch. but this is an ABI break as well
hlauer has joined #linux-sunxi
<apritzel>
if this is one-direction communication only (IIUC), can't we just put something in some memory location somewhere and let crust read that when it needs it?
<apritzel>
I mean I don't think we need to go super crazy on some system design, when the task at hand is comparably simple
<apritzel>
and it sounds like the amount of information is rather manageable, so to speak (a single byte/word, even?)
<smaeul>
one thing that needs to be configured is the IR protocol and key code, which I assume needs to be changeable at runtime
<apritzel>
but also I don't think anything or anybody stops us from using some SMC number, really
<smaeul>
IR key code is 32-bits, so any msgbox protocol would have to be stateful
gnarface has joined #linux-sunxi
<smaeul>
(which isn't necessarily a problem, just something to note)
<smaeul>
so options for NS world are 1) shared buffer in DRAM, 2) msgbox conduit, 3) SMC to secure world so it can use SRAM A2 for SCPI or a shared buffer
<apritzel>
if TF-A or U-Boot, as proxies for Crust, would put some address in the DT, and Linux writes some info there, can't Crust just pick that up?
<smaeul>
yeah, that would be option #1
Daanct12 has quit [Remote host closed the connection]
freemangordon1 has joined #linux-sunxi
freemangordon has quit [Read error: Connection reset by peer]
freemangordon has joined #linux-sunxi
freemangordon1 has quit [Read error: Connection reset by peer]
freemangordon has quit []
freemangordon has joined #linux-sunxi
Danct12 has joined #linux-sunxi
freemangordon1 has joined #linux-sunxi
freemangordon2 has joined #linux-sunxi
freemangordon has quit [Ping timeout: 480 seconds]
freemangordon1 has quit [Ping timeout: 480 seconds]
freemangordon has joined #linux-sunxi
<tuxd3v>
does any one knows any board that supports bluetooth5.0+ ??
freemangordon2 has quit [Read error: No route to host]
<apritzel>
I guess not ;-)
freemangordon1 has joined #linux-sunxi
freemangordon has quit [Ping timeout: 480 seconds]
freemangordon1 has quit []
freemangordon has joined #linux-sunxi
<apritzel>
tuxd3v: although, it looks like (at least on paper) the AW859A module sports BT5.0?
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
<apritzel>
which is used on the OrangePi Zero2, and probably many other H616 boards (or even TV boxes)
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
freemangordon1 has joined #linux-sunxi
freemangordon has quit [Read error: Connection reset by peer]
freemangordon1 has quit []
freemangordon has joined #linux-sunxi
freemangordon has quit []
freemangordon has joined #linux-sunxi
tuxd3v has quit [Remote host closed the connection]
gamiee2 has quit [Ping timeout: 480 seconds]
hlauer has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
aggi has quit [Read error: Connection reset by peer]