The MTTCAN controller uses different core clock frequencies depending on
the SoC variant: 40MHz for T264 and 50MHz for T194/T234. The 8Mbps data
bitrate needs to be an exact divisor of the clock frequency for proper
operation.
For 40MHz clock: 8Mbps = 8000000 bps (40MHz / 5)
For 50MHz clock: 8Mbps = 8333333 bps (50MHz / 6)
The previous single MTTCAN_SPEED_8MBPS definition (8333333) only worked
correctly for 50MHz clocks and would not divide evenly for 40MHz clocks.
Split MTTCAN_SPEED_8MBPS into two separate defines:
- MTTCAN_SPEED_8MBPS_40MHZ: 8000000 for exact 8Mbps on 40MHz clock
- MTTCAN_SPEED_8MBPS_50MHZ: 8333333 for closest 8Mbps on 50MHz clock
Both values use the same production settings (prod_c_can_8m) and will be
selected based on the chip's configured clock frequency. The 5Mbps rate
remains unchanged as it divides evenly for both clock frequencies.
Bug 5497458
Change-Id: I17190ae6821f89d33e76114f20b91dbd65ba25f2
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3469194
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Tested-by: Kevin Fu <chunhuaif@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
In Linux v6.16, the structure 'data_bittiming_params' was added to the
'can_priv' structure and all the related data bittiming parameters were
moved under this new structure. Add a test to conftest to determine if
this new structure is present and update the Tegra MTTCAN driver
accordingly.
JIRA LINQPJ14-60
Change-Id: Ibd8f6bd81a903b15a55d837023dada835a1e72ca
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3374645
(cherry picked from commit 86396ec47b78a7716a5faa8d492d74efc7f23dce)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3461874
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In Linux v6.15, the timer APIs hrtimer_init() and del_timer() have been
removed. The hrtimer_setup() was added in Linux v6.13 to replace
hrtimer_init() and hrtimer_init() have finally been removed. The
functions del_timer()/del_timer_sync() were renamed to
timer_delete()/timer_delete_sync() in Linux v6.15. Use conftest to
detect these changes and update the drivers as necessary.
JIRA LINQPJ14-47
Change-Id: Id3994900384aad4b91155507cda91e04898ab12c
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3336168
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Adding support in existing mttcan driver to control T264 FSI
CAN controllers from CCPLEX whether FSI firmware is loaded on
system or not. FSI CAN clocks will be enabled by FSI crystal clock
upon boot. SW does not need to enable or control clocks. CCPLEX cannot
control FSI controller resets, reset can be handled during boot, thus
disabled clocks and reset for T264 SOC.
Bug 4317516
Change-Id: I8e6b20640c8763ebc0a9d9192e3212a49902f9b4
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
[Issue]: CAN freezes/stops to send messages after restart from bus-off state.
Throws following log from kernel: "write: No buffer space available"
[Reason]: When message txfer starts, tx_object (which keeps track of active tx)
gets filled. If CAN goes to bus-off state, txfer remains incomplete for some
messages. In such case, tx_object bits will not get cleared. It will stop
adding more messages in controller RAM.
Along with tx_object, from network layer, there are socket echo buffers.
When CAN is initialized and up on network, netif_start_queue is pushed to start
transmission. When msg txfer starts, socket buffer gets filled and freed only
when txfer completes. During bus-off, since network queue remains ON, all the
queued msgs get filled in socket buffers and does not allow upcoming msgs.
Therefore we see "write: No buffer space available".
[Fix]: Clear tx_object when device goes to bus-off state and stop network queue.
Start network queue again during restart from bus-off.
Bug 4438223
Change-Id: I3cbc6529a90f357372c8b0095bdce4217b133e9b
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3142091
(cherry picked from commit f902d95962)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3144103
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Instead of using the Linux kernel version, use the
configs coming from core kernel to find out whether
legacy or next-gen prod configuration method is used.
This will help on porting changes on any kernel and
configuring via core kernel configs.
Bug 3389584
Change-Id: I19c242c573dd63c7dbecbf87d4ba807857dcf4fb
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3013911
Reviewed-by: Krishna Yarlagadda <kyarlagadda@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The new Tegra Prod APIs are to be used for NVIDIA Linux kernels v5.16+.
Building the MTTCAN and QUAD SPI driver currently fail for upstream
Linux v5.16 because the various version definitions are not correct.
Some definitions have greater than v5.16.0 instead of greater than OR
equal to v5.16.0. This means that the new APIs will only be used
starting with v5.16.1+ and not v5.16.0 as inteaded.
Other definitions have less than or equal to v5.16.0 instead of just
less than v5.16.0. This means that we will still use the legacy APIs for
v5.16.0.
Fix this by correcting the definition that the drivers can be built for
upstream Linux v5.16.
Bug 4097475
Change-Id: I7d8dd04911a7d6426c67e82396c8a6f1b372875d
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3006521
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Add new prod setting support which is the
property based on device tree. The prod
setting of each register field are new property
in DT and prod configurations are configured
via these new properties.
Bug 4097475
Change-Id: I86adc7b72a28802d73fee8a085db2bccf0d6d1cc
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2996771
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Instead of relying on kernel version to determine if functions or
specific versions of functions are present in the kernel, add compile
time tests to the conftest.sh script to determine this at compile time
for the kernel being used. This is beneficial for working with 3rd party
Linux kernels that may have back-ported upstream changes into their
kernel and so the kernel version checks do not work.
Bug 4119327
Change-Id: I79e701940ca70ca4d66500c75b5992f9d92b54b0
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2985744
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
CONFIG_CAN_LEDS has been marked as BROKEN since Linux v4.19 and was
finally removed in Linux v5.19. Only compile support for LEDS if enabled
in the kernel. Long-term we need to move the MTTCAN driver to use
LEDS_TRIGGER_NETDEV.
This is a better solution for working with 3rd party Linux kernels that
may backport upstream changes to the kernel and hence are not compatible
with these existing version checks.
Bug 4228080
Bug 4283911
Change-Id: I70e800c4a3699af59742d30111bc3a3cbf80bcb5
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2982135
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
When mttcan
- is set into DAR (Disable Automatic Retransmission) mode
- and Protocol Exception Handling is enabled
- and PXE (Protocol Exeception Event) is generated
then no TCF (Transmission cancellation Finished) event is generated.
This leads to mismatch between internal driver state and mttcan HW
state. This results in "no buffer space available" error.
This patch clears the driver internal state in close callback to
handle this situation.
Bug 200502350
Change-Id: Ie9f8fcc902a8d9b6c65662888904be5ad9aae49e
Signed-off-by: Abhijit <abhijit@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2854706
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2921328
Tested-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-by: Suresh Venkatachalam <skathirampat@nvidia.com>
Reviewed-by: Sandeep Trasi <strasi@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Building the mttcan driver currently fails for Linux v5.14 with the
following error ...
drivers/net/can/mttcan/native/m_ttcan_linux.c:1535:2: error: unknown
field 'ndo_eth_ioctl' specified in initializer
.ndo_eth_ioctl = mttcan_ioctl,
Fix this by using the appropriate field name for Linux v5.14.
Bug 3820317
Bug 3896592
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Change-Id: I822d988b097350538fbf4a568181e9fde9928ea3
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2836716
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Using this patch we are fixing below kernel compilation
warnings.
out/linux/arm64-defconfig-jetson-modules/nvidia-oot/drivers
/net/can/mttcan/native/m_ttcan_linux.c: In function 'mttcan_start_xmit':
/mlt/kernel/include/linux/stddef.h:8:14: warning: passing argument 4 of
'can_put_echo_skb' makes integer from pointer without a cast
[-Wint-conversion]
#define NULL ((void *)0)
Bug 3832874
Change-Id: I2aa565f37494f6af39a43b389ea3e1ad7775ed44
Signed-off-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2809373
Reviewed-by: Sandeep Trasi <strasi@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
When compiling the MTTCAN driver for Linux v5.19 the build fails because
the can_led_xxx() functions are not found. The can_led_xxx() functions
were removed for Linux v5.19 and not Linux 6.0 and so update the driver
accordingly to fix this.
Bug 3820317
Change-Id: I340cc9cbb44b5cb892c50cc0b5d06444ef894fe9
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2792549
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Upstream Linux kernel commit b48b89f9c189 ("net: drop the weight
argument from netif_napi_add") removes the weight argument from the
netif_napi_add() function and this is breaking the build of a few
drivers that use this function. Fix this by updating these drivers to
use the netif_napi_add_weight() function instead for Linux v6.1.
Bug 3831575
Change-Id: I5ab3c2380db75313f9226c68777e6245e9e9dad5
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2793511
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
