[PATCH 2/4] vmbus: add missing breaks

2014-02-21 Thread Gerd Hoffmann 
Signed-off-by: Gerd Hoffmann 
---
 drivers/hv/vmbus_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index b37c91b..2352ae48 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -899,10 +899,12 @@ static acpi_status vmbus_walk_resources(struct 
acpi_resource *res, void *ctx)
switch (res->type) {
case ACPI_RESOURCE_TYPE_IRQ:
irq = res->data.irq.interrupts[0];
+   break;
 
case ACPI_RESOURCE_TYPE_ADDRESS64:
hyperv_mmio_start = res->data.address64.minimum;
hyperv_mmio_size = res->data.address64.address_length;
+   break;
}
 
return AE_OK;
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/4] vmbus: use resource for hyperv mmio region

2014-02-21 Thread Gerd Hoffmann 
Use a resource for the hyperv mmio region instead of start/size
variables.  Register the region properly so it shows up in
/proc/iomem.

Signed-off-by: Gerd Hoffmann 
---
 drivers/hv/vmbus_drv.c | 16 ++--
 include/linux/hyperv.h |  3 +--
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 2352ae48..a14f603 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -43,10 +43,12 @@ static struct acpi_device  *hv_acpi_dev;
 static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
-u64 hyperv_mmio_start;
-EXPORT_SYMBOL_GPL(hyperv_mmio_start);
-u64 hyperv_mmio_size;
-EXPORT_SYMBOL_GPL(hyperv_mmio_size);
+
+struct resource hyperv_mmio = {
+   .name  = "hyperv mmio",
+   .flags = IORESOURCE_MEM,
+};
+EXPORT_SYMBOL_GPL(hyperv_mmio);
 
 static int vmbus_exists(void)
 {
@@ -902,8 +904,8 @@ static acpi_status vmbus_walk_resources(struct 
acpi_resource *res, void *ctx)
break;
 
case ACPI_RESOURCE_TYPE_ADDRESS64:
-   hyperv_mmio_start = res->data.address64.minimum;
-   hyperv_mmio_size = res->data.address64.address_length;
+   hyperv_mmio.start = res->data.address64.minimum;
+   hyperv_mmio.end = res->data.address64.maximum;
break;
}
 
@@ -933,6 +935,8 @@ static int vmbus_acpi_add(struct acpi_device *device)
 
if (ACPI_FAILURE(result))
goto acpi_walk_err;
+   if (hyperv_mmio.start && hyperv_mmio.end)
+   request_resource(&iomem_resource, &hyperv_mmio);
}
ret_val = 0;
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index be3028f..c93e342 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1459,8 +1459,7 @@ int hv_vss_init(struct hv_util_service *);
 void hv_vss_deinit(void);
 void hv_vss_onchannelcallback(void *);
 
-extern u64 hyperv_mmio_start;
-extern u64 hyperv_mmio_size;
+extern struct resource hyperv_mmio;
 
 /*
  * Negotiated version with the Host.
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/4] Drivers: hv: vmbus: Extract the mmio information from DSDT

2014-02-21 Thread Gerd Hoffmann 
From: "K. Y. Srinivasan" 

On Gen2 firmware, Hyper-V does not emulate the PCI bus. However, the MMIO
information is packaged up in DSDT. Extract this information and export it
for use by the synthetic framebuffer driver. This is the only driver that
needs this currently.

In this version of the patch mmio, I have updated the hyperv header file
(linux/hyperv.h) with mmio definitions.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/hv/vmbus_drv.c | 45 -
 include/linux/hyperv.h |  3 +++
 2 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 077bb1b..b37c91b 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -43,6 +43,10 @@ static struct acpi_device  *hv_acpi_dev;
 static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
+u64 hyperv_mmio_start;
+EXPORT_SYMBOL_GPL(hyperv_mmio_start);
+u64 hyperv_mmio_size;
+EXPORT_SYMBOL_GPL(hyperv_mmio_size);
 
 static int vmbus_exists(void)
 {
@@ -886,18 +890,19 @@ void vmbus_device_unregister(struct hv_device *device_obj)
 
 
 /*
- * VMBUS is an acpi enumerated device. Get the the IRQ information
- * from DSDT.
+ * VMBUS is an acpi enumerated device. Get the the information we
+ * need from DSDT.
  */
 
-static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *irq)
+static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
 {
+   switch (res->type) {
+   case ACPI_RESOURCE_TYPE_IRQ:
+   irq = res->data.irq.interrupts[0];
 
-   if (res->type == ACPI_RESOURCE_TYPE_IRQ) {
-   struct acpi_resource_irq *irqp;
-   irqp = &res->data.irq;
-
-   *((unsigned int *)irq) = irqp->interrupts[0];
+   case ACPI_RESOURCE_TYPE_ADDRESS64:
+   hyperv_mmio_start = res->data.address64.minimum;
+   hyperv_mmio_size = res->data.address64.address_length;
}
 
return AE_OK;
@@ -906,18 +911,32 @@ static acpi_status vmbus_walk_resources(struct 
acpi_resource *res, void *irq)
 static int vmbus_acpi_add(struct acpi_device *device)
 {
acpi_status result;
+   int ret_val = -ENODEV;
 
hv_acpi_dev = device;
 
result = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
-   vmbus_walk_resources, &irq);
+   vmbus_walk_resources, NULL);
 
-   if (ACPI_FAILURE(result)) {
-   complete(&probe_event);
-   return -ENODEV;
+   if (ACPI_FAILURE(result))
+   goto acpi_walk_err;
+   /*
+* The parent of the vmbus acpi device (Gen2 firmware) is the VMOD that
+* has the mmio ranges. Get that.
+*/
+   if (device->parent) {
+   result = acpi_walk_resources(device->parent->handle,
+   METHOD_NAME__CRS,
+   vmbus_walk_resources, NULL);
+
+   if (ACPI_FAILURE(result))
+   goto acpi_walk_err;
}
+   ret_val = 0;
+
+acpi_walk_err:
complete(&probe_event);
-   return 0;
+   return ret_val;
 }
 
 static const struct acpi_device_id vmbus_acpi_device_ids[] = {
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 344883d..be3028f 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1459,6 +1459,9 @@ int hv_vss_init(struct hv_util_service *);
 void hv_vss_deinit(void);
 void hv_vss_onchannelcallback(void *);
 
+extern u64 hyperv_mmio_start;
+extern u64 hyperv_mmio_size;
+
 /*
  * Negotiated version with the Host.
  */
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/4] hyperv-fb: add support for generation 2 virtual machines.

2014-02-21 Thread Gerd Hoffmann 
UEFI-based generation 2 virtual machines support vmbus devices only.
There is no pci bus.  Thus they use a different mechanism for the
graphics framebuffer:  Instead of using the vga pci bar a chunk of
memory muct be allocated from the hyperv mmio region declared using
APCI.  This patch implements support for it.

Based on a patch by Haiyang Zhang 

Signed-off-by: Gerd Hoffmann 
---
 drivers/video/hyperv_fb.c | 86 +--
 1 file changed, 60 insertions(+), 26 deletions(-)

diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 130708f..f956cd9 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -212,6 +213,7 @@ struct synthvid_msg {
 
 struct hvfb_par {
struct fb_info *info;
+   struct resource mem;
bool fb_ready; /* fb device is ready */
struct completion wait;
u32 synthvid_version;
@@ -460,13 +462,13 @@ static int synthvid_connect_vsp(struct hv_device *hdev)
goto error;
}
 
-   if (par->synthvid_version == SYNTHVID_VERSION_WIN7) {
+   if (par->synthvid_version == SYNTHVID_VERSION_WIN7)
screen_depth = SYNTHVID_DEPTH_WIN7;
-   screen_fb_size = SYNTHVID_FB_SIZE_WIN7;
-   } else {
+   else
screen_depth = SYNTHVID_DEPTH_WIN8;
-   screen_fb_size = SYNTHVID_FB_SIZE_WIN8;
-   }
+
+   screen_fb_size = hdev->channel->offermsg.offer.
+   mmio_megabytes * 1024 * 1024;
 
return 0;
 
@@ -627,26 +629,46 @@ static void hvfb_get_option(struct fb_info *info)
 /* Get framebuffer memory from Hyper-V video pci space */
 static int hvfb_getmem(struct fb_info *info)
 {
-   struct pci_dev *pdev;
-   ulong fb_phys;
+   struct hvfb_par *par = info->par;
+   struct pci_dev *pdev  = NULL;
void __iomem *fb_virt;
+   bool gen2vm = efi_enabled(EFI_BOOT);
+   int ret;
 
-   pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
+   par->mem.name = "hyperv_fb";
+   par->mem.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   if (gen2vm) {
+   ret = allocate_resource(&hyperv_mmio, &par->mem,
+   screen_fb_size,
+   0, -1,
+   screen_fb_size,
+   NULL, NULL);
+   if (ret != 0) {
+   pr_err("Unable to allocate framebuffer memory\n");
+   return -ENODEV;
+   }
+   } else {
+   pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
  PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
-   if (!pdev) {
-   pr_err("Unable to find PCI Hyper-V video\n");
-   return -ENODEV;
-   }
+   if (!pdev) {
+   pr_err("Unable to find PCI Hyper-V video\n");
+   return -ENODEV;
+   }
 
-   if (!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM) ||
-   pci_resource_len(pdev, 0) < screen_fb_size)
-   goto err1;
+   if (!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM) ||
+   pci_resource_len(pdev, 0) < screen_fb_size)
+   goto err1;
 
-   fb_phys = pci_resource_end(pdev, 0) - screen_fb_size + 1;
-   if (!request_mem_region(fb_phys, screen_fb_size, KBUILD_MODNAME))
-   goto err1;
+   par->mem.end = pci_resource_end(pdev, 0);
+   par->mem.start = par->mem.end - screen_fb_size + 1;
+   ret = request_resource(&pdev->resource[0], &par->mem);
+   if (ret != 0) {
+   pr_err("Unable to request framebuffer memory\n");
+   return -ENODEV;
+   }
+   }
 
-   fb_virt = ioremap(fb_phys, screen_fb_size);
+   fb_virt = ioremap(par->mem.start, screen_fb_size);
if (!fb_virt)
goto err2;
 
@@ -654,30 +676,42 @@ static int hvfb_getmem(struct fb_info *info)
if (!info->apertures)
goto err3;
 
-   info->apertures->ranges[0].base = pci_resource_start(pdev, 0);
-   info->apertures->ranges[0].size = pci_resource_len(pdev, 0);
-   info->fix.smem_start = fb_phys;
+   if (gen2vm) {
+   info->apertures->ranges[0].base = screen_info.lfb_base;
+   info->apertures->ranges[0].size = screen_info.lfb_size;
+   } else {
+   info->apertures->ranges[0].base = pci_resource_start(pdev, 0);
+   info->apertures->ranges[0].size = pci_resource_len(pdev, 0);
+   }
+
+   info->fix.smem_start = par->mem.start;
info->fix.smem_len = screen_fb_size;
info->screen_base = fb_virt;
info->screen_size = screen_fb_size;
 
-   pci_dev_put(pdev);
+   if (!gen2vm)
+   pci_d

[PATCH] mmc: sdhci: add support for realtek rts5250

2014-02-21 Thread micky_ching 
From: Micky Ching 

Add support for realtek rts5250 pci card reader. The card reader have
some problem with DDR50 mode, so add a new quirks2 for broken ddr50.

Signed-off-by: Micky Ching 
---
 drivers/mmc/host/sdhci-pci.c |   20 
 drivers/mmc/host/sdhci.c |3 ++-
 include/linux/mmc/sdhci.h|2 ++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index 0955777..fdc6121 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -610,6 +610,18 @@ static const struct sdhci_pci_fixes sdhci_via = {
.probe  = via_probe,
 };
 
+static int rtsx_probe_slot(struct sdhci_pci_slot *slot)
+{
+   slot->host->mmc->caps2 |= MMC_CAP2_HS200;
+   return 0;
+}
+
+static const struct sdhci_pci_fixes sdhci_rtsx = {
+   .quirks2= SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
+   SDHCI_QUIRK2_BROKEN_DDR50,
+   .probe_slot = rtsx_probe_slot,
+};
+
 static const struct pci_device_id pci_ids[] = {
{
.vendor = PCI_VENDOR_ID_RICOH,
@@ -732,6 +744,14 @@ static const struct pci_device_id pci_ids[] = {
},
 
{
+   .vendor = PCI_VENDOR_ID_REALTEK,
+   .device = 0x5250,
+   .subvendor  = PCI_ANY_ID,
+   .subdevice  = PCI_ANY_ID,
+   .driver_data= (kernel_ulong_t)&sdhci_rtsx,
+   },
+
+   {
.vendor = PCI_VENDOR_ID_INTEL,
.device = PCI_DEVICE_ID_INTEL_MRST_SD0,
.subvendor  = PCI_ANY_ID,
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9ddef47..8958edc 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3020,7 +3020,8 @@ int sdhci_add_host(struct sdhci_host *host)
} else if (caps[1] & SDHCI_SUPPORT_SDR50)
mmc->caps |= MMC_CAP_UHS_SDR50;
 
-   if (caps[1] & SDHCI_SUPPORT_DDR50)
+   if ((caps[1] & SDHCI_SUPPORT_DDR50) &&
+   !(host->quirks2 & SDHCI_QUIRK2_BROKEN_DDR50))
mmc->caps |= MMC_CAP_UHS_DDR50;
 
/* Does the host need tuning for SDR50? */
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 362927c4..7be12b8 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -100,6 +100,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_BROKEN_HOST_CONTROL   (1<<5)
 /* Controller does not support HS200 */
 #define SDHCI_QUIRK2_BROKEN_HS200  (1<<6)
+/* Controller does not support DDR50 */
+#define SDHCI_QUIRK2_BROKEN_DDR50  (1<<7)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path

2014-02-21 Thread Zhao, Gang 
On Fri, 2014-02-21 at 15:38:56 +0800, Dan Carpenter wrote:
> I don't think this is the right thing because it is needless code.
> Overall it doesn't really simplify anything.
>
> You are worried that reviewers will be confused and think there is a
> leak in et131x_rx_dma_memory_alloc() and then add a kfree() which breaks
> the code.  [...]

AFAIK, this doesn't break the code. the relevant code in
et131x_rx_dma_memory_free() is:

/* Free the FBR Lookup Table */
kfree(rx_ring->fbr[0]);
kfree(rx_ring->fbr[1]);

By setting rx->fbr[0] to NULL after freeing rx->fbr[0] in
et131x_rx_dma_memory_alloc(), et131x_rx_dma_memory_free() won't free
rx->fbr[0] twice, and kree(NULL) is legal.

> I think you are right that a reviewer would initially wonder
> why the code does not call kfree() but then you do a search for fb[0]
> and it becomes obvious.

The reviewer won't want to search after adding the kfree(). :)

>
> If we add your patch and the reviewer does a search for fb[0] then it is
> confusing what the right thing to do is.

My fault. I should remove that two lines of code in
et131x_rx_dma_memory_free(), although they don't break the code.

>
> These kinds of "free later" code, are not the most common way to do
> things in the kernel but they are used other places as well.

When the freeing code is huge and will let the real code logic not so
clear, it's OK to do things that way. I don't want to eliminate them at
all. My change just let a piece of memory "freed earlier", to make the
code a little more readable.

I doubt no one except me care about this, and it doesn't need the effort
to send a v2 about this(remove two lines of code in et131x_rx_dma_memory_free)?

>
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path

2014-02-21 Thread Dan Carpenter 
Come on...  :/

Don't randomly add a pointless kfree() to one error path when there are
four later error paths in this function that don't have a kfree().  It
just makes the code more difficult to understand for no reason.

And we're not going to add a comment to every single error path
either.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path

2014-02-21 Thread Dan Carpenter 
On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote:
> > If we add your patch and the reviewer does a search for fb[0] then it is
> > confusing what the right thing to do is.
> 
> My fault. I should remove that two lines of code in
> et131x_rx_dma_memory_free(), although they don't break the code.
> 

Think about what you are saying here for a minute.

regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv7][ 4/7] staging: imx-drm: Use de-active and pixelclk-active display-timings.

2014-02-21 Thread Denis Carikli 
If de-active and/or pixelclk-active properties were set in the
display-timings DT node, they were not used.

Instead the data-enable and the pixel data clock polarity
were hardcoded.

This change is needed for making the eukrea-cpuimx51
  QVGA display work.

Cc: Eric Bénard 
Cc: Greg Kroah-Hartman 
Cc: Sascha Hauer 
Cc: de...@driverdev.osuosl.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Denis Carikli 
---
ChangeLog v6->v7:
- Shrinked even more the Cc list.
- Rebased the patch
- val is now initialized in imx_pd_connector_get_modes

ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
- Removed wrong coments from the code.
- Corrected the code style of the "if (!!val)"

ChangeLog v3->v4:
- The old patch was named "staging: imx-drm: ipuv3-crtc: don't harcode some 
mode".
- Reworked the patch entierly: we now takes the mode flags from the device tree.

ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Ajusted the flags to match the changes in "drm: Add the lacking
  DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
---
 drivers/staging/imx-drm/imx-drm.h  |3 +++
 drivers/staging/imx-drm/ipuv3-crtc.c   |8 ++--
 drivers/staging/imx-drm/parallel-display.c |   27 +++
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm.h 
b/drivers/staging/imx-drm/imx-drm.h
index ae90c9c..dfdc180 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -5,6 +5,9 @@
 
 #define IPU_PIX_FMT_GBR24  v4l2_fourcc('G', 'B', 'R', '3')
 
+#define IMXDRM_MODE_FLAG_DE_HIGH   (1<<0)
+#define IMXDRM_MODE_FLAG_PIXDATA_POSEDGE   (1<<1)
+
 struct drm_crtc;
 struct drm_connector;
 struct drm_device;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 22be104..fbb3793 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -156,8 +156,12 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
 
-   sig_cfg.enable_pol = 1;
-   sig_cfg.clk_pol = 1;
+   if (mode->private_flags & IMXDRM_MODE_FLAG_DE_HIGH)
+   sig_cfg.enable_pol = 1;
+
+   if (mode->private_flags & IMXDRM_MODE_FLAG_PIXDATA_POSEDGE)
+   sig_cfg.clk_pol = 1;
+
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index bc2946e..3f7f09d 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -75,7 +75,34 @@ static int imx_pd_connector_get_modes(struct drm_connector 
*connector)
 
if (np) {
struct drm_display_mode *mode = drm_mode_create(connector->dev);
+   struct device_node *timings_np;
+   struct device_node *mode_np;
+   u32 val = 1;
+
of_get_drm_display_mode(np, &imxpd->mode, OF_USE_NATIVE_MODE);
+
+   timings_np = of_get_child_by_name(np, "display-timings");
+   if (timings_np) {
+   /* get the display mode node */
+   mode_np = of_parse_phandle(timings_np,
+  "native-mode", 0);
+   if (!mode_np)
+   mode_np = of_get_next_child(timings_np, NULL);
+
+   /* set de-active to 1 if not set */
+   of_property_read_u32(mode_np, "de-active", &val);
+   if (val) {
+   imxpd->mode.private_flags |=
+   IMXDRM_MODE_FLAG_DE_HIGH;
+   }
+
+   /* set pixelclk-active to 1 if not set */
+   of_property_read_u32(mode_np, "pixelclk-active", &val);
+   if (val) {
+   imxpd->mode.private_flags |=
+   IMXDRM_MODE_FLAG_PIXDATA_POSEDGE;
+   }
+   }
drm_mode_copy(mode, &imxpd->mode);
mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
drm_mode_probed_add(connector, mode);
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv7][ 5/7] staging: imx-drm: parallel display: add regulator support.

2014-02-21 Thread Denis Carikli 
Cc: Alexander Shiyan 
Cc: Eric Bénard 
Cc: Greg Kroah-Hartman 
Cc: Marek Vasut 
Cc: Sascha Hauer 
Cc: driverdev-devel@linuxdriverproject.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Denis Carikli 
---
ChangeLog v6->v7:
- Shrinked even more the Cc list.
- Rebased the patch and included video/of_display_timing.h
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |1 +
 drivers/staging/imx-drm/parallel-display.c |   13 +
 2 files changed, 14 insertions(+)

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 2d24425..4dd7ce5 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -28,6 +28,7 @@ Required properties:
 - compatible: Should be "fsl,imx-parallel-display"
 - crtc: the crtc this display is connected to, see below
 Optional properties:
+- display-supply : phandle to the regulator device tree node if needed.
 - interface_pix_fmt: How this display is connected to the
   crtc. Currently supported types: "rgb24", "rgb565", "bgr666", "rgb666"
 - edid: verbatim EDID data block describing attached display.
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index 3f7f09d..d65dad4 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 
 
@@ -36,6 +37,7 @@ struct imx_parallel_display {
struct drm_encoder encoder;
struct imx_drm_encoder *imx_drm_encoder;
struct device *dev;
+   struct regulator *disp_reg;
void *edid;
int edid_len;
u32 interface_pix_fmt;
@@ -141,6 +143,9 @@ static void imx_pd_encoder_prepare(struct drm_encoder 
*encoder)
 {
struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
 
+   if (regulator_enable(imxpd->disp_reg))
+   dev_err(imxpd->dev, "Failed to enable regulator.\n");
+
imx_drm_crtc_panel_format(encoder->crtc, DRM_MODE_ENCODER_NONE,
imxpd->interface_pix_fmt);
 }
@@ -157,6 +162,10 @@ 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 (regulator_disable(imxpd->disp_reg))
+   dev_err(imxpd->dev, "Failed to disable regulator.\n");
 }
 
 static void imx_pd_encoder_destroy(struct drm_encoder *encoder)
@@ -260,6 +269,10 @@ static int imx_pd_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   imxpd->disp_reg = devm_regulator_get(&pdev->dev, "display");
+   if (IS_ERR(imxpd->disp_reg))
+   return PTR_ERR(imxpd->disp_reg);
+
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

[PATCHv7][ 3/7] staging: imx-drm: Correct BGR666 and the board's dts that use them.

2014-02-21 Thread Denis Carikli 
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.

Cc: Greg Kroah-Hartman 
Cc: Eric Bénard 
Cc: Marek Vasut 
Cc: Sascha Hauer 
Cc: de...@driverdev.osuosl.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Denis Carikli 
---
ChangeLog v6->v7:
- Shrinked even more the Cc list.

ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
- Added a better explanation of the change.

ChangeLog v5:
- New patch.
---
 arch/arm/boot/dts/imx51-apf51dev.dts|2 +-
 arch/arm/boot/dts/imx53-m53evk.dts  |2 +-
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c |4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx51-apf51dev.dts 
b/arch/arm/boot/dts/imx51-apf51dev.dts
index c29cfa9..bff3201 100644
--- a/arch/arm/boot/dts/imx51-apf51dev.dts
+++ b/arch/arm/boot/dts/imx51-apf51dev.dts
@@ -19,7 +19,7 @@
display@di1 {
compatible = "fsl,imx-parallel-display";
crtcs = <&ipu 0>;
-   interface-pix-fmt = "bgr666";
+   interface-pix-fmt = "rgb666";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ipu_disp1>;
 
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts 
b/arch/arm/boot/dts/imx53-m53evk.dts
index e8d11e2..a984498 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -24,7 +24,7 @@
display@di1 {
compatible = "fsl,imx-parallel-display";
crtcs = <&ipu 1>;
-   interface-pix-fmt = "bgr666";
+   interface-pix-fmt = "rgb666";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ipu_disp1>;
 
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 617e65b..b11a2aa 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -397,9 +397,9 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
 
/* bgr666 */
ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
-   ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
+   ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue */
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 */
+   ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */
 
/* bgr24 */
ipu_dc_map_clear(priv, IPU_DC_MAP_BGR24);
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv7][ 2/7] staging: imx-drm: Add RGB666 support for parallel display.

2014-02-21 Thread Denis Carikli 
Cc: Greg Kroah-Hartman 
Cc: Eric Bénard 
Cc: Marek Vasut 
Cc: Sascha Hauer 
Cc: de...@driverdev.osuosl.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Denis Carikli 
---
ChangeLog v6->v7:
- Shrinked even more the Cc list.

ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.

ChangeLog v3->v5:
- Use the correct RGB order.

ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Removed the commit message long desciption that was just a copy of the short
  description.
- Rebased the patch.
- Fixed a copy-paste error in the ipu_dc_map_clear parameter.
---
 .../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 d0e3bc3..617e65b 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -92,6 +92,7 @@ enum ipu_dc_map {
IPU_DC_MAP_GBR24, /* TVEv2 */
IPU_DC_MAP_BGR666,
IPU_DC_MAP_BGR24,
+   IPU_DC_MAP_RGB666,
 };
 
 struct ipu_dc {
@@ -155,6 +156,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_BGR666;
case V4L2_PIX_FMT_BGR24:
return IPU_DC_MAP_BGR24;
+   case V4L2_PIX_FMT_RGB666:
+   return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -404,6 +407,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */
 
+   /* rgb666 */
+   ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+
return 0;
 }
 
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index 351d61d..bc2946e 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -223,6 +223,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] hyperv-fb: kick off efifb early

2014-02-21 Thread Gerd Hoffmann 
Remove firmware framebuffer before initializing hyperv-fb.  Needed
on gen2 virtual machines.   Letting register_framebuffer handle the
switchover results in efifb still being active while hyperv graphics
are initialized, which in turn can make the linux kernel hang.

Signed-off-by: Gerd Hoffmann 
---
 drivers/video/hyperv_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index f956cd9..3901ffe 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -683,6 +683,7 @@ static int hvfb_getmem(struct fb_info *info)
info->apertures->ranges[0].base = pci_resource_start(pdev, 0);
info->apertures->ranges[0].size = pci_resource_len(pdev, 0);
}
+   remove_conflicting_framebuffers(info->apertures, "hyperv-fb", false);
 
info->fix.smem_start = par->mem.start;
info->fix.smem_len = screen_fb_size;
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 4/4] hyperv-fb: add support for generation 2 virtual machines.

