In D43746#998246, @andrew wrote:

In D43746#997823, @pldrouin_gmail.com wrote:

Note: lx2160a_i2c_fdt should not be loaded along with vf_i2c, as they share the same FDT ID. What is the best way to handle this?

Can you merge the two drivers?

Fixing /sys/arm64/conf/std.nxp and sys/conf/files.arm64

In D43746#997823, @pldrouin_gmail.com wrote:

Note: lx2160a_i2c_fdt should not be loaded along with vf_i2c, as they share the same FDT ID. What is the best way to handle this?

Last diff is broken. Will investigate...

Adding devices to sys/arm64/conf/std.nxp . The driver should work for LX2160A, LX2120A, LX2080A, LS1046A and LS1026A based on their respective reference manuals. The ACPI driver could be included in GENERIC. However as previously mentioned, I think including the FDT version along with vf_i2c could be problematic due to them sharing the same ID, so I commented out the lx2160a_i2c_fdt device.

In D43746#998187, @pldrouin_gmail.com wrote:

Revised version with all requested changes

Fixing a few typos in debug print statements. Adding also one debug print statement.

Revised version with all requested changes

Just basic style(9) review.
Also you should add the devices in sys/arm64/conf/std.nxp

I think this is now ready for review.

modules/Makefile: Moving _lx2160a_i2c_fdt inside the nested condition on OPT_FDT

modules/Makefile: The modules are now only enabled for arm64/aarch64

Removing the verification of IBSR_IBB in i2c_stop. It was most likely potentially problematic and should have not been used.

Adding blank line to copyright notice

The templates shown at https://www.freebsd.org/internal/software-license/ have a (nearly) blank line after the Copyright . . . line:

* Copyright (c) [year] [your name]
*
* Redistribution and use in source and binary forms, with or without

In general it is a good place to look at for comparisons.

Updating the copyright notice as recommended.

Avoid use of "All rights reserved." in copyright notices? https://www.freebsd.org/internal/software-license/ reports:

With the ratification of the Berne Convention in 2000, it became obsolete. As such, the FreeBSD project recommends that new code omit the phrase and encourages existing copyright holders to remove it. In 2018, the project updated its templates to remove it.

-The logic in wait_for_icf was not quite right. It is now fixed.

Removing unnecessary small delay in i2c_stop. It had been introduced earlier as an attempt to fix the issue which was resolved by using wait_for_nibb in i2c_start.

Removing an unused define in lx2160a_i2c.h

-Moved the source files to sys/dev/iicbus/controller/qoriq
-Removed lx2160a_common.h
-Renamed the driver modules to separate names
-Now using wait_for_nibb in i2c_start so it works reliably after a reset
-Added the drivers to files.arm64
-Updated the copyright notice, and added credits.

Thanks, I will make these changes. I also have to tweak some delay that should apply when a start follows a reset.

We have a new-ish directory sys/dev/iicbus/controller/ for i2c controllers, it should go there.

Ok I have found a few things to change. It looks like some extra delays might be required when the module is not run in DEBUG mode.

I currently have it configured as a pair of modules. One weird thing I noticed is that I could kldload and kldunload them just fine when I was building the modules manually and before I included them in sys/modules/Makefile and I rebuilt the kernel. After adding them to sys/modules/Makefile, rebuilding and installing the kernel, I can only load them through /boot/loader.conf, otherwise it complains the modules are already loaded in the kernel, although kldstat -v and grep -R lx2160a_i2c /boot/kernel say otherwise. How can this be fixed? Thanks

I wrote a FDT/ACPI split driver for the LX2160A I2C controller based on the work started by Val, and the LX2160A I2C controller documentation. It deviates significantly from the Vybrid driver as the way the original driver was handling the controller's registers was not quite compatible with the LX2160A I2C controller. Should I start a new diff with my driver and link to it from here? It seems to work well so far based on the (limited) tests I made. I can scan the bus and get the correct output. I am able to query the MUX's register and the fan controller's ID.

In D43399#991801, @bses30074_gmail.com wrote:

Is this patch based on the three preceding patches? Were there compilation warnings (or errors) encountered when applying those three patches, leading to the creation of this patch to address those issues?

Happy to have your testing and participation in getting Marcos VCHIQ HDMI audio sound patch reviewed. I post many URL links below to share ideas for further reading and learning.. YES, this is first a FreeBSD code review and not related to other BSD and URL links. So the point is to specifically comment about using FreeBSD source code. Sorry for the overload, but I wanted a good post to answer your question and share links for the background information.

Is this patch based on the three preceding patches? Were there compilation warnings (or errors) encountered when applying those three patches, leading to the creation of this patch to address those issues?

In D24917#550057, @val_packett.cool wrote:

Looks like this needs to wait until there's some way to get the clock without devicetree (I guess Linux runs with fdt+acpi both to make it work..)

FYI: https://uefi.org/specs/ACPI/6.5/19_ASL_Reference.html#clock-input-resource-descriptor-macro reports:

Concatenated 7 git diff -u patch files into one_large_vchiq_freebsd_patch_file.patch and updated this diff. I see that the FreeBSD (src) does not yet contain Marcos Devesas Campos VCHIQ revision D378378 https://reviews.freebsd.org/D37878. So make a decision to use or not use that code before incorporating this D43399 revision.

I do not know how to add the 5 other patch files to be included in this diff comparision. Seems like 132598, got over written with this "update diff" instead of being added. Time for me to read and study hand book. okay

add file vchiq_2835_arm_.c.patch to diff section

https://reviews.freebsd.org/D42969 and the rest of the patch series are available for review. They break up this patch into logical commits, plus ensure that we do not erroneously consume an exception if a kernel thread triggers a VFP exception without having entered an FPU section. This lets fpu_kern_enter() work on ARM when a FPU context is supplied by the caller.

Fix up this review to work with DTS import from Linux 6.4

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

In D42415#969126, @arichardson wrote:

I see you have a reduced test case, would it be possible to turn it into a regression test for in the ld-elf tests?

I see you have a reduced test case, would it be possible to turn it into a regression test for in the ld-elf tests?

remove the entire if statement

Thanks for suggestions.

collapse tmp = *where + tmp -> tmp += *where

In D42415#968208, @jrtc27 wrote:

If IE is fixed then lib/libc/Makefile probably should enable it on arm as a follow-up, which I *think* is the only architecture not covered by that if statement, unless I'm missing something

Ensure we update tmp for dbg output

I have now reduced the diff down to the minimum. Thanks all for your continued comments.

If IE is fixed then lib/libc/Makefile probably should enable it on arm as a follow-up, which I *think* is the only architecture not covered by that if statement, unless I'm missing something

I studied what NetBSD is doing here. Here is an updated test program:

• Replaced the DEFINE_CLASS_0 -> struct driver_t
• removed pinctrl_single_pins_write / read
• update pinctrl_single_syscon_unlocked_write_4/read_4 to honor pinctrl-single,register-width. (even if the functionnames will be misleading and give the impression its an 4byte version of read/write)
• removed pinctrl_single_syscon_unlocked_modify_4
• update error handling after fdt_pinctrl_register() call to release syscon in case of failure.

Looks mostly good to me.

Thank you Manu. Followed your advice to move the bus_alloc_resource/syscon interface to the end of the attach function to avoid complicated error paths.

Replaced by D42124

I'm pretty sure that the last time I've tested my pandaboard (maybe 4-5 years ago) there were already problems.