In D43811#999391, @pldrouin_gmail.com wrote:

Updating copyright notice and credits.

Updating copyright notice and credits.

. . .
Thanks Mark. I am not the first one making changes though, I think at least @dgr_semihalf.com and @val_packett.cool did significant changes as well.

In D43811#999364, @markmi_dsl-only.net wrote:

If I understand right, the usual Copyright procedure for changes to a file that still has substantial original material but also substantial new material is to add copyright lines (for the new author's material, with years if in dated form), leaving the original Copyright line in place as well.

If new files (nearly just renaming would be: "not new") are created that are not substantially copies of older files, just the new author's Copyright would go in those. Similarly for the file naming not being changed but not much of the original material being left.

(The wording above may only provide a indication of the general direction and not much detail relative to various legal concepts involved.)

[A hint about "substantial changes": if omitting a Copyright means not finding the name of who to ask questions about notable parts of the resulting material, some Copyright notice(s) are likely missing.]

If I understand right, the usual Copyright procedure for changes to a file that still has substantial original material but also substantial new material is to add copyright lines (for the new author's material, with years if in dated form), leaving the original Copyright line in place as well.

Renaming the directory for the driver's source files from qoriq to vybrid

Merging the code with the existing driver in D43811. This differential is now obsolete.

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?

The main issue I have for the FDT driver, is the following couple of lines in vf_i2c.c:

So I looked at the VFXXX controller reference manual (https://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf), and the specs for the I2C controller look almost identical to the ones for the LX2160A I2C controller, except mostly for the clock divider table. Based on this information, I do not see why the new implementation could not work for the VFXXX controller. I would have to reintroduce the code by @dgr_semihalf.com to do the clock divider calculations for the devices that differ from the LX2160A though.

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: