Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various Updates #85

Open
wants to merge 15 commits into
base: cm-12.0
Choose a base branch
from
Open

Various Updates #85

wants to merge 15 commits into from

Conversation

sirmordred
Copy link
Contributor

ok ı have tested it all the patches for two days and its ready to go
BLN works like a charm :) but we need to disable enforced selinux or we have to put some selinux rules for BLN or it won't work

thanx

@Madridii
Copy link

Great work sirmordred, thank you so much

@sirmordred
Copy link
Contributor Author

Ok @arco i tested it and its good to go.. (Resetting branch is needed) This time i didnt use unnecessary brackets to not break anything also can you look into comments?

Thanx

@sirmordred
Copy link
Contributor Author

farewell gingerbread codes...
and more and more 3.4 style..
now its ready to go into 3.10

@arco
Copy link
Owner

arco commented Jun 4, 2015

I got compile errors with the first set of patches.

@sirmordred
Copy link
Contributor Author

yeah there was and ı had to clean these errors and ı resetted few times, now code is compilable(you can try it)

@doadin
Copy link
Contributor

doadin commented Jun 8, 2015

btw since you have mentioned 3.10 i have forked msm7x30/android_kernel_qcom_msm7x30 (kernel 3.10) and made this initial change to get work started to makeing the change doadin/android_kernel_qcom_msm7x30@c9ec755 . Baiscly just copied the same commit we used before the "Initial support for..." commits. So obviously there will be alot fo work needed but i think general msm7x30 support is well on the way with all the work they have done.

Sorry i know its a little off topic but just wanted to mention it...feel free to fork off mine and fix things up/add more if anyone wants. I didnt really do a whole lot just thought id do a little and maybe see if the ball starts rolling if not its probabbly more work than i wana put into it so oh well.

@doadin
Copy link
Contributor

doadin commented Jun 8, 2015

also more on topic imo we should revert sirmordred@cf55d42 as imo we should never remove any drivers because there maybe other forks out there that still use them or something and removing them completely just makes things difficult and its unnecessary the only thing removeing them does for us is make the kernel download a few kb smaller...no real point. We should just update what we use and if we ever have to change a like include file that affects other devices we should just make a copy of the new or old w.e. so support for both remains as best as possible.

@sirmordred
Copy link
Contributor Author

İm also working on 3.10
And there is no harm of removing those uncompiled code,driver because as i said they are not compiled so it doesnt affect to devices

@doadin
Copy link
Contributor

doadin commented Jun 8, 2015

I 100% know it doesnt affect us..thats what i said. Im just reffereing to the 153 forks of this kernel repo that other people use. I dont know about you but i havnt gone and check those 153 other repos to check if they are using a driver you are proposing to remove. Therefore i dont think it would be ok to remove them. I mean sure if some of those other 153 forks use one they can just commit it back in there fork but why make them have to do more work all so we can save 4kb? Like you said doesnt affect us so honestly i dont care and theres no point in even really discusing it. Just me 2 cents take it leave it. Ultimately its up to arco anyways its his repo.

And cool let me know how it turns out or if you want someone to help test or w.e.

@sirmordred
Copy link
Contributor Author

No compile error... no problem.. its ready to merge... ı have been using for five days

@sirmordred
Copy link
Contributor Author

And can we get also some cm12.1 love? :)

Repository owner locked and limited conversation to collaborators Jun 18, 2015
* lcd drivers can't control cpufreq directly
* modern lcd drivers dont use this way
* kernel cpufreq driver is controlling clocks while waking up from sleep itself
* For toggling ledflash from userspace
* node: /sys/class/camera/rear/rear_flash
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants