L3 Interconnect issue when accessing ISS

Nick Thompson

Other Parts Discussed in Thread: SYSCONFIG, TWL6037

Hi,

I have an SVT OMAP5432 EVM with an ES2.0 device on it. I'm running my own Linux kernel build, built from the board_support package from TI giving me a kernel that claims to be version 3.8.4vs. The system starts up fine.

I'm trying to create an ISS driver for very basic video ingest using the ISS CPI port, but I am failing at the first hurdle (almost). My driver is built into the kernel and inits as device_initcall(init_iss). At this time in the boot sequence, as long as I have done a omap_device_enable() on the ISS, the code can read the id of the ISS.

The hwmod for ISS covers the address range:

.pa_start = 0x52000000,
.pa_end = 0x520000ff,

which is not enough the access the ISP for example. I changed the range to:

.pa_start = 0x52000000,
.pa_end = 0x5201ffff,

I added a read to my kernel from pa address 0x52010000, to read the ISP id, but this read is in a timer thread that starts when the device is opened and fires 4 jiffies later. The L3 prevents the access and omap_l3_noc.c reports a standard error to target ISS at address 0x10000. It seems I can't access the ISS id in my timer thread either.

I can't tell what the actual error is though. _After_ the noc interrupt has been handled and the error is cleared, I see the following values in the ISS TARG registers:

[ 27.734924] TARG
[ 27.736877] 400: 0x130001
[ 27.739624] 404: 0xebc493
[ 27.742370] 408: 0x1
[ 27.744689] 40c: 0x0
[ 27.746978] 410: 0xa
[ 27.749267] 414: 0x0
[ 27.751586] 418: 0x0
[ 27.753875] 41c: 0x0
[ 27.756164] 420: 0x0
[ 27.758453] 424: 0x0
[ 27.760772] 428: 0x0
[ 27.763061] 42c: 0x0
[ 27.765350] 430: 0x0
[ 27.767639] 434: 0x0
[ 27.769958] 438: 0x0
[ 27.772247] 43c: 0x0
[ 27.774536] 440: 0x2
[ 27.776824] 444: 0x2
[ 27.779144] 448: 0x0
[ 27.781433] 44c: 0x804
[ 27.783905] 450: 0x0
[ 27.786193] 454: 0xa
[ 27.788513] 458: 0x84
[ 27.790893] 45c: 0x10000
[ 27.793548] 460: 0x0
[ 27.795837] 464: 0x0
[ 27.798156] 468: 0x51
[ 27.800537] 46c: 0x0
[ 27.802825] 470: 0x0
[ 27.805114] 474: 0x0
[ 27.807434] 478: 0x0
[ 27.809722] 47c: 0x0
[ 27.812011] 480: 0x1f

There is the remains of my error at address 0x10000, but the TRM doesn't document these registers very well, so I can't tell what it's complaining about.

What else do I need to do in the kernel to allow access to the ISS "sub" devices? I guessed that the ISS device has had its clock removed, but adding a call to pm_runtime_set_active() in my open function didn't seem to help.

Thanks,

Nick.

over 10 years ago

0 Gaurav Agarwal over 10 years ago

TI__Expert 3425 points

Nick,

We appreciate your interest in OMAP5432 EVM. This question is outside the scope of this forum which is intended forOMAP5432 EVM bring-up questions.

For more support, please contact one of our recommended partners.

0 Liem To over 10 years ago

Prodigy 140 points

Hi Nick,

I'm seeing this exact error as well. I've been trying to port an ISS driver from OMAP4 to OMAP5. Have you found a solution for this yet?

Liem

0 Nick Thompson over 10 years ago in reply to Liem To

Intellectual 330 points

Hi Leim,

Yes.

It's really nothing to do with the ISS, so the response from TI above was not as useful as I might have hoped. In my case, the cause was simply that I had not turned on the device clocks and power correctly. There is a framework in the TI kernel to do this for you, for each of the devices connected to the interconnect (including the ISS).

After examining other drivers, I added calls to:

pm_runtime_enable(dev);

r = pm_runtime_get_sync(dev);
WARN_ON(r < 0);

/* do something with the device until finished */

r = pm_runtime_put_sync(dev);
WARN_ON(r < 0 && r != -ENOSYS);

I tend to do this 'runtime enable' in the probe(), the 'get sync' in a function like open() (and while probing) and the 'put sync' in a function like close() (and when finished probing).

You will also need something to link the ISS device in the device tree with your driver. My driver definition looks like:

static const struct of_device_id iss_of_match[] = {
    {
    .compatible = "ti,omap5-iss",
    },
    {},
};
MODULE_DEVICE_TABLE(of, iss_of_match);

static struct platform_driver iss_driver = {
    .probe = iss_probe,
    .remove = iss_remove,
    .driver = {
       .name = DRIVER_NAME,
       .of_match_table = of_match_ptr(iss_of_match),
    },
};

I have added a device tree entry in arch/arm/boot/dts/omap5.dtsi that looks like:

iss: iss@52000000 {
compatible = "ti,omap5-iss";
reg = <0x52000000 0x20000>;
interrupts = <0 24 0x4>;
ti,hwmods = "iss";
};

If you prefer you can also build your own device using: omap_device_build(...), for which you will need to look up the hwmod definition first using: omap_hwmod_lookup("iss");

Your case might be completely different, but this needs to be done for any device on the 'OMAP bus' - and not just the ISS.

Good luck!

Nick.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

hello Nick,

I met the same issue, seems pm_runtime_enable is not helping me, can you give me some advice pls?

I didnot add dts, but I use

omap_hwmod_lookup(iss)

omap_device_build(omap4iss...

to create the device, seems it works.

but when doing probe, I have:

/* Clocks */
ret = iss_map_mem_resource(pdev, iss, OMAP4_ISS_MEM_TOP);
if (ret < 0)
goto error;

ret = iss_get_clocks(iss);
if (ret < 0)
goto error;

in iss_get_clocks, I clk_enable iss_ctrilclk...

but next, when real ISS register (0x520000xx), l3 bus error

0 Liem To over 10 years ago in reply to Ding Ding

Prodigy 140 points

I'm still getting the L3 standard error interrupt.

I've called pm_runtime_enable() and pm_runtime_get_sync as suggested above. I do use the omap_device_build() method.

It seems like I can read/write ISS registers, but it's when I try to do an ISS soft reset (ISS_HL_SYSCONFIG[0]) that this error occurs.

I read CM_CAM_CLKSTCTRL before doing this soft reset and I got a value of 0x00000b02. According to the TRM, this should mean that CAM_GCLK, CSI_PHY_GFCLK, and CAM_GCLK are running, while CAM_L3_GICLK and FDIF_GCLK are gated.

Does CAM_L3_GICLK need to be running in order for ISS to work?

Liem

0 Nick Thompson over 10 years ago in reply to Liem To

Intellectual 330 points

Liem,

I've not had any trouble with that. Is this simply that after the reset the device goes idle and the clocks get auto gated? Have you tried doing a put_sync after asserting the reset and then a get_sync once you start using the ISS again?

As far as I can tell, the ISS is quite happy to switch itself off, unless you keep it fairly busy.

I don't access the control model anywhere in my driver.

Nick

0 Liem To over 10 years ago in reply to Nick Thompson

Prodigy 140 points

Hi Nick,

Thanks for your help. The calls to pm_runtime_xxx are not helping my situation.

What I'm trying to do is I have an ISS driver that works on an OMAP4 platform (the e-CAM51-44xx sensor board for Panda4 board), which I am (foolishly) attempting to port over to the 5AJ-1.5 SDK on the OMAP 5432 EVM.

I think my problems stem from (1) not knowing exactly what the differences are between OMAP4 and OMAP5 with regards to the ISS, and/or (2) not knowing what to port over from the Panda4 kernel to the 5AJ.1.5 kernel.

Would you happen to know what specifically changed regarding the ISS between OMAP4 and OMAP5?

So far, in addition to adding the omap4iss driver itself, I've:

1. Made changes in omap_hwmod_54xx_data.c to add the rest of the ISS memory map, and also to connect the ISS to the L3.

2. Made changes to the pin mux settings for the CSI2.

3. Changed clock_54xx_data.c to add "iss_fck" which controls the main ISS functional clock.

Liem

0 Nick Thompson over 10 years ago in reply to Liem To

Intellectual 330 points

Hi Leim,

Sorry, I've not worked with the OMAP4 much. Spent a lot of time reading the OMAP5 TRM, in the ISS chapter :)

I haven't modified my kernel at all. I'm using the Linux 3.8.4vs straight from the TI GLSDK. The clock management for ISS is already builtin to that.

The ISS memory mapping wasn't big enough in the hwmod file I have, but I've ignored that and defined the mapping in the device-tree. Hence no need to touch the kernel.

I'm using the CPI port of the camera interface. The pinmux settings are configured in the device-tree as well.

I'm planning on updating to the newer GLSDK kernel soon.

Nick.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

hello guys,

finally I can access ISS registers and reset ISS, previously the mistake was caused by ES1.0 TRM, the ISS registers offset have changed to +3000 on ES2.0.

and I am doing CPI driver on GLSDK now. so far the v4l2 and subdev framework is done, next step I will debug sensor and get the date in.

@nick, what's your progress pls? may I know more details of your concern about ISS memory mapping modificaiotn.

thanks

ding D

0 Liem To over 10 years ago in reply to Ding Ding

Prodigy 140 points

Hi Ding,

Can you elaborate on this register offset change? I have an OMAP5432 EVM board from SVT, which is supposed to have the ES2.0 device. Are you saying the ISS register base is not at 0x52000000, but instead should be 0x52003000? Can you tell me what value you get when reading ISS_HL_REVISION (offset 0)? Reading this at 0x52000000, I get 0x40000202.

Liem

0 Nick Thompson over 10 years ago in reply to Liem To

Intellectual 330 points

Leim,

I see that same value at that address. I'm pretty sure the address you gave is correct.

My only concern was that the hwmod information only specified the size of the memory mapping to be big enough for the ISS HL registers and not the ISP, RSZ, IPIPEIF, etc, etc. I map all of that in one single mapping.

I pick up the size from the device tree now though, so the hwmod info is not important to me. What is in there is enough to switch on the power and clocks and that is all I need from it.

I do have video coming into memory over the CPI port, but I don't do V4L. Our requirements are kind of different and ingesting complete frames is not always interesting to us. It's not a port of any other driver and generates multiple video streams.

Currently I'm using the SVT for development board as well.

Nick.

0 Liem To over 10 years ago in reply to Nick Thompson

Prodigy 140 points

FYI,

Well at least I got past my ISS reset problem now. Found out that there needs to be some OCP clock cycles of delay after setting the soft reset ISS_HL_SYSCONFIG[0] bit, before I can read any ISS register again.

Now I believe I'm running into some problems with the power management system. My ISS driver initializes OK, and after the kernel finishes booting, Android will boot, and will initialize the kernel to its highest power state, e.g. and initial wakeup:

request_suspend_state: wakeup (3->0) at 14119444340 (2000-01-01 04:09:23.551774416 UTC)

For some reason, it looks like this doesn't succeed (due to my ISS driver changes) and Android can't get past the boot animation screen and into the home screen.

Liem

0 Ding Ding over 10 years ago in reply to Liem To

TI__Prodigy 515 points

hello guys,

ISS register is the same as ES1.0, my previous problem is from clock register offset.

btw, do you guys succeed to get the parallel interface sensor date from VP prot?

I get everything ready, but cannot get the interrupt from IPIPEIF_IRQ

H, V, pclk is working normally from sensor, But Vport of ISS still cannot recognize the input frame,

Pinmux is right, I can enable HS_VS_IRQ to get the H/V interrupt,

But IPIPEIF_IRQ is not coming.

Strange thing is, if I connect pclk to ground, the IPIPEIF_IRQ is coming.

any idea pls?

Do you have any experience and suggestions pls?

0 Ding Ding over 10 years ago in reply to Ding Ding

TI__Prodigy 515 points

helo nick

really need your helping hand pls, from email history, I saw you have make CPI sensor workign on omap5.

I am stuck at Vport for one week,

if I switch the input of IPIPEIF from VP to DDR, all thing is working, IPIPEIF_IRQ and ISIF_VDINT0 interrupt is coming.

my v4l2 applicatoion can get the data, the whole flow is working.

when I switch to Vport,no any interrupt, I even tried other sensor with good H/V/Pclk, not working.

I share my register dump, really appreciate if you can give some hints.

[ 54.874328] omap4iss omap4iss: ###CPI ISS_HL_SYSCONFIG=0x00000028

[ 54.880889] omap4iss omap4iss: ###CPI ISS_HL_IRQSTATUS_5=0x00000000

[ 54.887481] omap4iss omap4iss: ###CPI ISS_HL_IRQENABLE_5_SET=0x0000000f

[ 54.894470] omap4iss omap4iss: ###CPI ISS_CTRL=0x0000000e

[ 54.900207] omap4iss omap4iss: ###CPI ISS_CLKCTRL=0xfc000002

[ 54.906188] omap4iss omap4iss: ###CPI ISS_CLKSTAT=0xfc000002

[ 54.912200] omap4iss omap4iss: ###CPI ISS_PM_STATUS=0x00002880

[ 54.918334] omap4iss omap4iss: ###CPI ISP_IRQSTATUS=0x00000000

[ 54.924499] omap4iss omap4iss: ###CPI ISP_IRQENABLE=0x00000201

[ 54.930694] omap4iss omap4iss: ###CPI ISP_SYSCONFIG=0x00000021

[ 54.936859] omap4iss omap4iss: ###CPI ISP_CTRL=0x4220fff1

[ 54.942535] omap4iss omap4iss: ###CPI ISP_IRQENABLE2=0x00000008

[ 54.948822] omap4iss omap4iss: ###CPI ISIF_SYNCEN=0x00000003

[ 54.954803] omap4iss omap4iss: ###CPI ISIF_MODESET=0x00000000

[ 54.960906] omap4iss omap4iss: ###CPI ISIF_CGAMMAWD=0x0000000a

[ 54.967102] omap4iss omap4iss: ###CPI ISIF_SPH=0x00000010

[ 54.972778] omap4iss omap4iss: ###CPI ISIF_LNH=0x000002ef

[ 54.978485] omap4iss omap4iss: ###CPI ISIF_SLV0=0x00000000

[ 54.984313] omap4iss omap4iss: ###CPI ISIF_LNV=0x000001df

[ 54.989990] omap4iss omap4iss: ###CPI ISIF_HSIZE=0x00000018

[ 54.995880] omap4iss omap4iss: ###CPI ISIF_VDINT=0x000001db

[ 55.001800] omap4iss omap4iss: ###CPI ISIF_CADU=0x00000000

[ 55.007598] omap4iss omap4iss: ###CPI ISIF_CADL=0x00000000

[ 55.013366] omap4iss omap4iss: ###CPI IPIPEIF_CFG1=0x00000000

0 Nick Thompson over 10 years ago in reply to Ding Ding

Intellectual 330 points

Hi Ding,

If you're not getting IPIPEIF_IRQ, then your problem is probably in ISS, ISP or IPIPEIF config. Here is my init code...

ISS:

	iss_write32((ISS_TOP_CTRL_INPUT_SEL_CPI |
		     ISS_TOP_CTRL_SYNC_DETECT_VS_R),
		    &iss_top->ctrl);

	iss_write32(ISS_TOP_CLKCTRL_VPORT3_CLK,
		    &iss_top->clkctrl);

ISP:

	iss_write32(ISP_SYS1_SYSCONFIG_STANDBY_MODE |
		    ISP_SYS1_SYSCONFIG_SOFTRESET,
		    &isp_sys1->sysconfig);

	msleep(100);

	ctrl = iss_read32(&isp_sys1->ctrl);
	ctrl |= ISP_SYS1_CTRL_PSYNC_CLK_SEL;
	ctrl |= ISP_SYS1_CTRL_BL_CLK_EN;
	ctrl |= ISP_SYS1_CTRL_SYNC_EN;
	ctrl &= ~(ISP_SYS1_CTRL_VD_PULSE_EXT);
	iss_write32(ctrl, &isp_sys1->ctrl);

and IPIPEIF:

	iss_write32(ISP_IPIPEIF_CFG1_INPSRC2_ISIF |
		    ISP_IPIPEIF_CFG1_INPSRC1_VPORT_RAW |
		    ISP_IPIPEIF_CFG1_CLKSEL_VPORT, &ipipeif->cfg1);

	iss_write32(0, &ipipeif->clkdiv);

	iss_write32(ISP_IPIPEIF_CFG2_YUV16, &ipipeif->cfg2);

This is all I have setup, except for the IRQ setups and clock enable bits. Your cfg1 setting in IPIPEIF looks wrong to me...

I hope that helps.

Nick.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

thanks nick very much

IPIPEIF CFG1 in my setting is 0x0, my idea is inpsrc1 is vport, inpsrc2 is ISIF,clksel is from vport, could you point me where I go wrong pls? and what;s your value of CFG1 pls?

and

your setting almost same as mine, just one thing pls help to clarify,

I saw in your seting.

ISS:

        iss_write32((ISS_TOP_CTRL_INPUT_SEL_CPI |

                    ISS_TOP_CTRL_SYNC_DETECT_VS_R),

                   &iss_top->ctrl);

        iss_write32(ISS_TOP_CLKCTRL_VPORT3_CLK,

                   &iss_top->clkctrl);

//dd: no need to enable bit 1, ISP clk? btw, in my environment I alwasy saw this regiter is 0xfcxxxxxxxx, seems high 6bit is fixed, cannot be cleared.

ISP:

        iss_write32(ISP_SYS1_SYSCONFIG_STANDBY_MODE |

                   ISP_SYS1_SYSCONFIG_SOFTRESET,

                   &isp_sys1->sysconfig);

 //dd: after softrest, ISP CTR register should be set on standby bit, no need to set ctrl register to go from idle to normal?

        msleep(100);

        ctrl = iss_read32(&isp_sys1->ctrl);

        ctrl |= ISP_SYS1_CTRL_PSYNC_CLK_SEL;

        ctrl |= ISP_SYS1_CTRL_BL_CLK_EN;

        ctrl |= ISP_SYS1_CTRL_SYNC_EN;

        ctrl &= ~(ISP_SYS1_CTRL_VD_PULSE_EXT);

        iss_write32(ctrl, &isp_sys1->ctrl);

//dd: do we need to set up bit 14, ISIF_clk_enable?

and IPIPEIF:

        iss_write32(ISP_IPIPEIF_CFG1_INPSRC2_ISIF |

                   ISP_IPIPEIF_CFG1_INPSRC1_VPORT_RAW |

                   ISP_IPIPEIF_CFG1_CLKSEL_VPORT, &ipipeif->cfg1);

        iss_write32(0, &ipipeif->clkdiv);

 //DD: is it necessary to set clkdiv, seems it is used for internal pclk

        iss_write32(ISP_IPIPEIF_CFG2_YUV16, &ipipeif->cfg2);

0 Nick Thompson over 10 years ago in reply to Ding Ding

Intellectual 330 points

Ding,

Thanks for your comments, I will take a look at those. My ipipeif->cfg1 is posted above. Here it is:

       iss_write32(ISP_IPIPEIF_CFG1_INPSRC2_ISIF |
                   ISP_IPIPEIF_CFG1_INPSRC1_VPORT_RAW |
                   ISP_IPIPEIF_CFG1_CLKSEL_VPORT, &ipipeif->cfg1);

You are correct, that equates to a value of zero.

You do need to set the ISIF clock on to use it. I have that elsewhere:

	ctrl = iss_read32(&isp_sys1->ctrl);
	ctrl |= ISP_SYS1_CTRL_ISIF_CLK_EN;
	iss_write32(ctrl, &isp_sys1->ctrl);

You also might need:

	iss_write32(ISS_ISIF_MODESET_CCDMD_P |
		    ISS_ISIF_MODESET_IMPMOD_YUV16 |
		    ISS_ISIF_MODESET_SWEN,
		    &isif->modeset);

On the H/W side we also have to driver the WEN pin. It actually just mirrors HSYNC. I'm not sure any of that is relevant in terms of getting the IPIPEIF_IRQ to tigger though.

Nick.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

I almost tried again with your setting, still not work,

strange thing is that only if I pull low to pclk, IPIPEIF_IRQ is coming. but with frequency clock, it doesnot work,

btw, have you tried to disable SWEN, means "not used WEN"?

my sensor has no this pin, why you are using this bit and this pin pls?

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

btw, nick, do you have a email, may I send my codes, you can help to check pls?

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

hello nick,

could you do me a favor pls? I check my "omapconf show prcm cam" during the running.

Is it in line with yours pls?

thanks very much

|----------------------------------------------------------------|
| CAM Clock Domain Configuration                                 |
|--------------------------------------|-------------------------|
| Clock State Transition control       | SW-Forced Wakeup        |
|   CAM_L3_GIFCLK                      | Gated                   |
|   CAM_BOOST_GCLK                     | Running                 |
|   FDIF_GCLK                          | Gated                   |
|   CSI_PHY_GFCLK                      | Gated                   |
|   CAM_GCLK                           | Running                 |
|----------------------------------------------------------------|

0 Nick Thompson over 10 years ago in reply to Ding Ding

Intellectual 330 points

I don't have that utility. I have tracked down the source and it looks useful to have - I might add it to our full custom linux setup for development testing and could then send you the information - this may take a little while.

I also have an ubuntu setup I can boot from, do you know if there is a package for "omapconf"? If there is I can probably get you the information fairly quickly.

Regrets, but I can't offer you consultancy on your code source code.

Nick.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

I can share w/ you, omapconf is in GLSDK by default since omap4.

by the way, I use omapconf to make very simple sequence to set the registers, but still not work. can you help to checek if they are working on your environment pls?

omapconf write 0x4a009300 0x00000002

omapconf write 0x4a009320 0x00000002

omapconf write 0x52000010 0x3c

omapconf write 0x52000080 0x2e

omapconf write 0x52000084 0x80000002

omapconf write 0x52000078 0x2000f

omapconf write 0x52010010 0x21

omapconf write 0x5201002c 0x201

omapconf write 0x5201006c 0xfff8

after that, suppose to get 0x200 from "omapconf read 0x52010024'

0 Ding Ding over 10 years ago in reply to Ding Ding

TI__Prodigy 515 points

2330.omapconf.7z

0 Nick Thompson over 10 years ago in reply to Ding Ding

Intellectual 330 points

Thanks. Nice tool.

I see:

|----------------------------------------------------------------|
| CAM Power Domain Configuration                                 |
|----------------------------------------------------------------|
| Power State                      | Current | Target  | Last    |
|----------------------------------|---------|---------|---------|
| Domain                           | ON      | ON      | OFF     |
| Logic                            | ON      |         |         |
| Memory                           |         |         |         |
|     MEM                          | ON      |         |         |
|----------------------------------------------------------------|
| Ongoing Power Transition?        | NO                          |
|----------------------------------------------------------------|

|----------------------------------------------------------------|
| CAM Clock Domain Configuration                                 |
|--------------------------------------|-------------------------|
| Clock State Transition control       | SW-Forced Wakeup        |
|   CAM_L3_GIFCLK                      | Gated                   |
|   CAM_BOOST_GCLK                     | Running                 |
|   FDIF_GCLK                          | Gated                   |
|   CSI_PHY_GFCLK                      | Gated                   |
|   CAM_GCLK                           | Running                 |
|----------------------------------------------------------------|

|------------------------------------------------------------------------|
| FDIF Module Configuration                                              |
|----------------------------------|-------------------------------------|
| Source Clock                     | FDIF_GFCLK                          |
| Source Clock Rate                | 64.000MHz                           |
| Mode                             | Disabled (NO ACCESS)                |
| Idle Status                      | Disabled (NO ACCESS)                |
| Standby Status                   | In Standby                          |
| FDIF_CLK Ratio                   | FDIF_CLK = FUNC_128M_CLK / 1        |
| Context                          | Retained                            |
|------------------------------------------------------------------------|

|------------------------------------------------------------------------|
| ISS Module Configuration                                               |
|----------------------------------|-------------------------------------|
| Source Clock                     | CORE_ISS_MAIN_CLK                   |
| Source Clock Rate                | 304.000MHz                          |
| Mode                             | Enabled (EXPLICITLY)                |
| Idle Status                      | Full ON                             |
| Standby Status                   | Functional                          |
| Optional functional clock        | Disabled                            |
| Context                          | Retained                            |
|------------------------------------------------------------------------|

|------------------------------------------------------------------------|
| CAL Module Configuration                                               |
|----------------------------------|-------------------------------------|
| Source Clock                     | CAM_L3_GICLK                        |
| Source Clock Rate                | 266.000MHz                          |
| Mode                             | Disabled (NO ACCESS)                |
| Idle Status                      | Disabled (NO ACCESS)                |
| Standby Status                   | Not Available (does not exist)      |
| Context                          | Lost                                |
|------------------------------------------------------------------------|

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

thanks nick, it is got during CPI running, right pls? it is the same as mine.

can you pls help a little more?

can you have a trial with my previous omapconf sequence pls? and point out what mistake I made pls.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

hello nick,

finally I found it is related to WEN pin, seems it is necessary for IPIPEIF to work.

but my sensor has not this pin output,

do you know what's the requirment for WEN signal, I didot found it in TRM.

and how you mirror HD pls

your comment really help me a lot.

thanks

ding ding

0 Nick Thompson over 10 years ago in reply to Ding Ding

Intellectual 330 points

Yes, I think this caught me out as well.

In our system, the "camera" is an FPGA and it provides the WEN signal. It is identical to our H-SYNC as we don't use a short pulsed H-SYNC signal, but leave it active until the last valid pixel of the line is received. This is identical behaviour to what WEN should do (assuming all your video data is valid video).

WEN can be used to ignore invalid video data from your camera device (in band signalling, or embedded control codes for example). Also, with a short H-SYNC pulse (one or two pixels, say), WEN gates the invalid video data at the end of the line, if the pixel clock continues to run.

Glad to hear you have made progress.

Nick.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

thanks nick,

I am not using a puled H-SYNC either, I am thinking why not we keep WEN always high.

what do you think pls?

and another question, can I just connect H-SYNC to WEN, is it supposed to be the same as your environment, right pls?

and one more questions, how do you deal with FID pin? input or output? float or connect to where pls?

0 Nick Thompson over 10 years ago in reply to Ding Ding

Intellectual 330 points

I think you should try to connect H-SYNC to WEN. Keeping WEN high I don't think will work well with the extra PCLKS expected by the OMAP. You could try it though, as long as you set the resolution correctly.

We don't have any video interlacing so FID is not used here.

0 Ding Ding over 10 years ago in reply to Nick Thompson

TI__Prodigy 515 points

hello nick,

may I know your OMAP5 is ES1.0 or ES2.0 pls?

and what's the frequency of your PCLK pls? I found my pclk only work at less than 4Mhz.

thanks very much

ding ding

0 Nick Thompson over 10 years ago in reply to Ding Ding

Intellectual 330 points

Ding,

Linux says its an ES2.0. PCLK is running at the speed of DVI at 1024x768p60, though I have run it a 1280x1024p60 as well. That's about 76MHz.

Did you look at ISS_CTRL.ISS_CLK_DIV? Mine it set to zero. It's also worth checking for noise on the clock line.

Nick.

0 Liem To over 10 years ago in reply to Nick Thompson

Prodigy 140 points

Do you guys see anything wrong with my output of "omap show prcm cam" and "omap dump prcm cam" 
below?  I'm trying to get the CSI2 working and I've got the camera sensor running and streaming
data, but am not getting an interrupt from the CSI2 indicating it received anything.


|----------------------------------------------------------------|
| CAM Power Domain Configuration                                 |
|----------------------------------------------------------------|
| Power State                      | Current | Target  | Last    |
|----------------------------------|---------|---------|---------|
| Domain                           | ON      | OFF     | ON      |
| Logic                            | ON      |         |         |
| Memory                           |         |         |         |
|     MEM                          | ON      |         |         |
|----------------------------------------------------------------|
| Ongoing Power Transition?        | NO                          |
|----------------------------------------------------------------|

|----------------------------------------------------------------|
| CAM Clock Domain Configuration                                 |
|--------------------------------------|-------------------------|
| Clock State Transition control       | SW-Forced Wakeup        |
|   CAM_L3_GIFCLK                      | Gated                   |
|   CAM_BOOST_GCLK                     | Running                 |
|   FDIF_GCLK                          | Gated                   |
|   CSI_PHY_GFCLK                      | Running                 |
|   CAM_GCLK                           | Running                 |
|----------------------------------------------------------------|

|------------------------------------------------------------------------|
| FDIF Module Configuration                                              |
|----------------------------------|-------------------------------------|
| Source Clock                     | FDIF_GFCLK                          |
| Source Clock Rate                | 64.000MHz                           |
| Mode                             | Disabled (NO ACCESS)                |
| Idle Status                      | Disabled (NO ACCESS)                |
| Standby Status                   | In Standby                          |
| FDIF_CLK Ratio                   | FDIF_CLK = FUNC_128M_CLK / 1        |
| Context                          | Lost                                |
|------------------------------------------------------------------------|

|------------------------------------------------------------------------|
| ISS Module Configuration                                               |
|----------------------------------|-------------------------------------|
| Source Clock                     | CORE_ISS_MAIN_CLK                   |
| Source Clock Rate                | 304.000MHz                          |
| Mode                             | Enabled (EXPLICITLY)                |
| Idle Status                      | Full ON                             |
| Standby Status                   | Functional                          |
| Optional functional clock        | Enabled                             |
| Context                          | Lost                                |
|------------------------------------------------------------------------|

|------------------------------------------------------------------------|
| CAL Module Configuration                                               |
|----------------------------------|-------------------------------------|
| Source Clock                     | CAM_L3_GICLK                        |
| Source Clock Rate                | 266.000MHz                          |
| Mode                             | Disabled (NO ACCESS)                |
| Idle Status                      | Disabled (NO ACCESS)                |
| Standby Status                   | Not Available (does not exist)      |
| Context                          | Lost                                |
|------------------------------------------------------------------------|

shell@android:/ #
shell@android:/ # omapconf dump prcm cam
OMAPCONF (rev 1.68 built Wed Oct 16 04:13:08 IST 2013)

HW Platform:
  Omap5panda
  OMAP5432 ES2.0 GP Device (STANDARD performance (1.5GHz))
  TWL6035  ES UNKNOWN (EPROM rev3.0)
  TWL6040  ES1.2

SW Build Details:
  Build:
    Version: full_omap5panda-userdebug 4.2.2 JDQ39 eng.liem.20131023.171552 test-keys
    Pastry: Jelly Bean
    Type: userdebug
    Date: Wed Oct 23 17:17:42 PDT 2013

  Kernel:
    Version: 3.4.34
    Author: liem@android-dev
    Toolchain: gcc version 4.6.x-google 20120106 (prerelease) (GCC)
    Type: #114 SMP PREEMPT
    Date: Fri Dec 6 15:38:40 PST 2013

|-------------------------------------------------|
| PRM CAM Reg. Name   | Reg. Address | Reg. Value |
|-------------------------------------------------|
| PM_CAM_PWRSTCTRL    | 0x4AE07300   | 0x00030000 |
| PM_CAM_PWRSTST      | 0x4AE07304   | 0x03000037 |
| RM_CAM_ISS_CONTEXT  | 0x4AE07324   | 0x00000101 |
| RM_CAM_FDIF_CONTEXT | 0x4AE0732C   | 0x00000101 |
| RM_CAM_CAL_CONTEXT  | 0x4AE07334   | 0x00000101 |
|-------------------------------------------------|

|---------------------------------------------------|
| CM CORE CAM Reg. Name | Reg. Address | Reg. Value |
|---------------------------------------------------|
| CM_CAM_CLKSTCTRL      | 0x4A009300   | 0x00000B02 |
| CM_CAM_STATICDEP      | 0x4A009304   | 0x00000040 |
| CM_CAM_DYNAMICDEP     | 0x4A009308   | 0x00000000 |
| CM_CAM_ISS_CLKCTRL    | 0x4A009320   | 0x00000102 |
| CM_CAM_FDIF_CLKCTRL   | 0x4A009328   | 0x00070000 |
| CM_CAM_CAL_CLKCTRL    | 0x4A009330   | 0x00030000 |
|---------------------------------------------------|

0 Liem To over 10 years ago in reply to Liem To

Prodigy 140 points

Whoops, messed up the formatting. I meant to ask:

Do you guyse see anything wrong with my output of "omap show prcm cam" and "omap dump prcm cam?" I'm trying to get the CSI2 working, and I've got the camera sensor running and streaming data, but am not getting an interrupt from the CSI2 indicating it received anything

0 Ding Ding over 10 years ago in reply to Liem To

TI__Prodigy 515 points

look fine for me, suggest to check whether phy power is provided correctly from PMU.

0 Liem To over 10 years ago in reply to Ding Ding

Prodigy 140 points

Hi Ding, thanks for the suggestion. How precisely can I check this? FYI, here are some relevant register dumps. You'll see that CSI2_COMPLEXIO_CFG(0x52001050) = 0x4a000021. This shows that PWR_CMD[28:27] and PWR_STATUS[26:25] are both 0x1, indicating power to the PHY is on. However, RESET_DONE[29] is 0x0, indicating that the module is still ongoing reset. Do you know if this is a problem?

Thanks.

CONTROL_CAMERA_RX:                                      0x4A002E08 = 0x00C018F9
CONTROL_CORE_PAD0_CSIPORTA_LANE0X_PAD1_CSIPORTA_LANE0Y: 0x4A002958 = 0x01000100
CONTROL_CORE_PAD0_CSIPORTA_LANE1X_PAD1_CSIPORTA_LANE1Y: 0x4A00295C = 0x01000100
CONTROL_CORE_PAD0_CSIPORTA_LANE2X_PAD1_CSIPORTA_LANE2Y: 0x4A002960 = 0x01000100


CSI2_SYSCONFIG:               0x52001010 = 0x00001000
CSI2_SYSSTATUS:               0x52001014 = 0x00000001
CSI2_IRQSTATUS:               0x52001018 = 0x00000000
CSI2_IRQENABLE:               0x5200101c = 0x00007b01
CSI2_CTRL:                    0x52001040 = 0x00292111
CSI2_DBG_H:                   0x52001044 = 0x00000000
CSI2_COMPLEXIO_CFG:           0x52001050 = 0x4a000021
CSI2_COMPLEXIO_IRQSTATUS:     0x52001054 = 0x00000000
CSI2_SHORT_PACKET:            0x5200105c = 0x00000000
CSI2_COMPLEXIO_IRQENABLE:     0x52001060 = 0x07ffffff
CSI2_DBG_P:                   0x52001068 = 0x00000000
CSI2_TIMING:                  0x5200106c = 0x7fffe1ff
CSI2_CTX_CTRL1(0):            0x52001070 = 0x000003c9
CSI2_CTX_CTRL2(0):            0x52001074 = 0x00000022
CSI2_CTX_DAT_OFST(0):         0x52001078 = 0x00000000
CSI2_CTX_PING_ADDR(0):        0x5200107c = 0x93300000
CSI2_CTX_PONG_ADDR(0):        0x52001080 = 0x93300000
CSI2_CTX_IRQENABLE(0):        0x52001084 = 0x00000002
CSI2_CTX_IRQSTATUS(0):        0x52001088 = 0x00000000
CSI2_CTX_CTRL3(0):            0x5200108c = 0x00000000

ISS_HL_REVISION:              0x52000000 = 0x40000202
ISS_HL_SYSCONFIG:             0x52000010 = 0x00000014
ISS_HL_IRQSTATUS_RAW_5:       0x52000070 = 0x00000000
ISS_HL_IRQSTATUS_5:           0x52000074 = 0x00000000
ISS_HL_IRQENABLE_5_SET:       0x52000078 = 0x00000031
ISS_HL_IRQENABLE_5_CLR:       0x5200007c = 0x00000031
ISS_CTRL:                     0x52000080 = 0x00000000
ISS_CLKCTRL:                  0x52000084 = 0xfc000006
ISS_CLKSTAT:                  0x52000088 = 0xfc000006

0 Liem To over 10 years ago in reply to Liem To

Prodigy 140 points

OK, I finally fixed my problem. It turns out that the LDO1 output from the TWL6037 PMIC was not being properly configured and enabled. This LDO provides the power to the CSI PHY (vdda_csiporta, b, and c).

In the 5AJ.1.5 SDK, in the file kernel/android-3.4/arch/arm/mach-omap2/board-omap5panda.c, I made the following changes:

static struct regulator_init_data omap5_ldo1 = {
	.constraints = {
		//.min_uV		= 2800000,
		//.max_uV		= 2800000,
		.min_uV			= 1800000,
		.max_uV			= 1800000,
		.valid_modes_mask	= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY,
		.valid_ops_mask		= REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS,
		.apply_uV		= 1,
	},
};

The default min and max voltages were changed from 2.8V to 1.8V, per OMAP5432 datasheet. The "apply_uV" flag was set to indicated to the Linux regulator driver to configure this voltage at init time.

Then in my ISS driver, I call this:

iss->vddaphy_cam = regulator_get(&pdev->dev, "LDO1");

Then when I want to use the ISS, I call

regulator_enable(iss->vddaphy_cam);

And when I'm done with it, to save power:

regulator_disable(iss->vddaphy_cam);

Liem

0 Marc B. over 9 years ago in reply to Nick Thompson

Prodigy 100 points

Hi guys,

Do you have the settings from the CONTROL_CAMERA_RX(0x4A10 0608) register to support CPI ?

I am using an OMAP4460 platform. The TRM specifies the following:

The Parallel interface (CPI), CCP2, and CSI2-B share pins. Their modes are not supported
as a pin configuration mux option. The modes are configured from the CSI2-B/CCP2
CAMERARX configured from the system control module (see Chapter 18, Control Module).

On the OMAP5, this register is at 0x4A00 2E08, but I believe more is required to correctly mux CPI pins.

Any help would be greatly appreciated,

Thanks,

Marc

0 Nick Thompson over 9 years ago in reply to Marc B.

Intellectual 330 points

The OMAP5 manual says something similar. When using the serial pins you do have to configure lane assignments in the CAMERA_RX register. Using the CPI, I haven't had to set the register to anything. I added this to the device tree:

	camcpi_pins: pinmux_camcpi_pins {
		pinctrl-single,pins = <
			0x104 0x103	/* cpi_data9 INPUT | MODE 3 */
			0x106 0x103	/* cpi_data8 INPUT | MODE 3 */
			0x108 0x103	/* cpi_data11 INPUT | MODE 3 */
			0x10a 0x103	/* cpi_data10 INPUT | MODE 3 */
			0x10c 0x104	/* cpi_data12 INPUT | MODE 4 */
			0x10e 0x104	/* cpi_data13 INPUT | MODE 4 */
			0x110 0x104	/* cpi_data15 INPUT | MODE 4 */
			0x112 0x104	/* cpi_data14 INPUT | MODE 4 */
			0x114 0x104	/* cpi_vsyncin INPUT | MODE 4 */
			0x116 0x104	/* cpi_hsyncin INPUT | MODE 4 */
			0x118 0x103	/* cpi_pclk INPUT | MODE 3 */
			0x11a 0x103	/* cpi_wen INPUT | MODE 3 */
			0x11c 0x103	/* cpi_data1 INPUT | MODE 3 */
			0x11e 0x103	/* cpi_data0 INPUT | MODE 3 */
			0x120 0x103	/* cpi_data3 INPUT | MODE 3 */
			0x122 0x103	/* cpi_data2 INPUT | MODE 3 */
			0x124 0x103	/* cpi_data4 INPUT | MODE 3 */
			0x126 0x103	/* cpi_data5 INPUT | MODE 3 */
			0x128 0x103	/* cpi_data6 INPUT | MODE 3 */
			0x12a 0x103	/* cpi_data7 INPUT | MODE 3 */
			0x130 0x103	/* cpi_fid INPUT | MODE 3 */
		>;
	};

That seems to be fine for my usage. Make sure you select the correct pins for V and H sync. There is a choice - you need to set the correct ones for your H/W. Make sure you have the LDO or other power supply switched on for the camera I/O pins that have there own power supply. See post above about LDO.

Nick.

Processors

Processors forum

L3 Interconnect issue when accessing ISS