2014-02-21 Thread KY Srinivasan 


> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, February 21, 2014 12:57 AM
> To: linux-fb...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; gre...@linuxfoundation.org; KY Srinivasan;
> Haiyang Zhang; jasow...@redhat.com; Gerd Hoffmann; Jean-Christophe
> Plagniol-Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...
> Subject: [PATCH 4/4] hyperv-fb: add support for generation 2 virtual machines.
> 
> UEFI-based generation 2 virtual machines support vmbus devices only.
> There is no pci bus.  Thus they use a different mechanism for the
> graphics framebuffer:  Instead of using the vga pci bar a chunk of
> memory muct be allocated from the hyperv mmio region declared using
> APCI.  This patch implements support for it.
> 
> Based on a patch by Haiyang Zhang 
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/video/hyperv_fb.c | 86 +---
> ---
>  1 file changed, 60 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
> index 130708f..f956cd9 100644
> --- a/drivers/video/hyperv_fb.c
> +++ b/drivers/video/hyperv_fb.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
> 
> @@ -212,6 +213,7 @@ struct synthvid_msg {
> 
>  struct hvfb_par {
>   struct fb_info *info;
> + struct resource mem;
>   bool fb_ready; /* fb device is ready */
>   struct completion wait;
>   u32 synthvid_version;
> @@ -460,13 +462,13 @@ static int synthvid_connect_vsp(struct hv_device
> *hdev)
>   goto error;
>   }
> 
> - if (par->synthvid_version == SYNTHVID_VERSION_WIN7) {
> + if (par->synthvid_version == SYNTHVID_VERSION_WIN7)
>   screen_depth = SYNTHVID_DEPTH_WIN7;
> - screen_fb_size = SYNTHVID_FB_SIZE_WIN7;
> - } else {
> + else
>   screen_depth = SYNTHVID_DEPTH_WIN8;
> - screen_fb_size = SYNTHVID_FB_SIZE_WIN8;
> - }
> +
> + screen_fb_size = hdev->channel->offermsg.offer.
> + mmio_megabytes * 1024 * 1024;
> 
>   return 0;
> 
> @@ -627,26 +629,46 @@ static void hvfb_get_option(struct fb_info *info)
>  /* Get framebuffer memory from Hyper-V video pci space */
>  static int hvfb_getmem(struct fb_info *info)
>  {
> - struct pci_dev *pdev;
> - ulong fb_phys;
> + struct hvfb_par *par = info->par;
> + struct pci_dev *pdev  = NULL;
>   void __iomem *fb_virt;
> + bool gen2vm = efi_enabled(EFI_BOOT);

Gerd,
efi_enabled() returns an int and not a bool. That is the fix that Haiyang made 
last night.

K. Y
> + int ret;
> 
> - pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
> + par->mem.name = "hyperv_fb";
> + par->mem.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> + if (gen2vm) {
> + ret = allocate_resource(&hyperv_mmio, &par->mem,
> + screen_fb_size,
> + 0, -1,
> + screen_fb_size,
> + NULL, NULL);
> + if (ret != 0) {
> + pr_err("Unable to allocate framebuffer memory\n");
> + return -ENODEV;
> + }
> + } else {
> + pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
> PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
> - if (!pdev) {
> - pr_err("Unable to find PCI Hyper-V video\n");
> - return -ENODEV;
> - }
> + if (!pdev) {
> + pr_err("Unable to find PCI Hyper-V video\n");
> + return -ENODEV;
> + }
> 
> - if (!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM) ||
> - pci_resource_len(pdev, 0) < screen_fb_size)
> - goto err1;
> + if (!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM) ||
> + pci_resource_len(pdev, 0) < screen_fb_size)
> + goto err1;
> 
> - fb_phys = pci_resource_end(pdev, 0) - screen_fb_size + 1;
> - if (!request_mem_region(fb_phys, screen_fb_size,
> KBUILD_MODNAME))
> - goto err1;
> + par->mem.end = pci_resource_end(pdev, 0);
> + par->mem.start = par->mem.end - screen_fb_size + 1;
> + ret = request_resource(&pdev->resource[0], &par->mem);
> + if (ret != 0) {
> + pr_err("Unable to request framebuffer memory\n");
> + return -ENODEV;
> + }
> + }
> 
> - fb_virt = ioremap(fb_phys, screen_fb_size);
> + fb_virt = ioremap(par->mem.start, screen_fb_size);
>   if (!fb_virt)
>   goto err2;
> 
> @@ -654,30 +676,42 @@ static int hvfb_getmem(struct fb_info *info)
>   if (!info->apertures)
>   goto err3;
> 
> - info->apertures->ranges[0].base = pci_resource_start(pdev, 0);
> - info->apertures->ranges[0].size = pci_resource_len(pd

Question about staging drivers

2014-02-21 Thread Mark Hounschell 
When a kernel subsystem undergoes a global change such as the serial
subsystem has been since 3.5 or so, if a driver is in staging, does it
automatically get those changes if they are applicable to it?

Thanks
Mark
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Question about staging drivers

2014-02-21 Thread Greg KH 
On Fri, Feb 21, 2014 at 10:37:26AM -0500, Mark Hounschell wrote:
> When a kernel subsystem undergoes a global change such as the serial
> subsystem has been since 3.5 or so, if a driver is in staging, does it
> automatically get those changes if they are applicable to it?

Yes it does.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Question about staging drivers

2014-02-21 Thread Dan Carpenter 
On Fri, Feb 21, 2014 at 10:37:26AM -0500, Mark Hounschell wrote:
> When a kernel subsystem undergoes a global change such as the serial
> subsystem has been since 3.5 or so, if a driver is in staging, does it
> automatically get those changes if they are applicable to it?

Yes.  If you change an API then you have to change all the users as well
including staging.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv7][ 4/7] staging: imx-drm: Use de-active and pixelclk-active display-timings.

