Re: [PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY

[Florian Vaussard]

On 03/10/2014 07:03 PM, Tony Lindgren wrote:
 * Florian Vaussard florian.vauss...@epfl.ch [140310 08:17]:
 On 03/10/2014 11:30 AM, Roger Quadros wrote:

 If you don't use the OMAP3x30_CORE2_IOPAD() macro then these definitions 
 can fit in omap3-overo-base.dtsi.
 The offsets will be taken care of if you place them within omap3_pmx_core2 
 {} . e.g.

 +   0x50 (PIN_OUTPUT | MUX_MODE3)   /* 
 etk_d10.hsusb2_clk */
 +   0x52 (PIN_OUTPUT | MUX_MODE3)   /* 
 etk_d11.hsusb2_stp */
 +   0x54 (PIN_INPUT_PULLDOWN | MUX_MODE3)   /* 
 etk_d12.hsusb2_dir */
 +   0x56 (PIN_INPUT_PULLDOWN | MUX_MODE3)   /* 
 etk_d13.hsusb2_nxt */
 +   0x58 (PIN_INPUT_PULLDOWN | MUX_MODE3)   /* 
 etk_d14.hsusb2_data0 */
 +   0x5a (PIN_INPUT_PULLDOWN | MUX_MODE3)   /* 
 etk_d15.hsusb2_data1 */

 Do you think this is better?


 I do not think that this could work. Let's take for example hsusb2_clk
 et let's do the math. Here, 0x50 is the offset inside omap3_pmx_core2
 pinctrl, so:

 hsusb2_clk  omap3_pmx_core2  hsusb2_clk
  offsetbase addr.   PADCONF addr.
   -- --
 OMAP34xx: 0x500x480025d8 0x48002628  *NO*
 OMAP36xx: 0x500x480025a0 0x480025F0  *ok*

 Looking at the TRM, the PADCONF address for hsusb2_clk is 0x480025F0 in
 both cases. Thus we will be wrong on OMAP34xx (offset should be 0x18
 instead of 0x50). Thus so far, I do not see any magical solution apart
 putting the omap3_pmx_core2 pins in a SoC-dependant .dtsi file.

 I already expressed my concerns [1] about having a different base
 address for omap3_pmx_core2 depending on the SoC (although I do
 understand the rational behind). This makes cross-SoC platforms more
 difficult to maintain.
 
 Yeah the muxing should always be possible to do at board level.
 
 Just the use of external pulls for some boards will make it hard
 to have anything common. If you want something common, you can
 have something like omap36xx-usb-xyz.dtsi as long as it's always
 wired up the same way.
 

This is why I put the muxing in a file that will be shared by all Overo
expansion boards. Looking at the other .dts, only omap3-beagle.dts /
omap3-beagle-xm.dts define the pinmux for hsusb2_*, so for now I do not
think it is worth the effort to create a pinmux file common to all omap3
.dts.

Regards,
Florian

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mfd: twl-core: Fix accessibility of some twl4030 audio registers

[Lee Jones]

 There are some unused registers in twl4030 at I2C address 0x49 and function
 twl4030_49_nop_reg() is used to check accessibility of that registers. These
 registers are written in decimal format but the values are correct in
 hexadecimal format. (It can be checked few lines above the patched code -
 these registers are marked as unused there.)
 
 As a consequence three registers of audio submodule are treated as
 inaccessible (preamplifier carkit right and both handsfree registers).
 
 CC: Peter Ujfalusi peter.ujfal...@ti.com
 Signed-off-by: Tomas Novotny to...@novotny.cz
 ---
  drivers/mfd/twl-core.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mfd: twl-core: Fix accessibility of some twl4030 audio registers

[Lee Jones]

 There are some unused registers in twl4030 at I2C address 0x49 and function
 twl4030_49_nop_reg() is used to check accessibility of that registers. These
 registers are written in decimal format but the values are correct in
 hexadecimal format. (It can be checked few lines above the patched code -
 these registers are marked as unused there.)
 
 As a consequence three registers of audio submodule are treated as
 inaccessible (preamplifier carkit right and both handsfree registers).
 
 CC: Peter Ujfalusi peter.ujfal...@ti.com
 Signed-off-by: Tomas Novotny to...@novotny.cz
 ---
  drivers/mfd/twl-core.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

In future, please don't forget to CC LKML.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] arm: dts: omap4+: Add DMM bindings

[Tomi Valkeinen]

Hi,

On 15/10/13 10:04, Archit Taneja wrote:
 Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
 only requires address and irq information.
 
 Add documentation for the DMM bindings.
 
 Originally worked on by Andy Gross andy...@gmail.com
 
 Cc: Andy Gross andy...@gmail.com
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 
 ++
  arch/arm/boot/dts/omap4.dtsi   |  7 +++
  arch/arm/boot/dts/omap5.dtsi   |  7 +++
  3 files changed, 36 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

Has this been queued for 3.15?

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 1/2] arm: dts: omap4+: Add DMM bindings

[Archit Taneja]

On Tuesday 11 March 2014 12:45 PM, Tomi Valkeinen wrote:

Hi,

On 15/10/13 10:04, Archit Taneja wrote:

Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.

Add documentation for the DMM bindings.

Originally worked on by Andy Gross andy...@gmail.com

Cc: Andy Gross andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
  Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
  arch/arm/boot/dts/omap4.dtsi   |  7 +++
  arch/arm/boot/dts/omap5.dtsi   |  7 +++
  3 files changed, 36 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt


Has this been queued for 3.15?


Yes, It has got queued.

Archit

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mfd: twl-core: Fix accessibility of some twl4030 audio registers

[Peter Ujfalusi]

On 03/10/2014 08:12 PM, Tomas Novotny wrote:
 There are some unused registers in twl4030 at I2C address 0x49 and function
 twl4030_49_nop_reg() is used to check accessibility of that registers. These
 registers are written in decimal format but the values are correct in
 hexadecimal format. (It can be checked few lines above the patched code -
 these registers are marked as unused there.)
 
 As a consequence three registers of audio submodule are treated as
 inaccessible (preamplifier carkit right and both handsfree registers).
 
 CC: Peter Ujfalusi peter.ujfal...@ti.com
 Signed-off-by: Tomas Novotny to...@novotny.cz
 ---
  drivers/mfd/twl-core.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
 index ed71832..e87140b 100644
 --- a/drivers/mfd/twl-core.c
 +++ b/drivers/mfd/twl-core.c
 @@ -282,11 +282,11 @@ static struct reg_default twl4030_49_defaults[] = {
  static bool twl4030_49_nop_reg(struct device *dev, unsigned int reg)
  {
   switch (reg) {
 - case 0:
 - case 3:
 - case 40:
 - case 41:
 - case 42:
 + case 0x00:
 + case 0x03:
 + case 0x40:
 + case 0x41:
 + case 0x42:

Uhm, I can not be that @#$%^ that I did this... I have no idea how I left out
the 0x

Thanks for spotting it!

Acked-by Peter Ujfalusi peter.ujfal...@ti.com

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 00/14] v4l: ti-vpe: Some VPE fixes and enhancements

[Archit Taneja]

This patch set mainly consists of minor fixes for the VPE driver. These fixes
ensure the following:

- The VPE module can be inserted and removed successively.
- Make sure that smaller resolutions like qcif work correctly.
- Prevent race condition between firmware loading and an open call to the v4l2
  device.
- Prevent the possibility of output m2m queue not having sufficient 'ready'
  buffers.
- Some VPDMA data descriptor fields weren't understood correctly before. They
  are now used correctly.

The rest of the patches add some minor features like DMA buf support and
cropping/composing.

Reference branch:

g...@github.com:boddob/linux.git vpe_for_315

Changes in v3:

- improvements in selection API patch.
- querycap fixes for v4l2 compliance.
- v4l2_buffer 'field' and flags' fixes for compliance.
- fixes in try_fmt vpe_open for compliance.
- rename a IOMEM resource for better DT compatibility.

Changes in v2:

- selection API used instead of older cropping API.
- Typo fix.
- Some changes in patch 6/7 to support composing on the capture side of VPE.


Archit Taneja (14):
  v4l: ti-vpe: Make sure in job_ready that we have the needed number of
dst_bufs
  v4l: ti-vpe: register video device only when firmware is loaded
  v4l: ti-vpe: Use video_device_release_empty
  v4l: ti-vpe: Allow DMABUF buffer type support
  v4l: ti-vpe: Allow usage of smaller images
  v4l: ti-vpe: Fix some params in VPE data descriptors
  v4l: ti-vpe: Add selection API in VPE driver
  v4l: ti-vpe: Rename csc memory resource name
  v4l: ti-vpe: report correct capabilities in querycap
  v4l: ti-vpe: Use correct bus_info name for the device in querycap
  v4l: ti-vpe: Fix initial configuration queue data
  v4l: ti-vpe: zero out reserved fields in try_fmt
  v4l: ti-vpe: Set correct field parameter for output and capture
buffers
  v4l: ti-vpe: retain v4l2_buffer flags for captured buffers

 drivers/media/platform/ti-vpe/csc.c   |   2 +-
 drivers/media/platform/ti-vpe/vpdma.c |  68 ++---
 drivers/media/platform/ti-vpe/vpdma.h |  17 ++-
 drivers/media/platform/ti-vpe/vpe.c   | 263 --
 4 files changed, 281 insertions(+), 69 deletions(-)

-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/14] v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs

[Archit Taneja]

VPE has a ctrl parameter which decides how many mem to mem transactions the
active job from the job queue can perform.

The driver's job_ready() made sure that the number of ready source buffers are
sufficient for the job to execute successfully. But it didn't make sure if
there are sufficient ready destination buffers in the capture queue for the
VPE output.

If the time taken by VPE to process a single frame is really slow, then it's
possible that we don't need to imply such a restriction on the dst queue, but
really fast transactions(small resolution, no de-interlacing) may cause us to
hit the condition where we don't have any free buffers for the VPE to write on.

Add the extra check in job_ready() to make sure we have the sufficient amount
of destination buffers.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 7a77a5b..f3143ac 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -887,6 +887,9 @@ static int job_ready(void *priv)
if (v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx)  needed)
return 0;
 
+   if (v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx)  needed)
+   return 0;
+
return 1;
 }
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 10/14] v4l: ti-vpe: Use correct bus_info name for the device in querycap

[Archit Taneja]

The bus_info parameter in v4l2_capabilities expects a 'platform_' prefix. This
wasn't done in the driver and hence was breaking compliance. Update the bus_info
parameter accordingly.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 46b9d44..5591d04 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1346,7 +1346,8 @@ static int vpe_querycap(struct file *file, void *priv,
 {
strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1);
strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1);
-   strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info));
+   snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+   VPE_MODULE_NAME);
cap-device_caps  = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 05/14] v4l: ti-vpe: Allow usage of smaller images

[Archit Taneja]

The minimum width and height for VPE input/output was kept as 128 pixels. VPE
doesn't have a constraint on the image height, it requires the image width to
be at least 16 bytes.

Change the minimum supported dimensions to 32x32. This allows us to de-interlace
qcif content. A smaller image size than 32x32 didn't make much sense, so stopped
at this.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 0e7573a..dbdc338 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -49,8 +49,8 @@
 #define VPE_MODULE_NAME vpe
 
 /* minimum and maximum frame sizes */
-#define MIN_W  128
-#define MIN_H  128
+#define MIN_W  32
+#define MIN_H  32
 #define MAX_W  1920
 #define MAX_H  1080
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 02/14] v4l: ti-vpe: register video device only when firmware is loaded

[Archit Taneja]

vpe fops(vpe_open in particular) should be called only when VPDMA firmware
is loaded. File operations on the video device are possible the moment it is
registered.

Currently, we register the video device for VPE at driver probe, after calling
a vpdma helper to initialize VPDMA and load firmware. This function is
non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the
firmware is actually loaded when it returns.

We remove the device registration from vpe probe, and move it to a callback
provided by the vpe driver to the vpdma library, through vpdma_create().

The ready field in vpdma_data is no longer needed since we always have firmware
loaded before the device is registered.

A minor problem with this approach is that if the video_register_device
fails(which doesn't really happen), the vpe platform device would be registered.
however, there won't be any v4l2 device corresponding to it.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpdma.c |  8 +++--
 drivers/media/platform/ti-vpe/vpdma.h |  7 +++--
 drivers/media/platform/ti-vpe/vpe.c   | 55 ---
 3 files changed, 41 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/vpdma.c 
b/drivers/media/platform/ti-vpe/vpdma.c
index e8175e7..73dd38e 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -781,7 +781,7 @@ static void vpdma_firmware_cb(const struct firmware *f, 
void *context)
/* already initialized */
if (read_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
VPDMA_LIST_RDY_SHFT)) {
-   vpdma-ready = true;
+   vpdma-cb(vpdma-pdev);
return;
}
 
@@ -811,7 +811,7 @@ static void vpdma_firmware_cb(const struct firmware *f, 
void *context)
goto free_buf;
}
 
-   vpdma-ready = true;
+   vpdma-cb(vpdma-pdev);
 
 free_buf:
vpdma_unmap_desc_buf(vpdma, fw_dma_buf);
@@ -839,7 +839,8 @@ static int vpdma_load_firmware(struct vpdma_data *vpdma)
return 0;
 }
 
-struct vpdma_data *vpdma_create(struct platform_device *pdev)
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+   void (*cb)(struct platform_device *pdev))
 {
struct resource *res;
struct vpdma_data *vpdma;
@@ -854,6 +855,7 @@ struct vpdma_data *vpdma_create(struct platform_device 
*pdev)
}
 
vpdma-pdev = pdev;
+   vpdma-cb = cb;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vpdma);
if (res == NULL) {
diff --git a/drivers/media/platform/ti-vpe/vpdma.h 
b/drivers/media/platform/ti-vpe/vpdma.h
index cf40f11..bf5f8bb 100644
--- a/drivers/media/platform/ti-vpe/vpdma.h
+++ b/drivers/media/platform/ti-vpe/vpdma.h
@@ -35,8 +35,8 @@ struct vpdma_data {
 
struct platform_device  *pdev;
 
-   /* tells whether vpdma firmware is loaded or not */
-   bool ready;
+   /* callback to VPE driver when the firmware is loaded */
+   void (*cb)(struct platform_device *pdev);
 };
 
 enum vpdma_data_format_type {
@@ -208,6 +208,7 @@ void vpdma_set_frame_start_event(struct vpdma_data *vpdma,
 void vpdma_dump_regs(struct vpdma_data *vpdma);
 
 /* initialize vpdma, passed with VPE's platform device pointer */
-struct vpdma_data *vpdma_create(struct platform_device *pdev);
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+   void (*cb)(struct platform_device *pdev));
 
 #endif
diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index f3143ac..f1eae67 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1817,11 +1817,6 @@ static int vpe_open(struct file *file)
 
vpe_dbg(dev, vpe_open\n);
 
-   if (!dev-vpdma-ready) {
-   vpe_err(dev, vpdma firmware not loaded\n);
-   return -ENODEV;
-   }
-
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
@@ -2039,10 +2034,40 @@ static void vpe_runtime_put(struct platform_device 
*pdev)
WARN_ON(r  0  r != -ENOSYS);
 }
 
+static void vpe_fw_cb(struct platform_device *pdev)
+{
+   struct vpe_dev *dev = platform_get_drvdata(pdev);
+   struct video_device *vfd;
+   int ret;
+
+   vfd = dev-vfd;
+   *vfd = vpe_videodev;
+   vfd-lock = dev-dev_mutex;
+   vfd-v4l2_dev = dev-v4l2_dev;
+
+   ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
+   if (ret) {
+   vpe_err(dev, Failed to register video device\n);
+
+   vpe_set_clock_enable(dev, 0);
+   vpe_runtime_put(pdev);
+   pm_runtime_disable(pdev-dev);
+   v4l2_m2m_release(dev-m2m_dev);
+   vb2_dma_contig_cleanup_ctx(dev-alloc_ctx);
+   v4l2_device_unregister(dev-v4l2_dev);
+
+   return;
+   }
+
+   

[PATCH v3 12/14] v4l: ti-vpe: zero out reserved fields in try_fmt

[Archit Taneja]

Zero out the reserved formats in v4l2_pix_format_mplane and
v4l2_plane_pix_format members of the returned v4l2_format pointer when passed
through TRY_FMT ioctl.

This ensures that the user doesn't interpret the non-zero fields as some data
passed by the driver, and ensures compliance.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 85d1122..970408a 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1488,6 +1488,7 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct 
v4l2_format *f,
}
}
 
+   memset(pix-reserved, 0, sizeof(pix-reserved));
for (i = 0; i  pix-num_planes; i++) {
plane_fmt = pix-plane_fmt[i];
depth = fmt-vpdma_fmt[i]-depth;
@@ -1499,6 +1500,8 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct 
v4l2_format *f,
 
plane_fmt-sizeimage =
(pix-height * pix-width * depth)  3;
+
+   memset(plane_fmt-reserved, 0, sizeof(plane_fmt-reserved));
}
 
return 0;
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 13/14] v4l: ti-vpe: Set correct field parameter for output and capture buffers

[Archit Taneja]

The vpe driver wasn't setting the correct field parameter for dequed CAPTURE
type buffers for the case where the captured output is progressive.

Set the field to V4L2_FIELD_NONE for the completed destination buffers when
the captured output is progressive.

For OUTPUT type buffers, a queued buffer's field is forced to V4L2_FIELD_NONE
if the pixel format(configured through s_fmt for the buffer type
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE specifies) the field type isn't interlaced.
If the pixel format specified was V4L2_FIELD_ALTERNATE, and the queued buffer's
field isn't V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM, the vb2 buf_prepare op returns
an error.

This ensures compliance, and that the dequeued output and captured buffers
contain the field type that the driver used internally.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 970408a..c884910 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1296,10 +1296,10 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
d_buf-timecode = s_buf-timecode;
}
d_buf-sequence = ctx-sequence;
-   d_buf-field = ctx-field;
 
d_q_data = ctx-q_data[Q_DATA_DST];
if (d_q_data-flags  Q_DATA_INTERLACED) {
+   d_buf-field = ctx-field;
if (ctx-field == V4L2_FIELD_BOTTOM) {
ctx-sequence++;
ctx-field = V4L2_FIELD_TOP;
@@ -1308,6 +1308,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
ctx-field = V4L2_FIELD_BOTTOM;
}
} else {
+   d_buf-field = V4L2_FIELD_NONE;
ctx-sequence++;
}
 
@@ -1871,6 +1872,16 @@ static int vpe_buf_prepare(struct vb2_buffer *vb)
q_data = get_q_data(ctx, vb-vb2_queue-type);
num_planes = q_data-fmt-coplanar ? 2 : 1;
 
