<z3ntu>
Is there a proper way to model i2c pullups by some regulator (or fixed regulator) in dts?
<z3ntu>
like pullup-supply = <&foobar>; or whatever
frytaped has quit [Quit: frytaped]
pevik_ has quit [Ping timeout: 480 seconds]
<Mis012[m]>
don't think so, but there ought to be
<z3ntu>
I think in many cases the supply used for a device on the bus is also doing pull up but that's more of a coincidence from a software perspective
<bamse>
z3ntu: i think the most common case is that you have some shared pull-up source which is just always-on
<bamse>
z3ntu: but there's definitely other cases...
<Mis012[m]>
bamse: if it's not even per bus, then it's just the vendor being lazy with routing...
<Mis012[m]>
though I guess in anything that has an always-on LTE modem the savings are irrelevent
<Mis012[m]>
*irrelevant
<Mis012[m]>
funnily enough most laptops don't have one, so it shouldn't be too hard to make a laptop last considerably longer than a phone
<Mis012[m]>
but the screen is also a lot bigger
<bamse>
Mis012[m]: i think there's few cases where you have a dedicated pull-up regulator per function...but you're right in the power save context, that it might make sense to be able to turn off pull-up rails in some designs
<Mis012[m]>
bamse: my laptop's ACPI seems to turn off the i2c master until it gets an interrupt from the touchpad, I have no idea how it gets away with that...
<Mis012[m]>
also would sure be fun to try and replicate that without ACPI, but worth it
<bamse>
i2c is entirely driven from the master-side, so there shouldn't any problems with that
<bamse>
might have to leave the lines pulled up, so the device doesn't notice that you're gone
<bamse>
hmm, ground them should work as well...as long as you don't gets some signal that will be decodable by the clients it should be fine
<bamse>
Mis012[m]: you can see the same in qualcomm devices where they have some pinctrl state named "something-sleep"
<Mis012[m]>
I guess they do have that...
<Mis012[m]>
mainline mostly doesn't bother
<Mis012[m]>
do you think it actually saves relevant amounts of power, or is it just a gimmick?
<Mis012[m]>
especially with the touchpad
<bamse>
well, it's 29 days since i booted my laptop...and i haven't touched the touchpad during that time
<bamse>
how much power that would have saved if i turned the master off during that time i don't know...but it's quite likely measurable
<Mis012[m]>
I guess you don't happen to know where I could find the datasheet for ITE8225E?
<Mis012[m]>
or at least what arch core it uses
<Mis012[m]>
I need to port chromeos-ec to it because I intensely dislike the idea of having a linux driver target more than one sw-defined API
<bamse>
hehe, i can definitely relate to that problem
<bamse>
got some black box EC in my lenovo yoga c630...and it's responsible for battery management and usb-c, at least
<bamse>
probably keyboard backlight...and perhaps the keyboard itself as well
<bamse>
but the keyboard is exposed as a i2c-hid device
<Mis012[m]>
at least I managed to secure schematics for my lappy... it's nice to have connections
<bamse>
the rest seems to be acceissble over some completely bonkers protocol
<bamse>
nice
<Mis012[m]>
if the API is hw-defined, you can just make a driver
<bamse>
who knows...would surprise me
<Mis012[m]>
if it's sw defined... yuck
<bamse>
i've written a power-supply driver, based on the dsdt...and it's yuck
<bamse>
but one of the problems i'm facing is that i don't know if it's some common protocol, or if it's specific to this device etc
<Mis012[m]>
bamse: also I've found a nice diagram for why AMD SoCs probably can't have a unified address space mode, and it makes me sad
<Mis012[m]>
it seems that everything that's in the x86 cores' memory space is accessed through the SDF
<Mis012[m]>
and the USB phy that Linux has a bloody driver for is accessed though the SCF
<Mis012[m]>
and it seems that even the PSP's arm core only uses 16 ugly 1MB apertures to access the SCF
<Mis012[m]>
and then 32 ugly 1MB apertures to access the x86 cores' address space
<bamse>
i don't know much about x86...but isn't this just the split between ioport and memory?
<Mis012[m]>
bamse: even if the protocol is common across one brand... why have more protocols when one could just get the datasheet and port chromeos-ec
<bamse>
Mis012[m]: i bet that dual booting windows would be difficult then ;) but yeah that would have been nice...cros-ec or any other standard interface
<Mis012[m]>
windows belongs in a VM until they support device trees
<bamse>
they have exactly the same view about your os :)
<Mis012[m]>
the issue is that it's not my OS
<Mis012[m]>
and the Linux foundation's vested interest is to make M$ happy more than make me happy
<Mis012[m]>
bamse: and Linux does support ACPI, for better or worse
<Mis012[m]>
Advanced Standard For Ugly Glue
<Mis012[m]>
bamse: what is your EC called? I assume you already tried to get a datsheet :P
<Mis012[m]>
also speaking of standard interface, once I get my soldering equipment, I will assemble microSD adapter and try to use SWD to poke SSC
pevik_ has joined #linux-msm
pevik__ has joined #linux-msm
pevik_ has quit [Remote host closed the connection]