2014-02-21 Thread Lothar Waßmann 
Hi,

Denis Carikli wrote:
> If de-active and/or pixelclk-active properties were set in the
> display-timings DT node, they were not used.
> 
> Instead the data-enable and the pixel data clock polarity
> were hardcoded.
> 
> This change is needed for making the eukrea-cpuimx51
>   QVGA display work.
> 
> Cc: Eric Bénard 
> Cc: Greg Kroah-Hartman 
> Cc: Sascha Hauer 
> Cc: de...@driverdev.osuosl.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Denis Carikli 
> ---
> ChangeLog v6->v7:
> - Shrinked even more the Cc list.
> - Rebased the patch
> - val is now initialized in imx_pd_connector_get_modes
> 
> ChangeLog v5->v6:
> - Remove people not concerned by this patch from the Cc list.
> - Removed wrong coments from the code.
> - Corrected the code style of the "if (!!val)"
> 
> ChangeLog v3->v4:
> - The old patch was named "staging: imx-drm: ipuv3-crtc: don't harcode some 
> mode".
> - Reworked the patch entierly: we now takes the mode flags from the device 
> tree.
> 
> ChangeLog v2->v3:
> - Added some interested people in the Cc list.
> - Ajusted the flags to match the changes in "drm: Add the lacking
>   DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
> ---
>  drivers/staging/imx-drm/imx-drm.h  |3 +++
>  drivers/staging/imx-drm/ipuv3-crtc.c   |8 ++--
>  drivers/staging/imx-drm/parallel-display.c |   27 +++
>  3 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/imx-drm/imx-drm.h 
> b/drivers/staging/imx-drm/imx-drm.h
> index ae90c9c..dfdc180 100644
> --- a/drivers/staging/imx-drm/imx-drm.h
> +++ b/drivers/staging/imx-drm/imx-drm.h
> @@ -5,6 +5,9 @@
>  
>  #define IPU_PIX_FMT_GBR24v4l2_fourcc('G', 'B', 'R', '3')
>  
> +#define IMXDRM_MODE_FLAG_DE_HIGH (1<<0)
> +#define IMXDRM_MODE_FLAG_PIXDATA_POSEDGE (1<<1)
> +
CodingStyle: spaces around operators...?


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Android / binder: Fix broken walk in binder_node_release()

