How to disable CSI0 to enable UART4 and UART5 in IMX53_SMD

cancel
Showing results for 
Search instead for 
Did you mean: 

How to disable CSI0 to enable UART4 and UART5 in IMX53_SMD

Jump to solution
1,159 Views
winstonrodrigue
Contributor IV

Dear Friends,

        I am working on imx53 sabre tablet (imx53_smd) board. So far I am successfull in testing most of the peripherals.

Now i am stuck at a point where I cannot test UART4 and UART5. remaining UARTS are working fine.

I suspect from following reasons..

     1. May be UART pads are not defined properly.

         but I have added UART4 and UART5 pad definitions in iomux_v3_cfg_t mx53_smd_pads[] of mx53_smd.c

        these ones :

        MX53_PAD_CSI0_DAT12__UART4_TXD_MUX,

        MX53_PAD_CSI0_DAT13__UART4_RXD_MUX,

        MX53_PAD_CSI0_DAT14__UART5_TXD_MUX,

        MX53_PAD_CSI0_DAT15__UART5_RXD_MUX,

       even I have changed to iomux-mx53.h file as per the latest freescale kernel tree. for al the UARTS.

  2. May be CSI0 interface is not allowing the UARTS to be used.

     the connector on board has a 120 pin QTH connectorin which there are signals for auxillary display and camera

     interfaces (CSI0). On the Same CSI0 interface you will find UART4 and UART5 signals. And I definitely dont need CSI interface.

so my guess is since CSI0 interface is still enabled so i cannot access the UART4 and UART5 signals.

So is there any way to disable the CSI0 interface. ?

Regards,

   Winston

Labels (6)
1 Solution
412 Views
AlanZhang
Contributor V

Hi, Winston,

If as you said that all UART ports behave in the same way from the perspective of code flow, but no signals output on uart #4 and uart #5. So are you sure that the hardware connection are ok, and no active long low voltage on rx, tx pins at the init phase. How about the rts/cts voltage level? If all of these checklist are ok, we have to change uart4, and 5 to other alternative pins. Whether it is ok to ship one board to me?

Regards,

Alan Zhang

View solution in original post

0 Kudos
21 Replies
408 Views
winstonrodrigue
Contributor IV

And I tried to make UART4 tx/rx as gpios... as follows in mx53_smd.c file

        MX53_PAD_CSI0_DAT12__GPIO5_30,     number is 158

        MX53_PAD_CSI0_DAT13__GPIO5_31,       and 159


when I try to use them as GPIO like below .....

   cd /sys/class/gpio

   echo 158 > export

   cd gpio158

   echo out > direction

   echo 1 > val

   echo 0 > val

And when I see the output in oscilloscope signal doesnt change at all.... for both pins..

Why I cannot use these pins neither as UART nor as GPIOs....?

Regards,

   Winston


0 Kudos
408 Views
yektaayduk
Contributor II

I'm also struggling with uarts.

Maybe also clocks for uart4 and 5 should be registered ,because clock.c file has only registration for these uart 1-2-3.

linux-2.6.35.3/arch/arm/mach-mx5/clock.c

    _REGISTER_CLOCK("mxcintuart.0", NULL, uart1_clk[0]),

    _REGISTER_CLOCK("mxcintuart.1", NULL, uart2_clk[0]),

    _REGISTER_CLOCK("mxcintuart.2", NULL, uart3_clk[0]),


0 Kudos
408 Views
winstonrodrigue
Contributor IV

If you are using smd board and BSP 11.09 clocks are enabled for all the UARTS....

static struct clk_lookup mx53_lookups[] = {

        _REGISTER_CLOCK(NULL, "pll4", pll4_sw_clk),

        _REGISTER_CLOCK("mxcintuart.3", NULL, uart4_clk[0]),

        _REGISTER_CLOCK("mxcintuart.4", NULL, uart5_clk[0]),


0 Kudos
407 Views
yektaayduk
Contributor II

Any progress ?

0 Kudos
407 Views
winstonrodrigue
Contributor IV

Hey yekthaayduk.....

              There is npo progres on this... because I cannot access the UART4 and UART5 on SABRE board coz the pins are on camera sensopr connector that is J12. I could solder it but I m scared that I may damage the sensor connector pins. In my custom board I m going to remove the Camera So i will be using UART4 and UART5 later....

  Regards,

