• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 152 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5718: Does VIP change the CTRL_CORE_VIP_MUX_SELECT

Krishna Vashistha
Intellectual 770 points
Part Number: AM5718
Other Parts Discussed in Thread: AM5728

Dear Team,

We read the TRM of am5718 for a camera specific problem.

It is said on page 128 of TRM:-

If the CTRL_CORE_VIP_MUX_SELECT[6:4] VIP_SEL_1A bit field is set to 0x1 (GROUP5A pads) the
vin1a_clk0 signal can be mapped to the gpio6_10 device pad after the
CTRL_CORE_PAD_GPIO6_10[3:0] GPIO6_10_MUXMODE bit field has been set to 0x9.

We are using group5a pad for vin1a port.

But if check the Table 18-1054. CTRL_CORE_VIP_MUX_SELECT

at address 0x4A00 2E8C (ie using devmem2 0x4A00 2E8C)

we get 0x0000000.

Our question is, does VIP or any other driver set that register address indeed.

We also cross examine for am5728 TRM there is not any CTRL_CORE_VIP_MUX_SELECT.

We are able to capture on vin1a port if the SOC is am5728 but failed to perform same with am5718  SOC.

So any difference in the driver (VIP, VPDMA) configuration for both SOC?

Regards

Krishna Vashistha

  • 0
    TI__Guru**** 398480 points

    Hi Krishna,

    Krishna Vashistha said:
    Our question is, does VIP or any other driver set that register address indeed.

    Really doubt that the driver is setting this register, could you please try setting it from the userspace?

    Krishna Vashistha said:
    So any difference in the driver (VIP, VPDMA) configuration for both SOC?

    No, from VIP and VPDMA functionality point of view, there are no changes. There could be changes in the control module, like the one you figured out about mux_selection. But once this is taken care and pinmux is setup correctly for these pins, it should work fine with the same driver. 

    Rgds,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 770 points

    Dear Brijesh,

    Thank you for the answer.

    You said:

    There could be changes in the control module, like the one you figured out about mux_selection. But once this is taken care and pinmux is setup correctly for these pins, it should work fine with the same driver. 

    Which control module is there?

    What I understand that the pinmux gets configured at u-boot.

    (i.e. in mux_data.h)

    Should It be configured in kernel stage too?

    (i.e. to add pinctrl property in device tree)

    Regards

    Krishna Vashistha

  • 0 in reply to Krishna Vashistha
    Intellectual 770 points

    Dear Brijesh,

    The issue has been resolved.

    It is found that there is no register access for CTRL_CORE_VIP_MUX_SELECT in

    vip.h.

    On reset it sets the all bits to 0x0 (as per TRM), that's why we got 0x00000000 while checking the physical address.

    By changing the register bit according to our pinmux from user space,

    It attempts capture operation.

    Thank you to be with us.

    Regards

    Krishna Vashistha