<amstan>
doug suggests we move that to dw_mmc.c so it's common code
<amstan>
i still need to add hooks for the dts properties, right now everything's just hardcoded
<mmind00>
amstan: I'm just trying to determine if we need the new clock-ids (dt-bindings/...) to be separate
<amstan>
as a dependency to this patch?
<mmind00>
amstan: i.e. when both the clock declarations and the driver + dts changes make it into the 3.19 code we'll need a shared branch for the clock-ids that gets merged into both the clock-branch and the dts-branch
<mmind00>
amstan: it would be a series ... patch1 add the clock-ids to the binding-header, patch2 add the clk code
<amstan>
patch1 will surely be pretty small and useless by itself
<amstan>
i don't really like the idea, but if that's what needs to be done, i can split it up if you want
<mmind00>
amstan: yep, but you would need the clock-id in both the clock-code (v3.19-clk/next) as well as in the devicetree stuff (v3.19-armsoc/dts)
<mmind00>
amstan: that was the reason for my asking ... if the devicetree + mmc driver stuff is not expected to be accepted in time, we can skip this split
<amstan>
mmind00: so the idea is that i'll send https://chromium-review.googlesource.com/#/c/229387 soon upstream as well, and they won't really care if i drivers/clk/rockchip/clk-mmc-phase.c because all that dtsi needs is just the change in include/dt-bindings/clock/rk3288-cru.h
<mmind00>
amstan: correct, the mmc code does not care how you create the target phase and the clock stuff does not care what you do with it ;-)
<mmind00>
amstan: but of course it might be nice to link both together in cover-letters :-)
<amstan>
assuming i know how to use patman... lol
<mmind00>
:-D ... most of the time I only use git format-patch and git send-email (for bigger series) or my general mailclient (single patches or so)
dlezcano has quit [Ping timeout: 265 seconds]
<amstan>
mmind00: do you just copy+paste git diffs to emails? for single patches?
dlezcano has joined #linux-rockchip
<mmind00>
amstan: yep for single patches ... i.e. git format-patch and just subject line into the mail subject and the diff + commit message into the mail body ... of course the mailer should not line-wrap nor do html-crazyness ;-)
<amstan>
mmind00: yeah, i don't trust gmail to not do that
<amstan>
and apparently inbox.google.com always sends html stuff
<mmind00>
amstan: gmail can do imap + smtp so you can use a sane mail client ;-)
bengal has quit [Quit: Leaving]
<amstan>
yeah, but i like the gmail ui
<amstan>
so far..
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
ildar has joined #linux-rockchip
dlezcano has quit [Remote host closed the connection]
<amstan>
mmind00: alright! sent!
<amstan>
darn, patman didn't unionize the addresses, so only 2/2 got to patchwork(linux-rockchip@lists.infradead.org)
FreezingCold has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 244 seconds]
<karlp>
just for my own curiosity, why do you need to adjust phase of sdmcc clock? is to work around what? bad cards? do you need to change this often?
<karlp>
or is this badly laid boards with connectors that are introducing unexpected phase shifts?
<karlp>
s/badly//g no need to blame the hw dudes
<amstan>
karlp: at 200MHz bad stuff happens
<karlp>
right, but pushing the phase, this is board layout related right?
<amstan>
probably
<amstan>
but there might be variations in the chip
<karlp>
is this sdxc only I presume?
<amstan>
whatever runs at a fast clock speed(above 50MHz?)
<karlp>
huh, I didn't know SDIO was open collector
<amstan>
i don't think it is
<amstan>
there might be mild pullups just to keep the lines from floating, but i'm sure they driven from both sides
<karlp>
oh, seems to be in init mode
<karlp>
due to the legacy idea of "yeah, let's put 30 mmc cards on the same bus"
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<amstan>
mmind00: nooo! how could i have left that there? lol
<mmind00>
amstan: hehe ... happens to everyone occasionally :-D
<amstan>
alright, respinning
<amstan>
and sending it to all the people now
<karlp>
amstan: but this phase setting is definitely something that you expect to be completely ignored by most people right? you only use this at all if you'r eboard is exhibiting reliability problems with sd cards?
<amstan>
karlp: i don't think the users will ever have to do this
<amstan>
karlp: i'm going to follow my patch with some tuning code, so every time you plug in the card it'll try a bunch of angles and pick the middle/safest one
<amstan>
it's pretty much instant
<karlp>
ok, you're doing it for every card?
<karlp>
that's what I was curious about, I thought I saw that there were dt bindings for this, so I assumed this was for the layout of an sd connector, but doint it for every card is a different game altogether
<karlp>
how do you decide what the "safest/middle" on is?
<amstan>
try 45 degree increments
<amstan>
and you should see something like [ 1021.070009] candidates=0xfe ranges: 0 45* 90* 135* 180* 225* 270* 315* 1 good ranges found:45-315(7) best:45-315(7) middle=180
<amstan>
the * are the angles that work
<amstan>
then you pick an angle as far away as possible from the angles that don't work
<karlp>
is this common? I'm not deep in sdmmc code, but I wouldn't have thought you'd need to adjust the _phase_ so much _per card_
<amstan>
exynos does the same thing
<amstan>
grep for execute_tuning
<karlp>
exynos does lots of things, not entirely sure all of them ar egood ideas :)