00:18 <field^Mop> mmind00: woah! rk3188 radxa rock 4.18.7 seems to crash ext4 on sdcard. connected to usb: ssd, eth2usb and of course sdcard. cannot provide logs prior to crash yet. in process of restoring fs.

08:28 <s_frit> what would be the correct path to take to discuss and then submit a patch to mainline rk3399.dtsi (related to i2s pinctrl)?

08:29 <mmind00> s_frit: do the patch, write a nice commit message and submit it with "git send-email" (scripts/get_maintainer.pl for recipients)

08:32 <s_frit> mmind00: ok, so i shouldn't worry about whether i'm doing it the "best way" before submitting?

08:34 <mmind00> s_frit: discussions are generally done on the mailinglists ... so stuff can also be used as reference later on

08:35 <mmind00> s_frit: but if you have questions beforehand, you can also ask them here if needed

08:40 <s_frit> mmind00: well, perhaps this was resolved in the distant past, but right now, mainline is bundling the i2s_8ch_mclk pinctrl in with i2s0_2ch_bus and i2s0_8ch_bus (this is pin <4 0 ...>). however i2s_8ch_mclk is attached to a mux that allows it to receive the mclk for i2s0, i2s1 or i2s2, and some boards need the i2s1 clock (e.g. nanopc t4 with a codec attached to the 40-pin header, or

08:40 <s_frit> nanopi m4). so really there should be a separate i2s_8ch_mclk pinctrl. this is kind-of how it is done in the friendlyarm rk3399.dtsi for example

08:42 <s_frit> so my question is really around whether a decision was already made to not break out a separate i2s_8ch_mclk pinctrl

08:47 <mmind00> s_frit: sounds sensible to split that out ... and no I don't remember this coming up beforehand

08:48 <mmind00> s_frit: when splitting out the pinctrl, please make sure that all boards using the old ones, get the new pinctrl as well

08:49 <mmind00> s_frit: where is this "mux" sitting?

08:50 <s_frit> mmind00: ok. friendlyelec (or someone) split it out as a separate pin ctrl, but it's still inside the i2s0 subnode. i'm wondering, given that it can source fom i2s0, i2s1 or i2s2 whether i should create a new i2s012 (or just i2s) subnode to put it in, or something else?

08:53 <mmind00> s_frit: Sugar Zhang is a Rockchip employee :-) ... I guess just follow the example there and let it live in the i2s0 node ... or if you prefer create a new i2s group-node

08:56 <s_frit> mmind00: to be specific, the pinctrl data is <4 0 RK_FUNC_1 &pcfg_pull_none>, the pinctrl has sometimes been named i2s_8ch_mclk in rk3399.dtsi. The clock gate is SCLK_I2S_8CH_OUT (clk_i2sout) and the mux is SCLK_I2S_8CH (or clk_i2sout_src).

09:18 <mmind00> s_frit: I guess use your best judgement :-D ... renaming the clock-ids is a no-go, so I guess either re-use the name from the vendor kernel or name it i2s-mclk, or whatever ;-)

09:20 <s_frit> mmind00: yeah, i'm looking at the other rk*.dtsi files but there's very little consistency

09:29 <s_frit> does anyone here have audio working on the rk3399-firefly with mainline .dts? doesn't look quite right to me, but i don't have that board to try.

19:33 <ayaka> inode, it is hard to say, it depends on you are talking about android or linux

19:41 <inode> ayaka: thanks for the response, i was attempting to use rkdeveloptool from linux

19:45 <inode> i was able to query flash {id,info} and chip id but the request to read capability, rcb, seemed to cause the device to hang

19:46 <inode> in any case, i found that rkflashtool worked perfectly

19:48 <inode> i was able to enumerate the partition table via returned parameters and then dump the contents of each partition

19:48 <inode> and i was then able to write back to flash, so i'm happy

19:50 <ayaka> inode, always try the upgrade_tool from rk first

19:51 <inode> ok

19:52 <ayaka> in my memory, rk3368 is not designed for linux at all

19:52 <inode> how so?

19:55 <inode> at very worst, the usecase for the device in question could have an android kernel and a GNU userland if all else fails

19:57 <ayaka> so I am not sure whether there is a u-boot for it to support linux

20:00 <inode> ok, thanks for the heads up