On 12/4/2018 9:17 AM, Marc Gonzalez wrote:
I booted a downstream kernel with UFS debug enabled (log provided below)
The one difference that jumps out at me is:
DOWNSTREAM
[ 10.902119] ufshcd-qcom 1da4000.ufshc: ufshcd_init_clocks: clk: core_clk_unipro, rate: 150000000
[ 10.902161] ufshcd-qcom 1da4000.ufshc: ufshcd_init_clocks: clk: core_clk_ice, rate: 300000000
[ 10.902198] ufshcd-qcom 1da4000.ufshc: ufshcd_init_clocks: clk: ref_clk, rate: 1000
UPSTREAM
[ 2.072820] ufshcd-qcom 1da4000.ufshc: ufshcd_init_clocks: clk: core_clk_unipro, rate: 0
[ 2.080304] ufshcd-qcom 1da4000.ufshc: ufshcd_init_clocks: clk: core_clk_ice, rate: 0
[ 2.088547] ufshcd-qcom 1da4000.ufshc: ufshcd_init_clocks: clk: ref_clk, rate: 0
Jeffrey, I will check the regulators per your suggestion.
I'm all ears if you have suggestions for the clocks as well.
Hmm, this is interesting.
I know you mentioned before that the clock rates were 0. Even with the
downstream kernel, I've seen clock rates be zero (for other usecases).
Since we have a delta between downstream and upstream, that seems
significant.
When I've seen a clock keep its rate 0 like this, its been because of a
bad parent. You can check this in upstream via debugfs -
<debugfs>/clk/clk_summary
In downstream, I recall having to go into the individual clock sub
directory, and reading the parent file.
However, maybe a simple solution. Do you have
https://patchwork.codeaurora.org/patch/657871/ ?
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