2014-02-21 Thread Greg Kroah-Hartman 
On Thu, Feb 20, 2014 at 02:22:53PM +0100, Compostella, Jeremy wrote:
> From: "Compostella, Jeremy" 
> 
> This bug can manifest itself in several situations, here is the one that made 
> me
> hunt it last week:
> 
> When an Android device is encrypted, Android starts all the init services of
> core and main levels, then it asks for the password and checks it trying to
> mount /data.  On success, it kills all the main services, mount /data and
> restart all the main services.
> 
> Unfortunately, on restart of those main services we observe :
> 
> DisplayManager   Could not get display information from display manager.
> DisplayManager   android.os.DeadObjectException
> DisplayManager   at android.os.BinderProxy.transact(Native Method)
> DisplayManager   at 
> android.hardware.display.IDisplayManager$Stub$Proxy.getDisplayInfo(IDisplayManager.java:228)
> DisplayManager   at 
> android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:117)
> DisplayManager   at 
> android.hardware.display.DisplayManagerGlobal.getCompatibleDisplay(DisplayManagerGlobal.java:176)
> DisplayManager   at 
> android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:96)
> DisplayManager   at 
> android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:74)
> [...]
> 
> Which means that the 'display' service is registered into the service_manager
> but point to a dead object (understand died process).  This error is the first
> one of a chain of missing "remote" objects causing the death of processes 
> until
> the system can recovery by itself a few seconds later.
> 
> The binder driver allows a "process" to ask a notification when a particular
> reference die.  In that case, the binder driver associate a death object to 
> this
> reference.
> 
> When the system_server process died, the file descriptor to the binder driver 
> is
> automatically released and the binder driver will walk all the references
> associated to this process to unallocate them.  When such a reference has a
> death object associated it will execute a task to notify the death to the
> previously register process usually the service_manager process.
> 
> The bug is that this walk on all the references is broken due to an
> unfornate refactoring made by the following patch :
> 
> commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a
> Author: Mirsal Ennaime 
> Date:   Tue Mar 12 11:41:59 2013 +0100
> 
> which break the loop if the current reference does not have a death object
> instead of continuing to the next reference.  As a consequence all the next
> references will not be correctly unallocate and no death notification will be
> sent for them.
> 
> Signed-off-by: Jeremy Compostella 
> ---
>  drivers/staging/android/binder.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Thanks, but this fix has already been submitted, and has been part of
the Android kernel git tree for a while with the authorship of someone
else, so I'll use that patch instead when applying it.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] Staging: comedi: addi-data: comment cleanup in hwdrv_apci035.c

