Message ID | 1348214872-28594-1-git-send-email-s.hauer@pengutronix.de |
---|---|
State | New |
Headers | show |
On Fri, Sep 21, 2012 at 10:07:46AM +0200, Sascha Hauer wrote: > The following adds the i.MX IPUv3 base and KMS driver to the staging > tree. The patches apply cleanly on next-20120921. Dave has merged the > missing helper functions, so this series has no further dependencies. > > Greg, please apply this for staging. Nice job, all now applied to the staging-next tree. greg k-h
Hi Sascha, While testing against a video-enabled U-Boot on i.MX6, I found the issue below. On 09/21/2012 01:07 AM, Sascha Hauer wrote: > This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The > driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO > board and the i.MX6q sabrelite board in different clone mode and dual > head setups. > > Signed-off-by: Sascha Hauer<s.hauer@pengutronix.de> > --- > +++ b/drivers/staging/imx-drm/ipuv3-crtc.c > @@ -0,0 +1,579 @@ > +/* > + * i.MX IPUv3 Graphics driver > + * > > <snip> > > +static int ipu_get_resources(struct ipu_crtc *ipu_crtc, > + struct ipu_client_platformdata *pdata) > +{ > + > + ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch, > + IPU_IRQ_EOF); Interrupts get enabled here > + ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, ipu_irq_handler, 0, > + "imx_drm", ipu_crtc); > + if (ret< 0) { > + dev_err(ipu_crtc->dev, "irq request failed with %d.\n", ret); > + goto err_out; > + } > + > > <snip> > > + > +static int ipu_crtc_init(struct ipu_crtc *ipu_crtc, > + struct ipu_client_platformdata *pdata) > +{ > + int ret; > + > + ret = ipu_get_resources(ipu_crtc, pdata); > + if (ret) { > + dev_err(ipu_crtc->dev, "getting resources failed with %d.\n", > + ret); > + return ret; > + } > + But ipu_crtc->imx_crtc gets initialized in this call, and ipu_irq_handler() makes use of it. The U-Boot code doesn't enable interrupts, so it's not acking along the way, and leaves bits set in IPU1_INT_STAT_15. I found that I can get around this in U-Boot by disabling the LCD controller and acking all of the interrupts after disabling the controller, but I haven't yet figured out where to tap into cleanup_before_linux(). Regards, Eric
Hi Eric, On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: > Hi Sascha, > > While testing against a video-enabled U-Boot on i.MX6, I found the issue > below. > [...] > > But ipu_crtc->imx_crtc gets initialized in this call, and > ipu_irq_handler() makes use of it. > > The U-Boot code doesn't enable interrupts, so it's not acking > along the way, and leaves bits set in IPU1_INT_STAT_15. > > I found that I can get around this in U-Boot by disabling the > LCD controller and acking all of the interrupts after disabling > the controller, but I haven't yet figured out where to tap into > cleanup_before_linux(). Passing over an enabled IPU from the bootloader to the kernel is (currently) not a supported usecase, so U-Boot should indeed disable it. That said, the kernel driver should make sure the IPU is sufficiently configured before the interrupts are enabled, so this seems to be a bug that deserves fixing. Sascha
On 09/22/2012 03:17 AM, Sascha Hauer wrote: > Hi Eric, > > On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: >> Hi Sascha, >> >> >> But ipu_crtc->imx_crtc gets initialized in this call, and >> ipu_irq_handler() makes use of it. >> >> The U-Boot code doesn't enable interrupts, so it's not acking >> along the way, and leaves bits set in IPU1_INT_STAT_15. >> >> I found that I can get around this in U-Boot by disabling the >> LCD controller and acking all of the interrupts after disabling >> the controller, but I haven't yet figured out where to tap into >> cleanup_before_linux(). > > Passing over an enabled IPU from the bootloader to the kernel is > (currently) not a supported usecase, so U-Boot should indeed disable it. > That said, the kernel driver should make sure the IPU is sufficiently > configured before the interrupts are enabled, so this seems to be a bug > that deserves fixing. > Thanks Sascha, Patches for U-Boot are in process. http://lists.denx.de/pipermail/u-boot/2012-September/134807.html Regards, Eric