On Fri, 26 Jun 2020 at 18:00, <Eugen.Hristev@xxxxxxxxxxxxx> wrote: > > Hello Ulf, Adrian, and anyone interested, > > On our AT91 products we have an SD/MMC block with an included DLL that > does not lock if the SD clock is not configured depending on speed > modes, like high speed requires 25 Mhz, HS200 requires 100 Mhz, etc. > > All the spec and the code configures everything at 400 kHz and then > moves to high speed, etc. and in the end , the clock is raised. > While this is perfectly fine, on our block we need to raise the clock > first and change the speed mode after. > > Namely, in the function mmc_select_timing , if we call first > mmc_set_bus_speed then our DLL will lock correctly when selecting the > mode. If we select the mode first, our clock is stuck. > > My question is actually how (if possible) we could do a quirk in the > mmc such that our block will work correctly. > So I would need a little guidance about where to place such quirk, if it > would be accepted or not, and we are forced to be incompatible with the > linux-mmc sdhci . > > I have seen some patches for something similar a few years ago [1] on > the ML, but they were left floating in the end, so that is why I am > asking, which would be the proper way to do this. I would prefer if this is addressed in the host driver. Typically in the host's ->set_ios() callback, before you update the clock according to ios->clock, you can check the ios->timing value. If the conditions don't allow to update the clock, just defer it to next time when the ->set_ios() callback is being called, likely having the "correct" ios->timing. Would that work? > > Thanks ! > Eugen > > [1] https://patchwork.kernel.org/patch/7127441/ Kind regards Uffe