+   if (vb-vb2_queue-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+   if (!(q_data-flags  Q_DATA_INTERLACED)) {
+   vb-v4l2_buf.field = V4L2_FIELD_NONE;
+   } else {
+   if (vb-v4l2_buf.field != V4L2_FIELD_TOP ||
+   vb-v4l2_buf.field != V4L2_FIELD_BOTTOM)
+   return -EINVAL;
+   }
+   }
+
for (i = 0; i  num_planes; i++) {
if (vb2_plane_size(vb, i)  q_data-sizeimage[i]) {
vpe_err(ctx-dev,
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 14/14] v4l: ti-vpe: retain v4l2_buffer flags for captured buffers

[Archit Taneja]

The dequed CAPTURE_MPLANE type buffers don't contain the flags that the
originally queued OUTPUT_MPLANE type buffers have. This breaks compliance.

Copy the source v4l2_buffer flags to the destination v4l2_buffer flags before
they are dequed.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index c884910..f7759e8 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1288,13 +1288,12 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
s_buf = s_vb-v4l2_buf;
d_buf = d_vb-v4l2_buf;
 
+   d_buf-flags = s_buf-flags;
+
d_buf-timestamp = s_buf-timestamp;
-   d_buf-flags = ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
-   d_buf-flags |= s_buf-flags  V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
-   if (s_buf-flags  V4L2_BUF_FLAG_TIMECODE) {
-   d_buf-flags |= V4L2_BUF_FLAG_TIMECODE;
+   if (s_buf-flags  V4L2_BUF_FLAG_TIMECODE)
d_buf-timecode = s_buf-timecode;
-   }
+
d_buf-sequence = ctx-sequence;
 
d_q_data = ctx-q_data[Q_DATA_DST];
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 11/14] v4l: ti-vpe: Fix initial configuration queue data

[Archit Taneja]

The vpe output and capture queues are initially configured to default values in
vpe_open(). A G_FMT before any S_FMTs will result in these values being
populated.

The colorspace and bytesperline parameter of this initial configuration are
incorrect. This breaks compliance when as we get 'TRY_FMT(G_FMT) != G_FMT'.

Fix the initial queue configuration such that it wouldn't need to be fixed by
try_fmt.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 5591d04..85d1122 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -2012,9 +2012,11 @@ static int vpe_open(struct file *file)
s_q_data-fmt = vpe_formats[2];
s_q_data-width = 1920;
s_q_data-height = 1080;
-   s_q_data-sizeimage[VPE_LUMA] = (s_q_data-width * s_q_data-height *
+   s_q_data-bytesperline[VPE_LUMA] = (s_q_data-width *
s_q_data-fmt-vpdma_fmt[VPE_LUMA]-depth)  3;
-   s_q_data-colorspace = V4L2_COLORSPACE_SMPTE170M;
+   s_q_data-sizeimage[VPE_LUMA] = (s_q_data-bytesperline[VPE_LUMA] *
+   s_q_data-height);
+   s_q_data-colorspace = V4L2_COLORSPACE_REC709;
s_q_data-field = V4L2_FIELD_NONE;
s_q_data-c_rect.left = 0;
s_q_data-c_rect.top = 0;
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 09/14] v4l: ti-vpe: report correct capabilities in querycap

[Archit Taneja]

querycap currently returns V4L2_CAP_VIDEO_M2M as a capability, this should be
V4L2_CAP_VIDEO_M2M_MPLANE instead, as the driver supports multiplanar formats.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 4abb85c..46b9d44 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1347,7 +1347,7 @@ static int vpe_querycap(struct file *file, void *priv,
strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1);
strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1);
strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info));
-   cap-device_caps  = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING;
+   cap-device_caps  = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
 }
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 07/14] v4l: ti-vpe: Add selection API in VPE driver

[Archit Taneja]

Add selection ioctl ops. For VPE, cropping makes sense only for the input to
VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers).

For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output
in a rectangle within the capture buffer. For the OUTPUT type, V4L2_SEL_TGT_CROP
results in selecting a rectangle region within the source buffer.

Setting the crop/compose rectangles should successfully result in
re-configuration of registers which are affected when either source or
destination dimensions change, set_srcdst_params() is called for this purpose.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 141 
 1 file changed, 141 insertions(+)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index ece9b96..4abb85c 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx *ctx,
 {
switch (type) {
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+   case V4L2_BUF_TYPE_VIDEO_OUTPUT:
return ctx-q_data[Q_DATA_SRC];
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
+   case V4L2_BUF_TYPE_VIDEO_CAPTURE:
return ctx-q_data[Q_DATA_DST];
default:
BUG();
@@ -1587,6 +1589,142 @@ static int vpe_s_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
return set_srcdst_params(ctx);
 }
 
+static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection *s)
+{
+   struct vpe_q_data *q_data;
+
+   if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
+   (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
+   return -EINVAL;
+
+   q_data = get_q_data(ctx, s-type);
+   if (!q_data)
+   return -EINVAL;
+
+   switch (s-target) {
+   case V4L2_SEL_TGT_COMPOSE:
+   /*
+* COMPOSE target is only valid for capture buffer type, for
+* output buffer type, assign existing crop parameters to the
+* selection rectangle
+*/
+   if (s-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   break;
+
+   s-r = q_data-c_rect;
+   return 0;
+
+   case V4L2_SEL_TGT_CROP:
+   /*
+* CROP target is only valid for output buffer type, for capture
+* buffer type, assign existing compose parameters to the
+* selection rectangle
+*/
+   if (s-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+   break;
+
+   s-r = q_data-c_rect;
+   return 0;
+
+   /*
+* bound and default crop/compose targets are invalid targets to
+* try/set
+*/
+   default:
+   return -EINVAL;
+   }
+
+   if (s-r.top  0 || s-r.left  0) {
+   vpe_err(ctx-dev, negative values for top and left\n);
+   s-r.top = s-r.left = 0;
+   }
+
+   v4l_bound_align_image(s-r.width, MIN_W, q_data-width, 1,
+   s-r.height, MIN_H, q_data-height, H_ALIGN, S_ALIGN);
+
+   /* adjust left/top if cropping rectangle is out of bounds */
+   if (s-r.left + s-r.width  q_data-width)
+   s-r.left = q_data-width - s-r.width;
+   if (s-r.top + s-r.height  q_data-height)
+   s-r.top = q_data-height - s-r.height;
+
+   return 0;
+}
+
+static int vpe_g_selection(struct file *file, void *fh,
+   struct v4l2_selection *s)
+{
+   struct vpe_ctx *ctx = file2ctx(file);
+   struct vpe_q_data *q_data;
+
+   if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
+   (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
+   return -EINVAL;
+
+   q_data = get_q_data(ctx, s-type);
+   if (!q_data)
+   return -EINVAL;
+
+   switch (s-target) {
+   /* return width and height from S_FMT of the respective buffer type */
+   case V4L2_SEL_TGT_COMPOSE_DEFAULT:
+   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+   case V4L2_SEL_TGT_CROP_BOUNDS:
+   case V4L2_SEL_TGT_CROP_DEFAULT:
+   s-r.left = 0;
+   s-r.top = 0;
+   s-r.width = q_data-width;
+   s-r.height = q_data-height;
+   return 0;
+
+   /*
+* CROP target holds for the output buffer type, and COMPOSE target
+* holds for the capture buffer type. We still return the c_rect params
+* for both the target types.
+*/
+   case V4L2_SEL_TGT_COMPOSE:
+   case V4L2_SEL_TGT_CROP:
+   s-r.left = q_data-c_rect.left;
+   s-r.top = q_data-c_rect.top;
+   s-r.width = q_data-c_rect.width;
+   s-r.height = q_data-c_rect.height;
+   return 0;
+   }
+
+   return 

[PATCH v3 08/14] v4l: ti-vpe: Rename csc memory resource name

[Archit Taneja]

Rename the memory block resource vpe_csc to csc since it also exists within
the VIP IP block. This would make the name more generic, and both VPE and VIP DT
nodes in the future can use it.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/csc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/ti-vpe/csc.c 
b/drivers/media/platform/ti-vpe/csc.c
index acfea50..039 100644
--- a/drivers/media/platform/ti-vpe/csc.c
+++ b/drivers/media/platform/ti-vpe/csc.c
@@ -180,7 +180,7 @@ struct csc_data *csc_create(struct platform_device *pdev)
csc-pdev = pdev;
 
csc-res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-   vpe_csc);
+   csc);
if (csc-res == NULL) {
dev_err(pdev-dev, missing platform resources data\n);
return ERR_PTR(-ENODEV);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 03/14] v4l: ti-vpe: Use video_device_release_empty

[Archit Taneja]

The video_device struct is currently embedded in the driver data struct vpe_dev.
A vpe_dev instance is allocated by the driver, and the memory for the vfd is a
part of this struct.

The v4l2 core, however, manages the removal of the vfd region, through the
video_device's .release() op, which currently is the helper
video_device_release. This causes memory corruption, and leads to issues when
we try to re-insert the vpe module.

Use the video_device_release_empty helper function instead

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index f1eae67..0363df6 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -2000,7 +2000,7 @@ static struct video_device vpe_videodev = {
.fops   = vpe_fops,
.ioctl_ops  = vpe_ioctl_ops,
.minor  = -1,
-   .release= video_device_release,
+   .release= video_device_release_empty,
.vfl_dir= VFL_DIR_M2M,
 };
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/14] v4l: ti-vpe: Fix some params in VPE data descriptors

[Archit Taneja]

Some parameters of the VPE descriptors were understood incorrectly. They are now
fixed. The fixes are explained as follows:

- When adding an inbound data descriptor to the VPDMA descriptor list, we intend
  to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect-width
  shouldn't be used to calculate the line stride, the original image width
  should be used for that. We add a 'width' argument which gives the buffer
  width in memory.

- frame_width and frame_height describe the complete width and height of the
  client to which the channel is connected. If there are multiple channels
  fetching data and providing to the same client, the above 2 arguments should
  be the width and height of the region covered by all the channels. In the case
  where there is only one channel providing pixel data to the client
  (like in VPE), frame_width and frame_height should be the cropped width and
  cropped height respectively. The calculation of these params is done in the
  vpe driver now.

- start_h and start_v is also used in the case of multiple channels to describe
  where each channel should start filling pixel data. We don't use this in VPE,
  and pass 0s to the vpdma_add_in_dtd() helper.

- Some minor changes are made to the vpdma_add_out_dtd() helper. The c_rect
  param is used for specifying the 'composition' target, and 'width'  is added
  to calculate the line stride.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpdma.c | 60 +++
 drivers/media/platform/ti-vpe/vpdma.h | 10 +++---
 drivers/media/platform/ti-vpe/vpe.c   | 18 +++
 3 files changed, 64 insertions(+), 24 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/vpdma.c 
b/drivers/media/platform/ti-vpe/vpdma.c
index 73dd38e..a51a013 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -614,8 +614,17 @@ static void dump_dtd(struct vpdma_dtd *dtd)
 /*
  * append an outbound data transfer descriptor to the given descriptor list,
  * this sets up a 'client to memory' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory
+ * @c_rect: compose params of output image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * flags: VPDMA flags to configure some descriptor fileds
  */
-void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct v4l2_rect *c_rect,
+void vpdma_add_out_dtd(struct vpdma_desc_list *list, int width,
+   const struct v4l2_rect *c_rect,
const struct vpdma_data_format *fmt, dma_addr_t dma_addr,
enum vpdma_channel chan, u32 flags)
 {
@@ -623,6 +632,7 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct 
v4l2_rect *c_rect,
int field = 0;
int notify = 1;
int channel, next_chan;
+   struct v4l2_rect rect = *c_rect;
int depth = fmt-depth;
int stride;
struct vpdma_dtd *dtd;
@@ -630,11 +640,15 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list, 
struct v4l2_rect *c_rect,
channel = next_chan = chan_info[chan].num;
 
if (fmt-type == VPDMA_DATA_FMT_TYPE_YUV 
-   fmt-data_type == DATA_TYPE_C420)
+   fmt-data_type == DATA_TYPE_C420) {
+   rect.height = 1;
+   rect.top = 1;
depth = 8;
+   }
 
-   stride = ALIGN((depth * c_rect-width)  3, VPDMA_STRIDE_ALIGN);
-   dma_addr += (c_rect-left * depth)  3;
+   stride = ALIGN((depth * width)  3, VPDMA_STRIDE_ALIGN);
+
+   dma_addr += rect.top * stride + (rect.left * depth  3);
 
dtd = list-next;
WARN_ON((void *)(dtd + 1)  (list-buf.addr + list-buf.size));
@@ -664,31 +678,48 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list, 
struct v4l2_rect *c_rect,
 /*
  * append an inbound data transfer descriptor to the given descriptor list,
  * this sets up a 'memory to client' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory(not the cropped width)
+ * @c_rect: crop params of input image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * field: top or bottom field info of the input image
+ * flags: VPDMA flags to configure some descriptor fileds
+ * frame_width/height: the complete width/height of the image presented to the
+ * client (this makes sense when multiple channels are
+ * connected to the same client, forming a larger frame)
+ * start_h, start_v: position where the given channel starts providing pixel
+ * data to the client (makes sense when multiple channels
+ * contribute to the client)
  */
-void vpdma_add_in_dtd(struct 

[PATCH v3 04/14] v4l: ti-vpe: Allow DMABUF buffer type support

[Archit Taneja]

For OMAP and DRA7x, we generally allocate video and graphics buffers through
omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed
contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by
other drivers in the video pipeline.

Add VB2_DMABUF flag to the io_modes of the vb2 output and capture queues. This
allows the driver to import dma shared buffers.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/platform/ti-vpe/vpe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index 0363df6..0e7573a 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1770,7 +1770,7 @@ static int queue_init(void *priv, struct vb2_queue 
*src_vq,
 
memset(src_vq, 0, sizeof(*src_vq));
src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
-   src_vq-io_modes = VB2_MMAP;
+   src_vq-io_modes = VB2_MMAP | VB2_DMABUF;
src_vq-drv_priv = ctx;
src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq-ops = vpe_qops;
@@ -1783,7 +1783,7 @@ static int queue_init(void *priv, struct vb2_queue 
*src_vq,
 
memset(dst_vq, 0, sizeof(*dst_vq));
dst_vq-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
-   dst_vq-io_modes = VB2_MMAP;
+   dst_vq-io_modes = VB2_MMAP | VB2_DMABUF;
dst_vq-drv_priv = ctx;
dst_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
dst_vq-ops = vpe_qops;
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver

[Pavel Machek]

Hi!


  You still miss some wovels here. Sometimes it imakes it unlear: 
  chrg is charge? charger?
 
 chrgr means charger, chrg means charge. Isn't it used consistently?. Can fix 
 it if
 it's really annoying. Please suggest.

Well... with all the missing letters, it is not clear if letter is
missing because you just made it short, or it is real difference.

Please just use full words. ... but read below.

   + list_for_each_entry(bat_cache, psy_chrgr.batt_cache_lst, node) {
   + if (!strcmp(bat_cache-name, bat_prop_new-name))
   + goto update_props;
   + }
   +
   + bat_cache = kzalloc(sizeof(*bat_cache), GFP_KERNEL);
  
  What is it with all the caching? Is it good idea to have caches
  indexed by strings? Can't you go without caching, or attach caches to
  some structure? Interesting goto again.
 
 Cache is to store previous battery properties. On receiving a new event
 compare the properties with cached value to decide charging state
 (charging/not charging/full etc.) and to control charging. There is added
 saving with caching. If the previous and current battery properties  doesn't
 differ much, ignore the event instead of continuing (as implemented in
 is_trigger_charging_algo) with invoking charging algorithms. Also caching 
 helps
 to take few critical charging decisions - like charge termination which need
 charge current and voltage over a period of time.
 
 Since a power_supply object (driver) is identified by name, it's the only 
 index
 available.

Why can't you just use address of struct power_supply? There should be
no need to work with names.

Feel free to extend struct power_supply, wrap it in another struct,
anything.

   + if (psb  !psb-external_power_changed)
   + is_pwr_changed_defined = false;
  
  WTF?
 
 The is_supplied_to_has_ext_pwr_changed() return true if any of the 
 power_supply
 objects in supplied_to list has the external_power_changed() call back 
 defined.
 This to  optimize the notifications and to reduce charging algo invocations.
 This is used in is_trigger_charging_algo() to decide charging algorithms 
 should
 be invoked or not.

No, I mean... using = operator in case where plain assignment
should work is evil.

   + /* Identify chargers which are supplying power to the battery */
   + class_dev_iter_init(iter, power_supply_class, NULL, NULL);
   + while ((dev = class_dev_iter_next(iter))) {
   + pst = (struct power_supply *)dev_get_drvdata(dev);
   + if (!psy_is_charger(pst))
   + continue;
   + for (i = 0; i  pst-num_supplicants; i++) {
   + if (!strcmp(pst-supplied_to[i], psy-name))
   + psy_lst[cnt++] = pst;
   + }
  
  Awful lot of string compares around.
 
 In reality this would be one/two, just because the number of chargers 
 supplying
 power to a battery would be limited.

This whole file is nothing but string compares, bubble sorts, and
weird caches.

Please find a way to simplify a design. Rafael works for same company,
can he help?


  Does it really be so complex? Dynamically allocated caches, name
  compares everywhere?
 
 It's really not so complex. The caches are allocated dynamically only when
 a new charger/battery power supply object gets registered - basically when a
 charger/battery driver gets loaded. At runtime no dynamic allocation is 
 needed.
 There is not too many string comparisons just because the number of power
 supply objects are limited. Power supply subsystem has only name as unique
 identifier (psy-name). I couldn't find a better way without string 
 comparisons
 to identify a power supply object.

(void *) psy is also an unique identifier. Plus, you can add new
fields to psy.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM

[Roger Quadros]

Hi Lee,

On 02/27/2014 04:18 PM, Roger Quadros wrote:
 Hi,
 
 This patchset brings up USB Host ports and Ethernet port on
 the OMAP5 uEVM board.
 
 It also does some cleanup with respect to DT clock binding
 for the mfd/omap-usb-host driver.
 
 Please queue these for -next.
 
 Lee,
 
 I've folded some platform data dependent patches with mfd patches
 so that they don't break functionality when applied individually.
 You can safely pull in all MFD patches (1 to 6).
 
 Tony  Benoit,
 
 Can you please accept patches 7, 8 and 9?

Tony has already picked up 7,8 and 9 through omap-soc tree.

Since you acked most patches except 5 and 6, are you fine if Tony takes
all the patches 1 to 4 in this series via omap-soc tree?

What about patches 5 and 6?

cheers,
-roger

 
 Thanks.
 
 Tested on:
  - OMAP5 uEVM
  - Pandaboard ES Rev. B1
  - Beagleboard-XM Rev C2 (DT + Legacy)
  - Beagleboard Rev C4 (DT + Legacy)
 
 Changelog:
 
 v9:
 - Folded dependent platform data patches into MFD patches.
 
 v8:
 - Addressed review comments and split patch
   mfd: omap-usb-host: Get clocks based on hardware revision
 - Removed unnecessary usb host dummy clocks on OMAP3
 - Removed unnecessary clock alias ehci_logic_fck for OMAP3
 - Rebased on 3.14-rc3
 
 v7:
 - Rebased on 3.14-rc2
 - Removed incompatible ids from DT files and examples
 
 v6:
 - Initialized clocks to -ENODEV and split patch 3.
 
 v5:
 - Expose all clocks in the DT binding document for mfd:omap-usb-host
 and mfd:omap-usb-tll
 
 v4:
 - Updated DT binding document for clock binding
 
 v3:
 - Rebased on top of 3.13-rc7
 
 cheers,
 -roger
 
 ---
 Roger Quadros (9):
   mfd: omap-usb-host: Get clocks based on hardware revision
   mfd: omap-usb-host: Always fail on clk_get() error
   mfd: omap-usb-host: Use proper clock name instead of alias
   mfd: omap-usb-host: Use clock names as per function for reference
 clocks
   mfd: omap-usb-host: Update DT clock binding information
   mfd: omap-usb-tll: Update DT clock binding information
   ARM: OMAP2+: Remove legacy_init_ehci_clk()
   ARM: dts: OMAP2+: Get rid of incompatible ids for USB host nodes
   usb: omap: dts: Update DT binding example usage
 
  .../devicetree/bindings/mfd/omap-usb-host.txt  |  23 
  .../devicetree/bindings/mfd/omap-usb-tll.txt   |  10 ++
  .../devicetree/bindings/usb/ehci-omap.txt  |   2 +-
  .../devicetree/bindings/usb/ohci-omap3.txt |   2 +-
  arch/arm/boot/dts/omap3.dtsi   |   4 +-
  arch/arm/boot/dts/omap4-panda-common.dtsi  |   8 +-
  arch/arm/boot/dts/omap4.dtsi   |  10 +-
  arch/arm/boot/dts/omap5-uevm.dts   |   8 +-
  arch/arm/boot/dts/omap5.dtsi   |  10 +-
  arch/arm/mach-omap2/cclock3xxx_data.c  |   4 -
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   6 --
  arch/arm/mach-omap2/pdata-quirks.c |  16 ---
  drivers/clk/ti/clk-3xxx.c  |   4 -
  drivers/mfd/omap-usb-host.c| 116 
 ++---
  14 files changed, 135 insertions(+), 88 deletions(-)
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] mmc: omap_hsmmc: Enable SDIO IRQ.

[Andreas Fenkart]

Hi,

2014-03-05 17:33 GMT+01:00 Tony Lindgren t...@atomide.com:
 * Andreas Fenkart afenk...@gmail.com [140305 00:30]:
 Hi,

 2014-02-27 22:33 GMT+01:00 Tony Lindgren t...@atomide.com:
 
  The wake-irq is needed for omaps with wake-up path and also
  when doing GPIO remuxing. So the wake-up handling is pretty
  much the same for both cases.
 I added this comment to the patch, since I was puzzled that you need
 a wake_irq even whithout remuxing.

 Yeah we need it because omap_hsmmc is already doing runtime PM,
 so there's nothing stopping from shutting it down. And there's
 really no need to block runtime PM for it as it's working.

Also added this comment, since it really clarifies the issue.

FYI, just tried the patch without pin remuxing on am335x and
it actually works. Read: I'm always using the sdio pinmux never
reconfiguring the pin as a GPIO, but still get GPIO interrupts.
Yes, it fails if I comment out the pm_runtime_resume.

So it's not that the am335x suddenly has a swakeup line,
but looks like an implementation detail of the am335x GPIO
block.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 1/3] mmc: omap_hsmmc: Enable SDIO interrupt

[Andreas Fenkart]

There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.

Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.

This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.

This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.

Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
and Andreas Fenkart afenk...@gmail.com with the SDIO IRQ
handing improved following how sdhci.c is doing it.

For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.

To use it, you need to specify the wake-irq using the
interrupts-extended property.

[1] 
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446

Cc: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f8b9c3b..a771573 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
 #include linux/timer.h
 #include linux/clk.h
 #include linux/of.h
+#include linux/of_irq.h
 #include linux/of_gpio.h
 #include linux/of_device.h
 #include linux/omap-dma.h
@@ -36,6 +37,7 @@
 #include linux/mmc/core.h
 #include linux/mmc/mmc.h
 #include linux/io.h
+#include linux/irq.h
 #include linux/gpio.h
 #include linux/regulator/consumer.h
 #include linux/pinctrl/consumer.h
@@ -131,6 +133,7 @@ static void apply_clk_hack(struct device *dev)
 #define TC_EN  (1  1)
 #define BWR_EN (1  4)
 #define BRR_EN (1  5)
+#define CIRQ_EN(1  8)
 #define ERR_EN (1  15)
 #define CTO_EN (1  16)
 #define CCRC_EN(1  17)
@@ -205,6 +208,8 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+   int wake_irq;
+   int wake_irq_en;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -215,6 +220,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+   int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1  1)
struct omap_hsmmc_next  next_data;
struct  omap_mmc_platform_data  *pdata;
 };
@@ -495,27 +503,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host 
*host)
 static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
  struct mmc_command *cmd)
 {
-   unsigned int irq_mask;
+   u32 irq_mask = INT_EN_MASK;
+   unsigned long flags;
 
if (host-use_dma)
-   irq_mask = INT_EN_MASK  ~(BRR_EN | BWR_EN);
-   else
-   irq_mask = INT_EN_MASK;
+   irq_mask = ~(BRR_EN | BWR_EN);
 
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
 
+   spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+   /* latch pending CIRQ, but don't signal MMC core */
+   if (host-flags  HSMMC_SDIO_IRQ_ENABLED)
+   irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+   spin_unlock_irqrestore(host-irq_lock, flags);
 }
 
 static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
 {
-   OMAP_HSMMC_WRITE(host-base, ISE, 0);
-   OMAP_HSMMC_WRITE(host-base, IE, 0);
+   u32 irq_mask = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(host-irq_lock, flags);
+   /* no transfer running but need to keep cirq if enabled */
+   if (host-flags  HSMMC_SDIO_IRQ_ENABLED)
+   irq_mask |= CIRQ_EN;
+   

[PATCH v9 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.

[Andreas Fenkart]

Resend of v8, with Chris Ball on cc and following changes.

v9
- extended comment about why wake-irq is needed
- drop double '(' ')' around card_detect_irq
- drop final '.' in in subject line of patch

v8
- rebased on top of Tony Lindgrent...@atomide.com changes
  - improved changelog describing the earlier work
  - improved wakeup irq setup
  - works for am3730 es platform now
- my changes on top:
  - compile tested with #undef CONFIG_OF
  - disable wake_irq in handler to prevent infinite loop  
  - fixed typo and added comment about wake-irq

v7
- rebase on 3.14.0-rc3-49726-g77e15ec
- split omap_hsmmc_pin_init due to regression on omap-3730 platform

v6
- rebase on Linux 3.13-rc3
- reformatting debugfs

v5
- fix compile error introduced by last minute one line fix

v4:
- switch to interrupts-extended format
- drop ti,swakeup-missing flag convert to comaptible section

v3:
- removed gpio_irq from platform_data

v2:
- incorparated changes as suggested by reviewers
- simplified workaround for am335x, gpio will now only wake
  the module from runtime suspend, not handle the sdio irq
  itself 

Andreas Fenkart (3):
  mmc: omap_hsmmc: Enable SDIO interrupt
  mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on
AM335x
  mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux

 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   50 +++
 drivers/mmc/host/omap_hsmmc.c  |  339 ++--
 include/linux/platform_data/mmc-omap.h |1 +
 3 files changed, 365 insertions(+), 25 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x

[Andreas Fenkart]

The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.

Idea of remuxing the pins and some minor changes by Tony Lindgren.

Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..8e1195e 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -55,3 +55,53 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+  --
+   ^ |
+   swakeup | | fclk
+   | v
+   -----   -
+  | card | -- CIRQ --  | hsmmc | -- IRQ --  | CPU |
+   -----   -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request
+fclk restore, when an external event is detected. Once the clock
+is restored, the host detects the event normally. Since am33xx
+doesn't have this line it never wakes from suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon
+suspend. To make this work, we need to set 1) the named pinctrl
+states default, active and idle, 2) the gpio detecting
+sdio irq in suspend and 3) compatibe section, see example below.
+The MMC driver will then toggle between active and idle during
+the runtime. If configuration is incomplete, a warning message is
+emitted falling back to polling.  Mind not every application
+needs SDIO irq, e.g. MMC cards Affected chips are am335x,
+probably others
+
+
+   mmc1: mmc@48060100 {
+   compatible = ti,am33xx-hsmmc;
+   ...
+   interrupts-extended = intc 64 gpio2 28 0;
+   ...
+   pinctrl-names = default, active, idle
+   pinctrl-0 = mmc1_pins;
+   pinctrl-1 = mmc1_pins;
+   pinctrl-2 = mmc1_cirq_pin;
+   ...
+   };
+
+   mmc1_cirq_pin: pinmux_cirq_pin {
+   pinctrl-single,pins = 
+   0x0f8 0x3f  /* GPIO2_28 */
+   ;
+   };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a771573..36052f4e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -224,6 +224,8 @@ struct omap_hsmmc_host {
 #define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
 #define HSMMC_SWAKEUP_QUIRK(1  1)
struct omap_hsmmc_next  next_data;
+   struct pinctrl  *pinctrl;
+   struct pinctrl_state*fixed, *active, *idle;
struct  omap_mmc_platform_data  *pdata;
 };
 
