see D53894

In D43399#1179757, @christos wrote:

Please rebase all relevant patches, including this one, on top of main, stack them properly, and also re-generate and update the diffs with full context: https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface

This looks like an older review for

looks OK, but tagging for srcmgr review since some of it looks weird too :)

code looks OK, though my arm assembler is rusty. tagged as srcmgr for review

srcmgr review, likely OK, but not actually accepted.

Wonder what the status of this is... Tagging for srcmgr review, even though it didn't make it to accepted.

tagging for srcmgr review. These are all likely a sea of conflicts now, but that should be easy to resolve.

Looks like this would be easy to forward port. But the patch series likely needs some work. tagging for srcmgr review.

This isn't in current. Tagging for further review by srcmgr.
It's looking, though, like an incomplete patch that maybe should be closed.

This appears to have landed in slightly modified form in the following. Any lingering open issues should be addressed in a new review.

Please rebase all relevant patches, including this one, on top of main, stack them properly, and also re-generate and update the diffs with full context: https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface

Can you please:

• Rebase it on top of the current main branch.
• Generate the diffs with full context git diff -U999999.
• Organize the commit message, test plan and additional notes. Things are a bit all over the place now.

vybrid case it might be time to remove that one soon - some of the drivers seems to be used as base for the layerscape SoC for example D44020.
https://cgit.freebsd.org/src/commit/?id=ba9f8eeb478975069b644f2228808d5e0c0dc1b1

they should be in GENERIC if able (or at lease something tinderbox would build).

In D41888#977453, @oskar.holmlund_ohdata.se wrote:

Background why this driver is added:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm/boot/dts/am33xx-clocks.dtsi?h=v6.1.64&id=c2f2646057bcf3f86a75f6a8aa9fbd159a1d4784

Fix Mikes comments.

Sorry - just confused and update wrong reviews... :)

Update sys/arm/ti/files.ti aswell and remove clock_common.c

adds comment that you need to read the manual pages about TSLOG

Split of https://reviews.freebsd.org/D27889

In D46703#1064788, @manu wrote:

Not sure this is worth it, people can have local modification if they want to work on TI stuff.
We know that the current code doesn't boot with latest dtb so until this is solved no point of adding this config.

Not sure this is worth it, people can have local modification if they want to work on TI stuff.
We know that the current code doesn't boot with latest dtb so until this is solved no point of adding this config.

If this boots on bbb, then great.... well, boots as well as it can... I've had two or three people contact me about fixes for new dts... should ibdo introductions since you know the issues with much better fidelity?

I think this is in the TI kernel that's kinda on the way out unless it gets fixed... and oskar has been fixing it up...

Apologies for missing this. It looks like this file isn't compiled into any existing kernel config. Is that expected?

If it doesn't work, it's been broken long enough for us to retire.
IIRC, though, Oskar was working on making at least some TI SoCs working.
FreeBSD 11 or maybe early 12 was the last time my Pandaboard booted.

I think this is OK - FreeBSD is starting on the path of retiring 32-bit support. ARMv7 support will remain for FreeBSD 15.0, but if a specific SoC isn't working properly today and doesn't have anyone working on it then retiring it now is reasonable.

@bz Ok, so it turns out that the issue I had was not with the driver. So there was no issue with the reset function, and the current version of the Diff properly works for me with the ACPI version of the driver. Since the clk* functions are no longer called when sc->mutex is locked, I assume the issue regarding mutex ordering is also fixed for the FDT driver. So this means the driver should also be ready for you to test.

I will do additional tests. There have been quite a few moving parts this week on my end (with the I2C tool I have been working on in addition to the driver), so I could have rushed my tests a bit too much and have drawn the wrong conclusions. I will do systematic tests starting from working versions.

In D44020#1009471, @bz wrote:

In D44020#1009470, @pldrouin_gmail.com wrote:

In D44020#1009469, @bz wrote:

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.

My assumption here is that it is the reset function is not called twice at the same time in parallel from the bus.

What you describe is what I do in the latest version, but it does not work, since without the lock, i2c_get_div_val gets executed before the attach function has the chance to set the variables that are used by i2c_get_div_val. So I need to delay the call to i2c_get_div_val until the attach function completes. Without that I end up with the wrong divider value. Note that this problem seems to only occur at boot time and not if I load the driver as a module after booting.

Do you enable interrupts before you need them? Do you need IBIC_BIIE for the initial READ?

In D44020#1009470, @pldrouin_gmail.com wrote:

In D44020#1009469, @bz wrote:

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.

My assumption here is that it is the reset function is not called twice at the same time in parallel from the bus.

What you describe is what I do in the latest version, but it does not work, since without the lock, i2c_get_div_val gets executed before the attach function has the chance to set the variables that are used by i2c_get_div_val. So I need to delay the call to i2c_get_div_val until the attach function completes. Without that I end up with the wrong divider value. Note that this problem seems to only occur at boot time and not if I load the driver as a module after booting.

In D44020#1009469, @bz wrote:

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.

My assumption here is that it is the reset function is not called twice at the same time in parallel from the bus.

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.

In D44020#1009368, @pldrouin_gmail.com wrote:

Ok I think I know how this could be fixed. I should create a sc->initialized_freq flag which is set by the attach function once sc->freq has been set. The reset function should check the status of this flag after locking sc->mutex, and if it is not the case, it should cv_wait for a condition from attach. The attach function should cv_signal this condition after setting the flag. Does it look like the best strategy to you?

Ok I think I know how this could be fixed. I should create a sc->initialized_freq flag which is set by the attach function once sc->freq has been set. The reset function should check the status of this flag after locking sc->mutex, and if it is not the case, it should cv_wait for a condition from attach. The attach function should cv_signal this condition after setting the flag. Does it look like the best strategy to you?

Is there a way to prevent the reset function from being called before the driver is done attaching?

The driver seems to be misbehaving with the latest changes. I think it is due to interference between the attach and the reset functions (the attach and reset functions are called in parallel, and i2c_get_div_val gets called by the reset function before sc->freq is set to UINT32_MAX). This issue combined with the lock restrictions for the clk* functions makes it tricky to get the driver properly initialized at boot time. I will have to take a look at it another day...

Merging changes from D44020

Moving back sc->mutex initialization into vf_i2c_attach_common as before, but now locking the mutex whenever it is needed to communicate with the controller. No longer locking it before calling ofw* and clk* functions in vf_i2c_fdt_attach

I think I will have to make additional changes...

Trying to fix the "lock order reversal: (sleepable after non-sleepable)" error in FDT by moving back to an i2g_get_div_val function that gets called outside the sc->mutex lock with a WRITE call of the divider register inside the lock, that gets only called when the divider register value has been set.

Merging changes from D44020

Please ignore this revision

Based on the last couple of tests, it looks like the clk functions should not be called when a mutex is locked with mtx_lock?

We'll need to adjust that slightly in a different direction ...
@manu can you lend a hand? Probably a lot easier for you than for me.

Sorry the previous diff had been generated using an outdated version of the D44020 diff.

-The previous diff was not generated properly w.r.t. the last version of D44020