[DNM] [experimental-tmp] Add LG Nexus 5X support #220
Conversation
| @@ -40,6 +40,9 @@ static void mdp_cmd_signal_refresh(void) | |||
|
|
|||
| static void mdp_cmd_refresh_start(struct fbcon_config *fb) | |||
| { | |||
| #if ENABLE_AUTOREFRESH | |||
There was a problem hiding this comment.
The reason hw autorefresh wasn't used is because it didn't work on some platforms (i.e. on 8974) so it was decided to use a more "reliable" (even if ugly) solution. See #137 that adds this thread as well as a manual autorefresh kick via fastboot.
There was a problem hiding this comment.
I want to avoid making such changes unconditionally. lk2nd is meant to boot a variety of different boot images (downstream, mainline, lk2nd itself, other operating systems) and enabling autorefresh may break booting them (downstream would be the most likely candidate for that).
However, we could potentially enable autorefresh immediately before booting a Linux that needs this. It could be either detected using a special parameter on the kernel command line (e.g. lk2nd.display-autorefresh). Or we could introduce special magic: If /chosen/simple-framebuffer exists then enable autorefresh.
There was a problem hiding this comment.
Thanks for the feedback!
I want to avoid making such changes unconditionally. lk2nd is meant to boot a variety of different boot images (downstream, mainline, lk2nd itself, other operating systems) and enabling autorefresh may break booting them (downstream would be the most likely candidate for that).
Ah, I understand, makes sense :-) Downstream probably wouldn't like that.
However, we could potentially enable autorefresh immediately before booting a Linux that needs this. It could be either detected using a special parameter on the kernel command line (e.g.
lk2nd.display-autorefresh). Or we could introduce special magic: If/chosen/simple-framebufferexists then enable autorefresh.
To me the second option seems better, in that case adding framebuffer on such devices upstream would be the same as normally.
There was a problem hiding this comment.
But /chosen/simple-framebuffer would require mainline accepting this, but kernel command line can be used on vanilla mainline (unmodified kernel sources in case mainline does not want to accept /chosen/simple-framebuffer.
There was a problem hiding this comment.
FWIW I was looking at provisioning the full framebuffer data from the lk2nd, which could include enabling autorefresh as one of the steps. https://github.com/msm8916-mainline/lk2nd/blob/rebase/fb/lk2nd/display/simplefb.c
Interestingly upstream allows extending the simplefb bindings just for the bootloader data so theoretically we could even have custom lk2nd,simple-framebuffer compatible that would allow lk2nd,auto-refresh; property in mainline
There was a problem hiding this comment.
Interesting, that would be then good try to send a patch :). I suppose we'd have to add our lk2nd and it's property into allOf: section in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/simple-framebuffer.yaml, right?
BTW what from that file states simplefb bindings can be extended for bootloader data? That example with pipeline for allwinner and amlogic?
There was a problem hiding this comment.
Indeed, specifically the last part of the long description says firmware may need extra data.
However I think we shouldn't hurry extending it in case lk2nd can handle quirks internally, maybe it's nicer to have the required flags in lk2nd's own dts.
|
|
||
| / { | ||
| model = "LG Nexus 5X"; | ||
| qcom,msm-id = <251 0>, <252 0>; |
There was a problem hiding this comment.
| qcom,msm-id = <251 0>, <252 0>; | |
| qcom,msm-id = <QCOM_ID_MSM8992 0>; |
Let's use the qcom,ids.h like all other files around, I also doubt there is a phone with APQ8092 :)
There was a problem hiding this comment.
True :-) Sorry, I should've checked other examples before adding that, will fix it once I get home
Add support for LG Nexus 5X. Also enable autorefresh so that the framebuffer works on linux.
I would greatly appriciate any feedback regarding the framebuffer enabler, the way this is done here feels really hacky.