<JIaxyga[m]>
<calebccff> " JIaxyga: im here" <- I'm talking about uboot on sm7150. Unfortunately I'm very busy right now. Can you take a look please? https://github.com/sm7150-mainline/u-boot
<JIaxyga[m]>
It looks like uboot is loading, but I have no output via simplefb
<JIaxyga[m]>
Will you be free in 4-5 hours?
<calebccff>
JIaxyga[m]: without UART this is just a game of trial and error :/
<JIaxyga[m]>
calebccff: I tried to solder the uart. But the relatively new xiaomi have something like a fuse that blocks the uart output
<calebccff>
oh, you need to pull the phones Tx pin high (to 1.8v)
<calebccff>
soryr, the Rx pin
<calebccff>
on the phone
<calebccff>
it checks this before enabling UART
<JIaxyga[m]>
calebccff: The pins are already have 1.8V
<calebccff>
I'm fairly sure the Rx pin should be pulled down
pespin has joined #linux-msm
<JIaxyga[m]>
<calebccff> "I'm fairly sure the Rx pin..." <- Anyway, without any configurations, should I see the lk log?
<JIaxyga[m]>
But there is no log at all
<JIaxyga[m]>
theres not even trash
marc|gonzalez has joined #linux-msm
<marc|gonzalez>
lumag, konradybcio, jhugo_: errr, it's not clear to me (at all) how Kalle wants to move forward with the ath10k work-around. Can anyone enlighten me maybe?
<marc|gonzalez>
Is bamse still involved in qcom stuff? He hasn't commented on the msm8998-specific bits :(
<lumag>
marc|gonzalez, I'd say, post the patch moving the code. He wrote that "Testing real hardware (and corresponding firmware) is the most reliable way to know how different products/firmware work, unfortunately." So, I assume, my tested-by should be convincing.
<bamse>
marc|gonzalez: i am...been in the yard digging for apples, yer honor
<marc|gonzalez>
bamse: be careful, one rotten apple destroys the whole batch :D
<phh>
if it's to make calvados, that's an approved usage of time
<marc|gonzalez>
Isn't it like 5am on the west coast?!?!
<marc|gonzalez>
bamse: what's your take on the ath10k fiasco? Change default behavior for all systems, or just msm8998 boards?
<bamse>
marc|gonzalez: 7:22am here in texas
<bamse>
marc|gonzalez: i've not followed the thread, figured you guys will work it out :/
<marc|gonzalez>
texas! texas! why do you I keep forgetting texas!
<marc|gonzalez>
bamse: Kalle has been leaving cryptic messages even when I'm cattle prodding his butt
<bamse>
marc|gonzalez: well, might be that i was on the west coast last time we spoke
<marc|gonzalez>
ooooh
<bamse>
it's been a while
<marc|gonzalez>
Yeah 2019 :(
<bamse>
ohh, yeah i left california 2020
<marc|gonzalez>
bamse: will you attend the solar eclipse?
<bamse>
marc|gonzalez: weather report is promising clouds...but i'm living within the full-eclipse-band...
<bamse>
so one way or another, yes
<marc|gonzalez>
cheers then (or some other celebratory thingamabob)
aklimov has joined #linux-msm
jhugo_ is now known as jhugo
<calebccff>
JIaxyga[m]: the bootloader will not initialise the serial port unless it detects that the Rx pin is pulled up.
<aka_[m]>
so resistor you say
<aka_[m]>
calebccff: is there any work on aospm?
<aka_[m]>
glodroid looks stuck at A13
<aka_[m]>
konradybcio: *cough* audio *cough*
<phh>
and glodroid a13 did horrible things to be able to build on a13
<phh>
(so much horrible that it doesn't actually build for me)
<phh>
and yeah i'm definitely sad there is no turn-key solution to boot android on a proper linux mainline
<bryanodonoghue>
aka_[m] is the wcnss pinctrl different ? that really didn't jump out @ me
<abhinav__>
lumag bamse can you pls explain to me how we handle edp/dp phy differences in phy-qcom-qmp-combo.c ... I think the final conclusion was to use phy->mode for this?
<lumag>
abhinav__, Yes. DP driver detects eDP vs DP and then calls phy_set_mode_ext
<lumag>
Combo supports only DP, but phy-qcom-edp.c has been extended to handle both cases in a sensible way
<lumag>
Which means without having different compat strings for eDP and DP cases
<calebccff>
aka_[m]: phh: no, I don't and probably never will work on AOSPM again, it was fun (and I got paid...) but chasing upstream AOSP and knowing you'll never get your patches upstreamed is kinda exhausting... It would be really great if someone revived it.
<abhinav__>
lumag got it, I was again worried about #define DP_PHY_VCO_DIV 0x0074
<abhinav__>
since DP vs eDP PHY has a diffferent offset for this
<abhinav__>
but since this is in phy-qcom-edp.c
<abhinav__>
it should be okay
<lumag>
phy-qcom-qmp-combo is only for usb-and-DP. We have phy-qcom-qmo-usbc for usb-or-DP and phy-qcom-edp for pure eDP/DP .
svarbanov_ has joined #linux-msm
<abhinav__>
ack
minecrell3 has joined #linux-msm
danylo0 has joined #linux-msm
telent7 has joined #linux-msm
xtex_ has joined #linux-msm
gpiccoli_ has joined #linux-msm
gpiccoli has quit [Read error: Connection reset by peer]
svarbanov has quit [Read error: Connection reset by peer]
danylo has quit [Write error: connection closed]
telent has quit [Remote host closed the connection]
<aka_[m]>
I guess Bryan fails to see my msgs on irc side
minecrell8 has joined #linux-msm
minecrell8 has quit []
minecrell4 has joined #linux-msm
asriel has quit [Remote host closed the connection]
krzk_ has joined #linux-msm
krzk has quit [Read error: Connection reset by peer]
asriel has joined #linux-msm
krzk_ has quit [charon.oftc.net helix.oftc.net]
minecrell has quit [charon.oftc.net helix.oftc.net]
MollySophia[m] has quit [charon.oftc.net helix.oftc.net]
luka177[m] has quit [charon.oftc.net helix.oftc.net]
Mis012[m] has quit [charon.oftc.net helix.oftc.net]
MollySophia[m] has joined #linux-msm
minecrell has joined #linux-msm
Mis012[m] has joined #linux-msm
krzk_ has joined #linux-msm
luka177[m] has joined #linux-msm
minecrell4 has quit []
minecrell4 has joined #linux-msm
Mis012[m] has quit [Ping timeout: 481 seconds]
minecrell is now known as Guest530
minecrell4 is now known as minecrell
Guest530 has quit [Ping timeout: 481 seconds]
Mis012[m] has joined #linux-msm
<Marijn[m]>
calebccff: yeah it would be really fun to revive all the mainline "trees" for a bunch of phones, now that their kernels are somewhat usable and stable :)
<Marijn[m]>
I keep getting comments on old and terrible C++ code of mine that is in dire need to be Rustified
<Marijn[m]>
Not to forget the eternal "who has a working gralloc" quest
<lumag>
Marijn[m], wasn't it solved by gralloc.gbm? Oh wait, there is also minigbm...
<Marijn[m]>
How many forks does it have nowadays?
<phh>
calebccff: when you're speaking of upstream patches your speaking linux or aosp?
<Marijn[m]>
Must be AOSP, Linux is miles easier
<phh>
yeah that's my guess as well
<Marijn[m]>
Contributing to AOSP requires you to build from the master branch and fix a whole lot of cross-repository build issues - and implement testing - yourself
<Marijn[m]>
I've tried for trivial NDK header fixed - and abandoned it
<phh>
lol, that's the easy part xD
<Marijn[m]>
Not for the patient, though
<Marijn[m]>
s/Not/Only/
<phh>
the hard part is finding someone at google that cares enough to look at your patch, and answer every nitpick they could have
<phh>
I had a glimmer of hope when they paid linaro(?) to do "yukawa" tree which is an amlogic running on mainline, but well they stopped pretty soon
<Marijn[m]>
Fortunately I found someone for the few things that I wanted to make work
<Marijn[m]>
But it surely feels backwards if a hobbyist contributor starts writing HALs for generic mainline kernel interfaces, which should in theory just become part of AOSP for the greater good (which takes control fully away from said hobbyist contributor)
<lumag>
heh. We ported AOSP to PPC back in 201x. And then dropped because we could not convince Google that it was a sensible target.
<lumag>
And then I wonder who remembers Rowboat, another project that was basically destroyed by the lack of HWC.
pespin has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
<bamse>
abhinav__: how can the register offset differ between edp and dp, it's the same ip-block
<bamse>
abhinav__: i can understand if it differs between different targets...
<abhinav__>
bamse I was referring to edp/dp combo phy Vs usb/dp combo phy
<bamse>
abhinav__: ahh, yeah those are different ip-blocks, so there's only some resemblance
<bamse>
abhinav__: i did consider trying to reuse the dp-side of the combo driver when i wrote phy-qcom-edp.c, but the fact that everything was just slightly off made me back away from that idea
<abhinav__>
bamse glad you did that way :) otherwise the offset issue across chipsets issue would have been even bigger
<lumag>
bamse, I think we should extract common code like pipe & DP clocks.
<bamse>
lumag: to gain maximum entanglement?
<lumag>
To drop those repeating patterns of switch(rate) {case 1600; case 5400; case 8100; } (I don't remember the fourth one).
<bamse>
lumag: i'm not sure the added complexity is worth the deduplication...but i haven't looked at it in quite some time