    Winston

0 Kudos
408 Views
AlanZhang
Contributor V

First, modify the following points inside mx53_smd.c file:

1. Inside static iomux_v3_cfg_t mx53_smd_pads[]

    Remove :

/* CSI0 */

    MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12,

    MX53_PAD_CSI0_DAT13__IPU_CSI0_D_13,

    MX53_PAD_CSI0_DAT14__IPU_CSI0_D_14,

    MX53_PAD_CSI0_DAT15__IPU_CSI0_D_15,

    MX53_PAD_CSI0_DAT16__IPU_CSI0_D_16,

    MX53_PAD_CSI0_DAT17__IPU_CSI0_D_17,

    MX53_PAD_CSI0_DAT18__IPU_CSI0_D_18,

    MX53_PAD_CSI0_DAT19__IPU_CSI0_D_19,

    MX53_PAD_CSI0_VSYNC__IPU_CSI0_VSYNC,

    MX53_PAD_CSI0_MCLK__IPU_CSI0_HSYNC,

    MX53_PAD_CSI0_PIXCLK__IPU_CSI0_PIXCLK,

    Replace w/ :

    MX53_PAD_CSI0_DAT12__UART4_TXD_MUX

    MX53_PAD_CSI0_DAT13__UART4_RXD_MUX

    MX53_PAD_CSI0_DAT16__UART4_RTS

    MX53_PAD_CSI0_DAT17__UART4_CTS

    MX53_PAD_CSI0_DAT14__UART5_TXD_MUX

    MX53_PAD_CSI0_DAT15__UART5_RXD_MUX

    MX53_PAD_CSI0_DAT18__UART5_RTS

    MX53_PAD_CSI0_DAT19__UART5_CTS


2. Remove "ov5642" in  mxc_i2c0_board_info[];

3. Remove the following statements:

/* Camera reset */

    gpio_request(MX53_SMD_CSI0_RST, "cam-reset");

    gpio_direction_output(MX53_SMD_CSI0_RST, 1);

    /* Camera power down */

    gpio_request(MX53_SMD_CSI0_PWN, "cam-pwdn");

    gpio_direction_output(MX53_SMD_CSI0_PWN, 1);

    msleep(1);

    gpio_set_value(MX53_SMD_CSI0_PWN, 0);

Then, build the uImage, open log to see whether there exist any problem.


Regards,

Alan Zhang

408 Views
winstonrodrigue
Contributor IV

Hi Xia Zhang ,

            Thanks for your valuable suggestions. I did what you told me to do. but UART4 and UART5 are stil not working.

even when i connect oscilloscope on RX/TX pins there are no signal changes on the pins. but UART3/UART2/UART1 gives perfect signals.

         I have another idea ......

 

    by referring to the i.MX53 Multimedia Applications Processor Reference Manual, Rev. 2,.1, 6/2012

  section 45.51.1 Configuration Register (IPU_CONF)

   so this register is responsible for IPU interface initialization.

   so in this 32 bit register the 0th and 1st bits are responsible for enabling / disabling the CSI0 and CSI1 interfaces.

So i was just wondering if its possible to read / write this register or by OR-ing the value by 0x11111110 disables both the CSI interfaces. I think we can use __raw_writel(data,address);

  Any thoughts?

   Regards,

     Winston

0 Kudos
408 Views
AlanZhang
Contributor V

One more configuration item in kernel configuration file is needed to be "n", i.e. CONFIG_VIDEO_MXC_IPU_CAMERA=n.

Regards,

Alan Zhang

408 Views
winstonrodrigue
Contributor IV

Hi....

where can I find the kernel configuration file ??

thanks for the speedy reply ...

regards,

  Winston

0 Kudos
408 Views
AlanZhang
Contributor V

Under kernel/arch/arm/configs/imx5_defconfig, or imx5_android_defconfig.

Regards,

Alan Zhang

0 Kudos
408 Views
winstonrodrigue
Contributor IV

Dear Xia Zhang,

                I modified the kernel config file, rebuilt the kernel and booted. but no output on UART4 and UART5.

there is one more thing...

   on this SABRE board  in root directory /unit_test directory

