02:44 <jevinskie[m]> Is this an accidental mix of 64 and 128 bit copying? I can’t grok it otherwise. https://github.com/AsahiLinux/m1n1/blob/95ef45fd11dbc3d9da2781ac691136873b910c25/proxyclient/tools/chainload.py#L94

04:57 <marcan> jevinskie[m]: yes it is, ha

04:59 <marcan> jevinskie[m]: fixed, thanks :)

06:08 <marcan> robher_: to revisit the "tunables" issue, what are your thoughts on blobs in the DT? Apple puts a pile of register pokes in the DT to configure the USB3/Thunderbolt/DP PHYs... and in this case AIUI they have to be applied at runtime depending on what's connected

06:08 <marcan> I checked and they do indeed differ between different devices using the same SoC, though only slightly (not sure if they differ between different units of the same device)

06:08 <marcan> so we can't just throw it into the driver :/

06:09 <marcan> I think this has come up a few times before in vendor trees, but I don't know if any mainlined driver does this kind of thing?

06:10 <marcan> lol, soc/fsl/cpm_qe/qe.txt apparently puts an entire *firmware* blob in the devicetree? :D

06:15 <marcan> I see there's some precedent in stuff like qcom,ath10k-pre-calibration-data, but those are opaque blobs

06:15 <marcan> I don't know if there's anything that's a list of registers to write and values/masks

06:16 <marcan> (which is what we have)

07:23 <jannau> is the difference between devices in the written values or are there differences in the registers or the order of writes?

07:24 <jannau> if only values differ it can be easily transformed into a blob. The only disadvantage is that forward compatibility might not be possible

07:25 <jannau> marcan: don't we need to wait for Rob's ack on the iMac addition in the bindings change as well

07:26 <marcan> yes, it's along similar lines though

07:27 <marcan> jannau: usually the written values, but sometimes there's an extra reg or a whole tunable is missing/empty

07:27 <marcan> I think if we're doing this it's not worth trying to hardcode the offsets

07:29 <marcan> in fact, given what Apple did with t6000 in the memory controller, if this kind of thing is acceptable I'm tempted to use it for the mcc OPP table too, since t8103 needs two pokes and t6000 only one (to a different place) for the performance switching, but they're otherwise identical in high-level construction (number of channels differs but that was a variable already)

07:29 <marcan> I figure if we're putting magic reg values in the DT at all, we might as well put the reg addresses too and make it forward-compatible

07:29 <marcan> though right now apple uses the same values for everything in the MCC case, so alternatively this could all be hardcoded in the driver and driven by the SoC compatible

11:10 <kettenis> the MCC driver isn't really essential is it?

11:12 <kettenis> I mean, things will still work if for some future SoC the driver isn't there

11:32 <marcan> yes, it isn't, as long as cpufreq doesn't fail poorly without it

11:33 <marcan> though I think other parts of MCC are more stable between SoCs, e.g. we should implement error control

11:46 <kettenis> so then you'd need a "generic" compatible and you'd only apply the values if a more specific compatible matches as well

11:46 <kettenis> if you choose to put the values in the driver that is

11:48 <kettenis> but maybe the actual values depend on the RAM modules integrated in the SoC?

11:49 <kettenis> and Apple will maybe source different RAM modules at some point that need different parameters?

11:49 <marcan> nah, I don't think so. they're power management timers.

11:50 <marcan> I don't think it changes any characteristics of the interface, it just changes how eagerly it goes into lower power modes (to reduce cache miss latency when the CPUs are busy)

11:50 <marcan> I tried random values, zero, etc, and nothing broke (in fact I got better performance with zero, which presumably turns off all the PM stuff altogether)

12:02 <povik> i am thinking about how i should express the MCA stuff in DT

12:02 <povik> seems to me there should be one parent node for the MCA block as a whole

12:02 <povik> and then child nodes for particular subdivisions, let's call them clusters

12:03 <povik> now the clusters need to have a cluster index within the MCA as a whole

12:03 <povik> and also clusters have associated mmio ranges, which cannot be systematically derived from some large range for the whole MCA

12:04 <povik> i am thinking the cluster index should be in the reg= of the child nodes

12:04 <povik> a then the mmio ranges for the clusters should be listed in the parent node

12:05 <kettenis> that sounds wrong

12:05 <povik> another option is having the mmio ranges in reg= of the cluster nodes, and then an extra property for the cluster index

12:06 <kettenis> what do you need the cluster index for?

12:06 <povik> it is important for configuration in some registers

12:08 <kettenis> then I'd suggest using a property for that

12:09 <kettenis> "apple,cluster"

12:10 <povik> cluster-idx perhaps?

12:12 <kettenis> sure; but maybe check the existing bindings to see if there is an established pattern for such things

12:12 <povik> yeah

12:13 <kettenis> you can add a "syscon" compatible to the MCA block node to make it provide a regmap

12:13 <kettenis> and then use the "reg" property in the child nodes to provide offsets within the block of registers

12:18 <povik> hm, haven't seen "syscon" yet, will look at that

12:19 <marcan> see how pmgr does it

12:20 <marcan> though there's two ways, if you add a simple-mfd compatible it will probe the child nodes for you; if you don't it won't and the parent will be in charge of requesting that (which makes more sense if you have a common driver)

12:20 <marcan> also look at other ALSA/ASoC stuff because there's a good chance some other SoC does it similarly

12:21 <kettenis> there are two schemes for specifying how the various audio components are related

12:22 <kettenis> and it isn't clear to me what the preferred way of doing that is

12:23 <kettenis> "simple-audio" and "audio-graph"

20:04 <sven> the rtkit protocol seems to have at least the following power states: 0, 1, 2, maybe 3, 0x10, 0x20 and i think you can set an additional flag (0x200) for some of them which does $something while it's ignored for others

20:04 <sven> 0 it power off, 0x20 is power on (and so is 0x220 which seems to be the same). 0x10 is some kind of hibernation or sleep mode. no idea yet about 1 or 2 (or maybe 3; need to double check tomorrow) or what that flag means