AnsweredAssumed Answered

i.MX6SL MPU8080 LCD driver configuration

Question asked by Aaron Moore on Jul 31, 2014
Latest reply on Aug 1, 2014 by vasu babu

Hi All,

We’ve been trying to get a MIPI display interfaced to an i.MX6SL. Since the SL doesn’t support MIPI we’ve added a bridge chip which communits over an MPU8080 interface and controls the display. We’ve been successfully able to configure it and dump and image to it from uboot, and we’ve been able to hook up the fbcon to it to see at least static snapshots of the console, but we’re having some issues triggering the display to update.


We’re using the ELCDIF MPU8080 interface on the i.MX6SL to drive a MIPI bridge chip (SSD2805C) for a MIPI LCD. Since an existing asynchronous MCU8080 interface does not appear to have been implemented for this platform, we have developed drivers around a modified mxc_elcdif_fb.

Upon our driver initialization, the probe function triggers the ELCDIF run bit (see trigger function below) and updates the display. With a synchronous interface to a ‘dumb’ display the output will continue to refresh at the set timing rate until it is told to suspend. However, with the ‘smart’ display that we are using, the run bit is automatically reset once the data transfer for each screen refresh is completed (due to ELCDIF_CTRL_BYPASS_COUNT being cleared for MPU8080 mode).

As such, the driver currently is able to dump the FB to the screen, but only when the run bit is manually triggered.

We can trigger this run bit by invoking certain events from the system such as a display rotation event.

The Problem:

We need a mechanism to update the display when the FB has been updated. We’re not sure what hook we can use to tie into this event.

As an alternative to detecting the FB update/swap event, we have tested a GPIO input coming in from the display (BSYNC) signal which we tied to an IRQ event to trigger an update. But triggering the ELCDIF_CTRL_RUN bit causes a kernel panic. We’ve checked to make sure the run bit has been cleared, but it still causes a panic and looks like we cannot write this particular register from within the irq handler.

Basically, we’re looking for feedback on the proper way to detect when to update the async display, and the best way to trigger the run command.


Trigger function for the display update:

static void __iomem *elcdif_base;

// In mxc_elcdif_fb_probe() elcdif_base is remapped:
elcdif_base = ioremap(res->start, SZ_4K);

static inline void mxc_elcdif_run(struct mxc_elcdif_fb_data *data)

  if (!g_elcdif_axi_clk_enable) {
    g_elcdif_axi_clk_enable = true;

//waiting for run bit to complete does not seem to be needed

  __raw_writel(BF_ELCDIF_TRANSFER_COUNT_H_COUNT(240*3*8/16) |

  gpio_direction_output(PINID_LCD_RS, 1);

         elcdif_base + HW_ELCDIF_CTRL_SET);
         elcdif_base + HW_ELCDIF_CTRL_SET);
  data->running = true;