   when i run mxc_uart_test.out it looks like the UART4 and UART5 are working for IOCTL test..

for UART5

root@freescale /unit_tests$ ./mxc_uart_test.out /dev/ttymxc4              
Test: MXC UART!                                                           

Usage: mxc_uart_test <UART device name, opens UART2 if no dev name is specified>

/dev/ttymxc4 opened                                                       
Attributes set                                                            
Test: IOCTL Set                                                           
Data Written= Test                                                        

Data Read back= Test

for UART4

root@freescale /unit_tests$ ./mxc_uart_test.out /dev/ttymxc3              
Test: MXC UART!                                                           

Usage: mxc_uart_test <UART device name, opens UART2 if no dev name is specified>

/dev/ttymxc3 opened                                                       
Attributes set                                                            
Test: IOCTL Set                                                           
Data Written= Test                                                        

Data Read back= Test

So it looks like there is no prob in UARTS. so there must be problem in Pin settings or something..... ..

what else can be done ?


Regards,


  Winston.

0 Kudos
408 Views
AlanZhang
Contributor V

Good feedback! Could you check drivers/serial/mxc_uart.c file, insert printk() in .start_tx, .set_mctrl, and .set_termios to see whether the invocations are in there. NO hardware flow control involved, unless RTS is connected to CTS directly.

Regards,

Alan Zhang

408 Views
winstonrodrigue
Contributor IV

Dear Alan Zhang,

 

here is the modified mxc_uart.c file..

static void mxcuart_start_tx(struct uart_port *port)

{

    uart_mxc_port *umxc = (uart_mxc_port *) port;

    struct circ_buf *xmit = &umxc->port.state->xmit;

    volatile unsigned int cr1;

    mxc_dma_requestbuf_t writechnl_request;

    int tx_num;

        printk("transmitting\n");

    cr1 = readl(port->membase + MXC_UARTUCR1);

    /* Enable Transmitter rdy interrupt */

    if (umxc->dma_enabled == 1) {

        /*

         * If the channel is in use then return immediately and use

         * the mxcuart_dma_tx to transfer queued data when current DMA

         * transfer is complete

         */

        if (dma_list[umxc->port.line].dma_txchnl_inuse == 1) {

            return;

                 printk("channel is in use\n");

        }

        tx_num = uart_circ_chars_pending(xmit);

        if (tx_num > 0) {

            dma_list[umxc->port.line].dma_txchnl_inuse = 1;

            if (xmit->tail > xmit->head) {

                memcpy(umxc->tx_buf, xmit->buf + xmit->tail,

                       UART_XMIT_SIZE - xmit->tail);

                memcpy(umxc->tx_buf +

                       (UART_XMIT_SIZE - xmit->tail), xmit->buf,

                       xmit->head);

            } else {

                memcpy(umxc->tx_buf, xmit->buf + xmit->tail,

                       tx_num);

            }

            umxc->tx_handle =

                dma_map_single(umxc->port.dev, umxc->tx_buf,

                       TXDMA_BUFF_SIZE, DMA_TO_DEVICE);

                          printk("transmitt- wintu\n");

            writechnl_request.dst_addr =

                umxc->port.mapbase + MXC_UARTUTXD;

            writechnl_request.src_addr = umxc->tx_handle;

            writechnl_request.num_of_bytes = tx_num;

            if ((mxc_dma_config

                 (dma_list[umxc->port.line].wr_channel,

                  &writechnl_request, 1,

                  MXC_DMA_MODE_WRITE)) == 0) {

                mxc_dma_enable(dma_list[umxc->port.line].

                           wr_channel);

            }

            cr1 |= MXC_UARTUCR1_TXDMAEN;

        }

    } else {

        cr1 |= MXC_UARTUCR1_TRDYEN;

    }

    writel(cr1, port->membase + MXC_UARTUCR1);

}

Now when i use ttymxc2 (UART3) /UART1 /UART0 im getting

"transmitting"

"transmit -wintu" strings displayed... which means no problem.

but when i use UART4/UART5 i.e. ttymxc4 and ttymxc3  im getting only

"transmitting"

which means its not coming in the if (umxc->dma_enabled == 1) loop at all..

which means umxc->dma_enabled is not going 1..

whats the problem ?

Regards,

   Winston



0 Kudos
408 Views
AlanZhang
Contributor V

The configurations for serial port 0 ~ 4 is defined in arch/arm/mach-mx5/serial.c file, where you change the dma_enable to 0 for both port 4 and port 5, then whether these  ports are ok now. If it works, so we will check whether  the DMA config is proper for port 4 and port 5.

Regards,

Alan Zhang

0 Kudos
408 Views
winstonrodrigue
Contributor IV

Dear Xia Zhang,