@@ -480,6 +482,70 @@ static void omap_hsmmc_gpio_free(struct 
omap_mmc_platform_data *pdata)
gpio_free(pdata-slots[0].switch_pin);
 }
 
+static int omap_hsmmc_pin_init(struct omap_hsmmc_host *host)
+{
+   struct pinctrl *_pinctrl;
+   int ret;
+
+   _pinctrl = devm_pinctrl_get(host-dev);
+   if (IS_ERR(_pinctrl)) {
+   /* okay, if the bootloader set it up right */
+   dev_warn(host-dev, no pinctrl handle\n);
+   return 0;
+   }
+
+   host-fixed = pinctrl_lookup_state(_pinctrl,
+  PINCTRL_STATE_DEFAULT);
+   if (IS_ERR(host-fixed)) {
+   dev_info(host-dev,
+pins are not configured from the driver\n);
+   host-fixed = NULL;
+   devm_pinctrl_put(_pinctrl);
+   return 0;
+   }
+
+   ret = pinctrl_select_state(_pinctrl, host-fixed);
+   if (ret  0) {
+   dev_warn(host-dev, fixed pinctrl state failed %d\n, ret);
+   goto err;
+   }
+
+   /* For most cases we don't have wake-ups, and exit after this */
+   host-active = pinctrl_lookup_state(_pinctrl, active);
+   if (IS_ERR(host-active)) {
+   ret = PTR_ERR(host-active);
+   host-active = NULL;
+   goto done;
+   }
+
+   host-idle = pinctrl_lookup_state(_pinctrl, PINCTRL_STATE_IDLE);
+   if (IS_ERR(host-idle)) {
+   ret = PTR_ERR(host-idle);
+   host-idle = NULL;
+   goto err;
+   }
+
+   /* Let's make sure the active and idle states work */
+   ret = pinctrl_select_state(_pinctrl, host-idle);
+   if (ret  

Re: [PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY

[Roger Quadros]

On 03/10/2014 05:13 PM, Florian Vaussard wrote:
 Hi Roger,
 
 On 03/10/2014 11:30 AM, Roger Quadros wrote:
 Hi Florian,

 On 03/07/2014 09:22 PM, Florian Vaussard wrote:
 Add the High-Speed USB PHY.

 Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
 ---
  arch/arm/boot/dts/omap3-overo-base.dtsi  | 44 
 
  arch/arm/boot/dts/omap3-overo-storm.dtsi | 16 
  arch/arm/boot/dts/omap3-overo.dtsi   | 16 
  3 files changed, 76 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi 
 b/arch/arm/boot/dts/omap3-overo-base.dtsi
 index edac70e..13d1ad2 100644
 --- a/arch/arm/boot/dts/omap3-overo-base.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
 @@ -30,6 +30,24 @@
 ti,codec = twl_audio;
 };
  
 +   /* HS USB Port 2 Power */
 +   hsusb2_power: hsusb2_power_reg {
 +   compatible = regulator-fixed;
 +   regulator-name = hsusb2_vbus;
 +   regulator-min-microvolt = 500;
 +   regulator-max-microvolt = 500;
 +   gpio = gpio6 8 0;/* gpio_168: 
 vbus enable */
 +   startup-delay-us = 7;
 +   enable-active-high;
 +   };
 +
 +   /* HS USB Host PHY on PORT 2 */
 +   hsusb2_phy: hsusb2_phy {
 +   compatible = usb-nop-xceiv;
 +   reset-gpios = gpio6 23 GPIO_ACTIVE_LOW;  /* gpio_183 */
 +   vcc-supply = hsusb2_power;
 +   };
 +
 /* Regulator to trigger the nPoweron signal of the Wifi module */
 w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
 compatible = regulator-fixed;
 @@ -64,6 +82,11 @@
  };
  
  omap3_pmx_core {
 +   pinctrl-names = default;
 +   pinctrl-0 = 
 +   hsusb2_pins
 +   ;
 +
 uart2_pins: pinmux_uart2_pins {
 pinctrl-single,pins = 
 OMAP3_CORE1_IOPAD(0x216c, PIN_INPUT | MUX_MODE1)
 /* mcbsp3_dx.uart2_cts */
 @@ -116,6 +139,19 @@
 OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)   
 /* uart3_rts_sd.gpio_164 */
 ;
 };
 +
 +   hsusb2_pins: pinmux_hsusb2_pins {
 +   pinctrl-single,pins = 
 +   OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi1_cs3.hsusb2_data2 */
 +   OMAP3_CORE1_IOPAD(0x21d6, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_clk.hsusb2_data7 */
 +   OMAP3_CORE1_IOPAD(0x21d8, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_simo.hsusb2_data4 */
 +   OMAP3_CORE1_IOPAD(0x21da, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_somi.hsusb2_data5 */
 +   OMAP3_CORE1_IOPAD(0x21dc, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_cs0.hsusb2_data6 */
 +   OMAP3_CORE1_IOPAD(0x21de, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_cs1.hsusb2_data3 */
 +   OMAP3_CORE1_IOPAD(0x21be, PIN_OUTPUT | MUX_MODE4)   
 /* i2c2_scl.gpio_168 */
 +   OMAP3_CORE1_IOPAD(0x21c0, PIN_OUTPUT | MUX_MODE4)   
 /* i2c2_sda.gpio_183 */
 +   ;
 +   };
  };
  
  i2c1 {
 @@ -177,6 +213,14 @@
 power = 50;
  };
  
 +usbhshost {
 +   port2-mode = ehci-phy;
 +};
 +
 +usbhsehci {
 +   phys = 0 hsusb2_phy;
 +};
 +
  uart2 {
 pinctrl-names = default;
 pinctrl-0 = uart2_pins;
 diff --git a/arch/arm/boot/dts/omap3-overo-storm.dtsi 
 b/arch/arm/boot/dts/omap3-overo-storm.dtsi
 index c235ae8..6cb418b 100644
 --- a/arch/arm/boot/dts/omap3-overo-storm.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo-storm.dtsi
 @@ -10,6 +10,22 @@
  #include omap3-overo-base.dtsi
  
  omap3_pmx_core2 {
 +   pinctrl-names = default;
 +   pinctrl-0 = 
 +   hsusb2_2_pins
 +   ;
 +
 +   hsusb2_2_pins: pinmux_hsusb2_2_pins {
 +   pinctrl-single,pins = 
 +   OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
 /* etk_d10.hsusb2_clk */
 +   OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
 /* etk_d11.hsusb2_stp */
 +   OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d12.hsusb2_dir */
 +   OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d13.hsusb2_nxt */
 +   OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d14.hsusb2_data0 */
 +   OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d15.hsusb2_data1 */

 If you don't use the OMAP3x30_CORE2_IOPAD() macro then these definitions can 
 fit in omap3-overo-base.dtsi.
 The offsets will be taken care of if you place them within omap3_pmx_core2 
 {} . e.g.

 +   0x50 (PIN_OUTPUT | MUX_MODE3)   /* 
 etk_d10.hsusb2_clk */
 +   0x52 (PIN_OUTPUT | MUX_MODE3)   /* 
 etk_d11.hsusb2_stp */
 +   0x54 (PIN_INPUT_PULLDOWN | MUX_MODE3)   /* 
 etk_d12.hsusb2_dir */
 +  

[PATCH v9 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux

[Andreas Fenkart]

Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending

Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 36052f4e..2fdb2a8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -82,6 +82,7 @@ static void apply_clk_hack(struct device *dev)
 #define OMAP_HSMMC_RSP54   0x0118
 #define OMAP_HSMMC_RSP76   0x011C
 #define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE  0x0124
 #define OMAP_HSMMC_HCTL0x0128
 #define OMAP_HSMMC_SYSCTL  0x012C
 #define OMAP_HSMMC_STAT0x0130
@@ -1854,14 +1855,30 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
void *data)
 {
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+   const char *cirq_state;
+   bool suspended;
 
-   seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
-   mmc-index, host-context_loss);
+   seq_printf(s, mmc%d:\n, mmc-index);
+   if (mmc-caps  MMC_CAP_SDIO_IRQ)
+   cirq_state = (host-flags  HSMMC_SDIO_IRQ_ENABLED) ?
+   enabled : disabled;
+   else
+   cirq_state = polling;
+   seq_printf(s, sdio irq\t%s\n, cirq_state);
 
-   pm_runtime_get_sync(host-dev);
+   if (host-flags  HSMMC_SWAKEUP_QUIRK) {
+   suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+   seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+   }
+   seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
 
+   pm_runtime_get_sync(host-dev);
+   seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+   seq_printf(s, PSTATE:\t\t0x%08x\n,
+  OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY

[Roger Quadros]

On 03/07/2014 09:22 PM, Florian Vaussard wrote:
 Add the High-Speed USB PHY.
 
 Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch

Acked-by: Roger Quadros rog...@ti.com

cheers,
-roger

 ---
  arch/arm/boot/dts/omap3-overo-base.dtsi  | 44 
 
  arch/arm/boot/dts/omap3-overo-storm.dtsi | 16 
  arch/arm/boot/dts/omap3-overo.dtsi   | 16 
  3 files changed, 76 insertions(+)
 
 diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi 
 b/arch/arm/boot/dts/omap3-overo-base.dtsi
 index edac70e..13d1ad2 100644
 --- a/arch/arm/boot/dts/omap3-overo-base.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
 @@ -30,6 +30,24 @@
   ti,codec = twl_audio;
   };
  
 + /* HS USB Port 2 Power */
 + hsusb2_power: hsusb2_power_reg {
 + compatible = regulator-fixed;
 + regulator-name = hsusb2_vbus;
 + regulator-min-microvolt = 500;
 + regulator-max-microvolt = 500;
 + gpio = gpio6 8 0;/* gpio_168: 
 vbus enable */
 + startup-delay-us = 7;
 + enable-active-high;
 + };
 +
 + /* HS USB Host PHY on PORT 2 */
 + hsusb2_phy: hsusb2_phy {
 + compatible = usb-nop-xceiv;
 + reset-gpios = gpio6 23 GPIO_ACTIVE_LOW;  /* gpio_183 */
 + vcc-supply = hsusb2_power;
 + };
 +
   /* Regulator to trigger the nPoweron signal of the Wifi module */
   w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
   compatible = regulator-fixed;
 @@ -64,6 +82,11 @@
  };
  
  omap3_pmx_core {
 + pinctrl-names = default;
 + pinctrl-0 = 
 + hsusb2_pins
 + ;
 +
   uart2_pins: pinmux_uart2_pins {
   pinctrl-single,pins = 
   OMAP3_CORE1_IOPAD(0x216c, PIN_INPUT | MUX_MODE1)
 /* mcbsp3_dx.uart2_cts */
 @@ -116,6 +139,19 @@
   OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)   
 /* uart3_rts_sd.gpio_164 */
   ;
   };
 +
 + hsusb2_pins: pinmux_hsusb2_pins {
 + pinctrl-single,pins = 
 + OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi1_cs3.hsusb2_data2 */
 + OMAP3_CORE1_IOPAD(0x21d6, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_clk.hsusb2_data7 */
 + OMAP3_CORE1_IOPAD(0x21d8, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_simo.hsusb2_data4 */
 + OMAP3_CORE1_IOPAD(0x21da, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_somi.hsusb2_data5 */
 + OMAP3_CORE1_IOPAD(0x21dc, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_cs0.hsusb2_data6 */
 + OMAP3_CORE1_IOPAD(0x21de, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)   /* mcspi2_cs1.hsusb2_data3 */
 + OMAP3_CORE1_IOPAD(0x21be, PIN_OUTPUT | MUX_MODE4)   
 /* i2c2_scl.gpio_168 */
 + OMAP3_CORE1_IOPAD(0x21c0, PIN_OUTPUT | MUX_MODE4)   
 /* i2c2_sda.gpio_183 */
 + ;
 + };
  };
  
  i2c1 {
 @@ -177,6 +213,14 @@
   power = 50;
  };
  
 +usbhshost {
 + port2-mode = ehci-phy;
 +};
 +
 +usbhsehci {
 + phys = 0 hsusb2_phy;
 +};
 +
  uart2 {
   pinctrl-names = default;
   pinctrl-0 = uart2_pins;
 diff --git a/arch/arm/boot/dts/omap3-overo-storm.dtsi 
 b/arch/arm/boot/dts/omap3-overo-storm.dtsi
 index c235ae8..6cb418b 100644
 --- a/arch/arm/boot/dts/omap3-overo-storm.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo-storm.dtsi
 @@ -10,6 +10,22 @@
  #include omap3-overo-base.dtsi
  
  omap3_pmx_core2 {
 + pinctrl-names = default;
 + pinctrl-0 = 
 + hsusb2_2_pins
 + ;
 +
 + hsusb2_2_pins: pinmux_hsusb2_2_pins {
 + pinctrl-single,pins = 
 + OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
 /* etk_d10.hsusb2_clk */
 + OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
 /* etk_d11.hsusb2_stp */
 + OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d12.hsusb2_dir */
 + OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d13.hsusb2_nxt */
 + OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d14.hsusb2_data0 */
 + OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
 MUX_MODE3)/* etk_d15.hsusb2_data1 */
 + ;
 + };
 +
   w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
   pinctrl-single,pins = 
   OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
 /* etk_d2.gpio_16 */
 diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
 b/arch/arm/boot/dts/omap3-overo.dtsi
 index 95c59b2..c37b130 100644
 --- a/arch/arm/boot/dts/omap3-overo.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo.dtsi
 @@ 

Re: [PATCHv3 00/41] OMAPDSS: DT support v3

[Tomi Valkeinen]

On 10/03/14 17:41, Tony Lindgren wrote:

 How about do a pull request for just the .dts changes against current
 omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
 that just the .dts changes alone won't break anything.

 Unfortunately they do break. At least pinmuxing is moved from the global
 definitions to be handled by the respective display drivers, and there
 are some regulator_name hacks that the DT patches remove.
 
 OK. Will that cause regressions for omap3 as that's still also booting
 in legacy mode?

No, I don't think so. The problems revolve around the pdata-quirks, with
current DSS support when booting with DT. It's rather difficult to split
the series so that it could be merged freely in multiple parts.

If I split the series into three parts: 1) .dts changes 2) main DSS DT
changes 3) removal of pdata-quirks etc, I run into problems. Both 1) and
2) work fine individually, but when both are merged, there are two
competing systems, the proper DT stuff and the pdata-quirks stuff. And I
haven't found out a simple way to manage that, as the whole display
support is split into multiple independent devices.

One option would be to combine 1) and 3), so that when they are merged,
there would be proper DT data, and the pdata-quirks would be removed so
that it wouldn't be messing everything up. But that would, of course,
mean that after merging 1+3, the display wouldn't work on those boards
that rely on pdata-quirks, until 2) is merged.

 I think those changes could be removed from my patches, and then added
 back later when everything else has been merged.
 
 Or you could have a second branch that also merges in omap-for-v3.15/dt
 branch that you can send later towards the merge window after the arm-soc
 changes have been merged. If you want to do that, then feel free to add
 my ack also for the .dts changes:
 
 Acked-by: Tony Lindgren t...@atomide.com
 
 If however those changes get postponed to v3.16, it's best that you'll
 redo the branch as I'm sure we'll have other merge issues for v3.16.

Ok. At the moment I feel that the easiest option would be to keep the
DSS DT series as it is, but merge omap-for-v3.15/dt to it and solve the
conflicts. I'd keep that branch separate from the fbdev changes, so that
I could send the DSS DT pull request later, when arm-soc has been pulled.

 The bigger issue is that suddenly there's lots of discussion about the
 display DT bindings. If those are not resolved very soon, I guess I have
 no choice but to again skip the merge window for the DSS DT changes.
 
 OK, some of these more bindings can take easily six months to reach
 some kind of resolution. You may be able to use TI specific unstable
 bindings meanwhile if that makese sense.

Yep. I don't know... If the whole port/endpoint system that I currently
use is changed totally, it might be painful to support both the TI
specific bindings with the old format and the newer format.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling

[Mark Brown]

On Mon, Mar 10, 2014 at 01:41:14PM +0200, Jyri Sarha wrote:
 Since RFC:
 - fixed commit msg typo
 - added include/sound/soc.h changes too
 
 The sematics of bitclock-master and frame-master DT parameters
 should depend on whether they are found from a cpu-dai or codec
 sub-node.
 
 - bitclock-master in cpu-dai node means Codec-Bitclock-Slave
 - frame-master in cpu-dai node means Codec-Frame-Slave
 - bitclock-master in codec node means Codec-Bitclock-Master
 - frame-master in codec node means Codec-Frame-Master
 
 For example in a cpu-dai mode bitclock-master parameter should produce
 SND_SOC_DAIFMT_CBS_* daifmt flags and a codec node
 SND_SOC_DAIFMT_CBM_* flags.

I've added Morimoto-san and Xiubo to the CCs - can you please have a
look at this?  I can't see any in tree users but presumably there are
some existing out of tree users of the binding that use it without
current problems.


signature.asc
Description: Digital signature

[PATCH v5] ASoC: tlv320aic31xx: Add basic codec driver implementation

[Jyri Sarha]

This commit adds a bare bones driver support for TLV320AIC31XX family
audio codecs. The driver adds basic stereo playback trough headphone
and speaker outputs and mono capture trough microphone inputs.

The driver is currently missing support at least for mini DSP features
and jack detection. I have tested the driver only on TLV320AIC3111,
but based on the data sheets TLV320AIC3100, TLV320AIC3110, and
TLV320AIC3120 should work Ok too.

The base for the implementation was taken from:
g...@gitorious.org:ti-codecs/ti-codecs.git ajitk/topics/k3.10.1-aic31xx
-branch at commit 77504eba0294764e9e63b4a0c696b44db187cd13.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
Since v4 version:
- Remove MICBIAS_OFF DT parameter
- Remove logging and add missing default: to aic31xx_dapm_power_event() 
- Take control, widget, and route adding errors into account
- Don't try soft reset in power event handler
- Remove route to MICBIAS from codec driver damp routing table and add it
  as output pin to DT doc
- Update year in copyright message and change triple newlines to double
- Remove internal DAC/ADC routes that were still haunting in the previous patch
- Allow PLL reprogramming on the fly as it appears to work just fine

BR,
Jyri

 .../devicetree/bindings/sound/tlv320aic31xx.txt|   61 +
 include/dt-bindings/sound/tlv320aic31xx-micbias.h  |8 +
 sound/soc/codecs/Kconfig   |4 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/tlv320aic31xx.c   | 1295 
 sound/soc/codecs/tlv320aic31xx.h   |  258 
 6 files changed, 1628 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
 create mode 100644 include/dt-bindings/sound/tlv320aic31xx-micbias.h
 create mode 100644 sound/soc/codecs/tlv320aic31xx.c
 create mode 100644 sound/soc/codecs/tlv320aic31xx.h

diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt 
b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
new file mode 100644
index 000..74c66de
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
@@ -0,0 +1,61 @@
+Texas Instruments - tlv320aic31xx Codec module
+
+The tlv320aic31xx serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - string - One of:
+ti,tlv320aic310x - Generic TLV320AIC31xx with mono speaker amp
+ti,tlv320aic311x - Generic TLV320AIC31xx with stereo speaker amp
+ti,tlv320aic3100 - TLV320AIC3100 (mono speaker amp, no MiniDSP)
+ti,tlv320aic3110 - TLV320AIC3110 (stereo speaker amp, no MiniDSP)
+ti,tlv320aic3120 - TLV320AIC3120 (mono speaker amp, MiniDSP)
+ti,tlv320aic3111 - TLV320AIC3111 (stereo speaker amp, MiniDSP)
+
+- reg - int -  I2C slave address
+
+
+Optional properties:
+
+- gpio-reset - gpio pin number used for codec reset
+- ai31xx-micbias-vg - MicBias Voltage setting
+1 or MICBIAS_2_0V - MICBIAS output is powered to 2.0V
+2 or MICBIAS_2_5V - MICBIAS output is powered to 2.5V
+3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD
+   If this node is not mentioned or if the value is unknown, then
+   micbias is set to 2.0V.
+- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
+  DVDD-supply : power supplies for the device as covered in
+  Documentation/devicetree/bindings/regulator/regulator.txt
+
+CODEC output pins:
+  * HPL
+  * HPR
+  * SPL, devices with stereo speaker amp
+  * SPR, devices with stereo speaker amp
+  * SPK, devices with mono speaker amp
+  * MICBIAS
+
+CODEC input pins:
+  * MIC1LP
+  * MIC1RP
+  * MIC1LM
+
+The pins can be used in referring sound node's audio-routing property.
+
+Example:
+#include dt-bindings/sound/tlv320aic31xx-micbias.h
+
+tlv320aic31xx: tlv320aic31xx@18 {
+   compatible = ti,tlv320aic311x;
+   reg = 0x18;
+
+   ai31xx-micbias-vg = MICBIAS_OFF;
+
+   HPVDD-supply = regulator;
+   SPRVDD-supply = regulator;
+   SPLVDD-supply = regulator;
+   AVDD-supply = regulator;
+   IOVDD-supply = regulator;
+   DVDD-supply = regulator;
+};
diff --git a/include/dt-bindings/sound/tlv320aic31xx-micbias.h 
b/include/dt-bindings/sound/tlv320aic31xx-micbias.h
new file mode 100644
index 000..f5cb772
--- /dev/null
+++ b/include/dt-bindings/sound/tlv320aic31xx-micbias.h
@@ -0,0 +1,8 @@
+#ifndef __DT_TLV320AIC31XX_MICBIAS_H
+#define __DT_TLV320AIC31XX_MICBIAS_H
+
+#define MICBIAS_2_0V   1
+#define MICBIAS_2_5V   2
+#define MICBIAS_AVDDV  3
+
+#endif /* __DT_TLV320AIC31XX_MICBIAS_H */
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index e19b64f..af3c049 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -83,6 +83,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TAS5086 if I2C
select SND_SOC_TLV320AIC23 if I2C
select SND_SOC_TLV320AIC26 if SPI_MASTER
+   select SND_SOC_TLV320AIC31XX if I2C
 

Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM

[Lee Jones]

  Hi,
  
  This patchset brings up USB Host ports and Ethernet port on
  the OMAP5 uEVM board.
  
  It also does some cleanup with respect to DT clock binding
  for the mfd/omap-usb-host driver.
  
  Please queue these for -next.
  
  Lee,
  
  I've folded some platform data dependent patches with mfd patches
  so that they don't break functionality when applied individually.
  You can safely pull in all MFD patches (1 to 6).
  
  Tony  Benoit,
  
  Can you please accept patches 7, 8 and 9?
 
 Tony has already picked up 7,8 and 9 through omap-soc tree.
 
 Since you acked most patches except 5 and 6, are you fine if Tony takes
 all the patches 1 to 4 in this series via omap-soc tree?
 
 What about patches 5 and 6?

Any patches which are orthogonal can just be sucked into whichever tree
they belong in. If there are inter-subsystem dependencies I'd prefer
to take them and issue a immutable branch pull-request to the other
maintainers.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 04/14] v4l: ti-vpe: Allow DMABUF buffer type support

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 For OMAP and DRA7x, we generally allocate video and graphics buffers through
 omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed
 contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by
 other drivers in the video pipeline.
 
 Add VB2_DMABUF flag to the io_modes of the vb2 output and capture queues. This
 allows the driver to import dma shared buffers.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index 0363df6..0e7573a 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -1770,7 +1770,7 @@ static int queue_init(void *priv, struct vb2_queue 
 *src_vq,
  
   memset(src_vq, 0, sizeof(*src_vq));
   src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
 - src_vq-io_modes = VB2_MMAP;
 + src_vq-io_modes = VB2_MMAP | VB2_DMABUF;
   src_vq-drv_priv = ctx;
   src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
   src_vq-ops = vpe_qops;
 @@ -1783,7 +1783,7 @@ static int queue_init(void *priv, struct vb2_queue 
 *src_vq,
  
   memset(dst_vq, 0, sizeof(*dst_vq));
   dst_vq-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
 - dst_vq-io_modes = VB2_MMAP;
 + dst_vq-io_modes = VB2_MMAP | VB2_DMABUF;
   dst_vq-drv_priv = ctx;
   dst_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer);
   dst_vq-ops = vpe_qops;
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 05/14] v4l: ti-vpe: Allow usage of smaller images

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 The minimum width and height for VPE input/output was kept as 128 pixels. VPE
 doesn't have a constraint on the image height, it requires the image width to
 be at least 16 bytes.
 
 Change the minimum supported dimensions to 32x32. This allows us to 
 de-interlace
 qcif content. A smaller image size than 32x32 didn't make much sense, so 
 stopped
 at this.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index 0e7573a..dbdc338 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -49,8 +49,8 @@
  #define VPE_MODULE_NAME vpe
  
  /* minimum and maximum frame sizes */
 -#define MIN_W128
 -#define MIN_H128
 +#define MIN_W32
 +#define MIN_H32
  #define MAX_W1920
  #define MAX_H1080
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 03/14] v4l: ti-vpe: Use video_device_release_empty

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 The video_device struct is currently embedded in the driver data struct 
 vpe_dev.
 A vpe_dev instance is allocated by the driver, and the memory for the vfd is a
 part of this struct.
 
 The v4l2 core, however, manages the removal of the vfd region, through the
 video_device's .release() op, which currently is the helper
 video_device_release. This causes memory corruption, and leads to issues when
 we try to re-insert the vpe module.
 
 Use the video_device_release_empty helper function instead
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index f1eae67..0363df6 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -2000,7 +2000,7 @@ static struct video_device vpe_videodev = {
   .fops   = vpe_fops,
   .ioctl_ops  = vpe_ioctl_ops,
   .minor  = -1,
 - .release= video_device_release,
 + .release= video_device_release_empty,
   .vfl_dir= VFL_DIR_M2M,
  };
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM

[Roger Quadros]

On 03/11/2014 02:02 PM, Lee Jones wrote:
 Hi,

 This patchset brings up USB Host ports and Ethernet port on
 the OMAP5 uEVM board.

 It also does some cleanup with respect to DT clock binding
 for the mfd/omap-usb-host driver.

 Please queue these for -next.

 Lee,

 I've folded some platform data dependent patches with mfd patches
 so that they don't break functionality when applied individually.
 You can safely pull in all MFD patches (1 to 6).

 Tony  Benoit,

 Can you please accept patches 7, 8 and 9?

 Tony has already picked up 7,8 and 9 through omap-soc tree.

 Since you acked most patches except 5 and 6, are you fine if Tony takes
 all the patches 1 to 4 in this series via omap-soc tree?

 What about patches 5 and 6?
 
 Any patches which are orthogonal can just be sucked into whichever tree
 they belong in. If there are inter-subsystem dependencies I'd prefer
 to take them and issue a immutable branch pull-request to the other
 maintainers.
 
Awesome. That would be great, thanks.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/7] ARM: dts: overo: Add LIS33DE accelerometer