2014-02-21 Thread Chase Southwood 
This patch further cleans up the comments in hwdrv_apci035.c, converting
them to kernel style and removing some commented conditional statements
that are unused.

Signed-off-by: Chase Southwood 
---

I decided to return to the first driver I touched.  I found some more
things that could be cleaned up a little.

 .../comedi/drivers/addi-data/hwdrv_apci035.c   | 106 +++--
 1 file changed, 32 insertions(+), 74 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
index 8ce3335..7c40535 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
@@ -188,17 +188,14 @@ static int i_APCI035_ConfigTimerWatchdog(struct 
comedi_device *dev,
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
-   //
+
/* Set the reload value */
-   //
outl(data[3], devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 4);
-   /*/
+
/* Set the time unit */
-   /*/
outl(data[2], devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 8);
if (data[0] == ADDIDATA_TIMER) {
 
-   /**/
/* Set the mode : */
/* - Disable the hardware */
/* - Disable the counter mode */
@@ -206,23 +203,19 @@ static int i_APCI035_ConfigTimerWatchdog(struct 
comedi_device *dev,
/* - Disable the reset*/
/* - Enable the timer mode*/
/* - Set the timer mode   */
-   /**/
 
ui_Command =
(ui_Command & 0xFFF719E2UL) | ui_Mode << 13UL | 0x10UL;
 
-   }   /* if (data[0] == ADDIDATA_TIMER) */
-   else {
+   } else {
if (data[0] == ADDIDATA_WATCHDOG) {
 
-   /**/
/* Set the mode : */
/* - Disable the hardware */
/* - Disable the counter mode */
/* - Disable the warning  */
/* - Disable the reset*/
/* - Disable the timer mode   */
-   /**/
 
ui_Command = ui_Command & 0xFFF819E2UL;
 
@@ -234,73 +227,61 @@ static int i_APCI035_ConfigTimerWatchdog(struct 
comedi_device *dev,
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
-   //
+
/* Disable the hardware trigger */
-   //
ui_Command = ui_Command & 0xF89FUL;
if (data[4] == ADDIDATA_ENABLE) {
-   /**/
+
/* Set the hardware trigger level */
-   /**/
ui_Command = ui_Command | (data[5] << 5);
}
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
-   /*/
+
/* Disable the hardware gate */
-   /*/
ui_Command = ui_Command & 0xF87FUL;
if (data[6] == ADDIDATA_ENABLE) {
-   /***/
+
/* Set the hardware gate level */
-   /***/
ui_Command = ui_Command | (data[7] << 7);
}
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
-   /***/
+
/* Disable the hardware output */
-   /***/
ui_Command = ui_Command & 0xF9FBUL;
-   /*/
+
/* Set the hardware output level */
-   /*/
ui_Command = ui_Command | (data[8] << 2);
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
if (data[9] == ADDIDATA_ENABLE) {
-   //
+
/* Set the reload value */
-   //
outl(data[11],
devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 24);
-   /**/
+
/* Set the time unite */
-   /*

[PATCH 3/3] Staging: comedi: addi-data: fix a couple of lines that are too long

2014-02-21 Thread Chase Southwood 
There are a couple of cases where a comment being on the same line as a
statement is causing the line to be over 80 characters long.  This is an
easy fix; move these comments to the previous line.

Signed-off-by: Chase Southwood 
---
 drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
index 34e5321..d5c4e71 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
@@ -565,7 +565,9 @@ static int i_APCI035_Reset(struct comedi_device *dev)
 
for (i_Count = 1; i_Count <= 4; i_Count++) {
i_WatchdogNbr = i_Count;
-   outl(0x0, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 0);
/* stop all timers */
+
+   /* stop all timers */
+   outl(0x0, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 0);
}
outl(0x0, devpriv->iobase + 128 + 12);  /* Disable the warning delay */
 
@@ -624,11 +626,14 @@ static void v_APCI035_Interrupt(int irq, void *d)
 
/* Read the digital temperature value */
ui_DigitalTemperature = inl(devpriv->iobase + 128 + 60);
-   send_sig(SIGIO, devpriv->tsk_Current, 0);   /*  send signal 
to the sample */
+
+   /*  send signal to the sample */
+   send_sig(SIGIO, devpriv->tsk_Current, 0);
}
 
else if ((ui_StatusRegister2 & 0x1) == 0x1)
-   send_sig(SIGIO, devpriv->tsk_Current, 0);   /*  send signal 
to the sample */
+   /*  send signal to the sample */
+   send_sig(SIGIO, devpriv->tsk_Current, 0);
 
return;
 }
