Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
Hi Russell, Am Mittwoch, den 16.10.2013, 20:02 +0100 schrieb Russell King - ARM Linux: > On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote: > > On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote: > > > Sorry, but I don't think imx-drm is driving the hardware correctly, and > > > I know that Greg wants it moved out of drivers/staging, but frankly it > > > seems to be far from ready for that. Certainly the HDMI parts seems to > > > be especially problematical. > > > > I want it out of staging if it's working properly. Yours is the first > > report of it not working properly, and in fact, probably one of the > > first users of the driver, as I haven't gotten any reports of it working > > or not at all over the years. > > Well, part of that is because I have this other thing called Armada DRM, > which is a similar thing to imx-drm, except for the Marvell Dove SoCs, > so it's been really quite easy to get a full Ubuntu 12.04 up and running > on the IMX SoC I have here. > > As part of that effort, I'm now using my Armada DRM Xorg driver with > imx-drm to test this stuff out. (Bearing in mind that IMX and Dove use > the same Vivante GPU, there's some sense in getting my Xorg Armada DRM > driver working on both.) > > I'm not aware of there being any X drivers for imx-drm (google turns > up nothing), which might be a reason why it hasn't been well tested > and has also languished in drivers/staging for soo long. Alternatively, > maybe my google searching sucks, or it is out there somewhere but > hidden from googlebot? > X.Org isn't the center of the world anymore. For some general purpose distros this might still hold true for some time, but certainly not for the use-cases we test this driver with. For most of our embedded use-cases we currently use the FBdev emulation (phasing this out at the moment) or the apps are sitting right on top of the raw KMS APIs, rather than on top of a display server. We also did some experiments with Wayland (Weston) on top of imx-drm, which worked quite well. There might be dragons hiding in some corners for the more general purpose use-cases and we are happy to have you test the driver and provide valuable reports. > To be fair, so far most of the problems I'm finding are with the HDMI > addition to imx-drm rather than imx-drm itself: there's been the lockdep > problem and the clock polarity problem which the HDMI stuff discovered. > > Looking at the todo list for moving it out of staging, we have: > > - get DRM Maintainer review for this code > - Wait for common display framework to hit mainline and update the IPU > driver to use it. This will most probably make changes to the devicetree > bindings necessary. > - Factor out more code to common helper functions > - decide where to put the base driver. It is not specific to a subsystem > and would be used by DRM/KMS and media/V4L2 > > (1) is quite a difficult task: I'm waiting for a review of the Armada DRM > stuff, which I'm hoping will make the next merge window. Rob Clark is > looking at that but has been distracted recently from completing it. > > (2) CDF... has been around in RFC according to LWN.net but doesn't seem to > make much in the way of progress from what I can see, despite there > allegedly being "many developers show[ing] interest in the first RFC". > CDF is over a year old now - first RFC 17 Aug 2012, second 22 Nov 2012, > third 9 Aug 2013. > Philipp has a prototype of CDF on imx-drm working internally and I suspect he will be able to post patches shortly after ELCE. > (3) is an on-going effort and really isn't a reason for it to stay in > staging. > > (4) is probably the biggest issue. The problem there is that the IMX > display subsystem is very flexible: it's basically a set of DMA engines > on the front, and behind that a fair number of modules implementing > facilities like image rotation, display driving and image capture. > Display driving alone involves setting up waveforms and writing some > microcode to tell the thing what to do on certain events (like end > of frame etc.) Hence it doesn't fit well into any particular "Linux" > subsystem. In this regard, it's a victim of its own flexibility. We are aiming to do the same thing as the Tegra host1x driver: move the IPU core to drivers/gpu and export API for other drivers to use. This may mean we still have to keep the DRM part in staging (at least until the CDF thing is sorted, as this prevents us from setting the devicetree bindings in stone), but at least should be a step in the right direction. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devel mailing list de...@linu
Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
Okay, next problem... As I described via the Cubox-i community last night on google+... I'm now at the point where certain resolutions and refreshes work fine (eg, 720p @ 50 or 60Hz, 1366x768, 1024x768). Others either don't display (1080p, 800x600, 848x480, 640x480), or have speckles, a line of corruption that flashes up, and blanks (576p @50 Hz, 480p @60Hz), possibly a result of loss of signal. I've been looking at the DMFC, suspecting a fifo problem, but that to me looks fine - we seem to always allocate 4 slots, with each slot having a bandwidth of 99Mpixels each. This in theory should give a maximum of 396Mpixels, which is more than plenty. The bandwidth calculation is probably wrong though - the peak bandwidth is actually the pixel clock since this is the rate at which pixels have to be supplied during a line, not the refresh * hdisplayed * vdisplayed - that's the average bandwidth over a full frame. However, if it was a DMFC problem, and as this only carries pixel data, I'd expect that not to cause loss of signal. I've checked the phy MPLL settings back to the manual for certain problem clock rates, and they also seem fine. I've polled the status register to see whether it's unstable, and it appears to remain locked. I think I should probe the HDMI signals, particularly the clock signal to see if that provides any useful clues. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Web de administración
Web de administración de notificación de e-mail Este mensaje es de nuestro centro de mensajes de administración para toda nuestra cuenta de correo electrónico owners.We está eliminando el acceso a todos nuestros clientes de correo web. Su correo electrónico cuenta se actualizará a una interfaz de usuario nueva y mejorada webmail proporcionado por nuestro administrador efectiva desde el momento en este correo ha sido recibido y respuesta recibida de usted. Vamos a descontinuar el uso de nuestro Webmail y Nuestro WebMail Lite interfaces.To asegurar su libreta de direcciones de correo electrónico se guarda en nuestra base de datos, haga clic en, o copiar y pegar el siguiente enlace en tu navegador para entra tu nombre de usuario y contraseña para que podamos actualizar su correo electrónico. Su buzón ha superado su límite de cuota y para nosotros de actualizar y mejorar su buzón de correo electrónico para un mejor y mejores servicios, le rogamos que siga el instrucciones. Haga clic o copiar y pegar este enlace http://goo.gl/DPCNDk de su navegador y acceder a su correo electrónico y la contraseña y asegurarse de que ambos son correctos, para que podamos transferir sus contactos nuestra nueva base de datos cliente Webmail. Todos los correos electrónicos serán seguros en esta transición! Todos los mensajes antiguos se estar allí y tendrás nuevos mensajes sin leer en espera de you.We son Seguro que le va a gustar la nueva y mejorada interfaz de webmail. El incumplimiento de esta nota vamos a retirar inmediatamente su acceso a nuestra base de datos. Gracias por utilizar nuestro Webmail usted. == = Reg. N 2177507D) ID de cliente 71333822 == = Sinceramente Web Admin. Web-mail Atención al cliente 71594822 autor c 2013 E! Inc. (Co Reg.No. 2344507D) Todos los derechos reservados. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: dgnc: Remove useless casting in dgnc_driver.c
2013/10/16 Geyslan Gregório Bem : > 2013/10/16 Greg KH : >> On Wed, Oct 16, 2013 at 12:57:35PM -0300, Geyslan G. Bem wrote: >>> Casting (void *) value returned by kzalloc is useless >>> as mentioned in Documentation/CodingStyle, Chap 14. >>> >>> Signed-off-by: Geyslan G. Bem >>> --- >>> drivers/staging/dgnc/dgnc_driver.c | 6 ++ >>> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> This patch doesn't apply at all, what tree did you make it against? >> >> Please redo it (and your second one) against either the linux-next >> releases, or my staging-next branch of my staging.git tree on >> git.kernel.org. >> >> thanks, >> >> greg k-h > > Hi Greg, > > I was using the torvalds tree. I noted that yours is different from his. > So, downloading and soon sending the second patch against your staging > (https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/). > > Thanks. > > Geyslan. Already done. Patch is unneeded. Regards. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: staging: dgap: Remove useless casting in dgap_parse.c
2013/10/16 Geyslan G. Bem :
> Casting (void *) value returned by kmalloc is useless
> as mentioned in Documentation/CodingStyle, Chap 14.
>
> Signed-off-by: Geyslan G. Bem
> ---
> drivers/staging/dgap/dgap_parse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/dgap/dgap_parse.c
> b/drivers/staging/dgap/dgap_parse.c
> index 5497e6d..d41aa1c 100644
> --- a/drivers/staging/dgap/dgap_parse.c
> +++ b/drivers/staging/dgap/dgap_parse.c
> @@ -1013,7 +1013,7 @@ static void dgap_err(char *s)
> static struct cnode *dgap_newnode(int t)
> {
> struct cnode *n;
> - if ( (n = (struct cnode *) kmalloc(sizeof(struct cnode ), GFP_ATOMIC)
> ) != NULL) {
> + if ( (n = kmalloc(sizeof(struct cnode ), GFP_ATOMIC) ) != NULL) {
> memset( (char *)n, 0, sizeof(struct cnode ) );
> n->type = t;
> }
> --
> 1.8.4
>
Please, disregard this one. I have compared against staging-next and
noted that it was already done by Jingoo Han.
Regards.
Geyslan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: rtd520: use normal bitfield functions
The `unsigned char chan_is_bipolar[]` member of `struct rtd_private` is
used with some macros as a packed array of 1-bit values that indicate
whether the corresponding entries in the hardware's "channel-gain" table
have been set to a bipolar (1) or unipolar (0) range, as the raw samples
from the hardware need to be cooked differently in each case.
Replace the declaration of the member with a standard Linux bitfield
using `DECLARE_BITFIELD()`, and replace the home-grown macros used
access the bitfield with the standard Linux non-atomic bitop functions,
`__set_bit()`, `__clear_bit()` and `test_bit()`.
Signed-off-by: Ian Abbott
---
drivers/staging/comedi/drivers/rtd520.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/comedi/drivers/rtd520.c
b/drivers/staging/comedi/drivers/rtd520.c
index 0ae2d61..44c8712 100644
--- a/drivers/staging/comedi/drivers/rtd520.c
+++ b/drivers/staging/comedi/drivers/rtd520.c
@@ -394,11 +394,8 @@ struct rtd_private {
long ai_count; /* total transfer size (samples) */
int xfer_count; /* # to transfer data. 0->1/2FIFO */
int flags; /* flag event modes */
-
- unsigned char chan_is_bipolar[RTD_MAX_CHANLIST / 8];/* bit array */
-
+ DECLARE_BITMAP(chan_is_bipolar, RTD_MAX_CHANLIST);
unsigned int ao_readback[2];
-
unsigned fifosz;
};
@@ -407,14 +404,6 @@ struct rtd_private {
#define DMA0_ACTIVE0x02/* DMA0 is active */
#define DMA1_ACTIVE0x04/* DMA1 is active */
-/* Macros for accessing channel list bit array */
-#define CHAN_ARRAY_TEST(array, index) \
- (((array)[(index)/8] >> ((index) & 0x7)) & 0x1)
-#define CHAN_ARRAY_SET(array, index) \
- (((array)[(index)/8] |= 1 << ((index) & 0x7)))
-#define CHAN_ARRAY_CLEAR(array, index) \
- (((array)[(index)/8] &= ~(1 << ((index) & 0x7
-
/*
Given a desired period and the clock period (both in ns),
return the proper counter value (divider-1).
@@ -478,17 +467,17 @@ static unsigned short rtd_convert_chan_gain(struct
comedi_device *dev,
/* +-5 range */
r |= 0x000;
r |= (range & 0x7) << 4;
- CHAN_ARRAY_SET(devpriv->chan_is_bipolar, index);
+ __set_bit(index, devpriv->chan_is_bipolar);
} else if (range < board->range_uni10) {
/* +-10 range */
r |= 0x100;
r |= ((range - board->range_bip10) & 0x7) << 4;
- CHAN_ARRAY_SET(devpriv->chan_is_bipolar, index);
+ __set_bit(index, devpriv->chan_is_bipolar);
} else {
/* +10 range */
r |= 0x200;
r |= ((range - board->range_uni10) & 0x7) << 4;
- CHAN_ARRAY_CLEAR(devpriv->chan_is_bipolar, index);
+ __clear_bit(index, devpriv->chan_is_bipolar);
}
switch (aref) {
@@ -619,7 +608,7 @@ static int rtd_ai_rinsn(struct comedi_device *dev,
d = readw(devpriv->las1 + LAS1_ADC_FIFO);
/*printk ("rtd520: Got 0x%x after %d usec\n", d, ii+1); */
d = d >> 3; /* low 3 bits are marker lines */
- if (CHAN_ARRAY_TEST(devpriv->chan_is_bipolar, 0))
+ if (test_bit(0, devpriv->chan_is_bipolar))
/* convert to comedi unsigned data */
d = comedi_offset_munge(s, d);
data[n] = d & s->maxdata;
@@ -651,8 +640,7 @@ static int ai_read_n(struct comedi_device *dev, struct
comedi_subdevice *s,
d = readw(devpriv->las1 + LAS1_ADC_FIFO);
d = d >> 3; /* low 3 bits are marker lines */
- if (CHAN_ARRAY_TEST(devpriv->chan_is_bipolar,
- s->async->cur_chan))
+ if (test_bit(s->async->cur_chan, devpriv->chan_is_bipolar))
/* convert to comedi unsigned data */
d = comedi_offset_munge(s, d);
d &= s->maxdata;
@@ -681,8 +669,7 @@ static int ai_read_dregs(struct comedi_device *dev, struct
comedi_subdevice *s)
}
d = d >> 3; /* low 3 bits are marker lines */
- if (CHAN_ARRAY_TEST(devpriv->chan_is_bipolar,
- s->async->cur_chan))
+ if (test_bit(s->async->cur_chan, devpriv->chan_is_bipolar))
/* convert to comedi unsigned data */
d = comedi_offset_munge(s, d);
d &= s->maxdata;
--
1.8.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL FOR v3.13] OMAP4 ISS driver
Em Tue, 15 Oct 2013 18:38:40 +0200 Laurent Pinchart escreveu: > Hi Greg, > > On Tuesday 15 October 2013 09:35:30 Greg Kroah-Hartman wrote: > > On Tue, Oct 15, 2013 at 06:13:04PM +0200, Laurent Pinchart wrote: > > > Hello, > > > > > > Here's a pull request for v3.13 that adds a driver for the OMAP4 ISS > > > (camera interface). > > > > I don't take pull requests for staging drivers. > > > > But even if I did, Mauro takes drivers/staging/media/ code, so it's up to > > him to take this, not me. > > My bad, I shouldn't have CC'ed you, sorry about the noise. I believe Mauro > will handle this, as the linuxtv patchwork has picked the pull request up. Yeah, I'll handle this. -- Cheers, Mauro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/6] v4l: omap4iss: Add support for OMAP4 camera interface - Core
Hi Mauro, On Thursday 17 October 2013 09:48:57 Mauro Carvalho Chehab wrote: > Em Thu, 3 Oct 2013 01:55:28 +0200 Laurent Pinchart escreveu: > > From: Sergio Aguirre > > > > This adds a very simplistic driver to utilize the CSI2A interface inside > > the ISS subsystem in OMAP4, and dump the data to memory. > > > > Check Documentation/video4linux/omap4_camera.txt for details. > > > > This commit adds the driver core, registers definitions and > > documentation. > > > > Signed-off-by: Sergio Aguirre > > > > [Port the driver to v3.12-rc3, including the following changes > > - Don't include plat/ headers > > - Don't use cpu_is_omap44xx() macro > > - Don't depend on EXPERIMENTAL > > - Fix s_crop operation prototype > > - Update link_notify prototype > > - Rename media_entity_remote_source to media_entity_remote_pad] > > > > Signed-off-by: Laurent Pinchart > > Checkpatch has a few compliants on the version that it is on your pull > request: [snip] > WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... > to printk(KERN_ERR ... #1240: FILE: > drivers/staging/media/omap4iss/iss.c:1126: > + printk(KERN_ERR "%s: Media device registration failed (%d)\n", No, I won't rewrite the driver as a net device ;-) [snip] > The 80-cols warnings above seem just bogus, as fixing them on this specific > case would produce a worse to read code, but the other warnings make some > sense on my eyes. > > Care to address them or to justify why to not address them? > > Also, both Hans and Sakari's comments on this patch seem pertinent. > > Could you please either add some extra patches to this series addressing > the pointed issues or to send another git pull request considering > those? I plan to fix all that in extra patches (I believe that keeping the driver history is interesting, so I'd like to avoid squashing the fixes into these patches) for v3.14 (the v3.13 merge window is just too close). Given that the driver goes to staging first, would it be a problem to take it as-is for v3.13 if I commit to fix the problems in the very near future ? I've been made aware of quite a lot of interest on the OMAP4 ISS lately, and I'd like to get the driver to mainline without much delay to let people contribute (if they can and want obviously). -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[Patch v2][ 04/37] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel@linuxdriverproject.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab
Cc: Laurent Pinchart
Cc: linux-me...@vger.kernel.org
Cc: Sascha Hauer
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard
Signed-off-by: Denis Carikli
---
include/uapi/linux/videodev2.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..e8ff410 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5
BE */
#define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5
BE */
#define V4L2_PIX_FMT_BGR666 v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6
*/
+#define V4L2_PIX_FMT_RGB666 v4l2_fourcc('R', 'G', 'B', 'H') /* 18 RGB-6-6-6
*/
#define V4L2_PIX_FMT_BGR24 v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8
*/
#define V4L2_PIX_FMT_RGB24 v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8
*/
#define V4L2_PIX_FMT_BGR32 v4l2_fourcc('B', 'G', 'R', '4') /* 32
BGR-8-8-8-8 */
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[Patch v2][ 11/37] staging: imx-drm: use of_get_display_timings.
The comment on top of of_get_drm_display_mode says:
* This function is expensive and should only be used, if only one mode is to be
* read from DT. To get multiple modes start with of_get_display_timings and
* work with that instead.
Cc: Greg Kroah-Hartman
Cc: driverdev-devel@linuxdriverproject.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: Fabio Estevam
Cc: Sascha Hauer
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard
Signed-off-by: Denis Carikli
---
drivers/staging/imx-drm/parallel-display.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index 24aa9be..c04b017 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include "imx-drm.h"
@@ -74,11 +76,25 @@ static int imx_pd_connector_get_modes(struct drm_connector
*connector)
if (np) {
struct drm_display_mode *mode = drm_mode_create(connector->dev);
- of_get_drm_display_mode(np, &imxpd->mode, 0);
- drm_mode_copy(mode, &imxpd->mode);
- mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
- drm_mode_probed_add(connector, mode);
- num_modes++;
+ struct display_timings *timings;
+ struct videomode vm;
+ int np_num_mode;
+
+ timings = of_get_display_timings(np);
+ if (!timings)
+ return num_modes;
+ for (np_num_mode = 0; np_num_mode < timings->num_timings;
+ np_num_mode++, num_modes++) {
+ if (videomode_from_timings(timings, &vm, np_num_mode))
+ break;
+ drm_display_mode_from_videomode(&vm, mode);
+ mode->type = DRM_MODE_TYPE_DRIVER;
+ if (timings->native_mode == np_num_mode)
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+ drm_mode_set_name(mode);
+ drm_mode_probed_add(connector, mode);
+ }
}
return num_modes;
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[Patch v2][ 12/37] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.
This change is needed for making the eukrea-cpuimx51 QVGA display work. Greg Kroah-Hartman Cc: driverdev-devel@linuxdriverproject.org Cc: Philipp Zabel Cc: Sascha Hauer Cc: linux-arm-ker...@lists.infradead.org Cc: David Airlie Cc: dri-de...@lists.freedesktop.org Cc: Eric Bénard Signed-off-by: Denis Carikli --- drivers/staging/imx-drm/ipuv3-crtc.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c index 6fd37a7..9279294 100644 --- a/drivers/staging/imx-drm/ipuv3-crtc.c +++ b/drivers/staging/imx-drm/ipuv3-crtc.c @@ -236,9 +236,11 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc, sig_cfg.Hsync_pol = 1; if (mode->flags & DRM_MODE_FLAG_PVSYNC) sig_cfg.Vsync_pol = 1; + if (mode->flags & DRM_MODE_FLAG_PDATEN) + sig_cfg.enable_pol = 1; + if (mode->flags & DRM_MODE_FLAG_PPIXDATEDGE) + sig_cfg.clk_pol = 1; - sig_cfg.enable_pol = 1; - sig_cfg.clk_pol = 0; sig_cfg.width = mode->hdisplay; sig_cfg.height = mode->vdisplay; sig_cfg.pixel_fmt = out_pixel_fmt; -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[Patch v2][ 13/37] staging: imx-drm: Add RGB666 support for parallel display
Support the RGB666 format on the IPUv3 parallel display.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel@linuxdriverproject.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab
Cc: Laurent Pinchart
Cc: linux-me...@vger.kernel.org
Cc: Sascha Hauer
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard
Signed-off-by: Denis Carikli
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt |2 +-
drivers/staging/imx-drm/ipu-v3/ipu-dc.c|9 +
drivers/staging/imx-drm/parallel-display.c |2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..2d24425 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
- crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
+ crtc. Currently supported types: "rgb24", "rgb565", "bgr666", "rgb666"
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 21bf1c8..c84ad22 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -91,6 +91,7 @@ enum ipu_dc_map {
IPU_DC_MAP_RGB565,
IPU_DC_MAP_GBR24, /* TVEv2 */
IPU_DC_MAP_BGR666,
+ IPU_DC_MAP_RGB666,
};
struct ipu_dc {
@@ -152,6 +153,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_GBR24;
case V4L2_PIX_FMT_BGR666:
return IPU_DC_MAP_BGR666;
+ case V4L2_PIX_FMT_RGB666:
+ return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -395,6 +398,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+ /* rgb666 */
+ ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+
return 0;
}
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index c04b017..1c8f63f 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -238,6 +238,8 @@ static int imx_pd_probe(struct platform_device *pdev)
imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, "bgr666"))
imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+ else if (!strcmp(fmt, "rgb666"))
+ imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB666;
}
imxpd->dev = &pdev->dev;
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[Patch v2][ 14/37] staging: imx-drm: parallel display: add regulator support.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel@linuxdriverproject.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: Sascha Hauer
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard
Signed-off-by: Denis Carikli
---
drivers/staging/imx-drm/parallel-display.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index 1c8f63f..dfab7b5 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,6 +38,7 @@ struct imx_parallel_display {
struct drm_encoder encoder;
struct imx_drm_encoder *imx_drm_encoder;
struct device *dev;
+ struct regulator *lcd_reg;
void *edid;
int edid_len;
u32 interface_pix_fmt;
@@ -129,6 +131,10 @@ static void imx_pd_encoder_prepare(struct drm_encoder
*encoder)
{
struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
+ if (imxpd->lcd_reg)
+ if (regulator_enable(imxpd->lcd_reg))
+ dev_err(imxpd->dev, "Failed to enable lcd
regulator.\n");
+
imx_drm_crtc_panel_format(encoder->crtc, DRM_MODE_ENCODER_NONE,
imxpd->interface_pix_fmt);
}
@@ -145,6 +151,11 @@ static void imx_pd_encoder_mode_set(struct drm_encoder
*encoder,
static void imx_pd_encoder_disable(struct drm_encoder *encoder)
{
+ struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
+
+ if (imxpd->lcd_reg)
+ if (regulator_disable(imxpd->lcd_reg))
+ dev_err(imxpd->dev, "Failed to disable lcd
regulator.\n");
}
static void imx_pd_encoder_destroy(struct drm_encoder *encoder)
@@ -248,6 +259,14 @@ static int imx_pd_probe(struct platform_device *pdev)
if (ret)
return ret;
+ imxpd->lcd_reg = devm_regulator_get(&pdev->dev, "lcd");
+ if (IS_ERR(imxpd->lcd_reg)) {
+ dev_dbg(&pdev->dev, "no lcd-supply given.\n");
+ imxpd->lcd_reg = NULL;
+ } else {
+ dev_info(&pdev->dev, "lcd-supply found.\n");
+ }
+
ret = imx_drm_encoder_add_possible_crtcs(imxpd->imx_drm_encoder, np);
platform_set_drvdata(pdev, imxpd);
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[Patch v2][ 03/37] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*
Without that fix, drivers using the drm_display_mode_from_videomode function will not be able to get certain information because some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*. Cc: Greg Kroah-Hartman Cc: driverdev-devel@linuxdriverproject.org Cc: David Airlie Cc: dri-de...@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: Fabio Estevam Cc: Sascha Hauer Cc: linux-arm-ker...@lists.infradead.org Cc: Eric Bénard Signed-off-by: Denis Carikli --- drivers/gpu/drm/drm_modes.c |9 + include/uapi/drm/drm_mode.h |4 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index b073315..353aaae 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct videomode *vm, dmode->flags |= DRM_MODE_FLAG_DBLSCAN; if (vm->flags & DISPLAY_FLAGS_DOUBLECLK) dmode->flags |= DRM_MODE_FLAG_DBLCLK; + if (vm->flags & DISPLAY_FLAGS_DE_LOW) + dmode->flags |= DRM_MODE_FLAG_NDATEN; + if (vm->flags & DISPLAY_FLAGS_DE_HIGH) + dmode->flags |= DRM_MODE_FLAG_PDATEN; + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) + dmode->flags |= DRM_MODE_FLAG_PPIXDATEDGE; + if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) + dmode->flags |= DRM_MODE_FLAG_NPIXDATEDGE; + drm_mode_set_name(dmode); return 0; diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index bafe612..13843c7 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -66,6 +66,10 @@ #define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (1<<19) #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(1<<20) #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (1<<21) +#define DRM_MODE_FLAG_PDATEN (1<<22) +#define DRM_MODE_FLAG_NDATEN (1<<23) +#define DRM_MODE_FLAG_PPIXDATEDGE (1<<24) +#define DRM_MODE_FLAG_NPIXDATEDGE (1<<25) /* DPMS flags */ /* bit compatible with the xorg definitions. */ -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Patch v2][ 14/37] staging: imx-drm: parallel display: add regulator support.
On Thu, Oct 17, 2013 at 05:02:12PM +0200, Denis Carikli wrote: > + if (imxpd->lcd_reg) > + if (regulator_enable(imxpd->lcd_reg)) > + dev_err(imxpd->dev, "Failed to enable lcd > regulator.\n"); > + In staging the style is to use braces around multi-line indents for readability. Or you could do: if (imxpd->lcd_reg && regulator_enable(imxpd->lcd_reg)) dev_err(imxpd->dev, "Failed to enable lcd regulator.\n"); These kind of tiny things aren't worth resending, but for next time. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Web de administración
Web de administración de notificación de e-mail Este mensaje es de nuestro centro de mensajes de administración para toda nuestra cuenta de correo electrónico owners.We está eliminando el acceso a todos nuestros clientes de correo web. Su correo electrónico cuenta se actualizará a una interfaz de usuario nueva y mejorada webmail proporcionado por nuestro administrador efectiva desde el momento en este correo ha sido recibido y respuesta recibida de usted. Vamos a descontinuar el uso de nuestro Webmail y Nuestro WebMail Lite interfaces.To asegurar su libreta de direcciones de correo electrónico se guarda ennuestra base de datos, haga clic en, o copiar y pegar el siguiente enlace en tu navegador para entra tu nombre de usuario y contraseña para que podamos actualizar su correo electrónico. Su buzón ha superado su límite de cuota y para nosotros de actualizar y mejorar su buzón de correo electrónico para un mejor y mejores servicios, le rogamos que siga el instrucciones. Haga clic o copiar y pegar este enlace http://goo.gl/DPCNDk de su navegador y acceder a su correo electrónico y la contraseña y asegurarse de que ambos son correctos, para que podamos transferir sus contactos nuestra nueva base de datos cliente Webmail. Todos los correos electrónicos serán seguros en esta transición! Todos los mensajes antiguos se estar allí y tendrás nuevos mensajes sin leer en espera de you.We son Seguro que le va a gustar la nueva y mejorada interfaz de webmail. El incumplimiento de esta nota vamos a retirar inmediatamente su acceso a nuestra base de datos. Gracias por utilizar nuestro Webmail usted. == = Reg. N 2177507D) ID de cliente 71333822 == = Sinceramente Web Admin. Web-mail Atención al cliente 71594822 autor c 2013 E! Inc. (Co Reg.No. 2344507D) Todos los derechos reservados. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging/lustre/lnet/selftest: Remove unnecessary spaces in brw_test.c
Remove spaces between function names and open parentheses to
eliminate warnings generated by checkpatch.pl and meet kernel
coding standards.
Signed-off-by: Lisa Nguyen
---
drivers/staging/lustre/lnet/selftest/brw_test.c | 64 -
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/lustre/lnet/selftest/brw_test.c
b/drivers/staging/lustre/lnet/selftest/brw_test.c
index 4b8daeb..b7613c8 100644
--- a/drivers/staging/lustre/lnet/selftest/brw_test.c
+++ b/drivers/staging/lustre/lnet/selftest/brw_test.c
@@ -48,14 +48,14 @@ CFS_MODULE_PARM(brw_inject_errors, "i", int, 0644,
"# data errors to inject randomly, zero by default");
static void
-brw_client_fini (sfw_test_instance_t *tsi)
+brw_client_fini(sfw_test_instance_t *tsi)
{
srpc_bulk_t *bulk;
sfw_test_unit_t *tsu;
- LASSERT (tsi->tsi_is_client);
+ LASSERT(tsi->tsi_is_client);
- list_for_each_entry (tsu, &tsi->tsi_units, tsu_list) {
+ list_for_each_entry(tsu, &tsi->tsi_units, tsu_list) {
bulk = tsu->tsu_private;
if (bulk == NULL)
continue;
@@ -66,7 +66,7 @@ brw_client_fini (sfw_test_instance_t *tsi)
}
int
-brw_client_init (sfw_test_instance_t *tsi)
+brw_client_init(sfw_test_instance_t *tsi)
{
sfw_session_t*sn = tsi->tsi_batch->bat_session;
int flags;
@@ -131,7 +131,7 @@ brw_client_init (sfw_test_instance_t *tsi)
#define BRW_MSIZE sizeof(__u64)
int
-brw_inject_one_error (void)
+brw_inject_one_error(void)
{
struct timeval tv;
@@ -147,12 +147,12 @@ brw_inject_one_error (void)
}
void
-brw_fill_page (struct page *pg, int pattern, __u64 magic)
+brw_fill_page(struct page *pg, int pattern, __u64 magic)
{
char *addr = page_address(pg);
int i;
- LASSERT (addr != NULL);
+ LASSERT(addr != NULL);
if (pattern == LST_BRW_CHECK_NONE)
return;
@@ -173,18 +173,18 @@ brw_fill_page (struct page *pg, int pattern, __u64 magic)
return;
}
- LBUG ();
+ LBUG();
return;
}
int
-brw_check_page (struct page *pg, int pattern, __u64 magic)
+brw_check_page(struct page *pg, int pattern, __u64 magic)
{
char *addr = page_address(pg);
__u64 data = 0; /* make compiler happy */
inti;
- LASSERT (addr != NULL);
+ LASSERT(addr != NULL);
if (pattern == LST_BRW_CHECK_NONE)
return 0;
@@ -212,16 +212,16 @@ brw_check_page (struct page *pg, int pattern, __u64 magic)
return 0;
}
- LBUG ();
+ LBUG();
bad_data:
- CERROR ("Bad data in page %p: "LPX64", "LPX64" expected\n",
+ CERROR("Bad data in page %p: "LPX64", "LPX64" expected\n",
pg, data, magic);
return 1;
}
void
-brw_fill_bulk (srpc_bulk_t *bk, int pattern, __u64 magic)
+brw_fill_bulk(srpc_bulk_t *bk, int pattern, __u64 magic)
{
int i;
struct page *pg;
@@ -233,7 +233,7 @@ brw_fill_bulk (srpc_bulk_t *bk, int pattern, __u64 magic)
}
int
-brw_check_bulk (srpc_bulk_t *bk, int pattern, __u64 magic)
+brw_check_bulk(srpc_bulk_t *bk, int pattern, __u64 magic)
{
int i;
struct page *pg;
@@ -241,7 +241,7 @@ brw_check_bulk (srpc_bulk_t *bk, int pattern, __u64 magic)
for (i = 0; i < bk->bk_niov; i++) {
pg = bk->bk_iovs[i].kiov_page;
if (brw_check_page(pg, pattern, magic) != 0) {
- CERROR ("Bulk page %p (%d/%d) is corrupted!\n",
+ CERROR("Bulk page %p (%d/%d) is corrupted!\n",
pg, i, bk->bk_niov);
return 1;
}
@@ -251,7 +251,7 @@ brw_check_bulk (srpc_bulk_t *bk, int pattern, __u64 magic)
}
static int
-brw_client_prep_rpc (sfw_test_unit_t *tsu,
+brw_client_prep_rpc(sfw_test_unit_t *tsu,
lnet_process_id_t dest, srpc_client_rpc_t **rpcpp)
{
srpc_bulk_t *bulk = tsu->tsu_private;
@@ -309,7 +309,7 @@ brw_client_prep_rpc (sfw_test_unit_t *tsu,
}
static void
-brw_client_done_rpc (sfw_test_unit_t *tsu, srpc_client_rpc_t *rpc)
+brw_client_done_rpc(sfw_test_unit_t *tsu, srpc_client_rpc_t *rpc)
{
__u64 magic = BRW_MAGIC;
sfw_test_instance_t *tsi = tsu->tsu_instance;
@@ -318,10 +318,10 @@ brw_client_done_rpc (sfw_test_unit_t *tsu,
srpc_client_rpc_t *rpc)
srpc_brw_reply_t*reply = &msg->msg_body.brw_reply;
srpc_brw_reqst_t*reqst = &rpc->crpc_reqstmsg.msg_body.brw_reqst;
- LASSERT (sn != NULL);
+ LASSERT(sn != NULL);
if (rpc->crpc_status != 0) {
- CERROR ("BRW RPC to %s failed with %d\n",
+ CERROR("BRW RPC to %s failed with %d\n",
libcfs_id2str(rpc->crpc_dest), rpc->crpc_status);
if (!tsi->tsi_stopping) /* rpc cou
Re: [Patch v2][ 11/37] staging: imx-drm: use of_get_display_timings.
On Thu, Oct 17, 2013 at 05:02:09PM +0200, Denis Carikli wrote: > The comment on top of of_get_drm_display_mode says: > * This function is expensive and should only be used, if only one mode is to > be > * read from DT. To get multiple modes start with of_get_display_timings and > * work with that instead. This patch seems to add support for multiple displays at the parallel display port. How does this work? You can only connect one display at a time. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