[Florian Vaussard]

The LIS33DE accelerometer is used on several Gumstix expansion boards,
thus add the DT node to omap3-overo-common-peripherals.dtsi.

For the boards that do not have the accelerometer (like Tobi), mark the
status as disabled.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 .../boot/dts/omap3-overo-common-peripherals.dtsi   | 44 ++
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi |  4 ++
 2 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi 
b/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
index bca81ae..5831bcc 100644
--- a/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
@@ -10,6 +10,22 @@
  * Peripherals common to all Gumstix Overo boards (Tobi, Summit, Palo43,...)
  */
 
+/ {
+   lis33_3v3: lis33-3v3-reg {
+   compatible = regulator-fixed;
+   regulator-name = lis33-3v3-reg;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   };
+
+   lis33_1v8: lis33-1v8-reg {
+   compatible = regulator-fixed;
+   regulator-name = lis33-1v8-reg;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   };
+};
+
 omap3_pmx_core {
i2c3_pins: pinmux_i2c3_pins {
pinctrl-single,pins = 
@@ -37,6 +53,34 @@
reg = 0x51;
pagesize = 8;
};
+
+   lis33de: lis33de@1d {
+   compatible = st,lis33de, st,lis3lv02d;
+   reg = 0x1d;
+   Vdd-supply = lis33_1v8;
+   Vdd_IO-supply = lis33_3v3;
+
+   st,click-single-x;
+   st,click-single-y;
+   st,click-single-z;
+   st,click-thresh-x = 10;
+   st,click-thresh-y = 10;
+   st,click-thresh-z = 10;
+   st,irq1-click;
+   st,irq2-click;
+   st,wakeup-x-lo;
+   st,wakeup-x-hi;
+   st,wakeup-y-lo;
+   st,wakeup-y-hi;
+   st,wakeup-z-lo;
+   st,wakeup-z-hi;
+   st,min-limit-x = 120;
+   st,min-limit-y = 120;
+   st,min-limit-z = 140;
+   st,max-limit-x = 550;
+   st,max-limit-y = 550;
+   st,max-limit-z = 750;
+   };
 };
 
 mmc3 {
diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
index 060eb77..13df50b 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
@@ -35,3 +35,7 @@
};
 };
 
