AM3703: Continuous MMC clock

Hi user6204054,

user6204054 said:

However, we change the bit and our system occuer kernel panic.(below error message)

We try only to read the register but the erroe occur as well.

Can you please share the exact changes you made to read that register (PATCH), and what are the changes based on (TI SDK version XXX?).

Also if you could provide a complete Kernel log including the exception that would be great.

As I currently do not have access to AM3703 hardware to be able to experiment with that to provide a known-good example I need more info from you to see what potentially could be going wrong here.

Regards, Andreas

Thank you for replying.

I show up more info.

1.chanege info

srcfile:arch/arm/mach-omap2/pm34xx.c

function:prcm_setup_regs

content: add below code

pi1x800_write_mod_reg(0x0010700),0x480AC02C);

2.version

sh_mmcif.c says DRIVER VERSION 2010-04-28

3.log

[    1.806335] Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
[    1.819396] [<c0045d34>] (unwind_backtrace+0x0/0xec) from [<c02b3f2c>] (panic+0x4c/0x180)
[    1.827972] [<c02b3f2c>] (panic+0x4c/0x180) from [<c0035594>] (init_post+0x108/0x138)
[    1.836151] [<c0035594>] (init_post+0x108/0x138) from [<c0008454>] (kernel_init+0x110/0x150)
[    1.845001] [<c0008454>] (kernel_init+0x110/0x150) from [<c00411fc>] (kernel_thread_exit+0x0/0x8)

In our survey, We understand thata we can set  MMCHS_CON register. And we set the Clkextfree bit. But we can't make the SDIO clock continuous action. 

【Other things we notice】

We can get the 24μs intermittent clock with oscilloscope. Befor the set bit, 16ms intermittent clock.

【Question】

What we set any other registeer (and so on) so that we can get continuous sdio clock？

sorry, we forget the change point.

【change】

omap_hsmmc.c/omap_hsmmc_set_ios

 around L1662

modify

con = OMAP_HSMMC_READ(host->base,CON) | (3<<9) | (3<<8) ;

⇒

con = OMAP_HSMMC_READ(host->base,CON) | (3<<9) | (3<<8) | (1<<16);

user6204054,

thanks for the additional details. I'm planning on looking into this tomorrow to see if I can provide any pointers here.

Regards, Andreas

user6204054,

user6204054 said:

What we set any other registeer (and so on) so that we can get continuous sdio clock

Reviewing the processor reference manual, it seems like that you would also need to clear the AUTOIDLE bit in MMCHS_SYSCONFIG, as discussed in the description for the CEN control bit in MMCHS_HCTL. Just setting CLKEXTFREE may not be enough. Can you please verify the state of this bit and experiment with this and report back.

