AM6548: AM6548 with 2 CAN-FD supporting

HI Keerthy:

May you check with this E2E :https://e2e.ti.com/support/interface/f/138/t/841680?TCAN4550-Linux-Driver-for-TCAN4550

The Mr.Max said it will support in the Linux 5.4.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/m_can

May you confirm this?

THanks.

BR Rio

In this DTSI: board-support/linux-4.19.59+gitAUTOINC+5f8c1c6121-g5f8c1c6121/arch/arm64/boot/dts/ti# gedit k3-am65-mcu.dtsi

There are the code section below.

Q1: Why there are 2 mcan here, are those2 PRU acting like CAN bus?

      if no, do we need to modify this area for adapting TCAN4550?

               m_can0: mcan@40528000 {

                              compatible = "bosch,m_can";

                              reg = <0x0 0x40528000 0x0 0x400>,

                                    <0x0 0x40500000 0x0 0x4400>;

                              reg-names = "m_can", "message_ram";

                              power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;

                              clocks = <&k3_clks 102 0>, <&k3_clks 102 5>;

                              clock-names = "cclk", "hclk";

                              interrupt-parent = <&gic500>;

                              interrupts = <GIC_SPI 544 IRQ_TYPE_LEVEL_HIGH>,

                                                  <GIC_SPI 545 IRQ_TYPE_LEVEL_HIGH>;

                              interrupt-names = "int0", "int1";

                              bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;

                              status = "disabled";

               };

               m_can1: mcan@40568000 {

                              compatible = "bosch,m_can";

                              reg = <0x0 0x40568000 0x0 0x400>,

                                    <0x0 0x40540000 0x0 0x4400>;

                              reg-names = "m_can", "message_ram";

                              power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;

                              clocks = <&k3_clks 103 0>, <&k3_clks 103 5>;

                              clock-names = "cclk", "hclk";

                              interrupt-parent = <&gic500>;

                              interrupts = <GIC_SPI 547 IRQ_TYPE_LEVEL_HIGH>,

                                                  <GIC_SPI 548 IRQ_TYPE_LEVEL_HIGH>;

                              interrupt-names = "int0", "int1";

                              bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;

                              status = "disabled";

               };

We learned from TI Analog BU, there are TCAN4550 driver here.

• http://git.ti.com/gitweb/?p=ti-analog-linux-kernel/dmurphy-analog.git;a=blob;f=drivers/net/can/m_can/tcan4x5x.c;h=411502c3c98ed1df3b6036bb98deacaa7ec156be;hb=7f5ee781af9e8214ccd13755181e1e827af4ff50
• http://git.ti.com/gitweb/?p=ti-analog-linux-kernel/dmurphy-analog.git;a=commit;h=9fd038dbbe0bf975d6529f4d04a7e47e6302ca63
• http://git.ti.com/gitweb/?p=ti-analog-linux-kernel/dmurphy-analog.git;a=commit;h=7f5ee781af9e8214ccd13755181e1e827af4ff50

And this is the TCAN4550 upstream:

https://git.ti.com/gitweb?p=ti-analog-linux-kernel/dmurphy-analog.git;a=shortlog;h=refs/heads/tcan4x5x_upstream

Q2.

        Following Q1, if we enable the MCAN and the TCAN4550 driver, then, TCAN4550 should be working correct, Right?

BR Rio

Hi Karan:

-->The CAN-FD controller has a driver and the TCAN1042 doesn't need a driver per se. So no additional things should be needed to be done from your end to enable functionallity.

I'm not 100% understanding your point.

Please note, we want to adapt the TCAN4550 onto the AM65, it's our goal.

Let explain my knowing here:

       A. The TCAN4550 is a CAN-FD controller + Transceiver integrated.

            TCAN1042 is only a Transceiver 

       B.  TCAN1042 is not needing any Linux driver (Driver is the controller driver here)?

            If no need, then, how is the TCAN1042 working on the AM65 EVM now?  <-- I don't get it.

            if need, is the MCAN driver acting as a controller to control the TCAN1042 in the AM65 EVM?

       C.  I'm confusing with this sentence -->  no additional things should be needed to be done from your end to enable functionallity..

            Do you mean that we don't need to modify any code, just to connect the TCAN4550 onto the AM65 EVM, and it will work?

            My knowing is that we need to set the SPI for the communication between AM65 and TCAN4550.

Please comment,thanks.

BR Rio

Hi Rio,

So is this discussion in reference to some custom board based on AM65 SoC? Please confirm.

I was always talking about the EVM.

Regards,

Karan

Hi Karen:

It's the customer PCB, not the TI EVM.

Sorry for letting you miss-understanding.

BR Rio

Hi Karan:

I have posted the above E2E, thanks for your helping.

I think we can discuss here for more efficiency.

Now, this customer is able to make the TCAN4550 working on the kernel 4.19 on AM654X.

We know the MCAN is not necessary while adapting the TCAN4550 driver, please double confirm if this is correct way.

The major question from customer right now is: how is the correct way to set the TCAN4550 on the DTS and the interrupt pin for the DTS.

May you guide us what’s the right way or giving us the example of DTS setting the interrupt on AM65?

THanks.

BR Rio

Hi,

Rio Chan said:

Now, this customer is able to make the TCAN4550 working on the kernel 4.19 on AM654X.

When you say - able to make the TCAN4550 working, what does that mean? How have you tested?

Rio Chan said:

May you guide us what’s the right way or giving us the example of DTS setting the interrupt on AM65?

We do not support TCAN4550 on the EVM hence, I need to check this part.

Regards,

Karan

Hi Karen:

Besides the CAN IP issue (32 version) discussed in the mail, please help us for the CAN interrupt pin assignment on the DTS for AM654X.

TAhnk you very much~.

BR Rio

Hi Rio,

Can you please summarize the latest status on this thread? We should capture the summary after the issue is resolved.

Regards

Karthik

Hi Karthik:

This issue is still waiting the TI RnD to resolve.

Here is TCAN TI RND Ray Wes said:

==> I believe this is a known issue that we corrected in our version of 3.2 but we are verifying internally

BR Rio