+lis33de {
+   status = disabled;
+};
+
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/7] ARM: dts: overo: Add new expansion boards

[Florian Vaussard]

Hi,

This series adds the support for 5 new expansion boards from Gumstix:
- Palo43
- Gallop43
- Chestnut43
- Alto35
- Summit

The 1st patch is a preparatory work, in order to factorize some
peripherals that are common to most Gumstix expansion boards. Patch 2
adds the support for an accelerometer that is present on most boards.

Palo43, Gallop43 and Chestnut43 are all pretty similar. I tested
on a Gallop43 (with both OMAP35xx and OMAP36xx Overo).

Alto35 is slightly different. Again, I tested with both OMAP35xx and
OMAP36xx Overo.

Summit is pretty similar to Tobi. I do not have a Summit at hand,
but given the similarity with Tobi, it should work fine.

To avoid unnecessary duplications, I put all the common stuff for each
board inside an omap3-overo-xxx-common.dsti include file. By doing so,
I can have minimal SoC-specific omap3-overo-xxx.dts (omap34xx based)
and omap3-overo-storm-xxx.dts (omap36xx based) device trees.

This series depends on my previous Overo series [1]. A complete testing
tree (including the graphics support, soon to be posted) is available
at [2].

Regards,
Florian

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/111558
[2] https://github.com/vaussard/linux.git (overo/for-3.15/review1)

Florian Vaussard (7):
  ARM: dts: overo: Create a file for common Gumstix peripherals
  ARM: dts: overo: Add LIS33DE accelerometer
  ARM: dts: Add support for the Overo Palo43
  ARM: dts: Add support for the Overo Gallop43
  ARM: dts: Add support for the Overo Alto35
  ARM: dts: Add support for the Overo Chestnut43
  ARM: dts: Add support for the Overo Summit

 arch/arm/boot/dts/Makefile | 10 +++
 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi   | 77 ++
 arch/arm/boot/dts/omap3-overo-alto35.dts   | 22 +
 .../boot/dts/omap3-overo-chestnut43-common.dtsi| 69 
 arch/arm/boot/dts/omap3-overo-chestnut43.dts   | 38 +
 .../boot/dts/omap3-overo-common-peripherals.dtsi   | 94 ++
 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi | 57 +
 arch/arm/boot/dts/omap3-overo-gallop43.dts | 38 +
 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi   | 53 
 arch/arm/boot/dts/omap3-overo-palo43.dts   | 38 +
 arch/arm/boot/dts/omap3-overo-storm-alto35.dts | 21 +
 arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts | 38 +
 arch/arm/boot/dts/omap3-overo-storm-gallop43.dts   | 38 +
 arch/arm/boot/dts/omap3-overo-storm-palo43.dts | 38 +
 arch/arm/boot/dts/omap3-overo-storm-summit.dts | 30 +++
 arch/arm/boot/dts/omap3-overo-summit-common.dtsi   | 31 +++
 arch/arm/boot/dts/omap3-overo-summit.dts   | 30 +++
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 38 +
 18 files changed, 725 insertions(+), 35 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-alto35.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-chestnut43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-gallop43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-palo43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-alto35.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-gallop43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-palo43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-summit.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-summit-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-summit.dts

-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] ARM: dts: Add support for the Overo Gallop43

[Florian Vaussard]

Gallop43 is an expansion board for Gumstix Overo products.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/Makefile |  2 +
 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi | 57 ++
 arch/arm/boot/dts/omap3-overo-gallop43.dts | 38 +++
 arch/arm/boot/dts/omap3-overo-storm-gallop43.dts   | 38 +++
 4 files changed, 135 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-gallop43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-gallop43.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 98d508d..bd7821b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -209,6 +209,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-n900.dtb \
omap3-n9.dtb \
omap3-n950.dtb \
+   omap3-overo-gallop43.dtb \
+   omap3-overo-storm-gallop43.dtb \
omap3-overo-palo43.dtb \
omap3-overo-storm-palo43.dtb \
omap3-overo-tobi.dtb \
diff --git a/arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi
new file mode 100644
index 000..5e848c2
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi
@@ -0,0 +1,57 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Gallop43 expansion board is manufactured by Gumstix Inc.
+ */
+
+#include omap3-overo-common-peripherals.dtsi
+
+#include dt-bindings/input/input.h
+
+/ {
+   leds {
+   compatible = gpio-leds;
+   pinctrl-names = default;
+   pinctrl-0 = led_pins;
+   heartbeat {
+   label = overo:red:gpio21;
+   gpios = gpio1 21 GPIO_ACTIVE_LOW;/* 
gpio_21 */
+   linux,default-trigger = heartbeat;
+   };
+   gpio22 {
+   label = overo:blue:gpio22;
+   gpios = gpio1 22 GPIO_ACTIVE_LOW;/* 
gpio_22 */
+   };
+   };
+
+   gpio_keys {
+   compatible = gpio-keys;
+   pinctrl-names = default;
+   pinctrl-0 = button_pins;
+   #address-cells = 1;
+   #size-cells = 0;
+   button0@23 {
+   label = button0;
+   linux,code = BTN_0;
+   gpios = gpio1 23 GPIO_ACTIVE_LOW;/* 
gpio_23 */
+   gpio-key,wakeup;
+   };
+   button1@14 {
+   label = button1;
+   linux,code = BTN_1;
+   gpios = gpio1 14 GPIO_ACTIVE_LOW;/* 
gpio_14 */
+   gpio-key,wakeup;
+   };
+   };
+};
+
+usbhshost {
+   status = disabled;
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-gallop43.dts 
b/arch/arm/boot/dts/omap3-overo-gallop43.dts
new file mode 100644
index 000..241f5c1
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-gallop43.dts
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Gallop43 expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include omap3-overo.dtsi
+#include omap3-overo-gallop43-common.dtsi
+
+/ {
+   model = OMAP35xx Gumstix Overo on Gallop43;
+   compatible = gumstix,omap3-overo-gallop43, gumstix,omap3-overo, 
ti,omap3430, ti,omap3;
+};
+
+omap3_pmx_core2 {
+   led_pins: pinmux_led_pins {
+   pinctrl-single,pins = 
+   OMAP3430_CORE2_IOPAD(0x25ea, PIN_OUTPUT | MUX_MODE4)
/* etk_d7.gpio_21 */
+   OMAP3430_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 */
+   ;
+   };
+
+   button_pins: pinmux_button_pins {
+   pinctrl-single,pins = 
+   OMAP3430_CORE2_IOPAD(0x25ee, PIN_INPUT | MUX_MODE4) 
/* etk_d9.gpio_23 */
+   OMAP3430_CORE2_IOPAD(0x25dc, PIN_INPUT | MUX_MODE4) 
/* etk_d0.gpio_14 */
+   ;
+   };
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-storm-gallop43.dts 
b/arch/arm/boot/dts/omap3-overo-storm-gallop43.dts
new file mode 100644
index 000..a1b57e0
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-storm-gallop43.dts
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or 

[PATCH 6/7] ARM: dts: Add support for the Overo Chestnut43

[Florian Vaussard]

Chestnut43 is an expansion board for Gumstix Overo products.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/Makefile |  2 +
 .../boot/dts/omap3-overo-chestnut43-common.dtsi| 69 ++
 arch/arm/boot/dts/omap3-overo-chestnut43.dts   | 38 
 arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts | 38 
 4 files changed, 147 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-chestnut43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-chestnut43.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index de5cfcc..7742e69 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -211,6 +211,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-n950.dtb \
omap3-overo-alto35.dtb \
omap3-overo-storm-alto35.dtb \
+   omap3-overo-chestnut43.dtb \
+   omap3-overo-storm-chestnut43.dtb \
omap3-overo-gallop43.dtb \
omap3-overo-storm-gallop43.dtb \
omap3-overo-palo43.dtb \
diff --git a/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
new file mode 100644
index 000..19de6ff
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Chestnut43 expansion board is manufactured by Gumstix Inc.
+ */
+
+#include omap3-overo-common-peripherals.dtsi
+
+#include dt-bindings/input/input.h
+
+/ {
+   leds {
+   compatible = gpio-leds;
+   pinctrl-names = default;
+   pinctrl-0 = led_pins;
+   heartbeat {
+   label = overo:red:gpio21;
+   gpios = gpio1 21 GPIO_ACTIVE_LOW;/* 
gpio_21 */
+   linux,default-trigger = heartbeat;
+   };
+   gpio22 {
+   label = overo:blue:gpio22;
+   gpios = gpio1 22 GPIO_ACTIVE_LOW;/* 
gpio_22 */
+   };
+   };
+
+   gpio_keys {
+   compatible = gpio-keys;
+   pinctrl-names = default;
+   pinctrl-0 = button_pins;
+   #address-cells = 1;
+   #size-cells = 0;
+   button0@23 {
+   label = button0;
+   linux,code = BTN_0;
+   gpios = gpio1 23 GPIO_ACTIVE_LOW;/* 
gpio_23 */
+   gpio-key,wakeup;
+   };
+   button1@14 {
+   label = button1;
+   linux,code = BTN_1;
+   gpios = gpio1 14 GPIO_ACTIVE_LOW;/* 
gpio_14 */
+   gpio-key,wakeup;
+   };
+   };
+};
+
+#include omap-gpmc-smsc9221.dtsi
+
+gpmc {
+   ranges = 5 0 0x2c00 0x100;/* CS5 */
+
+   ethernet@gpmc {
+   reg = 5 0 0xff;
+   interrupt-parent = gpio6;
+   interrupts = 16 IRQ_TYPE_LEVEL_LOW;   /* GPIO 176 */
+   };
+};
+
+lis33de {
+   status = disabled;
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-chestnut43.dts 
b/arch/arm/boot/dts/omap3-overo-chestnut43.dts
new file mode 100644
index 000..fe0824a
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-chestnut43.dts
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Chestnut43 expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include omap3-overo.dtsi
+#include omap3-overo-chestnut43-common.dtsi
+
+/ {
+   model = OMAP35xx Gumstix Overo on Chestnut43;
+   compatible = gumstix,omap3-overo-chestnut43, gumstix,omap3-overo, 
ti,omap3430, ti,omap3;
+};
+
+omap3_pmx_core2 {
+   led_pins: pinmux_led_pins {
+   pinctrl-single,pins = 
+   OMAP3430_CORE2_IOPAD(0x25ea, PIN_OUTPUT | MUX_MODE4)
/* etk_d7.gpio_21 */
+   OMAP3430_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 */
+   ;
+   };
+
+   button_pins: pinmux_button_pins {
+   pinctrl-single,pins = 
+   OMAP3430_CORE2_IOPAD(0x25ee, PIN_INPUT | MUX_MODE4) 
/* etk_d9.gpio_23 */
+   OMAP3430_CORE2_IOPAD(0x25dc, PIN_INPUT | MUX_MODE4) 
/* etk_d0.gpio_14 */
+   ;
+   };
+};
+
diff --git 

[PATCH 1/7] ARM: dts: overo: Create a file for common Gumstix peripherals

[Florian Vaussard]

Gumstix expansion boards share a couple of peripherals:
- uart3 is used for the console
- AT24C01 EEPROM on i2c3

Use this file for overo-tobi.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 .../boot/dts/omap3-overo-common-peripherals.dtsi   | 50 ++
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 40 +
 2 files changed, 52 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi

diff --git a/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi 
b/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
new file mode 100644
index 000..bca81ae
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Peripherals common to all Gumstix Overo boards (Tobi, Summit, Palo43,...)
+ */
+
+omap3_pmx_core {
+   i2c3_pins: pinmux_i2c3_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0)
/* i2c3_scl.i2c3_scl */
+   OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0)
/* i2c3_sda.i2c3_sda */
+   ;
+   };
+
+   uart3_pins: pinmux_uart3_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | 
PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
+   OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)   
/* uart3_tx_irtx.uart3_tx_irtx */
+   ;
+   };
+};
+
+i2c3 {
+   pinctrl-names = default;
+   pinctrl-0 = i2c3_pins;
+   clock-frequency = 10;
+
+   /* optional 1K EEPROM with revision information */
+   eeprom@51 {
+   compatible = atmel,24c01;
+   reg = 0x51;
+   pagesize = 8;
+   };
+};
+
+mmc3 {
+   status = disabled;
+};
+
+uart3 {
+   pinctrl-names = default;
+   pinctrl-0 = uart3_pins;
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
index 384e87d..060eb77 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
@@ -10,6 +10,8 @@
  * Tobi expansion board is manufactured by Gumstix Inc.
  */
 
+#include omap3-overo-common-peripherals.dtsi
+
 / {
leds {
compatible = gpio-leds;
@@ -21,22 +23,6 @@
};
 };
 
-omap3_pmx_core {
-   i2c3_pins: pinmux_i2c3_pins {
-   pinctrl-single,pins = 
-   OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0)
/* i2c3_scl.i2c3_scl */
-   OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0)
/* i2c3_sda.i2c3_sda */
-   ;
-   };
-
-   uart3_pins: pinmux_uart3_pins {
-   pinctrl-single,pins = 
-   OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | 
PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
-   OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)   
/* uart3_tx_irtx.uart3_tx_irtx */
-   ;
-   };
-};
-
 #include omap-gpmc-smsc9221.dtsi
 
 gpmc {
@@ -49,25 +35,3 @@
};
 };
 
-i2c3 {
-   pinctrl-names = default;
-   pinctrl-0 = i2c3_pins;
-   clock-frequency = 10;
-
-   /* optional 1K EEPROM with revision information */
-   eeprom@51 {
-   compatible = atmel,24c01;
-   reg = 0x51;
-   pagesize = 8;
-   };
-};
-
-mmc3 {
-   status = disabled;
-};
-
-uart3 {
-   pinctrl-names = default;
-   pinctrl-0 = uart3_pins;
-};
-
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] ARM: dts: Add support for the Overo Alto35

[Florian Vaussard]

Alto35 is an expansion board for Gumstix Overo products.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/Makefile   |  2 +
 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi | 77 
 arch/arm/boot/dts/omap3-overo-alto35.dts | 22 +++
 arch/arm/boot/dts/omap3-overo-storm-alto35.dts   | 21 +++
 4 files changed, 122 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-alto35.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-alto35.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd7821b..de5cfcc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -209,6 +209,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-n900.dtb \
