On Thu, Feb 16, 2017 at 02:27:41PM -0800, Steve Longerbeam wrote:
>
>
> On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote:
> >On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:
> >>In version 4:
> >
> >With this version, I get:
> &g
On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:
> In version 4:
With this version, I get:
[28762.892053] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x
[28762.899409] ipu1_csi0: pipeline_set_stream failed with -110
--
RMK's Patch system: http://www.armlinux.org.uk/devel
On Thu, Feb 16, 2017 at 10:44:16AM -0800, Steve Longerbeam wrote:
> On 02/16/2017 04:40 AM, Russell King - ARM Linux wrote:
> >[8.012191] imx_media_common: module is from the staging directory, the
> >quality is unknown, you have been warned.
> >[8.018175] imx_medi
On Thu, Feb 16, 2017 at 01:09:35PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 16, 2017 at 12:40:27PM +0000, Russell King - ARM Linux wrote:
> > However, the following is primerily directed at Laurent as the one who
> > introduced the BUG_ON() in question...
> >
>
On Thu, Feb 16, 2017 at 02:02:03PM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> > +- imx-csi subdev is not being autoloaded as a kernel module, probably
> > + because ipu_add_client_devices() does not register the IPU client
> > + platform devices, bu
On Thu, Feb 16, 2017 at 12:40:27PM +, Russell King - ARM Linux wrote:
> However, the following is primerily directed at Laurent as the one who
> introduced the BUG_ON() in question...
>
> NEVER EVER USE BUG_ON() IN A PATH THAT CAN RETURN AN ERROR.
>
> It's possible to
On Thu, Feb 16, 2017 at 11:52:06AM +, Russell King - ARM Linux wrote:
> On Wed, Feb 15, 2017 at 06:19:22PM -0800, Steve Longerbeam wrote:
> > +static const struct platform_device_id imx_csi_ids[] = {
> > + { .name = "imx-ipuv3-csi" },
> > + { },
> >
On Wed, Feb 15, 2017 at 06:19:22PM -0800, Steve Longerbeam wrote:
> +static const struct platform_device_id imx_csi_ids[] = {
> + { .name = "imx-ipuv3-csi" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(platform, imx_csi_ids);
> +
> +static struct platform_driver imx_csi_driver = {
> + .probe
Two problems.
On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote:
> media: imx: propagate sink pad formats to source pads
1) It looks like all cases aren't being caught:
- entity 74: ipu1_csi0 (3 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
de
On Wed, Feb 15, 2017 at 06:19:30PM -0800, Steve Longerbeam wrote:
> diff --git a/drivers/staging/media/imx/imx-media-csi.c
> b/drivers/staging/media/imx/imx-media-csi.c
> index ae24b42..3cb97e2 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi
On Wed, Feb 15, 2017 at 06:19:25PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
>
> Signed-off-by: Steve Longerbeam
Just like I reported on the 30th January:
.git/rebase-apply/patch:236: trailing white
On Wed, Feb 15, 2017 at 06:19:20PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam
Just as I reported on the 30th January:
Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:614: new blank line at EOF.
+
.git/rebase-a
On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:
> >Actually, this exact function already exists as dw_mipi_dsi_phy_write in
> >drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY
> >register 0x44 might contain a field called HSFREQRANGE_SEL.
>
> Thanks for pointin
On Sun, Feb 05, 2017 at 05:24:30PM +0200, Laurent Pinchart wrote:
> Hi Russell,
>
> On Monday 30 Jan 2017 22:51:33 Russell King - ARM Linux wrote:
> > > + ov5640_to_mipi_csi: endpoint@1 {
> > > + reg = <1>;
> > >
On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> +/* register an internal subdev as a platform device */
> +static struct imx_media_subdev *
> +add_internal_subdev(struct imx_media_dev *imxmd,
> + const struct internal_subdev *isd,
> + int ipu_id)
On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> +struct imx_media_dev {
> + struct media_device md;
> + struct v4l2_device v4l2_dev;
This is similarly buggy.
struct v4l2_device {
struct device *dev;
#if defined(CONFIG_MEDIA_CONTROLLER)
struct media_dev
On Fri, Jan 06, 2017 at 06:11:38PM -0800, Steve Longerbeam wrote:
> +struct camif_priv {
> + struct device *dev;
> + struct video_devicevfd;
You can't do this.
> +static struct video_device camif_videodev = {
> + .fops = &camif_fops,
> + .ioctl_ops = &ca
On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote:
> Here is the current .queue_setup() op in imx-media-capture.c:
>
> static int capture_queue_setup(struct vb2_queue *vq,
>unsigned int *nbuffers,
>unsigned int *nplanes
On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote:
> On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote:
> >and for whatever reason we end up falling out through free_ring. This
> >is VERY bad news, because it means that the ring which SMFC took a copy
>
On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote:
> I thought, maybe, it's the IPU overwriting past the end of the buffer,
> but I've added checks and that doesn't seem to have fired. I also
> wondered if it was some kind of use-after-fre
I seem to be getting some sort of memory corruption with this driver.
I've had two instances now of uninitialised spinlocks in
imx_media_dma_buf_get_active() which show that the spinlock being
taken in this function is all-zeros.
That very quickly leads to an oops, where I've seen buf->ring is
NU
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +static int imxcsi2_get_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *sdformat)
> +{
> + struct imxcsi2_dev *csi2 = sd_to_dev(sd
Hi Steve,
On Fri, Jan 06, 2017 at 06:11:36PM -0800, Steve Longerbeam wrote:
> +/*
> + * Min/Max supported width and heights.
> + *
> + * We allow planar output from the SMFC, so we have to align
> + * output width by 16 pixels to meet IDMAC alignment requirements,
> + * which also means input widt
On Wed, Feb 01, 2017 at 11:42:31AM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-01 at 10:11 +0000, Russell King - ARM Linux wrote:
> Right, it's just that in the latest version there is no v4l2_subdev for
> fifos and idmac. There is the capture interface entity that represents
>
On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> [...]
> > right, need to fix that. Probably by poking the attached
> > source subdev (csi or prpenc/vf) for its supported formats.
>
> You are right, in bayer/raw mode only
On Tue, Jan 31, 2017 at 05:54:52PM -0800, Steve Longerbeam wrote:
> On 01/31/2017 04:23 PM, Russell King - ARM Linux wrote:
> First, thank you for the explanation, it clears up a lot.
>
> But of_parse_subdev() is used to parse the OF graph starting
> from the CSI ports, to discove
Hi Steve,
On Tue, Jan 31, 2017 at 05:02:40PM -0800, Steve Longerbeam wrote:
> But this also puts a requirement on MIPI sensors that s_power(ON)
> should only place the D_PHY in LP-11, and _not_ start the clock lane.
> But perhaps that is correct behavior anyway.
If the CSI2 DPHY is held in reset
On Tue, Jan 31, 2017 at 04:31:55PM -0800, Steve Longerbeam wrote:
>
>
> On 01/31/2017 03:20 AM, Russell King - ARM Linux wrote:
> >On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> >>+static int csi_link_validate(struct v4l2_subdev *sd,
> >&g
On Tue, Jan 31, 2017 at 03:43:22PM -0800, Steve Longerbeam wrote:
>
>
> On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote:
> >Just like smiapp, the camera sensor block (which is the very far end
> >of the pipeline) is marked with MEDIA_ENT_F_CAM_SENSOR. However, in
&g
On Tue, Jan 31, 2017 at 02:36:53PM -0800, Steve Longerbeam wrote:
> On 01/31/2017 02:04 PM, Russell King - ARM Linux wrote:
> >I don't want master though, I want v4.10-rc1, and if I ask for that
> >it tells me it knows nothing about v4.10-rc1, despite the fact that's
On Tue, Jan 31, 2017 at 09:55:29PM +, Ian Arkver wrote:
> On 31/01/17 20:33, Russell King - ARM Linux wrote:
> >On Tue, Jan 31, 2017 at 10:21:26AM -0800, Steve Longerbeam wrote:
> >>On 01/31/2017 05:42 AM, Russell King - ARM Linux wrote:
> >>>On Fri, Jan 20,
On Tue, Jan 31, 2017 at 10:21:26AM -0800, Steve Longerbeam wrote:
> On 01/31/2017 05:42 AM, Russell King - ARM Linux wrote:
> >On Fri, Jan 20, 2017 at 03:38:28PM +0100, Hans Verkuil wrote:
> >>Should be set to something like 'platform:imx-media-camif'. v4l2-complian
On Tue, Jan 31, 2017 at 03:25:10PM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 14:54 +0100, Philipp Zabel wrote:
> > Hi Steve,
> >
> > I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X
> > with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some
> > obser
On Tue, Jan 31, 2017 at 02:35:00PM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 13:14 +0000, Russell King - ARM Linux wrote:
> > This isn't limited to the serial side - the parallel bus side between
> > the CSI2 interface and CSI2IPU wrapper, and the CSI2IPU wrapp
On Fri, Jan 20, 2017 at 03:38:28PM +0100, Hans Verkuil wrote:
> Should be set to something like 'platform:imx-media-camif'. v4l2-compliance
> should complain about this.
... and more.
Driver Info:
Driver name : imx-media-camif
Card type : imx-media-camif
Bus info
On Tue, Jan 31, 2017 at 11:09:24AM +0100, Philipp Zabel wrote:
> On Mon, 2017-01-30 at 13:06 +0000, Russell King - ARM Linux wrote:
> > To help illustrate my point, consider the difference between
> > MEDIA_BUS_FMT_RGB565_1X16 and MEDIA_BUS_FMT_RGB565_2X8_BE or
> > MEDIA_
On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> +static int csi_link_validate(struct v4l2_subdev *sd,
> + struct media_link *link,
> + struct v4l2_subdev_format *source_fmt,
> + struct v4l2_subdev_format
On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote:
> I'm also having trouble finding a datasheet for it, but from what
> I've read, it has a MIPI CSI-2 interface. It should work fine as long
> as it presents a single source pad, registers asynchronously, and
> sets its entity functio
On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
>
> Signed-off-by: Steve Longerbeam
> ---
The lack of s_frame_interval/g_frame_interval in this driver means:
media-ctl -v -d /dev/media1 --set-v4l
On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote:
> Edit: I see a subdev that is missing: the video mux. Did you enable
> CONFIG_VIDEO_MULTIPLEXER?
Yes, and that's where the problem is - the video-multiplexer is
missing the module aliases to allow it to be automatically loaded.
-
On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote:
> Trying this driver with an imx219 camera (which works with Philipp's
> driver) results in not much happening... no /dev/media* node for it,
> no subdevs, no nothing. No clues as to what's missing eithe
On Fri, Jan 06, 2017 at 06:11:18PM -0800, Steve Longerbeam wrote:
> Philipp Zabel (3):
> ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
> connections
> add mux and video interface bridge entity functions
> platform: add video-multiplexer subdevice driver
>
> Steve L
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
...
> +#define DEVICE_NAME "imx6-mipi-csi2"
Why is the device/driver named imx6-mipi-csi2, but the module named
imx-mipi-csi2 - could there be some consistency here please?
Thanks.
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +static void imxcsi2_enable(struct imxcsi2_dev *csi2, bool enable)
> +{
> + if (enable) {
> + imxcsi2_write(csi2, 0x, CSI2_PHY_SHUTDOWNZ);
> + imxcsi2_write(csi2, 0x, CSI2_DPHY_RSTZ);
> +
On Fri, Jan 06, 2017 at 06:11:40PM -0800, Steve Longerbeam wrote:
> +config IMX_OV5640_MIPI
> + tristate "OmniVision OV5640 MIPI CSI-2 camera support"
> + depends on GPIOLIB && VIDEO_IMX_CAMERA
> + select IMX_MIPI_CSI2
> + default y
Why is this defaulting to y? New drivers
On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> + ov5640: camera@40 {
> + compatible = "ovti,ov5640";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5640>;
> + clocks = <&mipi_xclk>;
> + clock-names = "x
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
>
> Signed-off-by: Steve Longerbeam
Applying: media: imx: Add MIPI CSI-2 Receiver subdev driver
.git/rebase-apply/patch:52
On Fri, Jan 06, 2017 at 06:11:37PM -0800, Steve Longerbeam wrote:
> This is a set of three media entity subdevice drivers for the i.MX
> Image Converter. The i.MX IC module contains three independent
> "tasks":
>
> - Pre-processing Encode task: video frames are routed directly from
> the CSI and
On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
>
> Signed-off-by: Steve Longerbeam
warning: 3 lines add whitespace errors.
Applying: media: imx: Add CSI subdev driver
.git/rebase-apply/patch:38:
On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam
Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:516: new blank line at EOF.
+
.git/rebase-apply/patch:528: new blank line at EOF.
+
On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
> b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 66d10d8..9e2d26d 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -52,3 +5
On Mon, Jan 23, 2017 at 12:13:26PM +0100, Philipp Zabel wrote:
> Hi Steve,
>
> On Sun, 2017-01-22 at 18:31 -0800, Steve Longerbeam wrote:
> > Second, ignoring the above locking issue for a moment,
> > v4l2_pipeline_pm_use()
> > will call s_power on the sensor _first_, then the mipi csi-2 s_power,
> The central issue seems to be that I think media pad links / media bus
> formats should describe physical links, such as parallel or serial
> buses, and the formats of pixels flowing through them, whereas Steve
> would like to extend them to describe software transports and in-memory
> formats.
On Mon, Oct 31, 2016 at 12:53:13PM -0700, Michael Zoran wrote:
> On Mon, 2016-10-31 at 11:40 -0700, Michael Zoran wrote:
> > The comment is easy to change.
> >
> > I don't have the log available ATM, but if I remember the DMA API's
> > bugcheck the first time that are used.
> >
> > I think this
On Mon, Aug 08, 2016 at 10:49:34AM -0700, Laura Abbott wrote:
> +/*
> + * Make an area consistent for devices.
> + * Note: Drivers should NOT use this function directly, as it will break
> + * platforms with CONFIG_DMABOUNCE.
> + * Use the driver DMA support - see dma-mapping.h (dma_sync_*)
> + */
On Thu, May 26, 2016 at 10:58:35AM +0100, Liviu Dudau wrote:
> On Wed, May 25, 2016 at 12:48:02PM -0700, Laura Abbott wrote:
> >
> > Ion is currently using the DMA APIs in non-compliant ways for cache
> > maintaince. The issue is Ion needs to do cache operations outside of
> > the regular DMA mode
On Fri, Jan 15, 2016 at 03:03:42PM -0800, Laura Abbott wrote:
> (adding linux-arm and a few people)
>
> On 01/14/2016 06:42 PM, Chen Feng wrote:
> >The page is already alloc at ion_alloc function,
> >ion_mmap map the alloced pages to user-space.
> >
> >The default prot can be PTE_RDONLY. Take a lo
On Tue, Nov 10, 2015 at 12:35:50AM +0900, Jungseung Lee wrote:
> Hi,
>
> 2015-11-09 16:57 GMT+09:00 Shailendra Verma :
> > From: Shailendra Verma
> >
> > The module end boundary check is not proper.The out of bound value
> > of module end can produce undesired results.
> >
> > Signed-off-by: Shai
On Fri, Apr 03, 2015 at 03:57:27PM +0300, Dan Carpenter wrote:
> On Fri, Apr 03, 2015 at 02:42:02PM +0200, Geert Uytterhoeven wrote:
> > +int __init board_staging_register_clock(const struct board_staging_clk
> > *bsc)
> > +{
> > + struct clk *clk;
> > + int error;
> > +
> > + pr_debug("Regi
On Fri, Apr 03, 2015 at 03:27:40PM +0200, Geert Uytterhoeven wrote:
> On Fri, Apr 3, 2015 at 2:57 PM, Dan Carpenter
> wrote:
> >> + error = clk_register_clkdev(clk, bsc->con_id, bsc->dev_id);
> >> + if (error)
> >> + pr_err("Failed to register clock %s (%d)\n", bsc->clk,
> >>
On Thu, Dec 11, 2014 at 12:24:15PM +0100, Heiko Stübner wrote:
> Past practices suggest that having the dw in the name is a sane solution too,
> like in dw_mmc-foo (mmc/host), dwmac-foo (net/ethernet/stmicro/stmmac).
>
> And personally I'd keep to this already established naming scheme ... i.e.
On Fri, Dec 05, 2014 at 02:25:50PM +0800, Andy Yan wrote:
> hdmi phy configuration is platform specific, which can be adusted
Minor typo: adjusted
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
___
On Tue, Jan 06, 2015 at 12:52:24PM +0100, Heiko Stübner wrote:
> +static void imx_hdmi_bridge_nope(struct drm_bridge *bridge)
"_nope" ? As in "No"? Or should this be "_nop" for no-operation ?
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
_
On Thu, Dec 04, 2014 at 09:40:10AM +0100, Philipp Zabel wrote:
> You are right, no I don't want this. When I initially wrote this patch I
> was under the impression that the memory allocated by devm_kzalloc in
> bind() wouldn't be freed on unbind().
Resources claimed inside bind() will be freed in
On Thu, Dec 04, 2014 at 12:56:24AM +0800, Andy Yan wrote:
> Hi Russell:
> On 2014年12月04日 00:33, Russell King - ARM Linux wrote:
> >On Thu, Dec 04, 2014 at 12:30:23AM +0800, Andy Yan wrote:
> >>On 2014年12月04日 00:11, Russell King - ARM Linux wrote:
> >>>I meant th
On Thu, Dec 04, 2014 at 12:30:23AM +0800, Andy Yan wrote:
>
> On 2014年12月04日 00:11, Russell King - ARM Linux wrote:
> >I meant that imx_hdmi_bind should be passed these, so that it needs to
> >know nothing about the struct device beyond the generic device structure.
> >In
On Wed, Dec 03, 2014 at 05:20:15PM +0100, Philipp Zabel wrote:
> Hi Andy,
>
> It would be better if the bind function would not have to care about
> platform resources, that should be handled in the probe function. I had
> a patch to move them:
>
> http://lists.freedesktop.org/archives/dri-devel/
On Thu, Dec 04, 2014 at 12:04:37AM +0800, Andy Yan wrote:
> Hi Russell:
>
> On 2014年12月03日 23:38, Russell King - ARM Linux wrote:
> >On Wed, Dec 03, 2014 at 11:29:26PM +0800, Andy Yan wrote:
> >>+int imx_hdmi_bind(struct device *dev, struct device *master,
> >>
On Thu, Dec 04, 2014 at 12:01:25AM +0800, Andy Yan wrote:
> Hi Russell:
> Do you mean I just neet to do like bellow?
>
> +
> +config DRM_DW_HDMI
> + bool
> + depends on DRM
> + select DRM_KMS_HELPER
Yep.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
acco
On Wed, Dec 03, 2014 at 11:32:12PM +0800, Andy Yan wrote:
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 884923f..26162ef 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -3,3 +3,8 @@ config DRM_PTN3460
> depends
On Wed, Dec 03, 2014 at 11:29:26PM +0800, Andy Yan wrote:
> +int imx_hdmi_bind(struct device *dev, struct device *master,
> + void *data, struct drm_encoder *encoder,
> + const struct imx_hdmi_plat_data *plat_data)
> {
> struct platform_device *pdev = to_platform_
On Sat, Nov 15, 2014 at 10:12:18AM +, Russell King - ARM Linux wrote:
> Once the wranglings on the patch series are complete, I do intend to test
> it on the platforms I have - and remember that I do have the ALSA based
> audio and CEC bits as well, some of which will probably need
On Sat, Nov 15, 2014 at 06:07:50PM +0800, Daniel Kurtz wrote:
> On Fri, Nov 14, 2014 at 7:13 PM, Zubair Lutfullah Kakakhel
> wrote:
> >
> >
> > On 14/11/14 11:08, Andy Yan wrote:
> >>
> >> On 2014年11月14日 18:55, Zubair Lutfullah Kakakhel wrote:
> >>>
> >>> On 14/11/14 10:53, Andy Yan wrote:
>
On Thu, Nov 06, 2014 at 05:35:40PM +0800, Kuankuan.Yang wrote:
> I'm working on Designware hdmi-audio, also add it as a standard ALSA device.
> Before I saw this email, I also planed to submit my patchs to upsteam.
> I'm very grateful if you can email those patchs to us.
I've attached the set of p
On Tue, Nov 04, 2014 at 09:33:10PM +0800, Andy Yan wrote:
> From: Andy yan
>
> We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they also have some
> lightly difference, such as phy pll configuration, register widt
Greg,
Here's two oops fixes for imx-drm, which I've had queued up for a number
of months now. Shawn posted different fixes for the same oops recently
as well.
drivers/staging/imx-drm/imx-ldb.c | 3 +++
drivers/staging/imx-drm/ipuv3-plane.c | 3 ++-
2 files changed, 5 insertions(+), 1 deleti
On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote:
> 2014-07-01 23:22 GMT+09:00 Russell King - ARM Linux :
> > On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
> >> On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
> >> >
On Tue, Aug 19, 2014 at 05:36:10PM +0300, Yannis Damigos wrote:
> diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
> b/drivers/staging/imx-drm/ipuv3-crtc.c
> index 720868b..d6657a0 100644
> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -201,9 +201,10
On Fri, Jul 04, 2014 at 05:00:36PM +0530, Sachin Kamat wrote:
> On Fri, Jul 4, 2014 at 4:22 PM, Russell King - ARM Linux
> wrote:
> > On Fri, Jul 04, 2014 at 04:17:35PM +0530, Sachin Kamat wrote:
> >> Hi Russell
> >>
> >> > +int componen
On Fri, Jul 04, 2014 at 04:17:35PM +0530, Sachin Kamat wrote:
> Hi Russell
>
> > +int component_master_add_with_match(struct device *dev,
> > + const struct component_master_ops *ops,
> > + struct component_match *match)
> > {
> > struct master *master;
> > int ret;
>
On Thu, Jul 03, 2014 at 01:20:03PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 03, 2014 at 03:10:40PM +0100, Russell King wrote:
> > Greg,
> >
> > Please incorporate the latest component updates, which can be found at:
> >
> > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git component-for-drive
On Thu, Jul 03, 2014 at 01:51:19AM +0200, Laurent Pinchart wrote:
> On Wednesday 02 July 2014 15:59:04 Russell King - ARM Linux wrote:
> > On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote:
> > > A while back, Laurent raised some comments about th
On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote:
> It's has been just a week. I will check and look into your patch
> series. I think Exynos drm should also be considered for the use of
> component match array.
Actually, this series has been around for much longer than just a
week. Your
On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote:
> A while back, Laurent raised some comments about the component helper,
> which this patch set starts to address.
I looked back over the two other times which this series has posted,
and noticed that two patches ha
On Wed, May 14, 2014 at 08:42:17PM +0200, Thierry Reding wrote:
> I've been looking at converting the Tegra DRM driver to the component
> helpers for a while now and had to make some changes to make it work for
> that particular use-case. While updating the imx-drm and msm DRM drivers
> for those c
A while back, Laurent raised some comments about the component helper,
which this patch set starts to address.
The first point it addresses is the repeated parsing inefficiency when
deferred probing occurs. When DT is used, the structure of the
component helper today means that masters end up par
On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
> > Hi Russell,
> >
> > On Tue, Jun 24, 2014 at 9:29 PM, Russell King
> > wrote:
> > [...]
> > > +
The following two patches fix a couple of oopses I've found while
re-testing the unbind support for imx-drm.
Can I suggest that people check that it's possible to successfully
unbind and rebind the driver when they add stuff (like the ipu plane
support)?
I have these queued for Greg to pull. Tha
On Wed, Jun 25, 2014 at 11:44:47AM +0200, Denis Carikli wrote:
> On 06/25/2014 06:48 AM, Sascha Hauer wrote:
>>> +#define ENABLE_POL_LOW 0
>>> +#define ENABLE_POL_HIGH1
>>
>> Adding defines without a proper namespace (IPU_) outside a driver
>> private header file is not nice
On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
> Hi Russell,
>
> On Tue, Jun 24, 2014 at 9:29 PM, Russell King
> wrote:
> [...]
> > +/*
> > + * Add a component to be matched.
> > + *
> > + * The match array is first created or extended if necessary.
> > + */
> > +void component_ma
On Mon, Jun 16, 2014 at 12:11:21PM +0200, Denis Carikli wrote:
> The previous hardware behaviour was kept if the
> flags are not set.
I'd like to throw in a patch that I've been carrying for a bit now.
It conflicts with your patches, but I'm happy to fix that conflict
locally (and have been doing
On Wed, Jun 25, 2014 at 06:48:45AM +0200, Sascha Hauer wrote:
> On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> > +
> > /*
> > * Bitfield of Display Interface signal polarities.
> > */
> > @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
> > unsigned clksel_en:1;
> > unsig
A while back, Laurent raised some comments about the component helper,
which this patch set starts to address.
The first point it addresses is the repeated parsing inefficiency when
deferred probing occurs. When DT is used, the structure of the
component helper today means that masters end up par
On Tue, Jun 24, 2014 at 06:25:19PM +0200, Denis Carikli wrote:
> On 06/24/2014 05:13 PM, Russell King - ARM Linux wrote:
> [...]
>> If you'd like to send me better commit messages for
>> these patches, I'll add them to what I already have:
>
>> imx-drm: us
On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
It would be nice to have a little more explanation in the commit messages
for these patches. If you'd like to send me better commit messages for
these patches, I'll add them to what I already have:
Denis,
This patch creates binding documentation. Any patch which does so
should be copied to the DT people so they can review the bindings
and give appropriate acks. It would be better if you separate the
binding documentation updates from the other functional changes too.
I've added them on th
On Mon, Jun 16, 2014 at 12:11:19PM +0200, Denis Carikli wrote:
> The imx-drm driver can't use the de-active and
> pixelclk-active display-timings properties yet.
>
> Instead the data-enable and the pixel data clock
> polarity are hardcoded in the imx-drm driver.
>
> So theses properties are now s
On Mon, Jun 16, 2014 at 12:11:20PM +0200, Denis Carikli wrote:
> We need a way to pass signal polarity informations
> between DRM panels, and the display drivers.
>
> To do that, a pol_flags field was added to drm_display_mode.
>
> Signed-off-by: Denis Carikli
This patch needs an ack from the
On Mon, Jun 16, 2014 at 11:13:02AM -0300, Fabio Estevam wrote:
> On Wed, Jun 11, 2014 at 5:17 AM, Russell King - ARM Linux
> wrote:
>
> > The problem here is that we need more inteligence from CCF in order to
> > do that - we need it to be able to reprogram the dividers so
On Mon, Jun 16, 2014 at 12:11:17PM +0200, Denis Carikli wrote:
> The current BGR666 is not consistent with the other color mapings like BGR24.
> BGR666 should be in the same byte order than BGR24.
>
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
As I said probably around v10 time, I a
101 - 200 of 347 matches
Mail list logo
