Skip to content

Install latest renesas/linux-ptp-driver-package (commit c4cac41) #41

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: adrianni-tg-v6.12
Choose a base branch
from

Conversation

adrian-nicolau
Copy link

@adrian-nicolau adrian-nicolau commented Jul 11, 2025

Install latest linux/ files from https://github.com/renesas/linux-ptp-driver-package by install script scripts/installDriver.sh. Fix compile errors:

  • asm/unaligned.h renamed to linux/unaligned.h
  • stdbool.h removed
  • .remove functions changed to return void
  • rsmu_i2c_probe changed prototype

Cherry-pick Siklu patches.

@adrian-nicolau adrian-nicolau self-assigned this Jul 11, 2025
doron2020 and others added 2 commits July 11, 2025 13:46
The way to receive this order is to define the dpll as hw clock (in falcon.dts, and clock registration in ptp_clockmatrix.c dpll driver init function), and rely on the dts clock dependencies (declare both phy and pcie as depended on this clock).

This works well for the phy but the pcies (modem) need to enable two clocks ( CP110_GATE_PCIE_X1_0 & CP110_GATE_PCIE_X4) that were formerly disabled by the kernel, and that causes kernel stuck. (in the former version, the pcie driver init was earlier and before the kernel disabled those clocks). Also reset pcie through gpio after the disable+enable didn't help. So "DEV-6467: Improve DEV-6442-Add initialization order to the falcon phy and modems" was opened to further investigate and handle this problem, and meanwhile a patch was entered in cp110-system-controller.c:cp110_gate_disable to never disable those two clocks.
…he DPLL (#29)

The current implementation of the PTP clock phase correction (see
ClockPhaseAdjuster component inside "devices") uses an "adjust time" API
call which in turn uses frequency correction (via "do_phase_pull_in" API
call) for phase offset less than 15us. This intrudes into the frequency
correction loop and decreases the accuracy of the phase correction loop.
We mustn't use any frequency correction during phase correction to avoid
those problems.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants