07:34 <tomeu> mmind00, beeble: I was using bootm

07:35 <tomeu> just saw a message from ezequiel mentioning that he uses booti, and with that it's starting to boot

07:35 <tomeu> so thanks!

07:43 <mmind00> tomeu: great to hear that

07:51 <tomeu> mmind00: now that I have your attention, what's the best to upstream this? the DTs I'm using are from downstream linux-4.4 and rkboot, without any significant changes so far

07:52 <tomeu> the nanop[ic] *4 boards all share a common base DT

07:53 <mmind00> tomeu: are they actually different?

07:54 <tomeu> mmind00: the nanopc-T4 I have doesn't have any changes other than the name board, but the others do have changes

07:54 <mmind00> tomeu: i.e. the base-dtsi approach is somewhat common, see vamrs,ficus + rock960

07:55 <mmind00> tomeu: but it's interesting to find out beforehand if that are all real products ... like we don't add all CrOS board revisions, but only those that actually shipped

07:56 <tomeu> I think they are, let me check

07:58 <tomeu> mmind00: they look like real products one could get their hands on :) https://www.friendlyarm.com/index.php?search=rk3399&submit_search=&category_id=0&route=product%2Fsearch&sub_category=true&description=true

07:58 <tomeu> https://github.com/friendlyarm/kernel-rockchip/tree/4c0404dcf0baef405c3d3f4080ffd802fd48342e/arch/arm64/boot/dts/rockchip

07:59 <tomeu> not sure why downstream calls them rev00, rev01 and rev04 though

07:59 <tomeu> as they look more like variants than revisions

08:03 <mmind00> tomeu: yep, like 3 boards and at least the compatibles match the products

08:06 <mmind00> tomeu: so I guess for mainlining ... drop the vendor properties "mach", "rk_wlan" + bluetooth ... check for properties we have in rk3399.dtsi already (I noticed #sound-dai-cells) ... and ideally invert the delete-property things

08:07 <mmind00> tomeu: i.e. they define mmc-hs400-1_8v in the nanopi.dtsi only to delete it again in 2 boards, so that should simply only be defined in the one board using it

08:07 <tomeu> cool, sounds like a start

08:09 <mmind00> tomeu: other than that I guess it would be cool to also keep that separation ... with it being 3 boards ... don't forget to add entries to Documentation/devicetree/bindings/arm/rockchip.txt

08:10 <mmind00> tomeu: when inverting the mmc stuff, I think the "mmc-hs200-1_8v;" can also just stay, as it only declares a supported mode

08:11 <tomeu> ack

08:40 <somy> hi, any mpp "experts"? I'd like to know what need to be resetted between two decode "sessions" like a jump in a movie or a restart of the movie?

14:23 <tomeu> any ideas about this one?

14:23 <tomeu> [ 2.694961] dwc3 fe800000.dwc3: Failed to get clk 'ref': -2

14:23 <tomeu> [ 2.695736] dwc3 fe800000.dwc3: failed to initialize core

14:30 <Esmil> tomeu: when i looked at it, i concluded that the "failed to get clk 'ref'" is because the dwc3 core uses clk_bulk_get to request some of the same clocks as the rockchip wrapper already takes care of

14:30 <Esmil> ..so harmless from a functional standpoint

14:31 <Esmil> ..and the 'failed to initialize core' is usually just -EPROBE so it will try again later

14:31 <tomeu> yep, just read it :

14:31 <tomeu> * Clocks are optional, but new DT platforms should support all

14:31 <tomeu> * clocks as required by the DT-binding.

14:31 <tomeu> still have fe800000.dwc3 in /sys/kernel/debug/devices_deferred though

14:32 <tomeu> so something else is going on

14:32 <Esmil> Yeah, sometimes it fails to initialize the phy, and then you don't have usb3

14:33 <Esmil> ..but that happens maybe 1/10 boots for me

14:34 <Esmil> (for me this is the same on both 4.19 and 4.20)

14:44 <tomeu> ok, have switched to see why cdn_dp fails to probe

14:44 <tomeu> the probe is deferred because extcon_get_edev_by_phandle returned EPROBE_DEFER

14:45 <tomeu> but I know that the extcon specified in the DT has probed successfully

14:45 <tomeu> so not sure what could be going on

16:45 <mmind00> tomeu: the whole typec + dp stuff only really works on CrOS devices right now

16:47 <mmind00> tomeu: architectural difference: all non-cros devices use a fusb302 connected to one of the i2c hosts, which in turn should use the kernels typec framework to negotiate modes like gadget / dp

16:47 <mmind00> tomeu: on cros devices the ec hides all of that and simply emits an extcon with the negotiated states

16:48 <mmind00> tomeu: in the vendor kernel they hacked that extcon into the fusb302 driver

16:50 <mmind00> tomeu: everything should be converted to use the type-c framework of the kernel, but while I talked to Guenter Roeck about converting cros-ed-extcon + pd to somehow integrate into the typec framework ... this is probably quite a while away

16:50 <mmind00> tomeu: thanks to a patch from eballetbo we at least default now host-only usb3 on non-cros devices

16:53 <mmind00> tomeu: just checked the nanopi4 dtsi ... and as expected ... the fusb302 cannot provide that extcon, simply because that is a vendor-specific hack