omap3-n9.dtb \
omap3-n950.dtb \
+   omap3-overo-alto35.dtb \
+   omap3-overo-storm-alto35.dtb \
omap3-overo-gallop43.dtb \
omap3-overo-storm-gallop43.dtb \
omap3-overo-palo43.dtb \
diff --git a/arch/arm/boot/dts/omap3-overo-alto35-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-alto35-common.dtsi
new file mode 100644
index 000..19d6486
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-alto35-common.dtsi
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Alto35 expansion board is manufactured by Gumstix Inc.
+ */
+
+#include omap3-overo-common-peripherals.dtsi
+
+#include dt-bindings/input/input.h
+
+/ {
+   leds {
+   compatible = gpio-leds;
+   pinctrl-names = default;
+   pinctrl-0 = led_pins;
+   gpio148 {
+   label = overo:red:gpio148;
+   gpios = gpio5 20 GPIO_ACTIVE_HIGH;   /* gpio 
148 */
+   };
+   gpio150 {
+   label = overo:yellow:gpio150;
+   gpios = gpio5 22 GPIO_ACTIVE_HIGH;   /* gpio 
150 */
+   };
+   gpio151 {
+   label = overo:blue:gpio151;
+   gpios = gpio5 23 GPIO_ACTIVE_HIGH;   /* gpio 
151 */
+   };
+   gpio170 {
+   label = overo:green:gpio170;
+   gpios = gpio6 10 GPIO_ACTIVE_HIGH;   /* gpio 
170 */
+   };
+   };
+
+   gpio_keys {
+   compatible = gpio-keys;
+   #address-cells = 1;
+   #size-cells = 0;
+   pinctrl-names = default;
+   pinctrl-0 = button_pins;
+   button0@10 {
+   label = button0;
+   linux,code = BTN_0;
+   gpios = gpio1 10 GPIO_ACTIVE_LOW;/* 
gpio_10 */
+   gpio-key,wakeup;
+   };
+   };
+};
+
+omap3_pmx_core {
+   led_pins: pinmux_led_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE4)   
/* uart1_tx.gpio_148 */
+   OMAP3_CORE1_IOPAD(0x2180, PIN_OUTPUT | MUX_MODE4)   
/* uart1_cts.gpio_150 */
+   OMAP3_CORE1_IOPAD(0x2182, PIN_OUTPUT | MUX_MODE4)   
/* uart1_rx.gpio_151 */
+   OMAP3_CORE1_IOPAD(0x21c6, PIN_OUTPUT | MUX_MODE4)   
/* hdq_sio.gpio_170 */
+   ;
+   };
+};
+
+omap3_pmx_wkup {
+   button_pins: pinmux_button_pins {
+   pinctrl-single,pins = 
+   OMAP3_WKUP_IOPAD(0x2a18, PIN_INPUT | MUX_MODE4) 
/* sys_clkout1.gpio_10 */
+   ;
+   };
+};
+
+usbhshost {
+   status = disabled;
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-alto35.dts 
b/arch/arm/boot/dts/omap3-overo-alto35.dts
new file mode 100644
index 000..a3249eb
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-alto35.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Alto35 expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include omap3-overo.dtsi
+#include omap3-overo-alto35-common.dtsi
+
+/ {
+   model = OMAP35xx Gumstix Overo on Alto35;
+   compatible = gumstix,omap3-overo-alto35, gumstix,omap3-overo, 
ti,omap3430, ti,omap3;
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-storm-alto35.dts 
b/arch/arm/boot/dts/omap3-overo-storm-alto35.dts
new file mode 100644
index 000..e9cae52
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-storm-alto35.dts
@@ -0,0 +1,21 

[PATCH 7/7] ARM: dts: Add support for the Overo Summit

[Florian Vaussard]

Summit is an expansion board for Gumstix Overo products.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/Makefile   |  2 ++
 arch/arm/boot/dts/omap3-overo-storm-summit.dts   | 30 +++
 arch/arm/boot/dts/omap3-overo-summit-common.dtsi | 31 
 arch/arm/boot/dts/omap3-overo-summit.dts | 30 +++
 4 files changed, 93 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-summit.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-summit-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-summit.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7742e69..6565a7d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -217,6 +217,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-overo-storm-gallop43.dtb \
omap3-overo-palo43.dtb \
omap3-overo-storm-palo43.dtb \
+   omap3-overo-summit.dtb \
+   omap3-overo-storm-summit.dtb \
omap3-overo-tobi.dtb \
omap3-overo-storm-tobi.dtb \
omap3-gta04.dtb \
diff --git a/arch/arm/boot/dts/omap3-overo-storm-summit.dts 
b/arch/arm/boot/dts/omap3-overo-storm-summit.dts
new file mode 100644
index 000..a0d7fd8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-storm-summit.dts
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Summit expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include omap3-overo-storm.dtsi
+#include omap3-overo-summit-common.dtsi
+
+/ {
+   model = OMAP36xx/AM37xx/DM37xx Gumstix Overo on Summit;
+   compatible = gumstix,omap3-overo-summit, gumstix,omap3-overo, 
ti,omap36xx, ti,omap3;
+};
+
+omap3_pmx_core2 {
+   led_pins: pinmux_led_pins {
+   pinctrl-single,pins = 
+   OMAP3630_CORE2_IOPAD(0x25ea, PIN_OUTPUT | MUX_MODE4)
/* etk_d7.gpio_21 */
+   ;
+   };
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-summit-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-summit-common.dtsi
new file mode 100644
index 000..999d1cd
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-summit-common.dtsi
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Summit expansion board is manufactured by Gumstix Inc.
+ */
+
+#include omap3-overo-common-peripherals.dtsi
+
+/ {
+   leds {
+   compatible = gpio-leds;
+   pinctrl-names = default;
+   pinctrl-0 = led_pins;
+   heartbeat {
+   label = overo:red:gpio21;
+   gpios = gpio1 21 GPIO_ACTIVE_LOW;/* 
gpio_21 */
+   linux,default-trigger = heartbeat;
+   };
+   };
+};
+
+lis33de {
+   status = disabled;
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-summit.dts 
b/arch/arm/boot/dts/omap3-overo-summit.dts
new file mode 100644
index 000..6976560
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-summit.dts
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Summit expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include omap3-overo.dtsi
+#include omap3-overo-summit-common.dtsi
+
+/ {
+   model = OMAP35xx Gumstix Overo on Summit;
+   compatible = gumstix,omap3-overo-summit, gumstix,omap3-overo, 
ti,omap3430, ti,omap3;
+};
+
+omap3_pmx_core2 {
+   led_pins: pinmux_led_pins {
+   pinctrl-single,pins = 
+   OMAP3430_CORE2_IOPAD(0x25ea, PIN_OUTPUT | MUX_MODE4)
/* etk_d7.gpio_21 */
+   ;
+   };
+};
+
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7] ARM: dts: Add support for the Overo Palo43

[Florian Vaussard]

Palo43 is an expansion board for Gumstix Overo products.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/Makefile   |  2 +
 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi | 53 
 arch/arm/boot/dts/omap3-overo-palo43.dts | 38 +
 arch/arm/boot/dts/omap3-overo-storm-palo43.dts   | 38 +
 4 files changed, 131 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-palo43.dts
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-palo43.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..98d508d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -209,6 +209,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-n900.dtb \
omap3-n9.dtb \
omap3-n950.dtb \
+   omap3-overo-palo43.dtb \
+   omap3-overo-storm-palo43.dtb \
omap3-overo-tobi.dtb \
omap3-overo-storm-tobi.dtb \
omap3-gta04.dtb \
diff --git a/arch/arm/boot/dts/omap3-overo-palo43-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-palo43-common.dtsi
new file mode 100644
index 000..abea232
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-palo43-common.dtsi
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Palo43 expansion board is manufactured by Gumstix Inc.
+ */
+
+#include omap3-overo-common-peripherals.dtsi
+
+#include dt-bindings/input/input.h
+
+/ {
+   leds {
+   compatible = gpio-leds;
+   pinctrl-names = default;
+   pinctrl-0 = led_pins;
+   heartbeat {
+   label = overo:red:gpio21;
+   gpios = gpio1 21 GPIO_ACTIVE_LOW;/* 
gpio_21 */
+   linux,default-trigger = heartbeat;
+   };
+   gpio22 {
+   label = overo:blue:gpio22;
+   gpios = gpio1 22 GPIO_ACTIVE_LOW;/* 
gpio_22 */
+   };
+   };
+
+   gpio_keys {
+   compatible = gpio-keys;
+   pinctrl-names = default;
+   pinctrl-0 = button_pins;
+   #address-cells = 1;
+   #size-cells = 0;
+   button0@23 {
+   label = button0;
+   linux,code = BTN_0;
+   gpios = gpio1 23 GPIO_ACTIVE_LOW;/* 
gpio_23 */
+   gpio-key,wakeup;
+   };
+   button1@14 {
+   label = button1;
+   linux,code = BTN_1;
+   gpios = gpio1 14 GPIO_ACTIVE_LOW;/* 
gpio_14 */
+   gpio-key,wakeup;
+   };
+   };
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-palo43.dts 
b/arch/arm/boot/dts/omap3-overo-palo43.dts
new file mode 100644
index 000..cedb103
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-palo43.dts
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Palo43 expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include omap3-overo.dtsi
+#include omap3-overo-palo43-common.dtsi
+
+/ {
+   model = OMAP35xx Gumstix Overo on Palo43;
+   compatible = gumstix,omap3-overo-palo43, gumstix,omap3-overo, 
ti,omap3430, ti,omap3;
+};
+
+omap3_pmx_core2 {
+   led_pins: pinmux_led_pins {
+   pinctrl-single,pins = 
+   OMAP3430_CORE2_IOPAD(0x25ea, PIN_OUTPUT | MUX_MODE4)
/* etk_d7.gpio_21 */
+   OMAP3430_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 */
+   ;
+   };
+
+   button_pins: pinmux_button_pins {
+   pinctrl-single,pins = 
+   OMAP3430_CORE2_IOPAD(0x25ee, PIN_INPUT | MUX_MODE4) 
/* etk_d9.gpio_23 */
+   OMAP3430_CORE2_IOPAD(0x25dc, PIN_INPUT | MUX_MODE4) 
/* etk_d0.gpio_14 */
+   ;
+   };
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-storm-palo43.dts 
b/arch/arm/boot/dts/omap3-overo-storm-palo43.dts
new file mode 100644
index 000..b585d8f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-storm-palo43.dts
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the 

Re: [PATCH v3 07/14] v4l: ti-vpe: Add selection API in VPE driver

[Hans Verkuil]

Hi Archit,

A few small comments below...

On 03/11/14 09:33, Archit Taneja wrote:
 Add selection ioctl ops. For VPE, cropping makes sense only for the input to
 VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
 only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers).
 
 For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output
 in a rectangle within the capture buffer. For the OUTPUT type, 
 V4L2_SEL_TGT_CROP
 results in selecting a rectangle region within the source buffer.
 
 Setting the crop/compose rectangles should successfully result in
 re-configuration of registers which are affected when either source or
 destination dimensions change, set_srcdst_params() is called for this purpose.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/platform/ti-vpe/vpe.c | 141 
 
  1 file changed, 141 insertions(+)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index ece9b96..4abb85c 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx *ctx,
  {
   switch (type) {
   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
 + case V4L2_BUF_TYPE_VIDEO_OUTPUT:
   return ctx-q_data[Q_DATA_SRC];
   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
 + case V4L2_BUF_TYPE_VIDEO_CAPTURE:
   return ctx-q_data[Q_DATA_DST];
   default:
   BUG();
 @@ -1587,6 +1589,142 @@ static int vpe_s_fmt(struct file *file, void *priv, 
 struct v4l2_format *f)
   return set_srcdst_params(ctx);
  }
  
 +static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection *s)
 +{
 + struct vpe_q_data *q_data;
 +
 + if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
 + (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
 + return -EINVAL;
 +
 + q_data = get_q_data(ctx, s-type);
 + if (!q_data)
 + return -EINVAL;
 +
 + switch (s-target) {
 + case V4L2_SEL_TGT_COMPOSE:
 + /*
 +  * COMPOSE target is only valid for capture buffer type, for
 +  * output buffer type, assign existing crop parameters to the
 +  * selection rectangle
 +  */
 + if (s-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
 + break;

Shouldn't this return -EINVAL?

 +
 + s-r = q_data-c_rect;
 + return 0;
 +
 + case V4L2_SEL_TGT_CROP:
 + /*
 +  * CROP target is only valid for output buffer type, for capture
 +  * buffer type, assign existing compose parameters to the
 +  * selection rectangle
 +  */
 + if (s-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
 + break;

Ditto.

 +
 + s-r = q_data-c_rect;
 + return 0;
 +
 + /*
 +  * bound and default crop/compose targets are invalid targets to
 +  * try/set
 +  */
 + default:
 + return -EINVAL;
 + }
 +
 + if (s-r.top  0 || s-r.left  0) {
 + vpe_err(ctx-dev, negative values for top and left\n);
 + s-r.top = s-r.left = 0;
 + }
 +
 + v4l_bound_align_image(s-r.width, MIN_W, q_data-width, 1,
 + s-r.height, MIN_H, q_data-height, H_ALIGN, S_ALIGN);
 +
 + /* adjust left/top if cropping rectangle is out of bounds */
 + if (s-r.left + s-r.width  q_data-width)
 + s-r.left = q_data-width - s-r.width;
 + if (s-r.top + s-r.height  q_data-height)
 + s-r.top = q_data-height - s-r.height;
 +
 + return 0;
 +}
 +
 +static int vpe_g_selection(struct file *file, void *fh,
 + struct v4l2_selection *s)
 +{
 + struct vpe_ctx *ctx = file2ctx(file);
 + struct vpe_q_data *q_data;
 +
 + if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
 + (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
 + return -EINVAL;
 +
 + q_data = get_q_data(ctx, s-type);
 + if (!q_data)
 + return -EINVAL;
 +
 + switch (s-target) {
 + /* return width and height from S_FMT of the respective buffer type */
 + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
 + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
 + case V4L2_SEL_TGT_CROP_BOUNDS:
 + case V4L2_SEL_TGT_CROP_DEFAULT:
 + s-r.left = 0;
 + s-r.top = 0;
 + s-r.width = q_data-width;
 + s-r.height = q_data-height;

The crop targets only make sense for type OUTPUT and the compose only for
type CAPTURE. Add some checks for that.

 + return 0;
 +
 + /*
 +  * CROP target holds for the output buffer type, and COMPOSE target
 +  * holds for the capture buffer type. We still return the c_rect params
 +  * for both the target types.
 +  */
 + case V4L2_SEL_TGT_COMPOSE:
 + case V4L2_SEL_TGT_CROP:
 + s-r.left = 

Re: [PATCH v3 09/14] v4l: ti-vpe: report correct capabilities in querycap

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 querycap currently returns V4L2_CAP_VIDEO_M2M as a capability, this should be
 V4L2_CAP_VIDEO_M2M_MPLANE instead, as the driver supports multiplanar formats.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index 4abb85c..46b9d44 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -1347,7 +1347,7 @@ static int vpe_querycap(struct file *file, void *priv,
   strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1);
   strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1);
   strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info));
 - cap-device_caps  = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING;
 + cap-device_caps  = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
   cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
   return 0;
  }
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 10/14] v4l: ti-vpe: Use correct bus_info name for the device in querycap

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 The bus_info parameter in v4l2_capabilities expects a 'platform_' prefix. This
 wasn't done in the driver and hence was breaking compliance. Update the 
 bus_info
 parameter accordingly.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index 46b9d44..5591d04 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -1346,7 +1346,8 @@ static int vpe_querycap(struct file *file, void *priv,
  {
   strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1);
   strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1);
 - strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info));
 + snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
 + VPE_MODULE_NAME);
   cap-device_caps  = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
   cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
   return 0;
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 11/14] v4l: ti-vpe: Fix initial configuration queue data

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 The vpe output and capture queues are initially configured to default values 
 in
 vpe_open(). A G_FMT before any S_FMTs will result in these values being
 populated.
 
 The colorspace and bytesperline parameter of this initial configuration are
 incorrect. This breaks compliance when as we get 'TRY_FMT(G_FMT) != G_FMT'.
 
 Fix the initial queue configuration such that it wouldn't need to be fixed by
 try_fmt.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index 5591d04..85d1122 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -2012,9 +2012,11 @@ static int vpe_open(struct file *file)
   s_q_data-fmt = vpe_formats[2];
   s_q_data-width = 1920;
   s_q_data-height = 1080;
 - s_q_data-sizeimage[VPE_LUMA] = (s_q_data-width * s_q_data-height *
 + s_q_data-bytesperline[VPE_LUMA] = (s_q_data-width *
   s_q_data-fmt-vpdma_fmt[VPE_LUMA]-depth)  3;
 - s_q_data-colorspace = V4L2_COLORSPACE_SMPTE170M;
 + s_q_data-sizeimage[VPE_LUMA] = (s_q_data-bytesperline[VPE_LUMA] *
 + s_q_data-height);
 + s_q_data-colorspace = V4L2_COLORSPACE_REC709;
   s_q_data-field = V4L2_FIELD_NONE;
   s_q_data-c_rect.left = 0;
   s_q_data-c_rect.top = 0;
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 12/14] v4l: ti-vpe: zero out reserved fields in try_fmt

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 Zero out the reserved formats in v4l2_pix_format_mplane and
 v4l2_plane_pix_format members of the returned v4l2_format pointer when passed
 through TRY_FMT ioctl.
 
 This ensures that the user doesn't interpret the non-zero fields as some data
 passed by the driver, and ensures compliance.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index 85d1122..970408a 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -1488,6 +1488,7 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct 
 v4l2_format *f,
   }
   }
  
 + memset(pix-reserved, 0, sizeof(pix-reserved));
   for (i = 0; i  pix-num_planes; i++) {
   plane_fmt = pix-plane_fmt[i];
   depth = fmt-vpdma_fmt[i]-depth;
 @@ -1499,6 +1500,8 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct 
 v4l2_format *f,
  
   plane_fmt-sizeimage =
   (pix-height * pix-width * depth)  3;
 +
 + memset(plane_fmt-reserved, 0, sizeof(plane_fmt-reserved));
   }
  
   return 0;
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 13/14] v4l: ti-vpe: Set correct field parameter for output and capture buffers

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 The vpe driver wasn't setting the correct field parameter for dequed CAPTURE
 type buffers for the case where the captured output is progressive.
 
 Set the field to V4L2_FIELD_NONE for the completed destination buffers when
 the captured output is progressive.
 
 For OUTPUT type buffers, a queued buffer's field is forced to V4L2_FIELD_NONE
 if the pixel format(configured through s_fmt for the buffer type
 V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE specifies) the field type isn't interlaced.
 If the pixel format specified was V4L2_FIELD_ALTERNATE, and the queued 
 buffer's
 field isn't V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM, the vb2 buf_prepare op 
 returns
 an error.
 
 This ensures compliance, and that the dequeued output and captured buffers
 contain the field type that the driver used internally.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index 970408a..c884910 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -1296,10 +1296,10 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
   d_buf-timecode = s_buf-timecode;
   }
   d_buf-sequence = ctx-sequence;
 - d_buf-field = ctx-field;
  
   d_q_data = ctx-q_data[Q_DATA_DST];
   if (d_q_data-flags  Q_DATA_INTERLACED) {
 + d_buf-field = ctx-field;
   if (ctx-field == V4L2_FIELD_BOTTOM) {
   ctx-sequence++;
   ctx-field = V4L2_FIELD_TOP;
 @@ -1308,6 +1308,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
   ctx-field = V4L2_FIELD_BOTTOM;
   }
   } else {
 + d_buf-field = V4L2_FIELD_NONE;
   ctx-sequence++;
   }
  
 @@ -1871,6 +1872,16 @@ static int vpe_buf_prepare(struct vb2_buffer *vb)
   q_data = get_q_data(ctx, vb-vb2_queue-type);
   num_planes = q_data-fmt-coplanar ? 2 : 1;
  
 + if (vb-vb2_queue-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 + if (!(q_data-flags  Q_DATA_INTERLACED)) {
 + vb-v4l2_buf.field = V4L2_FIELD_NONE;
 + } else {
 + if (vb-v4l2_buf.field != V4L2_FIELD_TOP ||
 + vb-v4l2_buf.field != V4L2_FIELD_BOTTOM)
 + return -EINVAL;
 + }
 + }
 +
   for (i = 0; i  num_planes; i++) {
   if (vb2_plane_size(vb, i)  q_data-sizeimage[i]) {
   vpe_err(ctx-dev,
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 14/14] v4l: ti-vpe: retain v4l2_buffer flags for captured buffers

[Hans Verkuil]

On 03/11/14 09:33, Archit Taneja wrote:
 The dequed CAPTURE_MPLANE type buffers don't contain the flags that the
 originally queued OUTPUT_MPLANE type buffers have. This breaks compliance.
 
 Copy the source v4l2_buffer flags to the destination v4l2_buffer flags before
 they are dequed.
 
 Signed-off-by: Archit Taneja arc...@ti.com

Reviewed-by: Hans Verkuil hans.verk...@cisco.com

 ---
  drivers/media/platform/ti-vpe/vpe.c | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index c884910..f7759e8 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -1288,13 +1288,12 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
   s_buf = s_vb-v4l2_buf;
   d_buf = d_vb-v4l2_buf;
  
 + d_buf-flags = s_buf-flags;
 +
   d_buf-timestamp = s_buf-timestamp;
 - d_buf-flags = ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
 - d_buf-flags |= s_buf-flags  V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
 - if (s_buf-flags  V4L2_BUF_FLAG_TIMECODE) {
 - d_buf-flags |= V4L2_BUF_FLAG_TIMECODE;
 + if (s_buf-flags  V4L2_BUF_FLAG_TIMECODE)
   d_buf-timecode = s_buf-timecode;
 - }
 +
   d_buf-sequence = ctx-sequence;
  
   d_q_data = ctx-q_data[Q_DATA_DST];
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ARM: dts: overo: Add support for DVI output

[Florian Vaussard]

Summit and Tobi expansion boards have a HDMI connector with a TFP410
encoder. Add a common include file for this configuration, and then
use it for Summit and Tobi.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi| 109 +++
 arch/arm/boot/dts/omap3-overo-summit-common.dtsi |   1 +
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi   |   1 +
 3 files changed, 111 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi

diff --git a/arch/arm/boot/dts/omap3-overo-common-dvi.dtsi 
b/arch/arm/boot/dts/omap3-overo-common-dvi.dtsi
new file mode 100644
index 000..6fb5d1e
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-common-dvi.dtsi
@@ -0,0 +1,109 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * DVI output for some Gumstix Overo boards (Tobi and Summit)
+ */
+
+omap3_pmx_core {
+   i2c3_pins: pinmux_i2c3_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0)
/* i2c3_scl.i2c3_scl */
+   OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0)
/* i2c3_sda.i2c3_sda */
+   ;
+   };
+
+   dss_dpi_pins: pinmux_dss_dpi_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   
/* dss_pclk.dss_pclk */
+   OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   
/* dss_hsync.dss_hsync */
+   OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   
/* dss_vsync.dss_vsync */
+   OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   
/* dss_acbias.dss_acbias */
+   OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)   
/* dss_data0.dss_data0 */
+   OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)   
/* dss_data1.dss_data1 */
+   OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)   
/* dss_data2.dss_data2 */
+   OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)   
/* dss_data3.dss_data3 */
+   OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)   
/* dss_data4.dss_data4 */
+   OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)   
/* dss_data5.dss_data5 */
+   OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   
/* dss_data6.dss_data6 */
+   OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   
/* dss_data7.dss_data7 */
+   OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   
/* dss_data8.dss_data8 */
+   OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   
/* dss_data9.dss_data9 */
+   OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   
/* dss_data10.dss_data10 */
+   OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   
/* dss_data11.dss_data11 */
+   OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   
/* dss_data12.dss_data12 */
+   OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   
/* dss_data13.dss_data13 */
+   OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   
/* dss_data14.dss_data14 */
+   OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   
/* dss_data15.dss_data15 */
+   OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   
/* dss_data16.dss_data16 */
+   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   
/* dss_data17.dss_data17 */
+   OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE0)   
/* dss_data18.dss_data18 */
+   OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE0)   
/* dss_data19.dss_data19 */
+   OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE0)   
/* dss_data20.dss_data20 */
+   OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE0)   
/* dss_data21.dss_data21 */
+   OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE0)   
/* dss_data22.dss_data22 */
+   OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE0)   
/* dss_data23.dss_data23 */
+   ;
+   };
+};
+
+dss {
+   status = ok;
+
+   pinctrl-names = default;
+   pinctrl-0 = dss_dpi_pins
+i2c3_pins;
+
+   dpi_out: endpoint {
+   remote-endpoint = tfp410_in;
+   data-lines = 24;
+   };
+};
+
+/ {
+   aliases {
+   display0 = dvi0;
+   };
+
+   tfp410: encoder@0 {
+   compatible = ti,tfp410;
+
+   ports {
+

[PATCH 3/3] ARM: dts: overo: Add support for 3.5'' LCD output

[Florian Vaussard]

Alto35 expansion board has a ZIF connector for a 3.5'' LCD.
Add a common include file for this configuration, and use it
on Alto35.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi |   1 +
 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi  | 145 +++
 2 files changed, 146 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi

diff --git a/arch/arm/boot/dts/omap3-overo-alto35-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-alto35-common.dtsi
index 19d6486..7aae8fb 100644
--- a/arch/arm/boot/dts/omap3-overo-alto35-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-alto35-common.dtsi
@@ -11,6 +11,7 @@
  */
 
 #include omap3-overo-common-peripherals.dtsi
+#include omap3-overo-common-lcd35.dtsi
 
 #include dt-bindings/input/input.h
 
diff --git a/arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi 
b/arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi
new file mode 100644
index 000..5e0373b3
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi
@@ -0,0 +1,145 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * 4.3'' LCD panel output for some Gumstix Overo boards (Gallop43, Chestnut43)
+ */
+
+omap3_pmx_core {
+   dss_dpi_pins: pinmux_dss_dpi_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   
/* dss_pclk.dss_pclk */
+   OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   
/* dss_hsync.dss_hsync */
+   OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   
/* dss_vsync.dss_vsync */
+   OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   
/* dss_acbias.dss_acbias */
+   OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)   
/* dss_data0.dss_data0 */
+   OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)   
/* dss_data1.dss_data1 */
+   OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)   
/* dss_data2.dss_data2 */
+   OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)   
/* dss_data3.dss_data3 */
+   OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)   
/* dss_data4.dss_data4 */
+   OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)   
/* dss_data5.dss_data5 */
+   OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   
/* dss_data6.dss_data6 */
+   OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   
/* dss_data7.dss_data7 */
+   OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   
/* dss_data8.dss_data8 */
+   OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   
/* dss_data9.dss_data9 */
+   OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   
/* dss_data10.dss_data10 */
+   OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   
/* dss_data11.dss_data11 */
+   OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   
/* dss_data12.dss_data12 */
+   OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   
/* dss_data13.dss_data13 */
+   OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   
/* dss_data14.dss_data14 */
+   OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   
/* dss_data15.dss_data15 */
+   OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   
/* dss_data16.dss_data16 */
+   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   
/* dss_data17.dss_data17 */
+   OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE0)   
/* dss_data18.dss_data18 */
+   OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE0)   
/* dss_data19.dss_data19 */
+   OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE0)   
/* dss_data20.dss_data20 */
+   OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE0)   
/* dss_data21.dss_data21 */
+   OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE0)   
/* dss_data22.dss_data22 */
+   OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE0)   
/* dss_data23.dss_data23 */
+   OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE4)   
/* uart2_cts.gpio_144 */
+   OMAP3_CORE1_IOPAD(0x2176, PIN_OUTPUT | MUX_MODE4)   
/* uart2_rts.gpio_145 */
+   ;
+   };
+
+   mcspi1_pins: pinmux_mcspi1_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x21c8, PIN_INPUT | MUX_MODE0)
/* mcspi1_clk.mcspi1_clk */

