ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-msm
zstas_ has joined #linux-msm
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-msm
zstas has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: WeeChat 4.6.3]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-msm
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-msm
Caterpillar has quit [Read error: Connection reset by peer]
Caterpillar has joined #linux-msm
mripard_ has quit []
Daanct12 is now known as Danct12
zstas_ has quit [Ping timeout: 480 seconds]
zstas_ has joined #linux-msm
zstas_ has quit [Ping timeout: 480 seconds]
<CosmicPenguin>
I'm seeing a thing in the sm8250 camss where I can't get VFE to bump up to the next clock level. The clk_set_rate() works without error, but clk_get_rate() still returns the lower end value. Does that ring a bell with anybody?
<konradybcio>
CosmicPenguin: which clk exactly?
<CosmicPenguin>
vfe0
<konradybcio>
which 2 levels are we talking? CosmicPenguin
<CosmicPenguin>
konradybcio: default is 350Mhz, I was trying to jump up to 576Mhz
<konradybcio>
why on earth does the driver manually round_rate before set_Rate
khimaros has quit [Remote host closed the connection]
khimaros has joined #linux-msm
<konradybcio>
CosmicPenguin: i sent out a patch.. maybe the error in the freq table threw off the APIs, but it's really something that's easier to pr_err-bomb
<CosmicPenguin>
konradybcio: cool, let me check it out
khimaros has quit [Remote host closed the connection]
khimaros has joined #linux-msm
zstas_ has joined #linux-msm
<CosmicPenguin>
konradybcio: qcom-camss ac6a000.camss: Trying to round the clock rate to 68000000 | qcom-camss ac6a000.camss: Set VFE clock rate 680000000 | qcom-camss ac6a000.camss: Clock rate 68000000 does not match 350000097
<CosmicPenguin>
konradybcio: I wonder if this is a opp issue - 680000000 would be at turbo, 576000000 would be svs_l1
<konradybcio>
CosmicPenguin: can you also do the same for clk_rcg2_configure()?
<konradybcio>
you'll likely want some filtering in there or you'll spend most of your day waiting for uart to flush
<abhinav__>
when I expand the list, I also need to update the examples of all right
<konradybcio>
yes, otherwise you'll get a response from Rob's bot and an unamused human response from krzk
<abhinav__>
ok got it :) bindings check does not complain , so wanted to double check
<konradybcio>
you can test those with e.g. make dt_binding_check DT_SCHEMA_FILES="Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml"
<konradybcio>
(random yaml from my shell history)
<abhinav__>
Right, I did test it with make dt_binding_check DT_SCHEMA_FILES=display/msm
<abhinav__>
and it does not throw errors
<abhinav__>
even i dont update it
<abhinav__>
hence i wanted to check
<lumag>
abhinav__: most likely you made those clocks optional
<abhinav__>
lumag Yes they are optional as MST is not required by default
<konradybcio>
make them required in bindings and we'll make a big update of all dts to add them
<lumag>
+1
<lumag>
Make the clocks required for platforms which support MST
<lumag>
and update DTS
zstas_ has quit [Ping timeout: 480 seconds]
<abhinav__>
konradybcio lumag hmmm actually, clocks were already required, but I think its the minItems: 5 which is preventing the errors,
<abhinav__>
but we should keep minItems: 5 right
<lumag>
Add platform-specific clauses with correct minItems
pespin has quit [Remote host closed the connection]
<abhinav__>
Right, I was already doing that
<abhinav__>
the only change you are suggesting
<abhinav__>
is that, for platforms which support MST, I should update even minItems as 6?
<abhinav__>
rather than a 5
<abhinav__>
I was doing maxitems as 6 and minitems as 5
<abhinav__>
and kind of keeping MST as optional
<konradybcio>
yes min=max meaning we need all the clocks
<konradybcio>
there is no optionality, this hardware is set in stone
<lumag>
and for platforms with more than 2 MST streams we need more stream clocks.
<lumag>
So minItems = maxItems
<abhinav__>
ack, let me try that out
<CosmicPenguin>
konradybcio: oh, ffs, not only did I figured it out, but it also was something that burned me in the past. On sm8250 csid is inside vfe, so vfe comes up first, but csid still has vfe0 in its clock list, so vfe sets the clock and csid comes right around and whacks it
<CosmicPenguin>
konradybcio: I must not have sent that patch up when I was thinking about it the last time I raged with the camss but I sure will do it this time
<konradybcio>
bryanodonoghue: sounds like something we should take a look at..
Caterpillar has quit [Quit: Konversation terminated!]
Caterpillar has joined #linux-msm
jhovold has quit [Ping timeout: 480 seconds]
<konradybcio>
CosmicPenguin: if you dont't wanna burn your eyes, use lore.kernel.org :p
<abhinav__>
lumag I have one question, I tried to make min/max = 6 for qcom,x1e80100-mdss.yaml without updating the example but it still doesnt complain, clocks are required in the dp-controller.yaml but somehow is qcom,x1e80100-mdss.yaml excluded?
<lumag>
abhinav__: patch, please
<abhinav__>
lumag not much really
<abhinav__>
+ - if:
<abhinav__>
+ compatible:
<abhinav__>
+ properties:
<abhinav__>
+ contains:
<abhinav__>
+ - qcom,sc7280-dp
<abhinav__>
+ enum:
<abhinav__>
+ - qcom,sm8150-dp
<abhinav__>
+ - qcom,sc8180x-dp
<abhinav__>
+ - qcom,sc8280xp-dp
<abhinav__>
+ - qcom,sm8350-dp
<abhinav__>
+ - qcom,sm8450-dp
<abhinav__>
+ - qcom,sm8650-dp
<abhinav__>
+ - qcom,sa8775p-dp
<abhinav__>
+ - qcom,x1e80100-dp
<abhinav__>
+ then:
<abhinav__>
+ properties:
<abhinav__>
+ clocks:
<abhinav__>
+ minItems: 6
<abhinav__>
+ maxItems: 6
<abhinav__>
but no update to qcom,x1e80100-mdss.yaml
<abhinav__>
I expected this to throw an error
<abhinav__>
because there are only 5 entries in the example of qcom,x1e80100-mdss.yaml
<abhinav__>
for the dp-controller
<abhinav__>
but it compiles
<lumag>
abhinav__: dp-controller.yaml isn't enabled for x1e8
<lumag>
somebody forgot to add entries to the compatible: list
<konradybcio>
it should have complained harder then..
<lumag>
why? It's just skipped
<lumag>
obviously abelvesa forgot about it :-(
<konradybcio>
because there's a node in the dt that's effectively not being validated
<lumag>
but anyway, with this patch I got errors for sa8775p, sc7280 and sar2130p only.
<lumag>
It seems, we don't have examples for some of the platforms.
<abhinav__>
lumag right, we do not have examples for some of the platforms
<abhinav__>
ok, let me add it to the list
<abhinav__>
and see if it fails
<abhinav__>
it seems this effort has opened up quite a few errors
<abhinav__>
another one is that for sc7280, DISP_CC_MDSS_DP_PIXEL1_CLK/SRC is not even defined in qcom,dispcc-sc7280.h
<abhinav__>
let me fixup qcom,x1e80100-dp
<abhinav__>
and I have already fixed the ones it complained about
<abhinav__>
my main worry was why it was not complaining :)