-- 
1.8.5.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] Staging: comedi: addi-data: cleanup conditional blocks in hwdrv_apci035.c

2014-02-21 Thread Chase Southwood 
There were some conditional blocks that had an unneccesary level of
indentation in them.  We can remove this to improve code clarity.

Signed-off-by: Chase Southwood 
---
 .../comedi/drivers/addi-data/hwdrv_apci035.c   | 31 ++
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
index 7c40535..34e5321 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci035.c
@@ -207,23 +207,22 @@ static int i_APCI035_ConfigTimerWatchdog(struct 
comedi_device *dev,
ui_Command =
(ui_Command & 0xFFF719E2UL) | ui_Mode << 13UL | 0x10UL;
 
-   } else {
-   if (data[0] == ADDIDATA_WATCHDOG) {
+   } else if (data[0] == ADDIDATA_WATCHDOG) {
 
-   /* Set the mode : */
-   /* - Disable the hardware */
-   /* - Disable the counter mode */
-   /* - Disable the warning  */
-   /* - Disable the reset*/
-   /* - Disable the timer mode   */
+   /* Set the mode : */
+   /* - Disable the hardware */
+   /* - Disable the counter mode */
+   /* - Disable the warning  */
+   /* - Disable the reset*/
+   /* - Disable the timer mode   */
 
-   ui_Command = ui_Command & 0xFFF819E2UL;
+   ui_Command = ui_Command & 0xFFF819E2UL;
 
-   } else {
-   dev_err(dev->class_dev, "The parameter for 
Timer/watchdog selection is in error\n");
-   return -EINVAL;
-   }
+   } else {
+   dev_err(dev->class_dev, "The parameter for Timer/watchdog 
selection is in error\n");
+   return -EINVAL;
}
+
outl(ui_Command, devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
ui_Command = 0;
ui_Command = inl(devpriv->iobase + ((i_WatchdogNbr - 1) * 32) + 12);
@@ -628,10 +627,8 @@ static void v_APCI035_Interrupt(int irq, void *d)
send_sig(SIGIO, devpriv->tsk_Current, 0);   /*  send signal 
to the sample */
}
 
-   else {
-   if ((ui_StatusRegister2 & 0x1) == 0x1)
-   send_sig(SIGIO, devpriv->tsk_Current, 0);   /*  
send signal to the sample */
-   }
+   else if ((ui_StatusRegister2 & 0x1) == 0x1)
+   send_sig(SIGIO, devpriv->tsk_Current, 0);   /*  send signal 
to the sample */
 
return;
 }
-- 
1.8.5.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path

2014-02-21 Thread Zhao, Gang 
On Fri, 2014-02-21 at 20:35:50 +0800, Dan Carpenter wrote:
> On Fri, Feb 21, 2014 at 08:22:21PM +0800, Zhao, Gang wrote:
>> > If we add your patch and the reviewer does a search for fb[0] then it is
>> > confusing what the right thing to do is.
>> 
>> My fault. I should remove that two lines of code in
>> et131x_rx_dma_memory_free(), although they don't break the code.
>> 
>
> Think about what you are saying here for a minute.

Oh, a cold makes me stupid. that two lines of code is needed
definitively.

So is additional modification needed to let this patch be accepted ?

>
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel