OMAP4 Dallas 1W

Hi,

The 1-Wire IP on OMAP4 is the same as OMAP3 so the current driver for OMAP3 should work also on OMAP4.

Can you try to use the OMAP3 driver (setting CONFIG_HDQ_MASTER_OMAP ?) ?

Regards,

Hi,

thanks for your answer. I have done this already. The resulting driver doesn't start. It fails in getting clock ick.

[    4.894073] omap_hdq_probe: hw init start
[    4.898651] omap_hdq_probe: pdev name omap_hdq
[    4.903686] omap_hdq_probe: Can't get HDQ ick clock object
[    4.909881] omap_hdq: probe of omap_hdq.0 failed with error -2

Because I am a beginner I currently not know how to get the clock ick working.

There exists a kernel version 3.10 from linaro which can be configured to use the HDQ for all OMAP devices. It also uses pm.
I will try to use that driver in kernel 3.4.34 from omappedia.

Best regards,
Roman

It seems that the interface clock (ick) for HDQ/1-wire is missing in the omap4 clock data, only fck is present.

You can try to add it in arch/arm/mach-omap2/clock44xx_data.c. Take a look at other ick clocks to know how to do it.

Roughly I will add :

static struct clk hdq1w_ick = {
.name = "hdq1w_ick",
.ops = &clkops_omap4_dflt_wait,
.enable_reg = OMAP4430_CM_L4PER_HDQ1W_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = "l4_per_clkdm",
.parent = &l4_div_ck,
.recalc = &followparent_recalc,
.speculate = &omap2_clksel_speculate,
};

 and add  the following entry in omap44xx_clks structure : 

CLK("omap2_hdq.0", "ick", &hdq1w_ick, CK_44XX),

Regards,

Hi all,

I inserted the clock entry for hdq1w_ick like described in the last mail. I disabled the following entry in arch/arm/mach-omap2/clock44xx_data.c:
CLKDEV_INIT(NULL, "hdq1w_fck", &hdq1w_fck)

After this I inserted the following two entries:
CLKDEV_INIT("omap_hdq.0", "ick", &hdq1w_ick),
CLKDEV_INIT("omap_hdq.0", "fck", &hdq1w_fck),

Now the functions for getting the ick and the fck clock (file omap_hdq.c ) return without errors. I doesn't know if it works, because I shipped into the next problem.

The call of hdq_reg_in(hdq_data, OMAP_HDQ_REVISION) located in omap_hdq_probe gives me the following kernel dump:

[ 4.912902] omap_hdq_probe: ++
[ 4.916412] ------------[ cut here ]------------
[ 4.921630] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113 l3_interrupt_handler+0xc0/0x168()
[ 4.931274] L3 custom error: MASTER:MPU TARGET:L4 PER2
[ 4.936981] Modules linked in:
[ 4.940490] Backtrace:
[ 4.943359] [<c0017c14>] (dump_backtrace+0x0/0x10c) from [<c0651820>] (dump_stack+0x18/0x1c)
[ 4.952728] r6:00000071 r5:c0039770 r4:d682fca8 r3:c094e950
[ 4.959472] [<c0651808>] (dump_stack+0x0/0x1c) from [<c0046064>] (warn_slowpath_common+0x54/0x6c)
[ 4.969329] [<c0046010>] (warn_slowpath_common+0x0/0x6c) from [<c0046120>] (warn_slowpath_fmt+0x38/0x40)
[ 4.979736] r8:c0934f68 r7:c0934f68 r6:c0666308 r5:80080003 r4:e08f8b00
[ 4.987426] r3:00000009
[ 4.990570] [<c00460e8>] (warn_slowpath_fmt+0x0/0x40) from [<c0039770>] (l3_interrupt_handler+0xc0/0x168)
[ 5.001159] r3:c0934f6c r2:c07d6774
[ 5.005340] [<c00396b0>] (l3_interrupt_handler+0x0/0x168) from [<c00a86cc>] (handle_irq_event_percpu+0x80/0x)
[ 5.016601] r8:00000000 r7:0000002a r6:0000002a r5:c08f0190 r4:d68bdac0
[ 5.024566] [<c00a864c>] (handle_irq_event_percpu+0x0/0x2e4) from [<c00a8974>] (handle_irq_event+0x44/0x64)
[ 5.035369] [<c00a8930>] (handle_irq_event+0x0/0x64) from [<c00ab684>] (handle_fasteoi_irq+0xc4/0x16c)
[ 5.045684] r6:d682e000 r5:c08f0190 r4:c08f0140 r3:00000000
[ 5.052337] [<c00ab5c0>] (handle_fasteoi_irq+0x0/0x16c) from [<c00a7ea4>] (generic_handle_irq+0x38/0x4c)
[ 5.062835] r5:c08ea4f8 r4:c0912d78
[ 5.067047] [<c00a7e6c>] (generic_handle_irq+0x0/0x4c) from [<c00145a8>] (handle_IRQ+0x54/0xb4)
[ 5.076690] [<c0014554>] (handle_IRQ+0x0/0xb4) from [<c00084d0>] (gic_handle_irq+0x2c/0x60)
[ 5.085968] r8:00000013 r7:d682fe04 r6:d682fdd0 r5:c0911a40 r4:e0802100
[ 5.093566] r3:0000002a
[ 5.096801] [<c00084a4>] (gic_handle_irq+0x0/0x60) from [<c065c200>] (__irq_svc+0x40/0x70)
[ 5.105926] Exception stack(0xd682fdd0 to 0xd682fe18)

.....

The whole message can be found here 2248.omap4460_blaze_w1.txt.

What to do next? Any Ideas?

Best regards and many thank for help,
Roman Jordan

Hi all,

based on the patch from Paul Walmsley (2012-01-22) I changed the hdq access routines from 8 bit to 32 bit. Now the probe procedure runs a little further.

The original comment from Paul was:
> HDQ/1-wire registers are 32 bits long, even if the register contents
> fit into 8 bits, so accesses must be 32-bit aligned. Evidently the
> OMAP2/3 interconnects allowed the driver to get away with 8 bit accesses, …

Best regards,
Roman