[PATCH 2/3] ARM: dts: overo: Add support for 4.3'' LCD output

[Florian Vaussard]

Chestnut43, Gallop43 and Palo43 expansion boards have a ZIF connector
for a 4.3'' LCD.Add a common include file for this configuration, and
use it on relevant expansion boards.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 .../boot/dts/omap3-overo-chestnut43-common.dtsi|   1 +
 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi| 146 +
 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi |   1 +
 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi   |   1 +
 4 files changed, 149 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi

diff --git a/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
index 19de6ff..17b82f8 100644
--- a/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
@@ -11,6 +11,7 @@
  */
 
 #include omap3-overo-common-peripherals.dtsi
+#include omap3-overo-common-lcd43.dtsi
 
 #include dt-bindings/input/input.h
 
diff --git a/arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi 
b/arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi
new file mode 100644
index 000..c876d0d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * 4.3'' LCD panel output for some Gumstix Overo boards (Gallop43, Chestnut43)
+ */
+
+omap3_pmx_core {
+   dss_dpi_pins: pinmux_dss_dpi_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   
/* dss_pclk.dss_pclk */
+   OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   
/* dss_hsync.dss_hsync */
+   OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   
/* dss_vsync.dss_vsync */
+   OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   
/* dss_acbias.dss_acbias */
+   OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)   
/* dss_data0.dss_data0 */
+   OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)   
/* dss_data1.dss_data1 */
+   OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)   
/* dss_data2.dss_data2 */
+   OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)   
/* dss_data3.dss_data3 */
+   OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)   
/* dss_data4.dss_data4 */
+   OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)   
/* dss_data5.dss_data5 */
+   OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   
/* dss_data6.dss_data6 */
+   OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   
/* dss_data7.dss_data7 */
+   OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   
/* dss_data8.dss_data8 */
+   OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   
/* dss_data9.dss_data9 */
+   OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   
/* dss_data10.dss_data10 */
+   OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   
/* dss_data11.dss_data11 */
+   OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   
/* dss_data12.dss_data12 */
+   OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   
/* dss_data13.dss_data13 */
+   OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   
/* dss_data14.dss_data14 */
+   OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   
/* dss_data15.dss_data15 */
+   OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   
/* dss_data16.dss_data16 */
+   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   
/* dss_data17.dss_data17 */
+   OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE0)   
/* dss_data18.dss_data18 */
+   OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE0)   
/* dss_data19.dss_data19 */
+   OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE0)   
/* dss_data20.dss_data20 */
+   OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE0)   
/* dss_data21.dss_data21 */
+   OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE0)   
/* dss_data22.dss_data22 */
+   OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE0)   
/* dss_data23.dss_data23 */
+   OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE4)   
/* uart2_cts.gpio_144 */
+   OMAP3_CORE1_IOPAD(0x2176, PIN_OUTPUT | MUX_MODE4)   
/* uart2_rts.gpio_145 */
+   ;
+   };
+
+   

[PATCH 0/3] ARM: dts: overo: Add graphics output

[Florian Vaussard]

Hi,

This series enables the DVI / LCD graphics present on some of
the Overo expansion boards.

DVI output:
- Tobi
- Summit

LCD (3.5''):
- Alto35

LCD (4.3''):
- Chestnut43
- Palo43
- Gallop43

I tested on Tobi, Alto35 and Gallop43 using both OMAP35xx and OMAP36xx
Overo boards.

This series depends on Tomi's DSS patches [1] that are not yet merged.
It also depends on previous Overo series [2] and [3] that are under
review. A complete testing tree is available [4].

Regards,
Florian

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/295881
[2] http://thread.gmane.org/gmane.linux.ports.arm.omap/111558
[3] http://thread.gmane.org/gmane.linux.ports.arm.omap/111689
[4] https://github.com/vaussard/linux.git (overo/for-3.15/review1)

Florian Vaussard (3):
  ARM: dts: overo: Add support for DVI output
  ARM: dts: overo: Add support for 4.3'' LCD output
  ARM: dts: overo: Add support for 3.5'' LCD output

 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi   |   1 +
 .../boot/dts/omap3-overo-chestnut43-common.dtsi|   1 +
 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi  | 109 +++
 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi| 145 
 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi| 146 +
 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi |   1 +
 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi   |   1 +
 arch/arm/boot/dts/omap3-overo-summit-common.dtsi   |   1 +
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi |   1 +
 9 files changed, 406 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi

-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 4/4] omap crossbar support for v3.15

[Sricharan R]

Tony,

On Monday 10 March 2014 10:06 PM, Tony Lindgren wrote:
 * Olof Johansson o...@lixom.net [140308 23:36]:
 On Sun, Mar 02, 2014 at 03:14:49PM -0800, Tony Lindgren wrote:
 The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:

   Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.15/crossbar-signed

 for you to fetch changes up to 9594274201ac3c67d5c569aae63792e58bcd33e6:

   Merge branch 'crossbar_3.14_rc1' of 
 git://github.com/Sricharanti/sricharan into omap-for-v3.15/crossbar 
 (2014-02-28 13:35:02 -0800)

 

 Add support for GIC crossbar that routes interrupts on newer omaps.

 Looks like people wanted these merged via the omap tree as it's
 the only user for the GIC crossbar.

 
 Sricharan R (4):
   DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
   DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
   ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
   ARM: DRA: Enable Crossbar IP support for DRA7XX
 Whoa, lots of caps on those driver subjects. I don't think we need those
 in the future, lower case is just fine (and DRIVERS: usually isn't used).
 Oops yeah I had them as irqchip: crossbar and irqchip: irq-gic in
 my earlier branch for v3.14 that did not get merged, but this time I
 pulled from Sricharan.

 Scricharan, maybe use less yelling naming for any follow-up patches?
  
  Will make sure that there are no caps in the follow up patches.

Regards,
 Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 07/14] v4l: ti-vpe: Add selection API in VPE driver

[Archit Taneja]

On Tuesday 11 March 2014 05:51 PM, Hans Verkuil wrote:

Hi Archit,

A few small comments below...

On 03/11/14 09:33, Archit Taneja wrote:

Add selection ioctl ops. For VPE, cropping makes sense only for the input to
VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers).

For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output
in a rectangle within the capture buffer. For the OUTPUT type, V4L2_SEL_TGT_CROP
results in selecting a rectangle region within the source buffer.

Setting the crop/compose rectangles should successfully result in
re-configuration of registers which are affected when either source or
destination dimensions change, set_srcdst_params() is called for this purpose.

Signed-off-by: Archit Taneja arc...@ti.com
---
  drivers/media/platform/ti-vpe/vpe.c | 141 
  1 file changed, 141 insertions(+)

diff --git a/drivers/media/platform/ti-vpe/vpe.c 
b/drivers/media/platform/ti-vpe/vpe.c
index ece9b96..4abb85c 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx *ctx,
  {
switch (type) {
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+   case V4L2_BUF_TYPE_VIDEO_OUTPUT:
return ctx-q_data[Q_DATA_SRC];
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
+   case V4L2_BUF_TYPE_VIDEO_CAPTURE:
return ctx-q_data[Q_DATA_DST];
default:
BUG();
@@ -1587,6 +1589,142 @@ static int vpe_s_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
return set_srcdst_params(ctx);
  }

+static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection *s)
+{
+   struct vpe_q_data *q_data;
+
+   if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
+   (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
+   return -EINVAL;
+
+   q_data = get_q_data(ctx, s-type);
+   if (!q_data)
+   return -EINVAL;
+
+   switch (s-target) {
+   case V4L2_SEL_TGT_COMPOSE:
+   /*
+* COMPOSE target is only valid for capture buffer type, for
+* output buffer type, assign existing crop parameters to the
+* selection rectangle
+*/
+   if (s-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   break;


Shouldn't this return -EINVAL?


compose only makes sense for CAPTURE. So, it breaks and performs the 
calculations after the switch statement.





+
+   s-r = q_data-c_rect;
+   return 0;


The above 2 lines are called for if we try to set compose for OUTPUT. I 
don't return an error here, just keep the size as the original rect 
size, and return 0.


I'll replace these 2 lines with 'return -EINVAL;'


+
+   case V4L2_SEL_TGT_CROP:
+   /*
+* CROP target is only valid for output buffer type, for capture
+* buffer type, assign existing compose parameters to the
+* selection rectangle
+*/
+   if (s-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+   break;


Ditto.


+
+   s-r = q_data-c_rect;
+   return 0;
+
+   /*
+* bound and default crop/compose targets are invalid targets to
+* try/set
+*/
+   default:
+   return -EINVAL;
+   }
+
+   if (s-r.top  0 || s-r.left  0) {
+   vpe_err(ctx-dev, negative values for top and left\n);
+   s-r.top = s-r.left = 0;
+   }
+
+   v4l_bound_align_image(s-r.width, MIN_W, q_data-width, 1,
+   s-r.height, MIN_H, q_data-height, H_ALIGN, S_ALIGN);
+
+   /* adjust left/top if cropping rectangle is out of bounds */
+   if (s-r.left + s-r.width  q_data-width)
+   s-r.left = q_data-width - s-r.width;
+   if (s-r.top + s-r.height  q_data-height)
+   s-r.top = q_data-height - s-r.height;
+
+   return 0;
+}
+
+static int vpe_g_selection(struct file *file, void *fh,
+   struct v4l2_selection *s)
+{
+   struct vpe_ctx *ctx = file2ctx(file);
+   struct vpe_q_data *q_data;
+
+   if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
+   (s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
+   return -EINVAL;
+
+   q_data = get_q_data(ctx, s-type);
+   if (!q_data)
+   return -EINVAL;
+
+   switch (s-target) {
+   /* return width and height from S_FMT of the respective buffer type */
+   case V4L2_SEL_TGT_COMPOSE_DEFAULT:
+   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+   case V4L2_SEL_TGT_CROP_BOUNDS:
+   case V4L2_SEL_TGT_CROP_DEFAULT:
+   s-r.left = 0;
+   s-r.top = 0;
+   s-r.width = q_data-width;
+   s-r.height = q_data-height;


The crop targets only make sense 

Re: [PATCH v3 07/14] v4l: ti-vpe: Add selection API in VPE driver

[Hans Verkuil]

On 03/11/14 13:46, Archit Taneja wrote:
 On Tuesday 11 March 2014 05:51 PM, Hans Verkuil wrote:
 Hi Archit,

 A few small comments below...

 On 03/11/14 09:33, Archit Taneja wrote:
 Add selection ioctl ops. For VPE, cropping makes sense only for the input to
 VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
 only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers).

 For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output
 in a rectangle within the capture buffer. For the OUTPUT type, 
 V4L2_SEL_TGT_CROP
 results in selecting a rectangle region within the source buffer.

 Setting the crop/compose rectangles should successfully result in
 re-configuration of registers which are affected when either source or
 destination dimensions change, set_srcdst_params() is called for this 
 purpose.

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
   drivers/media/platform/ti-vpe/vpe.c | 141 
 
   1 file changed, 141 insertions(+)

 diff --git a/drivers/media/platform/ti-vpe/vpe.c 
 b/drivers/media/platform/ti-vpe/vpe.c
 index ece9b96..4abb85c 100644
 --- a/drivers/media/platform/ti-vpe/vpe.c
 +++ b/drivers/media/platform/ti-vpe/vpe.c
 @@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx 
 *ctx,
   {
   switch (type) {
   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
 +case V4L2_BUF_TYPE_VIDEO_OUTPUT:
   return ctx-q_data[Q_DATA_SRC];
   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
 +case V4L2_BUF_TYPE_VIDEO_CAPTURE:
   return ctx-q_data[Q_DATA_DST];
   default:
   BUG();
 @@ -1587,6 +1589,142 @@ static int vpe_s_fmt(struct file *file, void *priv, 
 struct v4l2_format *f)
   return set_srcdst_params(ctx);
   }

 +static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection 
 *s)
 +{
 +struct vpe_q_data *q_data;
 +
 +if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
 +(s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
 +return -EINVAL;
 +
 +q_data = get_q_data(ctx, s-type);
 +if (!q_data)
 +return -EINVAL;
 +
 +switch (s-target) {
 +case V4L2_SEL_TGT_COMPOSE:
 +/*
 + * COMPOSE target is only valid for capture buffer type, for
 + * output buffer type, assign existing crop parameters to the
 + * selection rectangle
 + */
 +if (s-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
 +break;

 Shouldn't this return -EINVAL?
 
 compose only makes sense for CAPTURE. So, it breaks and performs the 
 calculations after the switch statement.

It's so easy to get confused here.

 

 +
 +s-r = q_data-c_rect;
 +return 0;
 
 The above 2 lines are called for if we try to set compose for OUTPUT. I don't 
 return an error here, just keep the size as the original rect size, and 
 return 0.
 
 I'll replace these 2 lines with 'return -EINVAL;'

Yes, that makes more sense.

 
 +
 +case V4L2_SEL_TGT_CROP:
 +/*
 + * CROP target is only valid for output buffer type, for capture
 + * buffer type, assign existing compose parameters to the
 + * selection rectangle
 + */
 +if (s-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
 +break;

 Ditto.

 +
 +s-r = q_data-c_rect;
 +return 0;
 +
 +/*
 + * bound and default crop/compose targets are invalid targets to
 + * try/set
 + */
 +default:
 +return -EINVAL;
 +}
 +
 +if (s-r.top  0 || s-r.left  0) {
 +vpe_err(ctx-dev, negative values for top and left\n);
 +s-r.top = s-r.left = 0;
 +}
 +
 +v4l_bound_align_image(s-r.width, MIN_W, q_data-width, 1,
 +s-r.height, MIN_H, q_data-height, H_ALIGN, S_ALIGN);
 +
 +/* adjust left/top if cropping rectangle is out of bounds */
 +if (s-r.left + s-r.width  q_data-width)
 +s-r.left = q_data-width - s-r.width;
 +if (s-r.top + s-r.height  q_data-height)
 +s-r.top = q_data-height - s-r.height;
 +
 +return 0;
 +}
 +
 +static int vpe_g_selection(struct file *file, void *fh,
 +struct v4l2_selection *s)
 +{
 +struct vpe_ctx *ctx = file2ctx(file);
 +struct vpe_q_data *q_data;
 +
 +if ((s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) 
 +(s-type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
 +return -EINVAL;
 +
 +q_data = get_q_data(ctx, s-type);
 +if (!q_data)
 +return -EINVAL;
 +
 +switch (s-target) {
 +/* return width and height from S_FMT of the respective buffer type */
 +case V4L2_SEL_TGT_COMPOSE_DEFAULT:
 +case V4L2_SEL_TGT_COMPOSE_BOUNDS:
 +case V4L2_SEL_TGT_CROP_BOUNDS:
 +case V4L2_SEL_TGT_CROP_DEFAULT:
 +s-r.left = 0;
 +s-r.top = 0;
 +s-r.width = q_data-width;
 +s-r.height = q_data-height;

 The crop targets only make sense for type OUTPUT and the compose only for
 type CAPTURE. Add some checks for that.
 
 I return the image size for G_FMT irrespective 

Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM

[Lee Jones]

  This patchset brings up USB Host ports and Ethernet port on
  the OMAP5 uEVM board.
 
  It also does some cleanup with respect to DT clock binding
  for the mfd/omap-usb-host driver.
 
  Please queue these for -next.
 
  Lee,
 
  I've folded some platform data dependent patches with mfd patches
  so that they don't break functionality when applied individually.
  You can safely pull in all MFD patches (1 to 6).
 
  Tony  Benoit,
 
  Can you please accept patches 7, 8 and 9?
 
  Tony has already picked up 7,8 and 9 through omap-soc tree.
 
  Since you acked most patches except 5 and 6, are you fine if Tony takes
  all the patches 1 to 4 in this series via omap-soc tree?
 
  What about patches 5 and 6?
  
  Any patches which are orthogonal can just be sucked into whichever tree
  they belong in. If there are inter-subsystem dependencies I'd prefer
  to take them and issue a immutable branch pull-request to the other
  maintainers.
  
 Awesome. That would be great, thanks.

That does mean I need a) all of the Maintainer Acks and b) you to tell
me which ones need to go through a single tree.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 07/14] v4l: ti-vpe: Add selection API in VPE driver

[Archit Taneja]

On Tuesday 11 March 2014 06:19 PM, Hans Verkuil wrote:

On 03/11/14 13:46, Archit Taneja wrote:

On Tuesday 11 March 2014 05:51 PM, Hans Verkuil wrote:

Hi Archit,

A few small comments below...

On 03/11/14 09:33, Archit Taneja wrote:


snip


Yes. If for no other reason that I plan on adding crop/compose/scaling support
to v4l2-compliance soon, and this will probably be one of the tests.


Thanks, will update. Thanks for reviewing of the series.

Archit





Thanks,
Archit

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM

[Roger Quadros]

On 03/11/2014 03:07 PM, Lee Jones wrote:
 
 This patchset brings up USB Host ports and Ethernet port on
 the OMAP5 uEVM board.

 It also does some cleanup with respect to DT clock binding
 for the mfd/omap-usb-host driver.

 Please queue these for -next.

 Lee,

 I've folded some platform data dependent patches with mfd patches
 so that they don't break functionality when applied individually.
 You can safely pull in all MFD patches (1 to 6).

 Tony  Benoit,

 Can you please accept patches 7, 8 and 9?

 Tony has already picked up 7,8 and 9 through omap-soc tree.

 Since you acked most patches except 5 and 6, are you fine if Tony takes
 all the patches 1 to 4 in this series via omap-soc tree?

 What about patches 5 and 6?

 Any patches which are orthogonal can just be sucked into whichever tree
 they belong in. If there are inter-subsystem dependencies I'd prefer
 to take them and issue a immutable branch pull-request to the other
 maintainers.

 Awesome. That would be great, thanks.
 
 That does mean I need a) all of the Maintainer Acks and b) you to tell
 me which ones need to go through a single tree.
 

You need to take patches 1 to 6 in the MFD tree. Out of these, patches 1 to 4
need to be shared with Tony as an immutable branch.

Tony, could you please Ack patches 1 to 4? Thanks.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140311 06:13]:
 On 03/11/2014 03:07 PM, Lee Jones wrote:
  
  This patchset brings up USB Host ports and Ethernet port on
  the OMAP5 uEVM board.
 
  It also does some cleanup with respect to DT clock binding
  for the mfd/omap-usb-host driver.
 
  Please queue these for -next.
 
  Lee,
 
  I've folded some platform data dependent patches with mfd patches
  so that they don't break functionality when applied individually.
  You can safely pull in all MFD patches (1 to 6).
 
  Tony  Benoit,
 
  Can you please accept patches 7, 8 and 9?
 
  Tony has already picked up 7,8 and 9 through omap-soc tree.
 
  Since you acked most patches except 5 and 6, are you fine if Tony takes
  all the patches 1 to 4 in this series via omap-soc tree?
 
  What about patches 5 and 6?
 
  Any patches which are orthogonal can just be sucked into whichever tree
  they belong in. If there are inter-subsystem dependencies I'd prefer
  to take them and issue a immutable branch pull-request to the other
  maintainers.
 
  Awesome. That would be great, thanks.
  
  That does mean I need a) all of the Maintainer Acks and b) you to tell
  me which ones need to go through a single tree.
  
 
 You need to take patches 1 to 6 in the MFD tree. Out of these, patches 1 to 4
 need to be shared with Tony as an immutable branch.
 
 Tony, could you please Ack patches 1 to 4? Thanks.

Changes in 1 to 6 look OK to me, so for those please feel free to add:

Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 00/41] OMAPDSS: DT support v3

[Tony Lindgren]

* Tomi Valkeinen tomi.valkei...@ti.com [140311 03:19]:
 On 10/03/14 17:41, Tony Lindgren wrote:
 
  How about do a pull request for just the .dts changes against current
  omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
  that just the .dts changes alone won't break anything.
 
  Unfortunately they do break. At least pinmuxing is moved from the global
  definitions to be handled by the respective display drivers, and there
  are some regulator_name hacks that the DT patches remove.
  
  OK. Will that cause regressions for omap3 as that's still also booting
  in legacy mode?
 
 No, I don't think so. The problems revolve around the pdata-quirks, with
 current DSS support when booting with DT. It's rather difficult to split
 the series so that it could be merged freely in multiple parts.
 
 If I split the series into three parts: 1) .dts changes 2) main DSS DT
 changes 3) removal of pdata-quirks etc, I run into problems. Both 1) and
 2) work fine individually, but when both are merged, there are two
 competing systems, the proper DT stuff and the pdata-quirks stuff. And I
 haven't found out a simple way to manage that, as the whole display
 support is split into multiple independent devices.
 
 One option would be to combine 1) and 3), so that when they are merged,
 there would be proper DT data, and the pdata-quirks would be removed so
 that it wouldn't be messing everything up. But that would, of course,
 mean that after merging 1+3, the display wouldn't work on those boards
 that rely on pdata-quirks, until 2) is merged.