Also if the issue persists please report which specific Kernel tree you are using (This here? http://software-dl.ti.com/sitara_linux/esd/AM37xSDK/latest/index_FDS.html

Regards,
Andreas

Hi user6204054,

user6204054 said:

Sorry, we may be able to get continuous clock without clearing the AUTOIDLE bit. We will confirm waveform again around Nov 5. And we will report again.

Okay sounds good. I'm going to close this thread for now. If you need further help regarding this specific issue after you have run your additional experiments (or just would like provide your conclusion) please simply re-open by by amending your latest update and we can pick up things from there.

Thanks and Regards,
Andreas

Hello Andreas,

We've checked sdio clock waveform of our device with setting  CEN control bit and AUTOIDLE bit. As a result we can't get always continuous clock. The clock repeat 24 μs intermittent clock and continuous clock. We wanna always continuous clock. Do you have any idea？ (why repeat 24 μs intermittent clock and continuous clock？ etc, )

 we send the sdio clock waveform for mutual recognition.

Hi user6204054,

user6204054 said:

We can get continuous sdio waveform by removing the processing of disable CEN. Thank you for helping.

Sounds like the modification of the driver addressed your concern? If so then please set the thread to "Resolved", or amend with additional information as needed.

Regards, Andreas

Hello Andreas,

Sorry again.

When the device we develop wake up, we could get continuous sdio clock. But after the device wake up, sdio clock waveform is 24 μs interval.

We dumped the register below bit.

【checked bit】

CLKEXTFREE

AUTOIDLE

CEN

Do you have any idea we have to check？ We wonder if driver module change bit as  the function omap_hsmmc_stop_clock().

Regards,

user6204054

Hi user6204054,

user6204054 said:

When the device we develop wake up, we could get continuous sdio clock. But after the device wake up, sdio clock waveform is 24 μs interval.

Not sure if I understand what you are saying.

Are you saying that when booting the device and *before* going to sleep you get a continuous clock as expected with the changes we had been discussing. But then, *after* going to sleep and waking up, the SDIO clock is no longer continuous?

user6204054 said:

【checked bit】

CLKEXTFREE

AUTOIDLE

CEN

So did those bits change before vs. after wakeup?

If they did you probably need to also update the function omap_hsmmc_context_restore() which is called after wakeup to re-enable the bits that you need.

Regards, Andreas

Hello Andreas,

Yes, like you said, I mean booting up. After booting up, I checked the bit (CLKEXTFREE,AUTOIDLE,CEN).

In addition, we found when making a module not insmod, the sdio's clock is flat. 

Maybe, the clock may  work only when communication.

Is there like that mode ?

Regards

Hello Andreas,

May we ask Additional questions？

 The sdio clock's waveform's base is low. (Previously posted waveform)

Is there the measure that making sdio clock's waveform's base high？

Regards

Hi user6204054,

user6204054 said:

 The sdio clock's waveform's base is low. (Previously posted waveform)

Is there the measure that making sdio clock's waveform's base high？

I looked at the earlier waveform again but I'm not sure I fully understand your question. Looks like the amplitude of the "C2" signal trace is being measured as 1.68V which is pretty close to the 1.8V used during some SD transfers. From the scope shot it also looks like there are some issues with signal grounding (scope probe) or matching resulting in some amount of signal overshoot/undershoot.

How do you expect the signal waveform to look like?

Regards, Andreas

Hi user6204054,

user6204054 said:

In addition, we found when making a module not insmod, the sdio's clock is flat. 

Maybe, the clock may  work only when communication.

Are you saying that when not probing the omap_hsmmc driver you don't see the waveform being output? Where did you implement the changes to update the CLKEXTFREE / AUTOIDLE / CEN control bits in the Kernel? In omap_hsmmc.c or some other place?

Regards, Andreas

Hi,Andreas

>Are you saying that when not probing the omap_hsmmc driver you don't see the waveform being output？

Yes, that's right.

>Where did you implement the changes to update the CLKEXTFREE / AUTOIDLE / CEN control bits in the Kernel? In omap_hsmmc.c or some other place?

CLKEXTFREE set in omap_hsmmc.c/omap_hsmmc_set_ios

AUTOIDLE clear in omap_hsmmc.c/omap_hsmmc_context_restore and omap_hsmmc_conf_bus_power

CEN is originally set omap_hsmmc.c/omap_hsmmc_set_ios (temporarily clear and set in the function)

In addition to we dump these register and we checked setting.

Hi user6204054,

user6204054 said:

>Are you saying that when not probing the omap_hsmmc driver you don't see the waveform being output？

Yes, that's right.

So since in that case you are not probing the MMC driver you can't really expect your modified code to run.

Why do you want the clock to output when the MMC driver is not probed?

If you really want that you'd need to find another place in the kernel boot flow to manipulate those bits, independent of omap_hsmmc.

Or is there something else you are trying to do here?

Regards, Andreas

Hi Andreas

We removed  omap_hsmmc driver for trying aim to know wether SDIO clock work only when other module communicate with SD Interface. 

Regards,

Hi Andreas

We show the regulation below.

We seem the level is overshoot in the regulation's picture when clock rest as intermittent.

But our waveform undershoot when clock rest as intermittent.

【regulation】

academy.cba.mit.edu/.../SD.pdf

ver 6.00

p76 ref 4.4 Clock Control

Regards

Hi user6204054,

I reviewed section 4.4 of the document you linked but it does not mention anything of overshoot and undershoot so I'm still not sure exactly what you are describing. Are you talking about the signal levels? Or about the frequency, perhaps? Maybe it would help if you take another, more detailed (zoomed-in) scope shot where you annotate directly into the scope shot what your expected vs. the observed behavior is?

Thanks and Regards,
Andreas

We interpreted that the pause level in intermittent waveform is overshoot, but as you said there is no need overshoot.

Continuously we wanna ask how to get the continous MMC clock.

Regards

Hi user6204054,

user6204054 said:

Continuously we wanna ask how to get the continous MMC clock.

There are no other MMC-related bits besides the ones we have already manipulated and for which you confirmed earlier that lead to a (mostly) continuous waveform being output.

However If you can explain in detail what exactly are you trying to do with this external clock signal we may be able to arrive at an alternative hardware+software solution that may solve your what seems to be a system-level problem.

Thanks and Regards,
Andreas