ChanServ changed the topic of #linux-msm to:
hexdump01 has joined #linux-msm
hexdump0815 has quit [Ping timeout: 480 seconds]
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
pevik has joined #linux-msm
jhovold has joined #linux-msm
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
pespin has joined #linux-msm
<thara> lumag_ yes, you are right, theoretically you can have opp tables defined in DT for just one cluster. But have you come across anything like that ?Typically all clusters will want to scale ddr and l3 to get the performance boost.
<Mis012[m]> ok, so the mystery of why the clock are not showing as enabled is solved, turns out they only get enabled when I'm actually trying to read/write stuff over i2c :)
<Mis012[m]> *clocks
Daanct12 has quit [Quit: Quit]
Daanct12 has joined #linux-msm
<aka_[m]> <Mis012[m]> "if they don't fix the hw for the..." <- 662 if you mean new fxtec
<Mis012[m]> right
Daanct12 has quit [Quit: Quit]
Souradeep has joined #linux-msm
<lumag_> thara: I was hacking the cpufreq driver. So, yes, this is an imaginary situation
<lumag_> thara: btw, there is a bunch of cpufreq fixes from me on the mailing list. Could you please take a look?
pevik has quit [Ping timeout: 480 seconds]
<thara> lumag_: sure.. would you mind forwarding them to thara.gopinath@gmail.com
<lumag_> Will forward them later
<aka_[m]> Im editing commit msgs in Nano should there be empty line after commit body?
<aka_[m]> i understand it has to be commit tittle->empty line->commit body
jhovold has quit [Ping timeout: 480 seconds]
<aka_[m]> after running git format-patch it seems it just discarded empty lines anyway.....
<minecrell> aka_[m]: um, you mean empty line after the Sob?
<aka_[m]> yea
<aka_[m]> well
<aka_[m]> partially
<aka_[m]> can we post img here?
<minecrell> sure
<aka_[m]> when i change commit msg via cli it opens nano and leave me with prompt to enter commit msg.
<aka_[m]> My question was should i put empty space after body of commit. or delete it
<minecrell> it doesn't matter
<minecrell> the sob is missing though
<aka_[m]> turned out even if i leave no empty line or even two lines format patch cuts them
<aka_[m]> i know i used -s on generating
<aka_[m]> so it added it
<minecrell> right, git already strips the empty lines
<aka_[m]> yea
<aka_[m]> now if i have acked-by should i put it under sob?
<minecrell> There seem to be differing opinions there, some people add it after the sob, some people before the sob
<aka_[m]> So its not critical thats fine by me.
<aka_[m]> WIll they be added when i send-email?
<aka_[m]> also i wonder how it came my old patch had MIME and other additional lines under Subject but now after regenerating they are gone?
<minecrell> yes, git send-email generates all the magic email stuff
<aka_[m]> also i seen some conflicting info on resends.
<aka_[m]> Some ppl told me to just generate patches with -v and send them same way like before but in other places i see some infos about setting in-reply-to
<aka_[m]> and sending v2 under previous cover letter
<aka_[m]> im a little bit to dumb to figure out and messing once more and feeling like laughing stock triggers my anxiety disorders and wants me to quit and run away :(
<aka_[m]> However, for a multi-patch series, it is generally best to avoid using In-Reply-To: to link to older versions of the series.
<aka_[m]> so i assume i should not do anything other than just sending it like last time with -v2
<minecrell> if someone replied with a review comment, make sure to cc them now
<aka_[m]> Well Krzysztof replied and he is maintainer so he will be CC anyway
<minecrell> ah alright then :)
<aka_[m]> will it hurt if i have one patch with different capitalization on SoC name?
<aka_[m]> in one patch its msm8976 and other have MSM8976
<minecrell> aka_[m]: oh yeah such minor stuff is very critical
<aka_[m]> u joking or not because i really have hard times understanding <_<
<Mis012[m]> well, if the maintainer cares enough, they might change it themselves since it's simpler than telling you to do it, which would only make sense if there is some established standard that you would therefore be more likely to remember
<Mis012[m]> and if there happens to be an established standard, you should see that from past commits, and then you can just use whatever capitalization everyone uses unless you actually really want to find out whether anyone cares :P
<Mis012[m]> minecrell: is there some less hacky provision in qcom clock helper stuff for "don't even bother with this clock, just assume that it magically works" that would be equivalent to replacing the SCC PLL with a fixed clock?
<minecrell> you could create a fixed clock there I guess?
<Mis012[m]> but it's not a fixed clock :P
<Mis012[m]> it's just acting up
<Mis012[m]> something like `.flags = CLK_SUS`
<minecrell> um
<minecrell> make a fixed clock with a comment?
<Mis012[m]> ideally I would be able to figure out wtf is going on with it and use it properly :/
<Mis012[m]> I'm also not even 100% sure that the parent is the PLL, since it seems that none of the values 0 through 7 make the clocks below not work...
<Mis012[m]> so I can't rule out that the value there isn't being respected either
<Mis012[m]> yeah... GROUND for example sounds like it really shouldn't "just work"
<Mis012[m]> and if the QDSPSS PLL is on... that's really not great, wasting power for no reason
pespin has quit [Remote host closed the connection]
<Mis012[m]> does ↑ need new branch ops?
<Mis012[m]> also, the actual clock that I care about is i2c/spi, where the CLK_DIV is in a separate register and acts on both i2c and spi clocks
<Mis012[m]> not sure if that's a problem
<krzk> aka_[m]: your v2 was good, about the order - most of the opinions (although not all) are that it goes chronologically, so author's SoB, then any tags received in chronological order (so my Ack) and finally there will be committer SoB (the ones which commits to the repo).
<krzk> aka_[m]: thanks for changes
<aka_[m]> krzk: Thanks for comments and sorry for messing first time.
<krzk> no problem :)
* Mis012[m] had a sliver of hope that someone responded to his cries for help :P
<Mis012[m]> with a message appearing shortly after his
<aka_[m]> Mis012: you are to advanced for that, or too proprietary
<Mis012[m]> >too advanced for help
<Mis012[m]> sounds like stackoverflow :P
<Mis012[m]> "hi electronics stackexchange, any idea why my PLL doesn't want to lock?"
<Mis012[m]> "do you have a circuit diagram?"
<Mis012[m]> "if I had it, I would know better than to share it here..."
<minecrell> krzk: You could argue the patch was signed-off (again) by the author after you gave your ack :)
<Mis012[m]> minecrell: really should just put in another SoB :P
<Mis012[m]> #compromisesWhichBothSidesCanAgreeAreWorseThanEitherOption
<krzk> minecrell: Mis012[m]: yeah, following that logic there would be initial and final SoB of author. :) Some folks indeed like author's SoB at the end, but it's wrong... the SoB is proof of origin, so first you write a patch and you sign it.
<krzk> minecrell: you don't write a patch, send for review and then sign. It's always - first goes code (-> add SoB), then you get review (-> add tag) etc.
<krzk> Even if this is a v2 with already accumulated tags...
<krzk> what is more, I refuse to review a patch which is not signed, so my tag has to be after author's SoB.
cxl000_ has joined #linux-msm
cxl000 has quit [Read error: Connection reset by peer]
cxl000_ has quit [Read error: Connection reset by peer]
cxl000 has joined #linux-msm