12:05 <Kwiboo> qschulz: mmind00: any suggestion on how to best handle soc specific hs200_txclk_tapnum etc in sdhci driver?, normally I would add it to of_match_table however the driver is used by other platforms and these are specific to rk so unsure if I should extend the driver data struct or assign values to rk35xx priv struct

12:06 <Kwiboo> please see https://github.com/Kwiboo/linux-rockchip/commit/62484a44567f472afe5c93504ab771379f04a4a1 where I assign the values in dwcmshc_rk35xx_init

12:07 <Kwiboo> or should I try to move it to dwcmshc_pltfm_data?

12:11 <mmind00> Kwiboo: having a huge (and getting huger) if (of_device_is_compatible... tree is probably a no-go and also scales really badly ... also the txclk_tapnum thing seems to be already in the platform-data struct?

12:12 <mmind00> so I'd assume moving the other values in there too, would make sense

12:12 <mmind00> Kwiboo: ah no ... that txclk_tapnum is coming from the devicetree

12:14 <mmind00> which also makes sense I guess

12:14 <Kwiboo> mmind00: agree the big if of_device_is_compatible does not look right and should be reworked, and yes txclk_tapnum was in priv data and not driver data

12:15 <mmind00> so if txclk_tapnum is already in the dt, I guess there was already argument for putting it there ... so it'll be the same for the other "tapnum"s

12:15 <mmind00> are these values attached to the sdhci implementation of the soc, or do they hinge on the board-design in some way?

12:16 <Kwiboo> they seem to be attached to the sdhci implementation of the soc and not board-design specific, at least in vendor kernel the delay num's is hard-coded on soc level

12:19 <Kwiboo> and yes, having those tapnum in dt could be one option, or should it be seen as configuration and not be part of dt

12:20 <mmind00> Kwiboo: that is the 500€ question ;-)

12:25 <mmind00> Kwiboo: interestingly enough, the addition of the Rockchip stuff to the binding never got an Ack/Review from dt people ... https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dd12261e7fd9a3c7f6ddf76152764861ad4f0e12

12:27 <Kwiboo> hehe yep, I tried to look at the old revisions of that patch and can only see a commend from Rob about u32 -> u8

12:29 <Kwiboo> there does not seem to be any user of rockchip,txclk-tapnum and the controller use different txclk-tapnum depending on mode hs200/hs400 so that prop is not very useful

12:30 <mmind00> Kwiboo: though sdhci-am654.yaml also seems to define them

12:30 <mmind00> or similar at least

12:31 <mmind00> which actually matches your patch ... tapnum for each mode

12:33 <Kwiboo> mmind00: yeah, the values seem to be defined for each soc in dtsi files and not boards, so there is something to point at, thanks for the pointer :-)

12:33 <mmind00> but commit messages on that binding are also lacking dt-maintainer Acks

12:36 <mmind00> Kwiboo: but as they are describing tuning delays, I can imagine that while the defaults might work for boards following layout guidelines, there may be designs where you'd need a per-board override as well

12:36 <mmind00> so I guess for a first try, go with a dt-property and we'll see where that takes us

12:37 <Kwiboo> sounds good, thanks, I will re-work it to use dt-property

12:38 <Kwiboo> I mostly wanted to work on adding basic rk3506 support for linux, but fell down in a rk3528 sdhci trap preparing for an updated u-boot rk3528 v2 series :-)

12:39 <mmind00> :-)

12:39 <mmind00> That yak needs shaving ;-)

12:42 <Kwiboo> hehe :-)