i.MX6 IPU drivers

[gonzo]

Summary

This diff contains driver for IPU and HDMI framer.
Most of patch is self-contained. I had to add OF_device_register_xref so when usign reference to i2c device in hdmi node we can get actual iic device. not iicbus.

Driver simplifies actual structure of IPU. iMX6 can have up to two IPUs (IPU1 amd IPU2), each of them with two display interfaces (DI0, DI1) Driver assumes that display is on DI0 at IPU1, it's something we'll need to address later.

Driver also assumes that pixel clock is initialized by U-Boot for default 1026x768 mode. In order to use other modes we need to set pixel clock accordingly and for this we need more sophisticated clock control framework.

[andrew]

There are many magic numbers, and not many comments explaining what is happening. There are also style(9) issues.

Would it pay to split the review into two, one for ipu, one for hdmi?

Is imx_hdmi_sc needed? It seems like all calls to imx_hdmi_read_1 and imx_hdmi_write_1 already have access to a softc to pass to RD1 or WR1.

sys/arm/freescale/imx/imx6_ccm.c

367 ↗

(On Diff #10207)

void
imx_ccm_hdmi_enable(void)

sys/arm/freescale/imx/imx6_ccmreg.h

59–67 ↗

(On Diff #10207)

This indentation looks different than above. Is it correct?

sys/arm/freescale/imx/imx6_hdmi.c

114 ↗

(On Diff #10207)

Missing newline.

115 ↗

(On Diff #10207)

Why imx_hdmi_read_1 and not RD1?

124 ↗

(On Diff #10207)

Missing newline after void.

125 ↗

(On Diff #10207)

Extra indentation.

127 ↗

(On Diff #10207)

Why 0xFF?

286 ↗

(On Diff #10207)

static void\n

323 ↗

(On Diff #10207)

What's special about 45250000?

325–369 ↗

(On Diff #10207)

Many magic values

sys/arm/freescale/imx/imx6_ipu.c

718–734 ↗

(On Diff #10207)

What are all these magic numbers for?

902 ↗

(On Diff #10207)

if (err != 0) {

910 ↗

(On Diff #10207)

Ditto

948–949 ↗

(On Diff #10207)

Shouldn't err be set?

952–953 ↗

(On Diff #10207)

And here.

956 ↗

(On Diff #10207)

Is this needed? I don't see how err could be non-zero here.

982 ↗

(On Diff #10207)

Extra space after the (

[gonzo]

Andrew, I cleaned up HDMI driver per your suggestions and moved it to separate revision: D4174. I'll upload updated IPU driver here later.

[gonzo]

Update for IPU part of the driver:

• style clean-up
• magic numbers scrubbing

[gonzo]

Remove no-op IPU_READ4s that were used for debug purpose

[• ian]

sys/arm/freescale/imx/imx6_ipu.c

64 ↗

(On Diff #10806)

the freebsd idiom for this is #define EDID_DEBUG_not (although I haven't seen it as much recently as in years past)

195 ↗

(On Diff #10806)

the DI_COUNTER and DI_SYNC things seem strangely indented, as if they're subordinate to some missing IPU_DI_something register definitions.

421 ↗

(On Diff #10806)

I think if offset were defined as u_int the compiler would have a better chance of converting these divide ops into shifting and masking.

426 ↗

(On Diff #10806)

this check should probably be before the 1 << len. Also, this function is called from all those macros above, right? so len > 32 is a programming error, not a runtime error? if so, KASSERT is better.

and likewise in ​ipu_ch_param_get_value() below

571 ↗

(On Diff #10806)

a lot of this arithmetic is missing the spaces between operators throughout all these functions

609 ↗

(On Diff #10806)

should this be "microcode"?

749 ↗

(On Diff #10806)

s/User/Use/

1026 ↗

(On Diff #10806)

could just pass BUS_DMA_ZERO to bus_dmamem_alloc()

1168 ↗

(On Diff #10806)

why do we need this have_ipu thing enforcing that only one instance can exist? I don't see any global or static vars or anything that imply there can be only one.

[gonzo]

sys/arm/freescale/imx/imx6_ipu.c

1168 ↗

(On Diff #10806)

Because if there are more than one IPU instance they all handle HDMI connect event and create framebuffer. This will be handled later when I add support for multiple video paths.

[gonzo]

Address latest round of review comments