* Re: [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support
2013-12-20 17:52 [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support Philipp Zabel
@ 2013-12-20 19:12 ` Greg Kroah-Hartman
2014-01-03 16:59 ` Philipp Zabel
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-20 19:12 UTC (permalink / raw)
To: linux-fbdev
On Fri, Dec 20, 2013 at 06:52:41PM +0100, Philipp Zabel wrote:
> Hi,
>
> this is mostly about the first patch, which moves the IPUv3 core code
> (drivers/staging/imx-drm/ipu-v3) to drivers/gpu. host1x, which
> serves a similar purpose, already sits there.
> The other four patches add the necessary code for CSI and SMFC handling,
> which is used by the V4L2 CSI capture driver.
>
> Currently this is based on Russell's patch
> [PATCH 62/64] imx-drm: pass an IPU ID to crtc and core
>
> I am aware that there are now quite a few other patches in the pipeline
> that touch drivers/staging/imx-drm/ipu-v3/*, so I am happy to rebase this
> (or them) as needed. I'd like to move the core code out of staging so that
> we can start submitting V4L2 code for video capture and scaling / colorspace
> conversion in parallel.
I'd recommend doing the move (if the gpu/drm maintainer agrees) after
3.14-rc1 as then all of my pending patches would be applied and we would
be synced up with everything.
Once this "core" is moved, what is keeping the rest in staging and why
isn't it moving out as well?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support
2013-12-20 17:52 [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support Philipp Zabel
2013-12-20 19:12 ` Greg Kroah-Hartman
@ 2014-01-03 16:59 ` Philipp Zabel
2014-02-26 8:39 ` Dan Carpenter
2014-02-26 10:08 ` Russell King - ARM Linux
3 siblings, 0 replies; 5+ messages in thread
From: Philipp Zabel @ 2014-01-03 16:59 UTC (permalink / raw)
To: linux-fbdev
Am Freitag, den 20.12.2013, 11:12 -0800 schrieb Greg Kroah-Hartman:
> On Fri, Dec 20, 2013 at 06:52:41PM +0100, Philipp Zabel wrote:
> > Hi,
> >
> > this is mostly about the first patch, which moves the IPUv3 core code
> > (drivers/staging/imx-drm/ipu-v3) to drivers/gpu. host1x, which
> > serves a similar purpose, already sits there.
> > The other four patches add the necessary code for CSI and SMFC handling,
> > which is used by the V4L2 CSI capture driver.
> >
> > Currently this is based on Russell's patch
> > [PATCH 62/64] imx-drm: pass an IPU ID to crtc and core
> >
> > I am aware that there are now quite a few other patches in the pipeline
> > that touch drivers/staging/imx-drm/ipu-v3/*, so I am happy to rebase this
> > (or them) as needed. I'd like to move the core code out of staging so that
> > we can start submitting V4L2 code for video capture and scaling / colorspace
> > conversion in parallel.
>
> I'd recommend doing the move (if the gpu/drm maintainer agrees) after
> 3.14-rc1 as then all of my pending patches would be applied and we would
> be synced up with everything.
Ok.
> Once this "core" is moved, what is keeping the rest in staging and why
> isn't it moving out as well?
Russell put a lot of work into fixing imx-drm issues, and I'd like to
make the change to a common device tree binding before this leaves
staging.
regards
Philipp
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support
2013-12-20 17:52 [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support Philipp Zabel
2013-12-20 19:12 ` Greg Kroah-Hartman
2014-01-03 16:59 ` Philipp Zabel
@ 2014-02-26 8:39 ` Dan Carpenter
2014-02-26 10:08 ` Russell King - ARM Linux
3 siblings, 0 replies; 5+ messages in thread
From: Dan Carpenter @ 2014-02-26 8:39 UTC (permalink / raw)
To: linux-fbdev
Please fix the following static checker complaints before moving out of
staging:
drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c:164 ipu_dmfc_setup_channel() warn: variable dereferenced before check 'dmfc' (see line 157)
drivers/staging/imx-drm/imx-ldb.c:109 imx_ldb_connector_get_modes() error: potential null dereference 'mode'. (drm_mode_create returns null)
drivers/staging/imx-drm/imx-ldb.c:340 imx_ldb_get_clk() error: format string overflow. buf_size: 16 length: 18
probably 18 is theory and not real life, but 16 is based on
theory as well.
drivers/staging/imx-drm/parallel-display.c:64 imx_pd_connector_get_modes() error: potential null dereference 'mode'. (drm_mode_create returns null)
drivers/staging/imx-drm/parallel-display.c:73 imx_pd_connector_get_modes() error: potential null dereference 'mode'. (drm_mode_create returns null)
drivers/staging/imx-drm/ipuv3-plane.c: In function ‘ipu_plane_set_base’:
drivers/staging/imx-drm/ipuv3-plane.c:75:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘dma_addr_t’ [-Wformat]
cast it to u64 and use %llx
drivers/staging/imx-drm/imx-drm-core.c:89:21: warning: symbol 'imx_drm_find_crtc' was not declared. Should it be static?
regards,
dan carpenter
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support
2013-12-20 17:52 [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support Philipp Zabel
` (2 preceding siblings ...)
2014-02-26 8:39 ` Dan Carpenter
@ 2014-02-26 10:08 ` Russell King - ARM Linux
3 siblings, 0 replies; 5+ messages in thread
From: Russell King - ARM Linux @ 2014-02-26 10:08 UTC (permalink / raw)
To: linux-fbdev
On Wed, Feb 26, 2014 at 11:39:03AM +0300, Dan Carpenter wrote:
>
> Please fix the following static checker complaints before moving out of
> staging:
>
> drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c:164 ipu_dmfc_setup_channel() warn: variable dereferenced before check 'dmfc' (see line 157)
Note that what's being talked about being moved out is only the above,
not the files in drivers/staging/imx-drm. DRM people have not yet
reviewed imx-drm itself, which is a necessary step - but nevertheless,
thanks for running a static checker on this stuff.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply [flat|nested] 5+ messages in thread