Re: STM32F4: Correct translation from native to LL clock driver


Neil Armstrong
 

On 05/17/2017 11:39 AM, Daniel Thompson wrote:
On 15/05/17 17:37, Daniel Thompson wrote:
On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).

I will get back to you as soon as I can!
Yes!

It solves the problem in the sense that devices are now enumerating correctly! However I'm afraid that the code isn't really robust enough for me to contemplate a pull request at this point (even with ModemManager disabled I am only getting a couple of characters from samples/subsys/usb/console).

I'll try to keep a rebase branch working on my github for anyone interested (branch has Christer's patch, 96b_carbon support and modifications in samples/subsys/usb to allow some of the examples to build):
https://github.com/daniel-thompson/zephyr/tree/hacking/carbon-usb
Hi Daniel,

Thanks for the branch, I'll eventually experiment it on the L4 boards aswell.

But, these STM32 SoCs embeds all the same Synopsys IP, except FS one uses a register to power up the internal PHY.

The STMF4/F7 now runs Linux using the classic DWC2 driver, so it could be the same on Zephyr.
Had someone already tried this ?

Following question: What about Host support ?

Neil


Daniel.


On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@linaro.org <mailto:daniel.thompson@linaro.org>> wrote:

Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on
STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring
it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c
b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk =
device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};

clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work.
Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate
(there is no attempt to hotplug... if the USB clock rate were wrong
hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a
bisect to try and chase thise problem down. bisect took me straight
to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know
this is strictly related to the clock driver change rather than any
other zephyr changes.

Can you offer any clues?


Daniel.

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

Join devel@lists.zephyrproject.org to automatically receive all group messages.