         I changed the dma_enable to 0 and tried as u said.. But no luck its same as before.

  then I changed the dma_enabled to 1 .

  Now also there is no output signals on the TX rx pins.

    But its not coming into this loop in (mxc_uart.c).

        if (xmit->tail > xmit->head) {

                memcpy(umxc->tx_buf, xmit->buf + xmit->tail,

                       UART_XMIT_SIZE - xmit->tail);

                printk("transmit-UART_XMIT\n");

                memcpy(umxc->tx_buf +

                       (UART_XMIT_SIZE - xmit->tail), xmit->buf,

                       xmit->head);

  in abovve code printk statement is not executed.

  but its coming into this if loop without any problem ....

     if ((mxc_dma_config

                 (dma_list[umxc->port.line].wr_channel,

                  &writechnl_request, 1,

                  MXC_DMA_MODE_WRITE)) == 0) {

               printk("MXC_DMA_MODE\n");

                mxc_dma_enable(dma_list[umxc->port.line].

                           wr_channel);

  in this code printk statement is executed. 

  Regards,

   Winston

0 Kudos
408 Views
AlanZhang
Contributor V

HI, Winston,

Could you insert checkpoints into :

    mxc_ports[id]->clk = clk_get(&pdev->dev, NULL);
  

if (mxc_ports[id]->clk == NULL) {

    printk("No clock for this port.\n");

  

return -1;

}

static void mxcuart_dma_tx(uart_mxc_port *umxc)

{

......

    if ((mxc_dma_config(dma_list[umxc->port.line].wr_channel,
   &writechnl_request, 1,
   MXC_DMA_MODE_WRITE)) == 0) {
  

mxc_dma_enable(dma_list[umxc->port.line].wr_channel);

printk("checkpoint 1.\n");

   }

}

static void mxcuart_dma_writecallback(void *arg, int error, unsigned int count)

{

......

}

static void mxcuart_stop_tx(struct uart_port *port)

{

}

static void mxcuart_tx_chars(uart_mxc_port *umxc)

{

}

static irqreturn_t mxcuart_int(int irq, void *dev_id)

{

     insert printk to see whether interrupt is coming up.

}


0 Kudos
408 Views
winstonrodrigue
Contributor IV

Dear Xia Zhang,

      As you suggested, I inserted printk into all of the places mentioned above.

by seeing the output.

   all of the UARTS ports are executing throgh mxcuart_dma_writecallback


and the below functions are executed only during the startup...

static void mxcuart_stop_tx(struct uart_port *port)

{

}

static void mxcuart_tx_chars(uart_mxc_port *umxc)

{

}

static irqreturn_t mxcuart_int(int irq, void *dev_id)

{

     insert printk to see whether interrupt is coming up.

}

but stil no output on UART4 and UART5.

thanks .

Winston


0 Kudos
413 Views
AlanZhang
Contributor V

Hi, Winston,

If as you said that all UART ports behave in the same way from the perspective of code flow, but no signals output on uart #4 and uart #5. So are you sure that the hardware connection are ok, and no active long low voltage on rx, tx pins at the init phase. How about the rts/cts voltage level? If all of these checklist are ok, we have to change uart4, and 5 to other alternative pins. Whether it is ok to ship one board to me?

Regards,

Alan Zhang

View solution in original post

0 Kudos
408 Views
winstonrodrigue
Contributor IV

Hi Xia Zhang,

        I think I found the problem.... Actually I have no idea if UART4 and UART5 are workng fine.. but

I have beent esting the UART4 and uart5 on J78 120 pin QTH connector on imx53_smd board.

   If i look at the schematic of the board i came to a conclusion that the UART4 and UART5 signals are not at all conneted to CPU.

picture of the J78 is attached. Screenshot.png

i.e. for UART4 -- 26th and 28th pin

           UART5 - 32 and 34th pin. which are not connected anywhere.....

So no point in testing the UART4 and UART5...

Do u have any suggestions on how can i route the UART4 and UART5 pins to some other pins on the same connector. ?

0 Kudos
408 Views
AlanZhang
Contributor V

Hi, Winston,

You referred to a wrong connector. According to IOMUX config, the nets of UART 4 and 5 are associated with the connector J12, not J78. J12 is a CSI connector that you need to be very careful to wire out nets from it. So I suggest you to prepare an real customized board that follows your hardware spec, then let discuss on that real board.

Regards,

Alan Zhang