OK, best to keep the series together then.
 
  I think those changes could be removed from my patches, and then added
  back later when everything else has been merged.
  
  Or you could have a second branch that also merges in omap-for-v3.15/dt
  branch that you can send later towards the merge window after the arm-soc
  changes have been merged. If you want to do that, then feel free to add
  my ack also for the .dts changes:
  
  Acked-by: Tony Lindgren t...@atomide.com
  
  If however those changes get postponed to v3.16, it's best that you'll
  redo the branch as I'm sure we'll have other merge issues for v3.16.
 
 Ok. At the moment I feel that the easiest option would be to keep the
 DSS DT series as it is, but merge omap-for-v3.15/dt to it and solve the
 conflicts. I'd keep that branch separate from the fbdev changes, so that
 I could send the DSS DT pull request later, when arm-soc has been pulled.

OK makes sense to me.
 
  The bigger issue is that suddenly there's lots of discussion about the
  display DT bindings. If those are not resolved very soon, I guess I have
  no choice but to again skip the merge window for the DSS DT changes.
  
  OK, some of these more bindings can take easily six months to reach
  some kind of resolution. You may be able to use TI specific unstable
  bindings meanwhile if that makese sense.
 
 Yep. I don't know... If the whole port/endpoint system that I currently
 use is changed totally, it might be painful to support both the TI
 specific bindings with the old format and the newer format.

OK that's up you guys in the display land, I have not followed the
latest bindings discussion.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] mmc: omap_hsmmc: Enable SDIO IRQ.

[Tony Lindgren]

* Andreas Fenkart afenk...@gmail.com [140311 02:45]:
 Hi,
 
 2014-03-05 17:33 GMT+01:00 Tony Lindgren t...@atomide.com:
  * Andreas Fenkart afenk...@gmail.com [140305 00:30]:
  Hi,
 
  2014-02-27 22:33 GMT+01:00 Tony Lindgren t...@atomide.com:
  
   The wake-irq is needed for omaps with wake-up path and also
   when doing GPIO remuxing. So the wake-up handling is pretty
   much the same for both cases.
  I added this comment to the patch, since I was puzzled that you need
  a wake_irq even whithout remuxing.
 
  Yeah we need it because omap_hsmmc is already doing runtime PM,
  so there's nothing stopping from shutting it down. And there's
  really no need to block runtime PM for it as it's working.
 
 Also added this comment, since it really clarifies the issue.

OK thanks.
 
 FYI, just tried the patch without pin remuxing on am335x and
 it actually works. Read: I'm always using the sdio pinmux never
 reconfiguring the pin as a GPIO, but still get GPIO interrupts.
 Yes, it fails if I comment out the pm_runtime_resume.
 
 So it's not that the am335x suddenly has a swakeup line,
 but looks like an implementation detail of the am335x GPIO
 block.

Oh OK, that's good to know. I think 2420 behaved that way too
for the serial wake-up. What also may affect things is if that
GPIO line is in the first GPIO bank, for the other banks
remuxing may still be needed for deeper idle states.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap device tree changes for v3.15, part 2

[Olof Johansson]

On Fri, Mar 07, 2014 at 09:58:36AM -0800, Tony Lindgren wrote:
 The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84:
 
   Merge tag 'for_3.15/dts_signed' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into 
 omap-for-v3.15/dt (2014-03-02 14:22:03 -0800)
 
 are available in the git repository at:
 
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.15/dt-part2
 
 for you to fetch changes up to 18c49af3ee9e32a535413a949672bea726699f04:
 
   ARM: dts: am335x-evmsk: enable dual_emac mode (2014-03-05 11:53:36 -0800)
 
 
 Part two of omap device tree changes enabling driver features
 in the dts files.


Merged, thanks.

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15

[Suman Anna]

Hi Paul,

On 03/05/2014 06:24 PM, Suman Anna wrote:

Hi Paul, Benoit,

This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support
patches that are under arch/arm. The series just assimilates patches 8
through 13 from the v3 OMAP IOMMU DT adaptation for 3.15 series [1], and
all the v2 patches from the OMAP IOMMU DTS nodes [2].

The only change made with respect to the patches above is in the OMAP4
and OMAP5 DTS nodes - I have adjusted the reg sizes from 0xff to 0x100.

Can you please provide your acks on the hwmod patches and DTS
patches?


Ping. Can you review and provide your acks for Patches 2 and 5 (the 
hwmod patches) for Tony to pick up all the patches in the series?


regards
Suman



[1] http://marc.info/?l=linux-omapm=139362022805667w=2
[2] http://marc.info/?l=linux-omapm=139362062805816w=2
[3] http://marc.info/?l=linux-omapm=139404802021252w=2

Florian Vaussard (4):
   ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
   ARM: dts: OMAP3: Update ISP IOMMU node
   ARM: dts: OMAP3: Add IVA IOMMU node
   ARM: dts: OMAP4: Add IOMMU nodes

Suman Anna (6):
   ARM: OMAP3: fix iva mmu programming issues
   ARM: OMAP2+: change the ISP device archdata MMU name for DT
   ARM: OMAP2+: use pdata quirks for iommu reset lines
   ARM: OMAP5: hwmod data: add mmu data for ipu  dsp
   ARM: OMAP2+: extend iommu pdata-quirks to OMAP5
   ARM: dts: OMAP5: Add IOMMU nodes

  arch/arm/boot/dts/omap3.dtsi| 15 --
  arch/arm/boot/dts/omap4.dtsi| 15 ++
  arch/arm/boot/dts/omap5.dtsi| 15 ++
  arch/arm/mach-omap2/clockdomains3xxx_data.c |  2 +-
  arch/arm/mach-omap2/devices.c   |  3 ++
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++---
  arch/arm/mach-omap2/omap_hwmod_54xx_data.c  | 83 +
  arch/arm/mach-omap2/pdata-quirks.c  | 24 +
  arch/arm/plat-omap/Kconfig  |  3 --
  9 files changed, 157 insertions(+), 15 deletions(-)



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling

[Kuninori Morimoto]

Hi Jyri

 Since RFC:
 - fixed commit msg typo
 - added include/sound/soc.h changes too
 
 The sematics of bitclock-master and frame-master DT parameters
 should depend on whether they are found from a cpu-dai or codec
 sub-node.
 
 - bitclock-master in cpu-dai node means Codec-Bitclock-Slave
 - frame-master in cpu-dai node means Codec-Frame-Slave
 - bitclock-master in codec node means Codec-Bitclock-Master
 - frame-master in codec node means Codec-Frame-Master
 
 For example in a cpu-dai mode bitclock-master parameter should produce
 SND_SOC_DAIFMT_CBS_* daifmt flags and a codec node
 SND_SOC_DAIFMT_CBM_* flags.

SND_SOC_DAIFMT_xxx comment indicates codec clk/FRM indeed.
but does this codec means codec chip ??
I'm not sure.

but anyway, if my understanding is correct,

simple-audio-card,cpu {
...
bitclock-master;
frame-master;
};

simple-audio-card,codec {
...
bitclock-master;
frame-master;
};

This will be
cpu   : SND_SOC_DAIFMT_CBS_CFS
codec : SND_SOC_DAIFMT_CBM_CFM

but, it is un-understandable/confusable for me,
and it breaks our sound card.

${LINUX}/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
${LINUX}/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts

I guess you want like this ?

codec-bitclock-master;
codec-frame-master;

simple-audio-card,cpu {
...
};

simple-audio-card,codec {
...
};

# And I guess [1/2] and [2/2] should be 1 patch.
# otherwise, it breaks git-bisect :P


Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling

[Kuninori Morimoto]

Hi Mark, Jyri

  Since RFC:
  - fixed commit msg typo
  - added include/sound/soc.h changes too
  
  The sematics of bitclock-master and frame-master DT parameters
  should depend on whether they are found from a cpu-dai or codec
  sub-node.
  
  - bitclock-master in cpu-dai node means Codec-Bitclock-Slave
  - frame-master in cpu-dai node means Codec-Frame-Slave
  - bitclock-master in codec node means Codec-Bitclock-Master
  - frame-master in codec node means Codec-Frame-Master
  
  For example in a cpu-dai mode bitclock-master parameter should produce
  SND_SOC_DAIFMT_CBS_* daifmt flags and a codec node
  SND_SOC_DAIFMT_CBM_* flags.

I had misunderstood about SND_SOC_DAIFMT_xxx
So, please ignore my previous comment.

But, I wounder, if cpu/codec use identical format flags,
then, asoc_simple_dai don't need fmt ?

struct asoc_simple_dai {
const char *name;
unsigned int fmt;   = we can/should remove this ?
unsigned int sysclk;
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/5] Add USB nodes for am43xx epos and gp evm

[George Cherian]

Hi Tony,

On 3/7/2014 5:26 PM, George Cherian wrote:

The patch series adds USB dt nodes for am43xx epos and gp evm

Boot tested with  Benoit's for_3.15 + following patches

https://patchwork.kernel.org/patch/3600821/
https://patchwork.kernel.org/patch/3600831/
https://patchwork.kernel.org/patch/3600851/
https://patchwork.kernel.org/patch/3600841/


Changes from v1 - v2
* Reorder doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
* Address v1 coments on ARM: dts: AM4372: Add USB nodes

Changes from v2 - v3
* Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts
  and am43x-epos-evm.dts

George Cherian (5):
   doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
   ARM: dts: am43xx clock data
   ARM: dts: AM4372: Add USB nodes
   ARM: dts: am437x-gp-evm: Enable USB
   ARM: dts: am43x-epos-evm: Enable USB

  Documentation/devicetree/bindings/usb/omap-usb.txt |  4 +-
  arch/arm/boot/dts/am4372.dtsi  | 95 ++
  arch/arm/boot/dts/am437x-gp-evm.dts| 18 
  arch/arm/boot/dts/am43x-epos-evm.dts   | 18 
  arch/arm/boot/dts/am43xx-clocks.dtsi   | 17 
  5 files changed, 151 insertions(+), 1 deletion(-)

Can you please take this series.
The whole series Reviewed-by: Roger Quadros rog...@ti.com


--
-George

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling

[Richard Lee]

 On Wed, Mar 12, 2014 at 9:13 AM, Kuninori Morimoto
kuninori.morimoto...@gmail.com wrote:

 Hi Jyri

 Since RFC:
 - fixed commit msg typo
 - added include/sound/soc.h changes too

 The sematics of bitclock-master and frame-master DT parameters
 should depend on whether they are found from a cpu-dai or codec
 sub-node.

 - bitclock-master in cpu-dai node means Codec-Bitclock-Slave
 - frame-master in cpu-dai node means Codec-Frame-Slave
 - bitclock-master in codec node means Codec-Bitclock-Master
 - frame-master in codec node means Codec-Frame-Master

 For example in a cpu-dai mode bitclock-master parameter should produce
 SND_SOC_DAIFMT_CBS_* daifmt flags and a codec node
 SND_SOC_DAIFMT_CBM_* flags.

 SND_SOC_DAIFMT_xxx comment indicates codec clk/FRM indeed.
 but does this codec means codec chip ??
 I'm not sure.

 but anyway, if my understanding is correct,

 simple-audio-card,cpu {
 ...
 bitclock-master;
 frame-master;
 };

 simple-audio-card,codec {
 ...
 bitclock-master;
 frame-master;
 };

 This will be
 cpu   : SND_SOC_DAIFMT_CBS_CFS
 codec : SND_SOC_DAIFMT_CBM_CFM


Yes, That's also what my understanding of this patches.

But, IMO, if you want the CPU DAI be CBS_CFS and CODEC be CBM_CFM,
you could just do it like this:
 simple-audio-card,cpu {
 ...
 };

 simple-audio-card,codec {
 ...
 bitclock-master;
 frame-master;
 };

and vice versa.

Thanks,

(I could find this mails in my Freescale acount, so I will reply it here.)

--
Best Regards,
Xiubo


 but, it is un-understandable/confusable for me,
 and it breaks our sound card.

 ${LINUX}/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
 ${LINUX}/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts

 I guess you want like this ?

 codec-bitclock-master;
 codec-frame-master;

 simple-audio-card,cpu {
 ...
 };

 simple-audio-card,codec {
 ...
 };

 # And I guess [1/2] and [2/2] should be 1 patch.
 # otherwise, it breaks git-bisect :P


 Best regards
 ---
 Kuninori Morimoto
 --
 To unsubscribe from this list: send the line unsubscribe devicetree in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html