On Fri, Oct 20, 2023 at 10:25:19PM +0200, Alexandre Belloni wrote:Got it. I think we are on the same page. Thanks for explanations!
On 20/10/2023 17:12:53+0200, Zbigniew, Lukwinski wrote:
On 10/20/2023 4:33 PM, Miquel Raynal wrote:
Hi Frank,
Frank.li@xxxxxxx wrote on Fri, 20 Oct 2023 10:20:57 -0400:
On Fri, Oct 20, 2023 at 03:45:28PM +0200, Miquel Raynal wrote:Maybe it's not the first time this case is faced, would you mind
Hi Lukwinski,I agree. sys entry is more flexiable. and let controller choose better
zbigniew.lukwinski@xxxxxxxxxxxxxxx wrote on Fri, 20 Oct 2023 10:55:27
+0200:
On 10/18/2023 10:59 PM, Frank Li wrote:I don't think hotjoin should be considered as a debug feature. The
Add hotjoin entry in sys file system allow user enable/disable hotjoinWhat is the use case for having HJ enable knob in sysfs available for user space other than for debug stuff? In other words, does user space really need to enable/disable HJ in runtime for other reason but debug? If it is only for debug maybe it could be move to debugFS?
feature.
Add (*enable(disable)_hotjoin)() to i3c_master_controller_ops.
Add api i3c_master_enable(disable)_hotjoin();
problem here is the power consumption which is higher if you enable
this feature (you need to keep everything clocked and ready to handle
an IBI) whereas if your design is "fixed" (more like an I2C bus) you
may save power by disabling this feature.
A module parameter does not fit here because it's a per-bus
configuration.
power saving policy for difference user case.
including power management maintainers in this discussion? Perhaps they
might have pointers or even have the solution already.
I did not mind HJ as debug feature. But enabling / disabling the HJ sounds
to me like debug option.
So the flow you are considering here is like this:?
1. system boot with HJ enabled, so HJ works during initial bus
discovery
2. some entity in user space decides to disable HJ because power
consumption?
3. some entity in use space decide some time later to re-enable HJ
because some reason?
I am just wondering whether there is real use case when you starts with HJ
enabled and than disable it
I think it is validate user case. Assume a I3C GPS device, user only use
it when open map. Before map application open, enable i3c hotjoin and
power on GPS module. After map application close, disable i3c hotjoin and
power off GPS module.
FrankSure. Makes sense.
in runtime or start with HJ disabled and enable it in runtime. If you are
taking care about power saving
let's keep HJ disabled all the time. Default state for HJ could be
controlled by DT entry.
This would be HW configuration and not HW description.
Yes, DT maintainer may not accept this entry because it is not HW
description.
Thanks,
Miquèl
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com