narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 250 seconds]
gis has quit [Ping timeout: 248 seconds]
gis has joined #linux-amlogic
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 240 seconds]
Daanct12 has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
naoki has joined #linux-amlogic
Daanct12 has quit [Ping timeout: 268 seconds]
Daanct12 has joined #linux-amlogic
jacobk has joined #linux-amlogic
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_1 has joined #linux-amlogic
jacobk has quit [Ping timeout: 240 seconds]
<narmstrong> lvrp16: afaik there’s no refresh rate limit only timings and bandwidth limit
leohoo_sdu[m] has joined #linux-amlogic
ldevulder has joined #linux-amlogic
<phh> recent amlogic vendor kernel has 1080p120 mode (on g12a i think)
JerryXiao has quit [Quit: Bye]
JerryXiao has joined #linux-amlogic
Daaanct12 has joined #linux-amlogic
Daaanct12 has quit [Client Quit]
Daanct12 has quit [Ping timeout: 240 seconds]
Terry137322934 has quit [Quit: Bye Bye]
Terry137322934 has joined #linux-amlogic
gabes has quit [Quit: The Lounge - https://thelounge.chat]
gabes has joined #linux-amlogic
<narmstrong> minute: ok I managed to get a clean DSI probe patch, here is a ugly patchset based on the new DSI support https://github.com/superna9999/linux/tree/amlogic/v6.4/upstream/dsi-ccf-vim3
<narmstrong> beware the branch will be force pushed
camus has quit [Ping timeout: 240 seconds]
camus has joined #linux-amlogic
JohnnyonFlame has quit [Ping timeout: 246 seconds]
naoki has quit [Quit: naoki]
camus has quit [Quit: camus]
buzzmarshall has joined #linux-amlogic
camus has joined #linux-amlogic
f_ has joined #linux-amlogic
gis has quit [Ping timeout: 240 seconds]
<f_> Hey all.
<f_> Does anyone know how Amlogic's acs.bin works? (by which I mean, which values am I supposed to change if I was a board manufacturer)
jacobk has joined #linux-amlogic
psydroid has joined #linux-amlogic
JohnnyonFlame has joined #linux-amlogic
gis has joined #linux-amlogic
<narmstrong> f_: there's a table in the vendor u-boot that generates the binary
<f_> Yes.
<f_> But, what if I'm a board manufacturer. Which values inside that table would I need to change specifically?
<f_> I know that is a stupid question :P
<narmstrong> no idea
<narmstrong> there's some comments, but it's not very explicit
<f_> I agree.
<f_> Do you have a p201 with you?
<f_> If so, then can you tell me which RAM chips it uses?
<f_> I'll try to lookup RAM timing data about those, and try to understand the mess they've done.
<f_> Also...."timming"
<f_> narmstrong: Oh wait..do you have schematics for that reference board?
<narmstrong> Hmm maybe
<f_> Hmm....do we have the right to redistribute those or not?
<f_> (I hope we do)
<minute> narmstrong: thanks a lot, trying to figure out what i have to apply
<minute> narmstrong: basically the 2x "fixup!" and the "fix unbind"?
<narmstrong> Hmm I don’t know what version you have but I think you should rebase on the whole stuff because I changed the way the clocking is done
<minute> mhm mhm
<f_> narmstrong: Actually. I don't really care if the schematics are for P201 or P200. As long as we have U-Boot/ACS sources for those it's ok!
psydroid has quit [Excess Flood]
<minute> narmstrong: is dsi_tx_port (port 2) no longer necessary on vpu?
<minute> ah nevermind, found it
<f_> narmstrong: Ah. Nevermind.
<f_> The ODROID C2 schematics seem to be publicly available.
<f_> Ah nevermind :/ nothing about what RAM chips it uses
<narmstrong> Not sure there’s any dram info on the ref designs schematics
<narmstrong> You could use the jedec timings, it should work on any chip
<f_> The jedec timings?
<minute> ok, sn65dsi86 still probe pending. going to verify panel probing
<f_> So those are supposed to work?..
<narmstrong> Ddr chips are supposed to work on timings specified by the jedec specifications
<narmstrong> minute: hmm
<minute> i do have /sys/bus/platform/devices/panel and brightnessctl recognizes the backlight
<minute> will stuff some printks in sn65dsi86
<minute> and:
<minute> [ 14.305621] platform ffd07000.mipi-dsi: deferred probe pending
<minute> [ 14.305623] auxiliary ti_sn65dsi86.bridge.0: deferred probe pending
<minute> narmstrong: it is the same/similar problem as before, ti_sn65dsi86 defers because of_find_mipi_dsi_host_by_node() always fails
<narmstrong> minute: yes I’m afraid it’s not solved :-/
<narmstrong> The problem is the components stuff which makes everything bad
<narmstrong> on the meson dw mipi dsi driver, moving all the code from bind to probe, but keeping the component_add/del and empty bind function would probably work
<minute> narmstrong: ah, will try
Danct12 has quit [Quit: How would you be so reckless with someone's heart!?]
<minute> narmstrong: component_add at the end of probe i presume?
<narmstrong> minute: yep otherwise it won’t bind the master driver
<minute> ok
<narmstrong> minute: you can drop the unbind op but keep the bind op but empty
<minute> ok
Danct12 has joined #linux-amlogic
<minute> interesting, this now oopses in of_find_mipi_dsi_host_by_node+0x54/0xa4
<minute> (null pointer dereference)
leohoo_sdu[m] has quit [K-Lined]
<f_> I have no idea how or why, but ...
<f_> The WeTek Hub and NanoPi K2 ACS work..
<f_> Work, as in, linux boots.
<f_> Hmm
<f_> The P201 ACS doesn't work however.
<f_> * This board have not been autorized or product keys are not valid. *
<f_> * Please contact with Hardkernel or your distributor *
<f_> Heh
<f_> Does HardKernel implement DRM now?
<f_> I was wondering why the timings seemed different from the ones in my eMMC dump
<minute> narmstrong: ah, i think the bridge probes now
<narmstrong> f_: yes do not use the odroid c2 fip, they added a check for their HW
<narmstrong> minute: Nice!
<f_> narmstrong: Heh. That was for testing purposes. I wasn't actually going to use it.
<f_> But this looks like BL2..
jacobk has quit [Ping timeout: 240 seconds]
<f_> Pretty funny though.
<minute> narmstrong: the display pipeline is not starting though... some puzzle piece is missing
<minute> narmstrong: so no /dev/dri/card* is created for the display/vpu (only for gpu)
<narmstrong> minute: hmm it would mean the bridge isn’t properly detected, is there an error printed somehow ?
<minute> narmstrong: no, strangely no output from vpu this time except[ 3.869938] meson-drm ff900000.vpu: Queued 1 outputs on vpu
<narmstrong> Hmm this should be 2, are you sure you kept the component_add ?
<narmstrong> Or you disabled HDMI ?
<minute> narmstrong: disabled hdmi yep
<minute> narmstrong: meson_encoder_dsi_init() is not called now
<minute> narmstrong: ah i'm silly
<minute> narmstrong: i did a return before component_add, so it's not reached
<narmstrong> Ok this explains everything, if you get a -22 probe error on the drm driver, you could you try to add « if (!mipi_dsi->dsi_device) return -EPROBE_DEFER; » in the dsi bind function so it defers until the dsi bridge has attached to the dsi host
<minute> yeah, i get an oops again now
<minute> in (of_find_mipi_dsi_host_by_node+0x54/0xa4)
<narmstrong> Weird, can you share the call stack ?
<minute> sure
<minute> narmstrong: it's possible that your DEFER suggestion could fix it
<minute> narmstrong: i think it is because of the removed unbind
<minute> narmstrong: IIRC the oops happens if mipi_dsi->dmd is dangling
<narmstrong> minute: you should not remove dmd in unbind anymore so the dsi host remains
<minute> narmstrong: i don't, i commented out unbind as you suggested
<narmstrong> Wait, perhaps the component unbind frees all the devm allocated stuff
<minute> narmstrong: yes
<minute> narmstrong: or i think a DEFER does
<minute> but not sure... in any case when i was debugging in the last days, the problem was that you can't keep the host around during a DEFER because something gets deallocated but still referenced
<narmstrong> Yep I confirm it does in component_unbind :-/
<minute> but i didn't have enough experience to fix this
jacobk has joined #linux-amlogic
<minute> narmstrong: is there a workaround?
<narmstrong> Yeah stop using components… I maybe have an idea
<minute> haha ok!
<narmstrong> Ok so can you add the meson mipi dsi compatible in this list https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/meson/meson_drv.c#L450
<minute> wow ok :D
<narmstrong> And in the meson mipi dsi remove all the component stuff
<narmstrong> Since you already moved the code to probe
<minute> ok
<minute> i'm just removing the calls to component_add and component_del in meson_dw_mipi_dsi, yes?
<narmstrong> Yes
<minute> woah
<minute> stuff is happening
<narmstrong> I Hope good stuff
<minute> backlight turned on and i can control the brightness
<minute> and i do have a new card entry in /dev/dri
<minute> but i did not connect the mipi cable ^^ fixing
<narmstrong> Oh yeah it would help !
<minute> ok, now i just need to get the clock right so that sn65dsi86 can extract it's refclk
<minute> the drivers are doing the correct things now i think
<minute> narmstrong: are there any limitations on the mipi clock? (i.e. the one that is 960mhz in your example)
<minute> ideally i would need 972
<narmstrong> minute: 972mhz as dsi bitclk ? Hmm let me check on the datasheet
<narmstrong> The gp0 range may need to be extended
<narmstrong> How many dsi lanes do you use ?
<minute> narmstrong: 4
<minute> narmstrong: 972 as the ddr rate, so 486 actually
<minute> these could also work: 768, 832, 921.6, 936
<narmstrong> Yeah so the assigned clk is only needed for the controller init because it needs a clock at probe
<minute> those are the clocks that the sn65dsi86 can work with
<narmstrong> Normally the bit clock is derived from the mode clock the dsi driver receives
<minute> ah, automatically?
<narmstrong> Yep
<minute> so if i adjust my panel modeline, it should also adjust
<narmstrong> Can you check which rate is set in /sys/kernel/debug/clk/clk_summary
<narmstrong> It should be gp0_pll for the bit clk and cts_encl for the pixel clock
<minute> > gp0_pll_dco 1 1 1 3840000000
<minute> > cts_encl 1 1 0 160000000
<minute> so it adjusts the pixel clock from 162 to 160
<narmstrong> What is the value of gp0_pll (not dco)
<minute> ah sorry
<minute> > gp0_pll 2 2 1 960000000
<minute> so it's the one set in the dts
<narmstrong> Hmm it should change on a mode set
<narmstrong> This explains the 160 vs 162 if it’s unable to set the new rate
<narmstrong> Oh I know why
<narmstrong> Damn
<minute> i will try with 156mhz and 936mhz
<narmstrong> In the meson dsi driver, in dw_mipi_dsi_get_lane_mbps
<narmstrong> Remove the line « mipi_dsi->phy_opts.mipi_dphy.hs_clk_rate = clk_get_rate(mipi_dsi->bit_clk); »
<minute> ok
<minute> the clocks are correct now, still some trouble with sn65dsi86 but need to hack around a bit more
<narmstrong> Ok I’ll fix the probe and the clk setup on Monday…
<narmstrong> Thx for trying :-) now I have a clearer picture ^^
<minute> narmstrong: awesome, thanks for your help!
<minute> oh wow, i had sn65dsi86 on the wrong i2c bus in dts... but the driver happily probed it anyway
<narmstrong> It’s weird ^^
<minute> ok the i2c port/device numbering is weird
<minute> i2c1 in dtb appears to be bus 0, i2c0 is bus 3...
<minute> ohh, i have a flicker on the display
<minute> (wrong clock i guess)
<minute> or other dsi features
<minute> but low speed comms with the display works now it appears
<f_> TF-A experiments: ASSERT: drivers/io/io_storage.c:174
<f_> Starts well! :S
f_ has quit [Quit: disconnecting...]
<minute> narmstrong: do you think it would be possible to extend gp0 to 972mhz?
ldevulder has quit [Ping timeout: 264 seconds]
JohnnyonFlame has quit [Ping timeout: 256 seconds]
vagrantc has joined #linux-amlogic
<narmstrong> minute: the gp0 mult ranges are here https://elixir.bootlin.com/linux/latest/source/drivers/clk/meson/g12a.c#L1605 you can try to put a lower min mult
<narmstrong> Perhaps 120, no idea if it will lock
<narmstrong> minute: if screen flicked it means something is on the dsi lanes, which is a good news
<minute> narmstrong: thanks!
<narmstrong> I’m not sure at all about the mode timings settings, I have only 2 screens to test and I never managed to get them working with the timings used for rockchip :-/
<minute> oh ok
<minute> narmstrong: btw my version says max 250 instead of 255 like in the file you linked... this was updated later?
<narmstrong> Probably, updating the max won’t help achieving 972 anyway
<minute> oh, color bars test works (generated by sn65dsi86)
<minute> narmstrong: ok
<minute> ah, with 120 min and setting 972mhz in dts, i get > gp0_pll 2 2 1 972000000
<minute> but if i disable test pattern in sn65dsi86, still flicker on the display. so maybe something with the actual mipi frames
<narmstrong> Ok so the dsi bit clock is right so it can generate the right dp link, so yeah the pixel timings generation is completely off
<narmstrong> I think you can enable test color bars from the dw mipi dsi driver
<narmstrong> But I never understood how it worked…
<narmstrong> It’s vpg in debugfs
<minute> ah, pixel timing is unfinished?
<narmstrong> It is but based on the amlogic vendor code, but their base timings are completely different from other vendors
<minute> oh strange
<minute> hmm there's a lot of "TODO dw drv improvements" in dw-mipi-dsi.c
<narmstrong> Yeah well you know they did a complete implementation of dsi for no reason, typical vendor code
<narmstrong> I think the dsi part is ok
<narmstrong> You could check if you have the correct frame rate with modetest -s -v
<narmstrong> Anyway, it’s already a good result! Good night !
<minute> thanks so far!! good night
<minute> (getting 70.04hz, i think that's about right)
vagrantc has quit [Quit: leaving]
jacobk has quit [Ping timeout: 240 seconds]
JohnnyonFlame has joined #linux-amlogic
jacobk has joined #linux-amlogic
vagrantc has joined #linux-amlogic