ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<steev> bamse: your flex 5g doesn't show a massive number of interrupts for one of the hid over i2c devices?
<steev> 161: 26887116 0 0 0 0 0 0 0 msmgpio 37 Level hid-over-i2c
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov__ has quit [Ping timeout: 480 seconds]
matthias_bgg has quit [Ping timeout: 480 seconds]
SallyAhaj has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
<bamse> steev: it does
<bamse> steev: related to the keyboard i believe
<steev> hm, mine is definitely the touchpad
<steev> i'm still trying to track down what is going on here :(
matthias_bgg has joined #aarch64-laptops
matthias_bgg has quit []
jhovold has quit [Ping timeout: 480 seconds]
<qzed> bamse: are these devices supposed to have edid/ddc and all that fancy stuff over i2c?
<qzed> the SPX does have an i2c bus that kinda looks like it has all the right things
<qzed> but it turns out that the eeprom at 0x50 which normally holds edid info is access-protected by some GPIO that I'd have to pull up
<qzed> unfortunately that also enables some reset signal that I have no clue of what it does
<bamse> qzed: a dedicated i2c bus or the aux-bus associated with edp?
<qzed> seems to be dedicated
<bamse> qzed: the other sc8180x boards have an aux bus...
<qzed> does the edp have an internal bus?
<qzed> so from what i can tell (mostly the pin being named "DEPROM_PROG") that connection seems to be for programming the eeprom
<qzed> on the other hand I was able to read the edid from some "TCON" firmware
<qzed> which seems to be a timing controller on the display assembly
<qzed> by dedicated bus I mean it's handled via some QUP / I2C interface
<qzed> also it has some other things I2C chips associated with the TCON device
<qzed> but I haven't been able to read from the 0x50 eeprom... (later figured out it's somehow guarded from access as I said)
<bamse> qzed: there's a dedicated i2c bus in (e)dp...it seems unlikely that they did something other than use that
<bamse> qzed: look at linux-next, arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi, &mdss_edp node
<bamse> qzed: they use the "edp-panel" compatible, which relies on being able to read out the edid information from the panel
<bamse> qzed: what i did on primus etc predates the changes needed in the dp driver to make that work
<bamse> which means that i should update primus and flex dts files...
<qzed> ah, I was wondering about the "ddc-i2c-bus" property of that thing
<qzed> interesting
<qzed> so it should work without that property?
<qzed> it's still connected to some GPIO pins (39 and 40) on the TLMM though... is that the standard way of doing things?
<qzed> and those do run to the display connector as EDP_i2C_SD{A,L}
<qzed> although... aux may be EDP_AUX_C_D{N,P}?
<bamse> not sure about the 'C' in there, but in my schematics (for this other board) they are EDP_AUX_[NP]
<qzed> neat!
<qzed> initially I thought that I2C thing was supposed to be the aux, but I think that's just for control of their custom display driver stuff
<qzed> things are starting to make sense now, thanks!
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 481 seconds]