1. 28 Jan, 2016 1 commit
    • Michael Schanz's avatar
      CGT000028 QMX6: remove revision check of EXT CSD · 0def981b
      Michael Schanz authored
      Revision checking of EXT CSD area avoids that new eMMC devices are recognized
      at all. In the past, it has been observed that new types are still backward
      compatible and handled correctly, although not supported with complete feature set.
      This patch removes the revision checking of the EXT CSD area in order to get
      the driver working for devices with EXT_CSD rev. 6 and above.
      Signed-off-by: Michael Schanz's avatarMichael Schanz <michael.schanz@congatec.com>
  2. 27 Oct, 2015 1 commit
    • Michael Schanz's avatar
      CGT000027 QMX6: adjust camera rst signal/Q7 GPIO1 for · 740e5c70
      Michael Schanz authored
       conga-QMX6 hardware revision C.x
      In Q7 Spec. 2.0, the USB_OTG_PWR signal was moved from Q7 Connector, Pin 186 to Pin 56.
      Moreover the connector layout of the MIPI connector was specified.
      conga-QMX6 rev. C.x was designed according the new Q7 Spec. 2.0 (& Errata). In order to
      fulfill this requirement, this patch was released to adjust the device tree configuration.
      In detail, this patch
      - remaps the camera reset signal from GPIO1_8 (R5) to GPIO6_5 (L6). This frees GPIO1_8
      in order to be used as Q7 GPIO1 (Pin 186).
      - removes signal GPIO3_22 from the device tree configuration. In previous hardware
      revisions (e.g. A.x, B.x), this signal was used as Q7 GPIO1 (Pin 186).
      Attention: this patch breaks compatibility with rev. B.x boards when Q7 GPIO1 is in use.
      Signed-off-by: Michael Schanz's avatarMichael Schanz <michael.schanz@congatec.com>
  3. 09 Oct, 2015 1 commit
  4. 08 Oct, 2015 2 commits
  5. 13 Apr, 2015 22 commits
  6. 04 Mar, 2015 1 commit
  7. 02 Mar, 2015 1 commit
  8. 27 Feb, 2015 6 commits
  9. 26 Feb, 2015 1 commit
  10. 24 Feb, 2015 1 commit
  11. 18 Feb, 2015 2 commits
  12. 06 Feb, 2015 1 commit
    • Liu Ying's avatar
      MLK-10227 video: mxsfb: Correct interrupt handling · e4c03919
      Liu Ying authored
      We've got a race condition bewteen the interrupt handler mxsfb_irq_handler()
      and the function mxsfb_wait_for_vsync() on the flag host->wait4vsync.
      If a CUR_FRAME_DONE interrupt comes and we just finish setting host->wait4vsync
      to be 1 in mxsfb_wait_for_vsync() before we go to the interrupt handler, we are
      likely to see the VSYNC_EDGE interrupt status bit asserted in the interrupt
      handler for the CUR_FRAME_DONE interrupt, disable the not yet enabled VSYNC_EDGE
      interrupt and finally clear host->wait4vsync.
      Then, we go back to mxsfb_wait_for_vsync() and enable the VSYNC_EDGE interrupt
      with host->wait4vsync=0.  This may leave the VSYNC_EDGE interrupt enabled all
      the time and never get a chance to be disabled in the interrupt handler.
      So, we are deemed to hang up because the uncleared VSYNC_EDGE interrupt status
      bit will cause the CPU to be trapped forever, according to SoC designer's words.
      This patch corrects the interrupt handling to handle only the interrupts which
      are acknowledged by checking both the interrupt enablement bits and the status
      bits but not the status bits only.  This may avoid any bogus interrupt from
      being handled.
      Signed-off-by: 's avatarLiu Ying <Ying.Liu@freescale.com>
      (cherry picked from commit 24e1e55076b624f9dc93c1f23e14dd024bdff1c7)