date:20131007


Hi,

On Monday 16 September 2013 12:29 PM, Archit Taneja wrote:

Hi Hans, Laurent,

On Friday 06 September 2013 03:42 PM, Archit Taneja wrote:

VPE(Video Processing Engine) is an IP found on DRA7xx, this series
adds VPE as a
mem to mem v4l2 driver, and VPDMA as a helper library.

The first version of the patch series described VPE in detail, you can
have a
look at it here:

http://www.spinics.net/lists/linux-media/msg66518.html

Changes in v4:
- Control ID for the driver reserved in v4l2-controls.h
- Some fixes/clean ups suggested by Hans.
- A small hack done in VPE's probe to use a fixed 64K resource size, this
   is needed as the DT bindings will split the addresses accross VPE
   submodules, the driver currently works with register offsets from
the top
   level VPE base. The driver can be modified later to support multiple
   ioremaps of the sub modules.
- Addition of sync on channel descriptors for input DMA channels, this
   ensures the VPDMA list is stalled in the rare case of an input
channel's
   DMA getting completed after all the output channel DMAs.
- Removed the DT and hwmod patches from this series. DRA7xx support is
not
   yet got in the 3.12 merge window. Will deal with those separately.


I incorporated your comments and suggestions from the previous series.
Wanted to know if you think it looks good enough to get merged now?


Ping. Any comments on this?

Thanks,
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 v4 1/4] v4l: ti-vpe: Create a vpdma helper library

On 09/06/2013 12:12 PM, Archit Taneja wrote:
 The primary function of VPDMA is to move data between external memory and
 internal processing modules(in our case, VPE) that source or sink data. VPDMA 
 is
 capable of buffering this data and then delivering the data as demanded to the
 modules as programmed. The modules that source or sink data are referred to as
 clients or ports. A channel is setup inside the VPDMA to connect a specific
 memory buffer to a specific client. The VPDMA centralizes the DMA control
 functions and buffering required to allow all the clients to minimize the
 effect of long latency times.
 
 Add the following to the VPDMA helper:
 
 - A data struct which describe VPDMA channels. For now, these channels are the
   ones used only by VPE, the list of channels will increase when VIP(Video
   Input Port) also uses the VPDMA library. This channel information will be
   used to populate fields required by data descriptors.
 
 - Data structs which describe the different data types supported by VPDMA. 
 This
   data type information will be used to populate fields required by data
   descriptors and used by the VPE driver to map a V4L2 format to the
   corresponding VPDMA data type.
 
 - Provide VPDMA register offset definitions, functions to read, write and 
 modify
   VPDMA registers.
 
 - Functions to create and submit a VPDMA list. A list is a group of 
 descriptors
   that makes up a set of DMA transfers that need to be completed. Each
   descriptor will either perform a DMA transaction to fetch input buffers and
   write to output buffers(data descriptors), or configure the MMRs of sub 
 blocks
   of VPE(configuration descriptors), or provide control information to VPDMA
   (control descriptors).
 
 - Functions to allocate, map and unmap buffers needed for the descriptor list,
   payloads containing MMR values and scaler coefficients. These use the DMA
   mapping APIs to ensure exclusive access to VPDMA.
 
 - Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on the
   VPE interrupt line when a descriptor list is parsed completely and the DMA
   transactions are completed. This requires masking the events in VPDMA
   registers and configuring some top level VPE interrupt registers.
 
 - Enable some VPDMA specific parameters: frame start event(when to start DMA 
 for
   a client) and line mode(whether each line fetched should be mirrored or 
 not).
 
 - Function to load firmware required by VPDMA. VPDMA requires a firmware for
   it's internal list manager. We add the required request_firmware apis to 
 fetch
   this firmware from user space.
 
 - Function to dump VPDMA registers.
 
 - A function to initialize and create a VPDMA instance, this will be called by
   the VPE driver with it's platform device pointer, this function will take 
 care
   of loading VPDMA firmware and returning a vpdma_data instance back to the 
 VPE
   driver. The VIP driver will also call the same init function to initialize 
 it's
   own VPDMA instance.
 
 Signed-off-by: Archit Taneja arc...@ti.com

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

Regards,

Hans

 ---
  drivers/media/platform/ti-vpe/vpdma.c  | 578 
 +
  drivers/media/platform/ti-vpe/vpdma.h  | 155 
  drivers/media/platform/ti-vpe/vpdma_priv.h | 119 ++
  3 files changed, 852 insertions(+)
  create mode 100644 drivers/media/platform/ti-vpe/vpdma.c
  create mode 100644 drivers/media/platform/ti-vpe/vpdma.h
  create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h
 

--
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 v6 1/3] usb: dwc3: msm: Add device tree binding information

From: Ivan T. Ivanov iiva...@mm-sol.com

MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.

It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).

Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
Acked-by: Stephen Warren swar...@nvidia.com
---
 .../devicetree/bindings/usb/msm-ssusb.txt  |  105 
 1 file changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt

diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt 
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..a71bf00
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,105 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
+
+MSM DW Highspeed USB PHY
+
+Required properities:
+- compatible:  should contain qcom,dw-hsphy;
+- reg: offset and length of the register set in the memory map
+- clocks:  A list of phandle + clock-specifier pairs for the
+   clocks listed in clock-names
+- clock-names: Should contain the following:
+  xo External reference clock
+  sleep_aSleep clock, used when USB3 core goes into low
+   power mode (U3).
+- v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY.
+- v3p3-supply: phandle to the regulator for the 3.3v supply to HSPHY.
+- vbus-supply: phandle to the regulator for the vbus supply for host
+   mode.
+- vddcx-supply: phandle to the regulator for the vdd supply for HSPHY
+digital circuit operation.
+
+MSM DW Superspeed USB PHY
+=
+Required properities:
+- compatible:  should contain qcom,dw-ssphy;
+- reg: offset and length of the register set in the memory map
+- clocks:  A list of phandle + clock-specifier pairs for the
+   clocks listed in clock-names
+- clock-names: Should contain the following:
+  xo External reference clock
+  refReference clock - used in host mode.
+- v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY.
+- vddcx-supply: phandle to the regulator for the vdd supply for HSPHY
+digital circuit operation.
+
+MSM DWC3 controller wrapper
+===
+Required properties:
+- compatible:  should contain qcom,dwc3
+- reg: offset and length of the TCSR register for routing USB
+   signals to either picoPHY0 or picoPHY1.
+- clocks:  A list of phandle + clock-specifier pairs for the
+   clocks listed in clock-names
+- clock-names: Should contain the following:
+  core   Master/Core clock, have to be = 125 MHz for SS
+   operation and = 60MHz for HS operation
+  iface  System bus AXI clock
+  sleep  Sleep clock, used when USB3 core goes into low
+   power mode (U3).
+  utmi   Generated by HSPHY. Used to clock the low power
+   parts of thr HS Link layer.
+Optional regulator:
+- gdsc-supply: phandle to the regulator from globally distributed
+   switch controller
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Example device nodes:
+
+   dw_hsphy: phy@f92f8800 {
+   compatible = qcom,dw-hsphy;
+   reg = 0xf92f8800 0x30;
+
+   clocks = cxo, usb2a_phy_sleep_cxc;
+   clock-names = xo, sleep_a;
+
+   vbus-supply = supply;
+   vddcx-supply = supply;
+   v1p8-supply = supply;
+   v3p3-supply = supply;
+   };
+
+   dw_ssphy: phy@f92f8830 {
+   compatible = qcom,dw-ssphy;
+   reg = 0xf92f8830 0x30;
+
+   clocks = cxo, usb30_mock_utmi_cxc;
+   clock-names = xo, ref;
+
+   vddcx-supply = supply;
+   v1p8-supply = supply;
+   };
+
+   usb@fd4ab000 {
+   compatible = qcom,dwc3;
+   #address-cells = 1;
+   #size-cells = 1;
+   reg = 0xfd4ab000 0x4;
+
+   clocks = usb30_master_cxc, sys_noc_usb3_axi_cxc,
+   usb30_sleep_cxc, usb30_mock_utmi_cxc;
+   clock-names = core, iface, sleep, utmi;
+
+   gdsc-supply = supply;
+
+   ranges;
+   dwc3@f920 {
+   compatible = snps,dwc3;
+   reg = 0xf920 0xcd00;
+   interrupts = 0 131;
+   usb-phy = dw_hsphy, dw_ssphy;
+

[PATCH v6 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DW PHY's

From: Ivan T. Ivanov iiva...@mm-sol.com

These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.

Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
 drivers/usb/phy/Kconfig |   11 ++
 drivers/usb/phy/Makefile|2 +
 drivers/usb/phy/phy-msm-dw-hs.c |  329 ++
 drivers/usb/phy/phy-msm-dw-ss.c |  375 +++
 4 files changed, 717 insertions(+)
 create mode 100644 drivers/usb/phy/phy-msm-dw-hs.c
 create mode 100644 drivers/usb/phy/phy-msm-dw-ss.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index d5589f9..bbb2d0e 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -214,6 +214,17 @@ config USB_RCAR_PHY
  To compile this driver as a module, choose M here: the
  module will be called phy-rcar-usb.
 
+config USB_MSM_DW_PHYS
+   tristate Qualcomm USB controller DW PHY's wrappers support
+   depends on (USB || USB_GADGET)  ARCH_MSM
+   select USB_PHY
+   help
+ Enable this to support the DW USB PHY transceivers on MSM chips
+ with DWC3 USB core. It handles PHY initialization, clock
+ management required after resetting the hardware and power
+ management. This driver is required even for peripheral only or
+ host only mode configurations.
+
 config USB_ULPI
bool Generic ULPI Transceiver Driver
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 2135e85..4813eb5 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA)  += phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
 obj-$(CONFIG_USB_ISP1301)  += phy-isp1301.o
 obj-$(CONFIG_USB_MSM_OTG)  += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DW_PHYS)  += phy-msm-dw-hs.o
+obj-$(CONFIG_USB_MSM_DW_PHYS)  += phy-msm-dw-ss.o
 obj-$(CONFIG_USB_MV_OTG)   += phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)  += phy-mxs-usb.o
 obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dw-hs.c b/drivers/usb/phy/phy-msm-dw-hs.c
new file mode 100644
index 000..d29c1f1
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dw-hs.c
@@ -0,0 +1,329 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/usb/phy.h
+
+/**
+ *  USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG  (0x04)
+#define QSCRATCH_GENERAL_CFG   (0x08)
+#define PHY_CTRL_REG   (0x10)
+#define PARAMETER_OVERRIDE_X_REG   (0x14)
+#define CHARGING_DET_CTRL_REG  (0x18)
+#define CHARGING_DET_OUTPUT_REG(0x1c)
+#define ALT_INTERRUPT_EN_REG   (0x20)
+#define PHY_IRQ_STAT_REG   (0x24)
+#define CGCTL_REG  (0x28)
+
+#define PHY_3P3_VOL_MIN305 /* uV */
+#define PHY_3P3_VOL_MAX330 /* uV */
+#define PHY_3P3_HPM_LOAD   16000   /* uA */
+
+#define PHY_1P8_VOL_MIN180 /* uV */
+#define PHY_1P8_VOL_MAX180 /* uV */
+#define PHY_1P8_HPM_LOAD   19000   /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO   1   /* index */
+#define USB_VDDCX_MIN  5   /* index */
+#define USB_VDDCX_MAX  7   /* index */
+
+struct msm_dw_hs_phy {
+   struct usb_phy  phy;
+   void __iomem*base;
+   struct device   *dev;
+
+   struct clk  *xo_clk;
+   struct clk  *sleep_a_clk;
+
+   struct regulator*v3p3;
+   struct regulator*v1p8;
+   struct regulator*vddcx;
+   struct regulator*vbus;
+};
+
+#definephy_to_dw_phy(x)container_of((x), struct msm_dw_hs_phy, 
phy)
+
+
+/**
+ * Write register.
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ */
+static inline void msm_dw_hs_write(void __iomem *base, u32 offset, u32 val)
+{
+

[PATCH v6 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver

From: Ivan T. Ivanov iiva...@mm-sol.com

DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.

Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
 drivers/usb/dwc3/Kconfig|8 +++
 drivers/usb/dwc3/Makefile   |1 +
 drivers/usb/dwc3/dwc3-msm.c |  168 +++
 3 files changed, 177 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-msm.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 70fc430..4c7b5a4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -59,6 +59,14 @@ config USB_DWC3_EXYNOS
  Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
  say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_MSM
+   tristate Qualcomm MSM/APQ Platforms
+   default USB_DWC3
+   select USB_MSM_DWC3_PHYS
+   help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
 config USB_DWC3_PCI
tristate PCIe-based Platforms
depends on PCI
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..a90de66 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -31,4 +31,5 @@ endif
 
 obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
 obj-$(CONFIG_USB_DWC3_EXYNOS)  += dwc3-exynos.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
 obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..1d73f92
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/usb/phy.h
+
+struct dwc3_msm {
+   struct device   *dev;
+
+   struct clk  *core_clk;
+   struct clk  *iface_clk;
+   struct clk  *sleep_clk;
+   struct clk  *utmi_clk;
+
+   struct regulator*gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+   struct device_node *node = pdev-dev.of_node;
+   struct dwc3_msm *mdwc;
+   struct resource *res;
+   void __iomem *tcsr;
+   int ret = 0;
+
+   mdwc = devm_kzalloc(pdev-dev, sizeof(*mdwc), GFP_KERNEL);
+   if (!mdwc)
+   return -ENOMEM;
+
+   platform_set_drvdata(pdev, mdwc);
+
+   mdwc-dev = pdev-dev;
+
+   mdwc-gdsc = devm_regulator_get(mdwc-dev, gdsc);
+
+   mdwc-core_clk = devm_clk_get(mdwc-dev, core);
+   if (IS_ERR(mdwc-core_clk)) {
+   dev_dbg(mdwc-dev, failed to get core clock\n);
+   return PTR_ERR(mdwc-core_clk);
+   }
+
+   mdwc-iface_clk = devm_clk_get(mdwc-dev, iface);
+   if (IS_ERR(mdwc-iface_clk)) {
+   dev_dbg(mdwc-dev, failed to get iface clock\n);
+   return PTR_ERR(mdwc-iface_clk);
+   }
+
+   mdwc-sleep_clk = devm_clk_get(mdwc-dev, sleep);
+   if (IS_ERR(mdwc-sleep_clk)) {
+   dev_dbg(mdwc-dev, failed to get sleep clock\n);
+   return  PTR_ERR(mdwc-sleep_clk);
+   }
+
+   mdwc-utmi_clk = devm_clk_get(mdwc-dev, utmi);
+   if (IS_ERR(mdwc-utmi_clk)) {
+   dev_dbg(mdwc-dev, failed to get utmi clock\n);
+   return  PTR_ERR(mdwc-utmi_clk);
+   }
+
+   if (!IS_ERR(mdwc-gdsc)) {
+   ret = regulator_enable(mdwc-gdsc);
+   if (ret)
+   dev_err(mdwc-dev, cannot enable gdsc\n);
+   }
+
+   /*
+* DWC3 Core requires its CORE CLK (aka master / bus clk) to
+* run at 125Mhz in SSUSB mode and 60MHZ for HSUSB mode.
+*/
+   clk_set_rate(mdwc-core_clk, 12500);
+   clk_prepare_enable(mdwc-core_clk);
+   clk_prepare_enable(mdwc-iface_clk);
+   clk_prepare_enable(mdwc-sleep_clk);
+   clk_prepare_enable(mdwc-utmi_clk);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   tcsr = devm_ioremap_resource(mdwc-dev, res);
+   if (!tcsr) {
+   ret = PTR_ERR(tcsr);
+   goto dis_clks;
+   }
+
+   /*
+*

[PATCH v6 0/3] DWC3 USB support for Qualcomm platform

From: Ivan T. Ivanov iiva...@mm-sol.com

Hi,

This is sixth version of MSM USB3 drivers patches.

Changes since v5:
* devicetree bindings descriptions fixes 
* Fixed NULL pointer dereferences in dev_prink's
* Removed extra space in sleep  clock name

Changes since v4:
* Substitute references to wc3 with just dw in USB PHY drivers and
  file names. This is to indicate that the PHY's are DesignWare, but
  not necessarily related to DWC3 IP core. 

Changes since v3:
* Remove _clk suffix from clock names
* Clarify required child node for qcom,dwc3
* Fix comments in functions headers
* Use dbg instead err in drivers probe functions.

Changes since v2:
* Several improvements in devicetree bindings description
* Disable regulators in glue layer if there is error during 
  ioremap.

Changes since first version:
* Split devicetree bindings description file to separate patch
* Address comments for device bindings description
* Fix typo in 'gdsc' requlator name.

These patches add basic support for USB3.0 controllers found
on MSM platforms. USB3.0 core is based on Synopsys DesignWare 
SuperSpeed IP. 

Generated on top of Felipe 'testing' branch.

Ivan T. Ivanov (3):
  usb: dwc3: msm: Add device tree binding information
  usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DW PHY's
  usb: dwc3: Add Qualcomm DWC3 glue layer driver

 .../devicetree/bindings/usb/msm-ssusb.txt  |  105 ++
 drivers/usb/dwc3/Kconfig   |8 +
 drivers/usb/dwc3/Makefile  |1 +
 drivers/usb/dwc3/dwc3-msm.c|  168 +
 drivers/usb/phy/Kconfig|   11 +
 drivers/usb/phy/Makefile   |2 +
 drivers/usb/phy/phy-msm-dw-hs.c|  329 +
 drivers/usb/phy/phy-msm-dw-ss.c|  375 
 8 files changed, 999 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
 create mode 100644 drivers/usb/dwc3/dwc3-msm.c
 create mode 100644 drivers/usb/phy/phy-msm-dw-hs.c
 create mode 100644 drivers/usb/phy/phy-msm-dw-ss.c

-- 
1.7.9.5

--
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 3/4] v4l: ti-vpe: Add VPE mem to mem driver

Hi Archit,

I've got a few comments below...

On 09/06/2013 12:12 PM, Archit Taneja wrote:
 VPE is a block which consists of a single memory to memory path which can
 perform chrominance up/down sampling, de-interlacing, scaling, and color space
 conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
 interleaved video formats.
 
 We create a mem2mem driver based primarily on the mem2mem-testdev example.
 The de-interlacer, scaler and color space converter are all bypassed for now
 to keep the driver simple. Chroma up/down sampler blocks are implemented, so
 conversion beteen different YUV formats is possible.
 
 Each mem2mem context allocates a buffer for VPE MMR values which it will use
 when it gets access to the VPE HW via the mem2mem queue, it also allocates
 a VPDMA descriptor list to which configuration and data descriptors are added.
 
 Based on the information received via v4l2 ioctls for the source and
 destination queues, the driver configures the values for the MMRs, and stores
 them in the buffer. There are also some VPDMA parameters like frame start and
 line mode which needs to be configured, these are configured by direct 
 register
 writes via the VPDMA helper functions.
 
 The driver's device_run() mem2mem op will add each descriptor based on how the
 source and destination queues are set up for the given ctx, once the list is
 prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
 upload MMR registers, start DMA of video buffers on the various input and 
 output
 clients/ports.
 
 When the list is parsed completely(and the DMAs on all the output ports done),
 an interrupt is generated which we use to notify that the source and 
 destination
 buffers are done.
 
 The rest of the driver is quite similar to other mem2mem drivers, we use the
 multiplane v4l2 ioctls as the HW support coplanar formats.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/platform/Kconfig   |   16 +
  drivers/media/platform/Makefile  |2 +
  drivers/media/platform/ti-vpe/Makefile   |5 +
  drivers/media/platform/ti-vpe/vpe.c  | 1750 
 ++
  drivers/media/platform/ti-vpe/vpe_regs.h |  496 +
  include/uapi/linux/v4l2-controls.h   |4 +
  6 files changed, 2273 insertions(+)
  create mode 100644 drivers/media/platform/ti-vpe/Makefile
  create mode 100644 drivers/media/platform/ti-vpe/vpe.c
  create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
 

snip

 +
 +static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 +{
 + struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
 + struct vpe_ctx *ctx = file2ctx(file);
 + struct vb2_queue *vq;
 + struct vpe_q_data *q_data;
 + int i;
 +
 + vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
 + if (!vq)
 + return -EINVAL;
 +
 + q_data = get_q_data(ctx, f-type);
 +
 + pix-width = q_data-width;
 + pix-height = q_data-height;
 + pix-pixelformat = q_data-fmt-fourcc;
 + pix-colorspace = q_data-colorspace;
 + pix-num_planes = q_data-fmt-coplanar ? 2 : 1;
 +
 + for (i = 0; i  pix-num_planes; i++) {
 + pix-plane_fmt[i].bytesperline = q_data-bytesperline[i];
 + pix-plane_fmt[i].sizeimage = q_data-sizeimage[i];
 + }
 +
 + return 0;
 +}
 +
 +static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
 +struct vpe_fmt *fmt, int type)
 +{
 + struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
 + struct v4l2_plane_pix_format *plane_fmt;
 + int i;
 +
 + if (!fmt || !(fmt-types  type)) {
 + vpe_err(ctx-dev, Fourcc format (0x%08x) invalid.\n,
 + pix-pixelformat);
 + return -EINVAL;
 + }
 +
 + pix-field = V4L2_FIELD_NONE;
 +
 + v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
 +   pix-height, MIN_H, MAX_H, H_ALIGN,
 +   S_ALIGN);
 +
 + pix-num_planes = fmt-coplanar ? 2 : 1;
 + pix-pixelformat = fmt-fourcc;
 + pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?

You do this only for capture. Output sets the colorspace, so try_fmt should
leave the colorspace field untouched for the output direction.

 + V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;

Zero pix-priv as well:

pix-priv = 0;

 +
 + for (i = 0; i  pix-num_planes; i++) {
 + int depth;
 +
 + plane_fmt = pix-plane_fmt[i];
 + depth = fmt-vpdma_fmt[i]-depth;
 +
 + if (i == VPE_LUMA)
 + plane_fmt-bytesperline =
 + round_up((pix-width * depth)  3,
 + 1  L_ALIGN);
 + else
 + plane_fmt-bytesperline = pix-width;
 +
 + plane_fmt-sizeimage =
 + (pix-height * pix-width * depth)  3;
 + }
 +

Re: [PATCH v4 2/4] v4l: ti-vpe: Add helpers for creating VPDMA descriptors

On 09/06/2013 12:12 PM, Archit Taneja wrote:
 Create functions which the VPE driver can use to create a VPDMA descriptor and
 add it to a VPDMA descriptor list. These functions take a pointer to an 
 existing
 list, and append the configuration/data/control descriptor header to the list.
 
 In the case of configuration descriptors, the creation of a payload block may 
 be
 required(the payloads can hold VPE MMR values, or scaler coefficients). The
 allocation of the payload buffer and it's content is left to the VPE driver.
 However, the VPDMA library provides helper macros to create payload in the
 correct format.
 
 Add debug functions to dump the descriptors in a way such that it's easy to 
 see
 the values of different fields in the descriptors.
 
 Signed-off-by: Archit Taneja arc...@ti.com

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

Regards,

Hans

 ---
  drivers/media/platform/ti-vpe/vpdma.c  | 268 +++
  drivers/media/platform/ti-vpe/vpdma.h  |  48 +++
  drivers/media/platform/ti-vpe/vpdma_priv.h | 522 
 +
  3 files changed, 838 insertions(+)
 

--
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 4/4] v4l: ti-vpe: Add de-interlacer support in VPE

On 09/06/2013 12:12 PM, Archit Taneja wrote:
 Add support for the de-interlacer block in VPE.
 
 For de-interlacer to work, we need to enable 2 more sets of VPE input ports
 which fetch data from the 'last' and 'last to last' fields of the interlaced
 video. Apart from that, we need to enable the Motion vector output and input
 ports, and also allocate DMA buffers for them.
 
 We need to make sure that two most recent fields in the source queue are
 available and in the 'READY' state. Once a mem2mem context gets access to the
 VPE HW(in device_run), it extracts the addresses of the 3 buffers, and 
 provides
 it to the data descriptors for the 3 sets of input ports((LUMA1, CHROMA1),
 (LUMA2, CHROMA2), and (LUMA3, CHROMA3)) respectively for the 3 consecutive
 fields. The motion vector and output port descriptors are configured and the
 list is submitted to VPDMA.
 
 Once the transaction is done, the v4l2 buffer corresponding to the oldest
 field(the 3rd one) is changed to the state 'DONE', and the buffers 
 corresponding
 to 1st and 2nd fields become the 2nd and 3rd field for the next de-interlace
 operation. This way, for each deinterlace operation, we have the 3 most recent
 fields. After each transaction, we also swap the motion vector buffers, the 
 new
 input motion vector buffer contains the resultant motion information of all 
 the
 previous frames, and the new output motion vector buffer will be used to hold
 the updated motion vector to capture the motion changes in the next field. The
 motion vector buffers are allocated using the DMA allocation API.
 
 The de-interlacer is removed from bypass mode, it requires some extra default
 configurations which are now added. The chrominance upsampler coefficients are
 added for interlaced frames. Some VPDMA parameters like frame start event and
 line mode are configured for the 2 extra sets of input ports.
 
 Signed-off-by: Archit Taneja arc...@ti.com

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

Regards,

Hans

 ---
  drivers/media/platform/ti-vpe/vpe.c | 392 
 
  1 file changed, 358 insertions(+), 34 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 v5 1/3] usb: dwc3: msm: Add device tree binding information


Hi Felipe,

On Fri, 2013-10-04 at 09:31 -0500, Felipe Balbi wrote: 
 On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote:
  From: Ivan T. Ivanov iiva...@mm-sol.com
  
  MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
  (SNPS) and HS, SS PHY's control and configuration registers.
  
  It could operate in device mode (SS, HS, FS) and host
  mode (SS, HS, FS, LS).
  
  Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
 
 these patches were sent *ages* and nobody from DT mailing list has
 reviewed. Unless someone steps up now, I'll be queueing these patches
 next week.
 

Please take v6 of the patch set, which I have just posted. 
They contain several fixes and I have also added ACK from
Stephen Warren for DT part.

Thanks, 
Ivan

--
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 09/10] usb: dwc3: omap: manage usb_otg_ss_refclk960m clock

On 10/04/2013 04:23 PM, Greg KH wrote:
 On Fri, Oct 04, 2013 at 01:46:08PM +0300, Roger Quadros wrote:
 Greg,

 On 10/03/2013 06:41 PM, Greg KH wrote:
 On Thu, Oct 03, 2013 at 05:54:14PM +0300, Roger Quadros wrote:
 On 10/03/2013 03:29 PM, Felipe Balbi wrote:
 Hi,

 On Wed, Oct 02, 2013 at 04:41:53PM +0300, Roger Quadros wrote:
 On 10/02/2013 04:11 PM, Felipe Balbi wrote:
 On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote:
 Hi Felipe,

 On 09/18/2013 03:49 PM, Roger Quadros wrote:
 usb_otg_ss_refclk960m is an optional functional clock to the
 UBS_OTG_SS module. So manage it in the driver.


 Just realized that usb_otg_ss_refclk960m is in fact functional clock 
 to the 
 PHY and not USB_OTG_SS module. The name is misleading.

 So please ignore patch 9 and 10.

 ignored. All others are fine, right ?

 Yes. But I might have to rebase this on top of Phy framework stuff.

 alright, Greg already took the PHY framework, so maybe we need to just
 give him my Acked-by and he takes the patches directly as I don't have
 PYH framework.

 OK. I'll resend this series to Greg in a while.

 It looks like you did, but forgot Felipe's ack :(

 I was under the impression that Felipe will explicitly give his Ack there.
 Should I resend with his Acked-bys?
 
 No need, I took the patches yesterday, you should have seen the
 automated emails, right?
 
Thanks. Yes, I got the automated e-mails.

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: Odd behavior with dpll4_m4x2_ck on omap3 + DT

2013-10-07 Thread Paul Walmsley

On Tue, 10 Sep 2013, Tero Kristo wrote:

 In theory, DPLLs can also be used in their bypass mode to feed customer nodes
 clocks. I just think the check in the clkoutx2_recalc is wrong, and should be
 enhanced to actually check what is the target mode for the clock once it is
 enabled. Maybe something like this would work properly:
 
 diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
 index 3a0296c..ba218fb 100644
 --- a/arch/arm/mach-omap2/dpll3xxx.c
 +++ b/arch/arm/mach-omap2/dpll3xxx.c
 @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 
 dd = pclk-dpll_data;
 
 -   WARN_ON(!dd-enable_mask);
 -
 -   v = __raw_readl(dd-control_reg)  dd-enable_mask;
 -   v = __ffs(dd-enable_mask);
 -   if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags  DPLL_J_TYPE))
 +   if ((dd-flags  DPLL_J_TYPE) ||
 +   __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk))
 rate = parent_rate;
 else
 rate = parent_rate * 2;
 +
 return rate;
  }
 

[...]

 Getting comment from someone like Paul would probably help here.

Looks like this is a regression from the CCF port.

Seems to me that the code above assumes that when the DPLL's rate is set 
to the same rate as the bypass clock's rate, we can assume that the DPLL 
is in bypass.  I wonder if that's valid in a case where a previous OS or 
bootloader may have programmed the DPLL.

Sounds to me like the best way to fix it would be to test whether this 
code is intended to return the target rate (when the struct clk 
representing the DPLL is disabled), versus the current rate (when the 
struct clk representing the DPLL is enabled).  If it's the target rate, 
then there's no point checking the current state of the hardware.  A check 
similar to the above would probably be fine.  Otherwise, seems best to use 
the existing code that does test the PLL state.



- Paul

--
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 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

Hi Javier,

On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:
 Add device nodes for the HS USB Host port 1, USB PHY and its
 required regulator and also pin mux setup for HS USB1 pins.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/omap3-igep.dtsi| 22 ++
  arch/arm/boot/dts/omap3-igep0020.dts | 25 +
  2 files changed, 47 insertions(+)
 
 diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
 b/arch/arm/boot/dts/omap3-igep.dtsi
 index 0f92224..ec2ecd2 100644
 --- a/arch/arm/boot/dts/omap3-igep.dtsi
 +++ b/arch/arm/boot/dts/omap3-igep.dtsi
 @@ -27,6 +27,11 @@
  };
  
  omap3_pmx_core {
 + pinctrl-names = default;
 + pinctrl-0 = 
 + hsusbb1_pins
 + ;
 +
   uart1_pins: pinmux_uart1_pins {
   pinctrl-single,pins = 
   0x152 (PIN_INPUT | MUX_MODE0)   /* 
 uart1_rx.uart1_rx */
 @@ -78,6 +83,23 @@
   ;
   };
  
 + hsusbb1_pins: pinmux_hsusbb1_pins {
 + pinctrl-single,pins = 
 + 0x5aa (PIN_OUTPUT | MUX_MODE3)  /* 
 etk_ctl.hsusb1_clk */
 + 0x5a8 (PIN_OUTPUT | MUX_MODE3)  /* 
 etk_clk.hsusb1_stp */
 + 0x5bc (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d8.hsusb1_dir */
 + 0x5be (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d9.hsusb1_nxt */
 + 0x5ac (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d0.hsusb1_data0 */
 + 0x5ae (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d1.hsusb1_data1 */
 + 0x5b0 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d2.hsusb1_data2 */
 + 0x5b2 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d3.hsusb1_data7 */
 + 0x5b4 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d4.hsusb1_data4 */
 + 0x5b6 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d5.hsusb1_data5 */
 + 0x5b8 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d6.hsusb1_data6 */
 + 0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d7.hsusb1_data3 */
 + ;
 + };
 +

Is this pin config required for igep0030 as well? If not then you should move 
these pinmux
definitions to omap3-igep0020.dts.

All else looks good to me.

   leds_pins: pinmux_leds_pins { };
  };
  
 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
 b/arch/arm/boot/dts/omap3-igep0020.dts
 index 903e944..180b186 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -55,6 +55,23 @@
   regulator-name = vdd33a;
   regulator-always-on;
   };
 +
 +   /* HS USB Port 1 Power */
 +   hsusb1_power: hsusb1_power_reg {
 +   compatible = regulator-fixed;
 +   regulator-name = hsusb1_vbus;
 +   regulator-min-microvolt = 330;
 +   regulator-max-microvolt = 330;
 +   gpio = twl_gpio 18 GPIO_ACTIVE_LOW;/* GPIO LEDA */
 +   startup-delay-us = 7;
 +   };
 +
 + /* HS USB Host PHY on PORT 1 */
 + hsusb1_phy: hsusb1_phy {
 + compatible = usb-nop-xceiv;
 + reset-gpios = gpio1 24 GPIO_ACTIVE_LOW; /* gpio_24 */
 + vcc-supply = hsusb1_power;
 + };
  };
  
  leds_pins {
 @@ -173,3 +190,11 @@
   mode = 3;
   power = 50;
  };
 +
 +usbhshost {
 + port1-mode = ehci-phy;
 +};
 +
 +usbhsehci {
 + phys = hsusb1_phy;
 +};
 

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 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

On Mon, Oct 7, 2013 at 10:33 AM, Roger Quadros rog...@ti.com wrote:
 Hi Javier,

 On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:
 Add device nodes for the HS USB Host port 1, USB PHY and its
 required regulator and also pin mux setup for HS USB1 pins.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/omap3-igep.dtsi| 22 ++
  arch/arm/boot/dts/omap3-igep0020.dts | 25 +
  2 files changed, 47 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
 index 0f92224..ec2ecd2 100644
 --- a/arch/arm/boot/dts/omap3-igep.dtsi
 +++ b/arch/arm/boot/dts/omap3-igep.dtsi
 @@ -27,6 +27,11 @@
  };

  omap3_pmx_core {
 + pinctrl-names = default;
 + pinctrl-0 = 
 + hsusbb1_pins
 + ;
 +
   uart1_pins: pinmux_uart1_pins {
   pinctrl-single,pins = 
   0x152 (PIN_INPUT | MUX_MODE0)   /*
uart1_rx.uart1_rx */
 @@ -78,6 +83,23 @@
   ;
   };

 + hsusbb1_pins: pinmux_hsusbb1_pins {
 + pinctrl-single,pins = 
 + 0x5aa (PIN_OUTPUT | MUX_MODE3)  /*
etk_ctl.hsusb1_clk */
 + 0x5a8 (PIN_OUTPUT | MUX_MODE3)  /*
etk_clk.hsusb1_stp */
 + 0x5bc (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d8.hsusb1_dir */
 + 0x5be (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d9.hsusb1_nxt */
 + 0x5ac (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d0.hsusb1_data0 */
 + 0x5ae (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d1.hsusb1_data1 */
 + 0x5b0 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d2.hsusb1_data2 */
 + 0x5b2 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d3.hsusb1_data7 */
 + 0x5b4 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d4.hsusb1_data4 */
 + 0x5b6 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d5.hsusb1_data5 */
 + 0x5b8 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d6.hsusb1_data6 */
 + 0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
etk_d7.hsusb1_data3 */
 + ;
 + };
 +

 Is this pin config required for igep0030 as well? If not then you should move
these pinmux
 definitions to omap3-igep0020.dts.

 All else looks good to me.


Hi Roger,

Well that's a very good question indeed.

The thing is that the IGEP0030 is a Computer-on-Module [1] that is used in
conjunction with expansion boards and some of them have USB HOST support such as
IGEP Paris [2] and IGEP Berlin [3].

Support for this expansion boards is still not in mainline but there are plans
to add them using Device Tree overlays [4] once/if this land on mainline.

So, answering your question right now this is not required but I thought it
would be good to have it configured by default in case someone using an IGEP0030
and a expansion board wants to extend omap3-igep0030.dts to add support for its
expansion board.

I've no strong opinion on this though and I can send a new patch with those pins
moved to omap3-igep0020.dts though if you think that would be better.

   leds_pins: pinmux_leds_pins { };
  };

 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
 index 903e944..180b186 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -55,6 +55,23 @@
   regulator-name = vdd33a;
   regulator-always-on;
   };
 +
 +   /* HS USB Port 1 Power */
 +   hsusb1_power: hsusb1_power_reg {
 +   compatible = regulator-fixed;
 +   regulator-name = hsusb1_vbus;
 +   regulator-min-microvolt = 330;
 +   regulator-max-microvolt = 330;
 +   gpio = twl_gpio 18 GPIO_ACTIVE_LOW;/* GPIO LEDA */
 +   startup-delay-us = 7;
 +   };
 +
 + /* HS USB Host PHY on PORT 1 */
 + hsusb1_phy: hsusb1_phy {
 + compatible = usb-nop-xceiv;
 + reset-gpios = gpio1 24 GPIO_ACTIVE_LOW; /* gpio_24 */
 + vcc-supply = hsusb1_power;
 + };
  };

  leds_pins {
 @@ -173,3 +190,11 @@
   mode = 3;
   power = 50;
  };
 +
 +usbhshost {
 + port1-mode = ehci-phy;
 +};
 +
 +usbhsehci {
 + phys = hsusb1_phy;
 +};


 cheers,
 -roger
 --

Thanks a lot and best regards,
Javier

[1]: http://www.isee.biz/products/processor-boards/igep-com-module
[2]: http://www.isee.biz/products/expansion-boards/product-igep-paris
[3]: http://www.isee.biz/products/expansion-boards/product-igep-berlin
[4]:
http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays
--
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 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

+devicetree

Javier,

On 10/07/2013 11:50 AM, Javier Martinez Canillas wrote:
 On Mon, Oct 7, 2013 at 10:33 AM, Roger Quadros rog...@ti.com wrote:
 Hi Javier,

 On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:
 Add device nodes for the HS USB Host port 1, USB PHY and its
 required regulator and also pin mux setup for HS USB1 pins.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/omap3-igep.dtsi| 22 ++
  arch/arm/boot/dts/omap3-igep0020.dts | 25 +
  2 files changed, 47 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
 b/arch/arm/boot/dts/omap3-igep.dtsi
 index 0f92224..ec2ecd2 100644
 --- a/arch/arm/boot/dts/omap3-igep.dtsi
 +++ b/arch/arm/boot/dts/omap3-igep.dtsi
 @@ -27,6 +27,11 @@
  };

  omap3_pmx_core {
 + pinctrl-names = default;
 + pinctrl-0 = 
 + hsusbb1_pins
 + ;
 +
   uart1_pins: pinmux_uart1_pins {
   pinctrl-single,pins = 
   0x152 (PIN_INPUT | MUX_MODE0)   /*
 uart1_rx.uart1_rx */
 @@ -78,6 +83,23 @@
   ;
   };

 + hsusbb1_pins: pinmux_hsusbb1_pins {
 + pinctrl-single,pins = 
 + 0x5aa (PIN_OUTPUT | MUX_MODE3)  /*
 etk_ctl.hsusb1_clk */
 + 0x5a8 (PIN_OUTPUT | MUX_MODE3)  /*
 etk_clk.hsusb1_stp */
 + 0x5bc (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d8.hsusb1_dir */
 + 0x5be (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d9.hsusb1_nxt */
 + 0x5ac (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d0.hsusb1_data0 */
 + 0x5ae (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d1.hsusb1_data1 */
 + 0x5b0 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d2.hsusb1_data2 */
 + 0x5b2 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d3.hsusb1_data7 */
 + 0x5b4 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d4.hsusb1_data4 */
 + 0x5b6 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d5.hsusb1_data5 */
 + 0x5b8 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d6.hsusb1_data6 */
 + 0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3)  /*
 etk_d7.hsusb1_data3 */
 + ;
 + };
 +

 Is this pin config required for igep0030 as well? If not then you should move
 these pinmux
 definitions to omap3-igep0020.dts.

 All else looks good to me.

 
 Hi Roger,
 
 Well that's a very good question indeed.
 
 The thing is that the IGEP0030 is a Computer-on-Module [1] that is used in
 conjunction with expansion boards and some of them have USB HOST support such 
 as
 IGEP Paris [2] and IGEP Berlin [3].
 
 Support for this expansion boards is still not in mainline but there are plans
 to add them using Device Tree overlays [4] once/if this land on mainline.
 

Why would your boards need Device Tree overlays? From the looks of it, the 
configuration
of SOM + base board don't seem to change at runtime.

 So, answering your question right now this is not required but I thought it
 would be good to have it configured by default in case someone using an 
 IGEP0030
 and a expansion board wants to extend omap3-igep0030.dts to add support for 
 its
 expansion board.

I think all you need is a .dts file for each expansion board that extends
omap3-iegp0030.dts.

That way, the pinmux for USB host pins will come only in those boards that have 
the USB host port.

 
 I've no strong opinion on this though and I can send a new patch with those 
 pins
 moved to omap3-igep0020.dts though if you think that would be better.

If you don't put it in omap3-igep0020.dts, how will you handle the case when a 
omap3-igep0030
SOM is used with an expansion board that doesn't have USB host port and uses it 
for something
else?

 
   leds_pins: pinmux_leds_pins { };
  };

 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
 b/arch/arm/boot/dts/omap3-igep0020.dts
 index 903e944..180b186 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -55,6 +55,23 @@
   regulator-name = vdd33a;
   regulator-always-on;
   };
 +
 +   /* HS USB Port 1 Power */
 +   hsusb1_power: hsusb1_power_reg {
 +   compatible = regulator-fixed;
 +   regulator-name = hsusb1_vbus;
 +   regulator-min-microvolt = 330;
 +   regulator-max-microvolt = 330;
 +   gpio = twl_gpio 18 GPIO_ACTIVE_LOW;/* GPIO LEDA 
 */
 +   startup-delay-us = 7;
 +   };
 +
 + /* HS USB Host PHY on PORT 1 */
 + hsusb1_phy: hsusb1_phy {
 + compatible = usb-nop-xceiv;
 + reset-gpios = gpio1 24 GPIO_ACTIVE_LOW; /* gpio_24 */
 + vcc-supply = hsusb1_power;
 + };
  };

  leds_pins {
 @@ -173,3 +190,11 @@
   mode = 3;
   power = 50;
  };
 +
 +usbhshost {
 + port1-mode =

Re: [PATCH v4 3/4] v4l: ti-vpe: Add VPE mem to mem driver


On Monday 07 October 2013 01:25 PM, Hans Verkuil wrote:

Hi Archit,

I've got a few comments below...

On 09/06/2013 12:12 PM, Archit Taneja wrote:

VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.

We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.

Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are added.

Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and stores
them in the buffer. There are also some VPDMA parameters like frame start and
line mode which needs to be configured, these are configured by direct register
writes via the VPDMA helper functions.

The driver's device_run() mem2mem op will add each descriptor based on how the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
upload MMR registers, start DMA of video buffers on the various input and output
clients/ports.

When the list is parsed completely(and the DMAs on all the output ports done),
an interrupt is generated which we use to notify that the source and destination
buffers are done.

The rest of the driver is quite similar to other mem2mem drivers, we use the
multiplane v4l2 ioctls as the HW support coplanar formats.

Signed-off-by: Archit Taneja arc...@ti.com
---
  drivers/media/platform/Kconfig   |   16 +
  drivers/media/platform/Makefile  |2 +
  drivers/media/platform/ti-vpe/Makefile   |5 +
  drivers/media/platform/ti-vpe/vpe.c  | 1750 ++
  drivers/media/platform/ti-vpe/vpe_regs.h |  496 +
  include/uapi/linux/v4l2-controls.h   |4 +
  6 files changed, 2273 insertions(+)
  create mode 100644 drivers/media/platform/ti-vpe/Makefile
  create mode 100644 drivers/media/platform/ti-vpe/vpe.c
  create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h



snip


+
+static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
+   struct vpe_ctx *ctx = file2ctx(file);
+   struct vb2_queue *vq;
+   struct vpe_q_data *q_data;
+   int i;
+
+   vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
+   if (!vq)
+   return -EINVAL;
+
+   q_data = get_q_data(ctx, f-type);
+
+   pix-width = q_data-width;
+   pix-height = q_data-height;
+   pix-pixelformat = q_data-fmt-fourcc;
+   pix-colorspace = q_data-colorspace;
+   pix-num_planes = q_data-fmt-coplanar ? 2 : 1;
+
+   for (i = 0; i  pix-num_planes; i++) {
+   pix-plane_fmt[i].bytesperline = q_data-bytesperline[i];
+   pix-plane_fmt[i].sizeimage = q_data-sizeimage[i];
+   }
+
+   return 0;
+}
+
+static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
+  struct vpe_fmt *fmt, int type)
+{
+   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
+   struct v4l2_plane_pix_format *plane_fmt;
+   int i;
+
+   if (!fmt || !(fmt-types  type)) {
+   vpe_err(ctx-dev, Fourcc format (0x%08x) invalid.\n,
+   pix-pixelformat);
+   return -EINVAL;
+   }
+
+   pix-field = V4L2_FIELD_NONE;
+
+   v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
+ pix-height, MIN_H, MAX_H, H_ALIGN,
+ S_ALIGN);
+
+   pix-num_planes = fmt-coplanar ? 2 : 1;
+   pix-pixelformat = fmt-fourcc;
+   pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?


You do this only for capture. Output sets the colorspace, so try_fmt should
leave the colorspace field untouched for the output direction.


+   V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;


The input to the VPE block can be various YUV formats, and the VPE can 
generate both RGB and YUV formats.


So, I guess the output(V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) side has 
choice only to set V4L2_COLORSPACE_SMPTE170M. And in the 
capture(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) capture side we have both 
SRG and SMPTE170M options.


One thing I am not clear about is whether the userspace application has 
to set the colorspace in the v4l2 format for OUTPUT or CAPTURE or both?


From what I understood, the code should be as below.

For output:

if (!pix-colorspace)
pix-colorspace

Congratulations !!!

2013-10-07 Thread office3

Ticket Number: 7PWYZ2008
Ballot Number: BT:12052008/20
Draw:#1471

Special Notification to you,You are receiving this email because you have just 
been picked for a total grand prize of One Million Dollars in the top 10 
winners of the Coca-Cola Consumer`s Award for the year 2013: kindly send your:

Name:
Address:
Country:
Phone Number:

To Mr. Bruce Morgan
via Email: colaclaim...@msn.com
Telephone Number:+44701006909
--
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 v6 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DW PHY's

2013-10-07 Thread Stanimir Varbanov

Hi Ivan,

Few comments below.

On 10/07/2013 10:44 AM, Ivan T. Ivanov wrote:
 From: Ivan T. Ivanov iiva...@mm-sol.com
 
 These drivers handles control and configuration of the HS
 and SS USB PHY transceivers. They are part of the driver
 which manage Synopsys DesignWare USB3 controller stack
 inside Qualcomm SoC's.
 
 Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
 ---
  drivers/usb/phy/Kconfig |   11 ++
  drivers/usb/phy/Makefile|2 +
  drivers/usb/phy/phy-msm-dw-hs.c |  329 ++
  drivers/usb/phy/phy-msm-dw-ss.c |  375 
 +++
  4 files changed, 717 insertions(+)
  create mode 100644 drivers/usb/phy/phy-msm-dw-hs.c
  create mode 100644 drivers/usb/phy/phy-msm-dw-ss.c
 
 diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
 index d5589f9..bbb2d0e 100644
 --- a/drivers/usb/phy/Kconfig
 +++ b/drivers/usb/phy/Kconfig
 @@ -214,6 +214,17 @@ config USB_RCAR_PHY
 To compile this driver as a module, choose M here: the
 module will be called phy-rcar-usb.
  
 +config USB_MSM_DW_PHYS
 + tristate Qualcomm USB controller DW PHY's wrappers support
 + depends on (USB || USB_GADGET)  ARCH_MSM
 + select USB_PHY
 + help
 +   Enable this to support the DW USB PHY transceivers on MSM chips
 +   with DWC3 USB core. It handles PHY initialization, clock
 +   management required after resetting the hardware and power
 +   management. This driver is required even for peripheral only or
 +   host only mode configurations.
 +
  config USB_ULPI
   bool Generic ULPI Transceiver Driver
   depends on ARM
 diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
 index 2135e85..4813eb5 100644
 --- a/drivers/usb/phy/Makefile
 +++ b/drivers/usb/phy/Makefile
 @@ -26,6 +26,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA)+= 
 phy-tegra-usb.o
  obj-$(CONFIG_USB_GPIO_VBUS)  += phy-gpio-vbus-usb.o
  obj-$(CONFIG_USB_ISP1301)+= phy-isp1301.o
  obj-$(CONFIG_USB_MSM_OTG)+= phy-msm-usb.o
 +obj-$(CONFIG_USB_MSM_DW_PHYS)+= phy-msm-dw-hs.o
 +obj-$(CONFIG_USB_MSM_DW_PHYS)+= phy-msm-dw-ss.o
  obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
  obj-$(CONFIG_USB_MXS_PHY)+= phy-mxs-usb.o
  obj-$(CONFIG_USB_RCAR_PHY)   += phy-rcar-usb.o
 diff --git a/drivers/usb/phy/phy-msm-dw-hs.c b/drivers/usb/phy/phy-msm-dw-hs.c
 new file mode 100644
 index 000..d29c1f1
 --- /dev/null
 +++ b/drivers/usb/phy/phy-msm-dw-hs.c
 @@ -0,0 +1,329 @@
 +/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 and
 + * only version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/platform_device.h
 +#include linux/regulator/consumer.h
 +#include linux/usb/phy.h
 +
 +/**
 + *  USB QSCRATCH Hardware registers
 + */
 +#define QSCRATCH_CTRL_REG(0x04)
 +#define QSCRATCH_GENERAL_CFG (0x08)
 +#define PHY_CTRL_REG (0x10)
 +#define PARAMETER_OVERRIDE_X_REG (0x14)
 +#define CHARGING_DET_CTRL_REG(0x18)
 +#define CHARGING_DET_OUTPUT_REG  (0x1c)
 +#define ALT_INTERRUPT_EN_REG (0x20)
 +#define PHY_IRQ_STAT_REG (0x24)
 +#define CGCTL_REG(0x28)
 +

Please remove braces above and below.

 +#define PHY_3P3_VOL_MIN  305 /* uV */
 +#define PHY_3P3_VOL_MAX  330 /* uV */
 +#define PHY_3P3_HPM_LOAD 16000   /* uA */
 +
 +#define PHY_1P8_VOL_MIN  180 /* uV */
 +#define PHY_1P8_VOL_MAX  180 /* uV */
 +#define PHY_1P8_HPM_LOAD 19000   /* uA */
 +
 +/* TODO: these are suspicious */
 +#define USB_VDDCX_NO 1   /* index */
 +#define USB_VDDCX_MIN5   /* index */
 +#define USB_VDDCX_MAX7   /* index */
 +
 +struct msm_dw_hs_phy {
 + struct usb_phy  phy;
 + void __iomem*base;
 + struct device   *dev;
 +
 + struct clk  *xo_clk;
 + struct clk  *sleep_a_clk;
 +
 + struct regulator*v3p3;
 + struct regulator*v1p8;
 + struct regulator*vddcx;
 + struct regulator*vbus;
 +};
 +
 +#define  phy_to_dw_phy(x)container_of((x), struct msm_dw_hs_phy, 
 phy)

I think that using tab after #define is uncommon,

Re: [PATCH v6 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver

2013-10-07 Thread Stanimir Varbanov

Hi Ivan,

Minor comments below.

On 10/07/2013 10:44 AM, Ivan T. Ivanov wrote:
 From: Ivan T. Ivanov iiva...@mm-sol.com
 
 DWC3 glue layer is hardware layer around Synopsys DesignWare
 USB3 core. Its purpose is to supply Synopsys IP with required
 clocks, voltages and interface it with the rest of the SoC.
 
 Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
 ---
  drivers/usb/dwc3/Kconfig|8 +++
  drivers/usb/dwc3/Makefile   |1 +
  drivers/usb/dwc3/dwc3-msm.c |  168 
 +++
  3 files changed, 177 insertions(+)
  create mode 100644 drivers/usb/dwc3/dwc3-msm.c
 
 diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
 index 70fc430..4c7b5a4 100644
 --- a/drivers/usb/dwc3/Kconfig
 +++ b/drivers/usb/dwc3/Kconfig
 @@ -59,6 +59,14 @@ config USB_DWC3_EXYNOS
 Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
 say 'Y' or 'M' if you have one such device.
  
 +config USB_DWC3_MSM
 +   tristate Qualcomm MSM/APQ Platforms
 +   default USB_DWC3
 +   select USB_MSM_DWC3_PHYS
 +   help
 + Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
 + say 'Y' or 'M' if you have one such device.
 +
  config USB_DWC3_PCI
   tristate PCIe-based Platforms
   depends on PCI
 diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
 index dd17601..a90de66 100644
 --- a/drivers/usb/dwc3/Makefile
 +++ b/drivers/usb/dwc3/Makefile
 @@ -31,4 +31,5 @@ endif
  
  obj-$(CONFIG_USB_DWC3_OMAP)  += dwc3-omap.o
  obj-$(CONFIG_USB_DWC3_EXYNOS)+= dwc3-exynos.o
 +obj-$(CONFIG_USB_DWC3_MSM)   += dwc3-msm.o
  obj-$(CONFIG_USB_DWC3_PCI)   += dwc3-pci.o
 diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
 new file mode 100644
 index 000..1d73f92
 --- /dev/null
 +++ b/drivers/usb/dwc3/dwc3-msm.c
 @@ -0,0 +1,168 @@
 +/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 and
 + * only version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/io.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/of_platform.h
 +#include linux/platform_device.h
 +#include linux/regulator/consumer.h
 +#include linux/usb/phy.h
 +
 +struct dwc3_msm {
 + struct device   *dev;
 +
 + struct clk  *core_clk;
 + struct clk  *iface_clk;
 + struct clk  *sleep_clk;
 + struct clk  *utmi_clk;
 +
 + struct regulator*gdsc;
 +};
 +
 +static int dwc3_msm_probe(struct platform_device *pdev)
 +{
 + struct device_node *node = pdev-dev.of_node;
 + struct dwc3_msm *mdwc;
 + struct resource *res;
 + void __iomem *tcsr;
 + int ret = 0;
 +
 + mdwc = devm_kzalloc(pdev-dev, sizeof(*mdwc), GFP_KERNEL);
 + if (!mdwc)
 + return -ENOMEM;
 +
 + platform_set_drvdata(pdev, mdwc);
 +
 + mdwc-dev = pdev-dev;
 +
 + mdwc-gdsc = devm_regulator_get(mdwc-dev, gdsc);
 +
 + mdwc-core_clk = devm_clk_get(mdwc-dev, core);
 + if (IS_ERR(mdwc-core_clk)) {
 + dev_dbg(mdwc-dev, failed to get core clock\n);
 + return PTR_ERR(mdwc-core_clk);
 + }
 +
 + mdwc-iface_clk = devm_clk_get(mdwc-dev, iface);
 + if (IS_ERR(mdwc-iface_clk)) {
 + dev_dbg(mdwc-dev, failed to get iface clock\n);
 + return PTR_ERR(mdwc-iface_clk);
 + }
 +
 + mdwc-sleep_clk = devm_clk_get(mdwc-dev, sleep);
 + if (IS_ERR(mdwc-sleep_clk)) {
 + dev_dbg(mdwc-dev, failed to get sleep clock\n);
 + return  PTR_ERR(mdwc-sleep_clk);
 + }
 +
 + mdwc-utmi_clk = devm_clk_get(mdwc-dev, utmi);
 + if (IS_ERR(mdwc-utmi_clk)) {
 + dev_dbg(mdwc-dev, failed to get utmi clock\n);
 + return  PTR_ERR(mdwc-utmi_clk);
 + }

I'm not sure that those dev_dbg() are useful at all.

 +
 + if (!IS_ERR(mdwc-gdsc)) {
 + ret = regulator_enable(mdwc-gdsc);
 + if (ret)
 + dev_err(mdwc-dev, cannot enable gdsc\n);
 + }
 +
 + /*
 +  * DWC3 Core requires its CORE CLK (aka master / bus clk) to
 +  * run at 125Mhz in SSUSB mode and 60MHZ for HSUSB mode.
 +  */
 + clk_set_rate(mdwc-core_clk, 12500);
 + clk_prepare_enable(mdwc-core_clk);
 + clk_prepare_enable(mdwc-iface_clk);
 + clk_prepare_enable(mdwc-sleep_clk);
 + clk_prepare_enable(mdwc-utmi_clk);

All function calls above could return errors. Aren't those clocks fatal?

Re: [PATCH v4 3/4] v4l: ti-vpe: Add VPE mem to mem driver

On 10/07/2013 11:16 AM, Archit Taneja wrote:
 On Monday 07 October 2013 01:25 PM, Hans Verkuil wrote:
 Hi Archit,

 I've got a few comments below...

 On 09/06/2013 12:12 PM, Archit Taneja wrote:
 VPE is a block which consists of a single memory to memory path which can
 perform chrominance up/down sampling, de-interlacing, scaling, and color 
 space
 conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
 interleaved video formats.

 We create a mem2mem driver based primarily on the mem2mem-testdev example.
 The de-interlacer, scaler and color space converter are all bypassed for now
 to keep the driver simple. Chroma up/down sampler blocks are implemented, so
 conversion beteen different YUV formats is possible.

 Each mem2mem context allocates a buffer for VPE MMR values which it will use
 when it gets access to the VPE HW via the mem2mem queue, it also allocates
 a VPDMA descriptor list to which configuration and data descriptors are 
 added.

 Based on the information received via v4l2 ioctls for the source and
 destination queues, the driver configures the values for the MMRs, and 
 stores
 them in the buffer. There are also some VPDMA parameters like frame start 
 and
 line mode which needs to be configured, these are configured by direct 
 register
 writes via the VPDMA helper functions.

 The driver's device_run() mem2mem op will add each descriptor based on how 
 the
 source and destination queues are set up for the given ctx, once the list is
 prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA 
 will
 upload MMR registers, start DMA of video buffers on the various input and 
 output
 clients/ports.

 When the list is parsed completely(and the DMAs on all the output ports 
 done),
 an interrupt is generated which we use to notify that the source and 
 destination
 buffers are done.

 The rest of the driver is quite similar to other mem2mem drivers, we use the
 multiplane v4l2 ioctls as the HW support coplanar formats.

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
   drivers/media/platform/Kconfig   |   16 +
   drivers/media/platform/Makefile  |2 +
   drivers/media/platform/ti-vpe/Makefile   |5 +
   drivers/media/platform/ti-vpe/vpe.c  | 1750 
 ++
   drivers/media/platform/ti-vpe/vpe_regs.h |  496 +
   include/uapi/linux/v4l2-controls.h   |4 +
   6 files changed, 2273 insertions(+)
   create mode 100644 drivers/media/platform/ti-vpe/Makefile
   create mode 100644 drivers/media/platform/ti-vpe/vpe.c
   create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h


 snip

 +
 +static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 +{
 +   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
 +   struct vpe_ctx *ctx = file2ctx(file);
 +   struct vb2_queue *vq;
 +   struct vpe_q_data *q_data;
 +   int i;
 +
 +   vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
 +   if (!vq)
 +   return -EINVAL;
 +
 +   q_data = get_q_data(ctx, f-type);
 +
 +   pix-width = q_data-width;
 +   pix-height = q_data-height;
 +   pix-pixelformat = q_data-fmt-fourcc;
 +   pix-colorspace = q_data-colorspace;
 +   pix-num_planes = q_data-fmt-coplanar ? 2 : 1;
 +
 +   for (i = 0; i  pix-num_planes; i++) {
 +   pix-plane_fmt[i].bytesperline = q_data-bytesperline[i];
 +   pix-plane_fmt[i].sizeimage = q_data-sizeimage[i];
 +   }
 +
 +   return 0;
 +}
 +
 +static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
 +  struct vpe_fmt *fmt, int type)
 +{
 +   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
 +   struct v4l2_plane_pix_format *plane_fmt;
 +   int i;
 +
 +   if (!fmt || !(fmt-types  type)) {
 +   vpe_err(ctx-dev, Fourcc format (0x%08x) invalid.\n,
 +   pix-pixelformat);
 +   return -EINVAL;
 +   }
 +
 +   pix-field = V4L2_FIELD_NONE;
 +
 +   v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
 + pix-height, MIN_H, MAX_H, H_ALIGN,
 + S_ALIGN);
 +
 +   pix-num_planes = fmt-coplanar ? 2 : 1;
 +   pix-pixelformat = fmt-fourcc;
 +   pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?

 You do this only for capture. Output sets the colorspace, so try_fmt should
 leave the colorspace field untouched for the output direction.

 +   V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
 
 The input to the VPE block can be various YUV formats, and the VPE can 
 generate both RGB and YUV formats.
 
 So, I guess the output(V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) side has 
 choice only to set V4L2_COLORSPACE_SMPTE170M. And in the 
 capture(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) capture side we have both 
 SRG and SMPTE170M options.
 
 One thing I am not clear about is whether the userspace application has 
 to set the colorspace in the v4l2 format for OUTPUT or CAPTURE or both?

The spec today says that the colorspace field is filled in by the driver.
It does not

[PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues

With the new omapdss device model. The user(omapdrm/omapfb) of a omap_dss_device
has to call connect() to use the device. A connect() call can request to defer
probe if the device(or the previous entities in the chain) have missing
resources like a regulator or an I2C bus.

We make omapdrm defer probe by trying to first connect all panels, and request
for deferral if any panel requests for a defer. This makes sure that all the
panels are set up correctly when we finally proceed with omapdrm initialization.

In order for omapdrm module to be removed successfully, we need to disconnect
the panels which omapdrm connected. Another thing noticed was that omapdrm
insertion followed by some usage results in panels getting enabled.

Trying to remove omapdrm with a panel enabled results in failure while
disconnecting. This leaves omapdss panels in a bad state. I have added an
explicit panel disable in the omap_encoder_destroy() op, I needed some
suggestions on whether there is a better way to do this.

changes in v2:
- Add special case when no panels are available to connect.
- Make sure panels are diabled (and then disconnected) when omapdrm is removed

Archit Taneja (2):
  drm: omap: fix: Defer probe if an omapdss device requests for it at
connect
  drm: omap: disconnect devices when omapdrm module is removed

 drivers/gpu/drm/omapdrm/omap_crtc.c|  5 +++
 drivers/gpu/drm/omapdrm/omap_drv.c | 77 --
 drivers/gpu/drm/omapdrm/omap_drv.h |  1 +
 drivers/gpu/drm/omapdrm/omap_encoder.c |  3 ++
 4 files changed, 64 insertions(+), 22 deletions(-)

-- 
1.8.1.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 v2 2/2] drm: omap: disconnect devices when omapdrm module is removed

omapdrm establishes connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it also causes
issues when we try to remove or re-insert omapdrm module.

Before omapdrm module is removed, we need to make sure that all the connectors
are disabled. Without this, the omap_dss_devices won't disconnect, and cause
issues when we try to re-insert omapdrm.

For now, disable encoders in omap_encoder_destroy. We are not clear if this is
the best place to disable an encoder. This makes successive module insertions
and removal work unlike before. But it leads to warning backtraces when the
module is removed. The func omap_crtc_destroy() gves a warning because
omap_crtc-apply_irq.registered is still set when we try to disable the crtc. I
haven't figured out a way to prevent this, would appreciate some help here.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 15 +++
 drivers/gpu/drm/omapdrm/omap_encoder.c |  3 +++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index be3bfe1..45f7ec6 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum 
omap_channel channel)
 
return false;
 }
+static void omap_disconnect_dssdevs(void)
+{
+   struct omap_dss_device *dssdev = NULL;
+
+   for_each_dss_dev(dssdev)
+   dssdev-driver-disconnect(dssdev);
+}
 
 static int omap_connect_dssdevs(void)
 {
@@ -116,10 +123,7 @@ cleanup:
 * if we are deferring probe, we disconnect the devices we previously
 * connected
 */
-   dssdev = NULL;
-
-   for_each_dss_dev(dssdev)
-   dssdev-driver-disconnect(dssdev);
+   omap_disconnect_dssdevs();
 
return r;
 }
@@ -694,6 +698,9 @@ static int pdev_remove(struct platform_device *device)
DBG();
drm_platform_exit(omap_drm_driver, device);
 
+   omap_disconnect_dssdevs();
+   omap_crtc_pre_uninit();
+
platform_driver_unregister(omap_dmm_driver);
return 0;
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c 
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index 6a12e89..5290a88 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -51,6 +51,9 @@ struct omap_dss_device *omap_encoder_get_dssdev(struct 
drm_encoder *encoder)
 static void omap_encoder_destroy(struct drm_encoder *encoder)
 {
struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
+
+   omap_encoder_set_enabled(encoder, false);
+
drm_encoder_cleanup(encoder);
kfree(omap_encoder);
 }
-- 
1.8.1.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 v2 1/2] drm: omap: fix: Defer probe if an omapdss device requests for it at connect

Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require
regulators. The output's connect op tries to get a regulator which may not exist
yet because it might get registered later in the kernel boot.

omapdrm currently ignores those panels which return a non zero value when
connected. A better approach would be for omapdrm to request for probe deferral
if a panel's connect op returns -EPROBE_DEFER.

A special case has to be considered when no panels are available to connect when
omapdrm probes. In this case too, we defer probe and expect that a panel will be
available to connect the next time.

The connecting of panels is moved very early in the the drm device's probe
before anything else is initialized. When we enter omap_modeset_init(), we have
a set of panels that have been connected. We now proceed with registering only
those panels which are already connected.

Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.

This fixes boot with omapdrm on an omap4 panda ES board. The regulators used by
HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized
as it's pins are not configured because pinctrl is yet to probe.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/gpu/drm/omapdrm/omap_crtc.c |  5 +++
 drivers/gpu/drm/omapdrm/omap_drv.c  | 70 +
 drivers/gpu/drm/omapdrm/omap_drv.h  |  1 +
 3 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..9c01311 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
dss_install_mgr_ops(mgr_ops);
 }
 
+void omap_crtc_pre_uninit(void)
+{
+   dss_uninstall_mgr_ops();
+}
+
 /* initialize crtc */
 struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2603d90..be3bfe1 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -87,6 +87,43 @@ static bool channel_used(struct drm_device *dev, enum 
omap_channel channel)
return false;
 }
 
+static int omap_connect_dssdevs(void)
+{
+   int r;
+   struct omap_dss_device *dssdev = NULL;
+   bool no_displays = true;
+
+   for_each_dss_dev(dssdev) {
+   r = dssdev-driver-connect(dssdev);
+   if (r == -EPROBE_DEFER) {
+   omap_dss_put_device(dssdev);
+   goto cleanup;
+   } else if (r) {
+   dev_warn(dssdev-dev, could not connect display: %s\n,
+   dssdev-name);
+   } else {
+   no_displays = false;
+   }
+   }
+
+   if (no_displays)
+   return -EPROBE_DEFER;
+
+   return 0;
+
+cleanup:
+   /*
+* if we are deferring probe, we disconnect the devices we previously
+* connected
+*/
+   dssdev = NULL;
+
+   for_each_dss_dev(dssdev)
+   dssdev-driver-disconnect(dssdev);
+
+   return r;
+}
+
 static int omap_modeset_init(struct drm_device *dev)
 {
struct omap_drm_private *priv = dev-dev_private;
@@ -95,9 +132,6 @@ static int omap_modeset_init(struct drm_device *dev)
int num_mgrs = dss_feat_get_num_mgrs();
int num_crtcs;
int i, id = 0;
-   int r;
-
-   omap_crtc_pre_init();
 
drm_mode_config_init(dev);
 
@@ -119,26 +153,8 @@ static int omap_modeset_init(struct drm_device *dev)
enum omap_channel channel;
struct omap_overlay_manager *mgr;
 
-   if (!dssdev-driver) {
-   dev_warn(dev-dev, %s has no driver.. skipping it\n,
-   dssdev-name);
-   continue;
-   }
-
-   if (!(dssdev-driver-get_timings ||
-   dssdev-driver-read_edid)) {
-   dev_warn(dev-dev, %s driver does not support 
-   get_timings or read_edid.. skipping it!\n,
-   dssdev-name);
-   continue;
-   }
-
-   r = dssdev-driver-connect(dssdev);
-   if (r) {
-   dev_err(dev-dev, could not connect display: %s\n,
-   dssdev-name);
+   if (!omapdss_device_is_connected(dssdev))
continue;
-   }
 
encoder = omap_encoder_init(dev, dssdev);
 
@@ -656,9

[PATCH v2 0/3] ARM: dts: omap3-igep: improvements for v3.13

Hi Benoit,

This series are some enhancements and cleanups for IGEP boards
that it would be great if can make it for v3.13.

This is a second version of the patch-set that addresses some issues
raised by Roger Quadros and is composed of the following patches:

[PATCH v2 1/3] ARM: dts: omap3-igep: Add USB OTG support
[PATCH v2 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support
[PATCH v2 3/3] ARM: dts: omap3-igep0020: use standard constant for IRQ

Patch 1 and 2 adds USB OTG and Host support respectively and patch 3
is a small cleanup to get rid of a magic number and use the proper
constant for IRQ edge/level type flags.

Thanks a lot and best regards,
Javier
--
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 v2 1/3] ARM: dts: omap3-igep: Add USB OTG support

Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards)
added USB OTG support for most OMAP boards but some OMAP3 boards
such as IGEP boards were not updated. This patch adds an USB OTG
device node to these board.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---

Changes since v1:
 - Add USB OTG support for both IGEPv2 and IGEP COM and not only to IGEPv2

 arch/arm/boot/dts/omap3-igep.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index 0f92224..4e2eda2 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -143,3 +143,10 @@
 twl_gpio {
ti,use-leds;
 };
+
+usb_otg_hs {
+   interface-type = 0;
+   usb-phy = usb2_phy;
+   mode = 3;
+   power = 50;
+};
-- 
1.8.4.rc3

--
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 v2 3/3] ARM: dts: omap3-igep0020: use standard constant for IRQ flags

Commit 840ef8b7 (ARM: dt: add header to define IRQ flags) added
constants for IRQ edge/level triggered types so use it instead of
a magic number to enhance the DT readability.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Changes since v1:
 - None

 arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index 35346f2..750ce84 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -199,7 +199,7 @@
gpmc,cycle2cycle-diffcsen;
 
interrupt-parent = gpio6;
-   interrupts = 16 8;
+   interrupts = 16 IRQ_TYPE_LEVEL_LOW;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
-- 
1.8.4.rc3

--
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 v2 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

Add device nodes for the HS USB Host port 1, USB PHY and its
required regulator and also pin mux setup for HS USB1 pins.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---

Changes since v1:
 - Add HST USB port 1 pinmux setup in omap3-igep0020 instead of
   omap3-igep.dtsi since is not used by IGEP COM; suggested by Roger Quadros

 arch/arm/boot/dts/omap3-igep0020.dts | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index eedf0d8..35346f2 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -55,6 +55,47 @@
regulator-name = vdd33a;
regulator-always-on;
};
+
+   /* HS USB Port 1 Power */
+   hsusb1_power: hsusb1_power_reg {
+   compatible = regulator-fixed;
+   regulator-name = hsusb1_vbus;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   gpio = twl_gpio 18 GPIO_ACTIVE_LOW;  /* GPIO LEDA */
+   startup-delay-us = 7;
+   };
+
+   /* HS USB Host PHY on PORT 1 */
+   hsusb1_phy: hsusb1_phy {
+   compatible = usb-nop-xceiv;
+   reset-gpios = gpio1 24 GPIO_ACTIVE_LOW; /* gpio_24 */
+   vcc-supply = hsusb1_power;
+   };
+};
+
+omap3_pmx_core {
+   pinctrl-names = default;
+   pinctrl-0 = 
+   hsusbb1_pins
+   ;
+
+   hsusbb1_pins: pinmux_hsusbb1_pins {
+   pinctrl-single,pins = 
+   0x5aa (PIN_OUTPUT | MUX_MODE3)  /* 
etk_ctl.hsusb1_clk */
+   0x5a8 (PIN_OUTPUT | MUX_MODE3)  /* 
etk_clk.hsusb1_stp */
+   0x5bc (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d8.hsusb1_dir */
+   0x5be (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d9.hsusb1_nxt */
+   0x5ac (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d0.hsusb1_data0 */
+   0x5ae (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d1.hsusb1_data1 */
+   0x5b0 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d2.hsusb1_data2 */
+   0x5b2 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d3.hsusb1_data7 */
+   0x5b4 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d4.hsusb1_data4 */
+   0x5b6 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d5.hsusb1_data5 */
+   0x5b8 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d6.hsusb1_data6 */
+   0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d7.hsusb1_data3 */
+   ;
+   };
 };
 
 leds_pins {
@@ -166,3 +207,11 @@
smsc,save-mac-address;
};
 };
+
+usbhshost {
+   port1-mode = ehci-phy;
+};
+
+usbhsehci {
+   phys = hsusb1_phy;
+};
-- 
1.8.4.rc3

--
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 v2 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

On 10/07/2013 12:55 PM, Javier Martinez Canillas wrote:
 Add device nodes for the HS USB Host port 1, USB PHY and its
 required regulator and also pin mux setup for HS USB1 pins.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Tested-by: Enric Balletbo i Serra eballe...@gmail.com

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

 ---
 
 Changes since v1:
  - Add HST USB port 1 pinmux setup in omap3-igep0020 instead of
omap3-igep.dtsi since is not used by IGEP COM; suggested by Roger Quadros
 
  arch/arm/boot/dts/omap3-igep0020.dts | 49 
 
  1 file changed, 49 insertions(+)
 
 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
 b/arch/arm/boot/dts/omap3-igep0020.dts
 index eedf0d8..35346f2 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -55,6 +55,47 @@
   regulator-name = vdd33a;
   regulator-always-on;
   };
 +
 +   /* HS USB Port 1 Power */
 +   hsusb1_power: hsusb1_power_reg {
 +   compatible = regulator-fixed;
 +   regulator-name = hsusb1_vbus;
 +   regulator-min-microvolt = 330;
 +   regulator-max-microvolt = 330;
 +   gpio = twl_gpio 18 GPIO_ACTIVE_LOW;/* GPIO LEDA */
 +   startup-delay-us = 7;
 +   };
 +
 + /* HS USB Host PHY on PORT 1 */
 + hsusb1_phy: hsusb1_phy {
 + compatible = usb-nop-xceiv;
 + reset-gpios = gpio1 24 GPIO_ACTIVE_LOW; /* gpio_24 */
 + vcc-supply = hsusb1_power;
 + };
 +};
 +
 +omap3_pmx_core {
 + pinctrl-names = default;
 + pinctrl-0 = 
 + hsusbb1_pins
 + ;
 +
 + hsusbb1_pins: pinmux_hsusbb1_pins {
 + pinctrl-single,pins = 
 + 0x5aa (PIN_OUTPUT | MUX_MODE3)  /* 
 etk_ctl.hsusb1_clk */
 + 0x5a8 (PIN_OUTPUT | MUX_MODE3)  /* 
 etk_clk.hsusb1_stp */
 + 0x5bc (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d8.hsusb1_dir */
 + 0x5be (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d9.hsusb1_nxt */
 + 0x5ac (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d0.hsusb1_data0 */
 + 0x5ae (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d1.hsusb1_data1 */
 + 0x5b0 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d2.hsusb1_data2 */
 + 0x5b2 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d3.hsusb1_data7 */
 + 0x5b4 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d4.hsusb1_data4 */
 + 0x5b6 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d5.hsusb1_data5 */
 + 0x5b8 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d6.hsusb1_data6 */
 + 0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
 etk_d7.hsusb1_data3 */
 + ;
 + };
  };
  
  leds_pins {
 @@ -166,3 +207,11 @@
   smsc,save-mac-address;
   };
  };
 +
 +usbhshost {
 + port1-mode = ehci-phy;
 +};
 +
 +usbhsehci {
 + phys = hsusb1_phy;
 +};
 

--
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 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

On Mon, Oct 7, 2013 at 11:13 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 On 10/07/2013 11:06 AM, Roger Quadros wrote:

 Well that's a very good question indeed.

 The thing is that the IGEP0030 is a Computer-on-Module [1] that is used in
 conjunction with expansion boards and some of them have USB HOST support 
 such as
 IGEP Paris [2] and IGEP Berlin [3].

 Support for this expansion boards is still not in mainline but there are 
 plans
 to add them using Device Tree overlays [4] once/if this land on mainline.


 Why would your boards need Device Tree overlays? From the looks of it, the 
 configuration
 of SOM + base board don't seem to change at runtime.


 Indeed, a static configuration (DTS) would be enough now that I think about 
 it.


Hi Roger,

Now that I had coffee I remember why I think that even when Device
Tree overlays are not strictly required for a SOM + base board it
could be handy to use. If we use a static configuration (DTB) then the
same firmware can't be used by any IGEP COM Module user. She would
have to choose a DTB to pass to the kernel on boot.

While using DT overlays the same firmware that provides a minimal DTB
can be used regardless of the base board used (as long as there are
all the needed fragment/overlays hooks in the DTS).

After all the SOM has a NAND flash memory and a uSD/MMC slot so a
minimal DTB is needed to boot and the support for all the peripherals
present on the base board can be added by triggering a device tree
overlay load from user-space.

Or maybe I'm misunderstanding the use case for DT overlays since I had
just read about it but I don't have practical experience with it.

Thanks a lot and best regards,
Javier
--
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 3/4] v4l: ti-vpe: Add VPE mem to mem driver


On Monday 07 October 2013 03:04 PM, Hans Verkuil wrote:

On 10/07/2013 11:16 AM, Archit Taneja wrote:

On Monday 07 October 2013 01:25 PM, Hans Verkuil wrote:

Hi Archit,

I've got a few comments below...

On 09/06/2013 12:12 PM, Archit Taneja wrote:

VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.

We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.

Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are added.

Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and stores
them in the buffer. There are also some VPDMA parameters like frame start and
line mode which needs to be configured, these are configured by direct register
writes via the VPDMA helper functions.

The driver's device_run() mem2mem op will add each descriptor based on how the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
upload MMR registers, start DMA of video buffers on the various input and output
clients/ports.

When the list is parsed completely(and the DMAs on all the output ports done),
an interrupt is generated which we use to notify that the source and destination
buffers are done.

The rest of the driver is quite similar to other mem2mem drivers, we use the
multiplane v4l2 ioctls as the HW support coplanar formats.

Signed-off-by: Archit Taneja arc...@ti.com
---
   drivers/media/platform/Kconfig   |   16 +
   drivers/media/platform/Makefile  |2 +
   drivers/media/platform/ti-vpe/Makefile   |5 +
   drivers/media/platform/ti-vpe/vpe.c  | 1750 
++
   drivers/media/platform/ti-vpe/vpe_regs.h |  496 +
   include/uapi/linux/v4l2-controls.h   |4 +
   6 files changed, 2273 insertions(+)
   create mode 100644 drivers/media/platform/ti-vpe/Makefile
   create mode 100644 drivers/media/platform/ti-vpe/vpe.c
   create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h



snip


+
+static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
+   struct vpe_ctx *ctx = file2ctx(file);
+   struct vb2_queue *vq;
+   struct vpe_q_data *q_data;
+   int i;
+
+   vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
+   if (!vq)
+   return -EINVAL;
+
+   q_data = get_q_data(ctx, f-type);
+
+   pix-width = q_data-width;
+   pix-height = q_data-height;
+   pix-pixelformat = q_data-fmt-fourcc;
+   pix-colorspace = q_data-colorspace;
+   pix-num_planes = q_data-fmt-coplanar ? 2 : 1;
+
+   for (i = 0; i  pix-num_planes; i++) {
+   pix-plane_fmt[i].bytesperline = q_data-bytesperline[i];
+   pix-plane_fmt[i].sizeimage = q_data-sizeimage[i];
+   }
+
+   return 0;
+}
+
+static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
+  struct vpe_fmt *fmt, int type)
+{
+   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
+   struct v4l2_plane_pix_format *plane_fmt;
+   int i;
+
+   if (!fmt || !(fmt-types  type)) {
+   vpe_err(ctx-dev, Fourcc format (0x%08x) invalid.\n,
+   pix-pixelformat);
+   return -EINVAL;
+   }
+
+   pix-field = V4L2_FIELD_NONE;
+
+   v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
+ pix-height, MIN_H, MAX_H, H_ALIGN,
+ S_ALIGN);
+
+   pix-num_planes = fmt-coplanar ? 2 : 1;
+   pix-pixelformat = fmt-fourcc;
+   pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?


You do this only for capture. Output sets the colorspace, so try_fmt should
leave the colorspace field untouched for the output direction.


+   V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;


The input to the VPE block can be various YUV formats, and the VPE can
generate both RGB and YUV formats.

So, I guess the output(V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) side has
choice only to set V4L2_COLORSPACE_SMPTE170M. And in the
capture(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) capture side we have both
SRG and SMPTE170M options.

One thing I am not clear about is whether the userspace application has
to set the colorspace in the v4l2 format for OUTPUT or CAPTURE or both?


The

[PATCH] ARM: OMAP4/highbank: Flush L2 cache before disabling

2013-10-07 Thread Taras Kondratiuk

Kexec disables outer cache before jumping to reboot code, but it doesn't
flush it explicitly. Flush is done implicitly inside of l2x0_disable().
But some SoC's override default .disable handler and don't flush cache.
This may lead to a corrupted memory during Kexec reboot on these platforms.

This patch adds cache flush inside of OMAP4 and Highbank outer_cache.disable()
handlers to make it consistent with default l2x0_disable().
Also it removes redundant outer_flush_all() call just before outer_disable().

Acked-by: Rob Herring rob.herr...@calxeda.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org
---
Based on v3.12-rc3

RFC v2: https://patchwork.kernel.org/patch/2990231/
Make the fix specific to platforms that don't use l2x0_disable().
RFC v1: https://patchwork.kernel.org/patch/2974431/
---
Cc: Will Deacon will.dea...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: linaro-ker...@lists.linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
---
 arch/arm/mach-highbank/highbank.c  |1 +
 arch/arm/mach-highbank/pm.c|1 -
 arch/arm/mach-omap2/omap4-common.c |1 +
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-highbank/highbank.c 
b/arch/arm/mach-highbank/highbank.c
index 8e63ccd..22e6f34 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -63,6 +63,7 @@ void highbank_set_cpu_jump(int cpu, void *jump_addr)
 
 static void highbank_l2x0_disable(void)
 {
+   outer_flush_all();
/* Disable PL310 L2 Cache controller */
highbank_smc1(0x102, 0x0);
 }
diff --git a/arch/arm/mach-highbank/pm.c b/arch/arm/mach-highbank/pm.c
index 04eddb4..9a5b8a7 100644
--- a/arch/arm/mach-highbank/pm.c
+++ b/arch/arm/mach-highbank/pm.c
@@ -28,7 +28,6 @@
 
 static int highbank_suspend_finish(unsigned long val)
 {
-   outer_flush_all();
outer_disable();
 
highbank_set_pwr_suspend();
diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 2840d1e..f6ccab61 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -163,6 +163,7 @@ void __iomem *omap4_get_l2cache_base(void)
 
 static void omap4_l2x0_disable(void)
 {
+   outer_flush_all();
/* Disable PL310 L2 Cache controller */
omap_smc1(0x102, 0x0);
 }
-- 
1.7.9.5

--
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] i2c: omap: Clear ARDY bit twice

2013-10-07 Thread Taras Kondratiuk

Initially commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac
i2c-omap: Double clear of ARDY status in IRQ handler
added a workaround for undocumented errata ProDB0017052.
But then commit 1d7afc95946487945cc7f5019b41255b72224b70
i2c: omap: ack IRQ in parts refactored code and missed
one of ARDY clearings. So current code violates errata.
It causes often i2c bus timeouts on my Pandaboard.

This patch adds a second clearing in place.

Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org
---
Cc: Felipe Balbi ba...@ti.com
Cc: Richard woodruff r-woodru...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/i2c/busses/i2c-omap.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f5d6de0..d69826e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -939,6 +939,9 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
/*
 * ProDB0017052: Clear ARDY bit twice
 */
+   if (stat  OMAP_I2C_STAT_ARDY)
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ARDY);
+
if (stat  (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
-- 
1.7.9.5

--
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 1/3] ARM: dts: omap3-igep0020: Add USB OTG support

Javier,

On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:
 Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ 
 boards)
 added USB OTG support for most OMAP boards but some OMAP3 boards
 such as the IGEPv2 were not updated. This patch adds an USB OTG
 device node to this board.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/omap3-igep0020.dts | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
 b/arch/arm/boot/dts/omap3-igep0020.dts
 index eedf0d8..903e944 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -166,3 +166,10 @@
   smsc,save-mac-address;
   };
  };
 +
 +usb_otg_hs {
 + interface-type = 0;
 + usb-phy = usb2_phy;

With the PHY generic framework in Greg's usb-next branch [1], you will also 
need to add

+   phys = usb2_phy;
+   phy-names = usb2-phy;

 + mode = 3;
 + power = 50;
 +};
 

So it would be good to test with the usb-next branch.

cheers,
-roger

[1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
--
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 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

On 10/07/2013 01:22 PM, Javier Martinez Canillas wrote:
 On Mon, Oct 7, 2013 at 11:13 AM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 On 10/07/2013 11:06 AM, Roger Quadros wrote:

 Well that's a very good question indeed.

 The thing is that the IGEP0030 is a Computer-on-Module [1] that is used in
 conjunction with expansion boards and some of them have USB HOST support 
 such as
 IGEP Paris [2] and IGEP Berlin [3].

 Support for this expansion boards is still not in mainline but there are 
 plans
 to add them using Device Tree overlays [4] once/if this land on mainline.


 Why would your boards need Device Tree overlays? From the looks of it, the 
 configuration
 of SOM + base board don't seem to change at runtime.


 Indeed, a static configuration (DTS) would be enough now that I think about 
 it.

 
 Hi Roger,
 
 Now that I had coffee I remember why I think that even when Device
 Tree overlays are not strictly required for a SOM + base board it
 could be handy to use. If we use a static configuration (DTB) then the
 same firmware can't be used by any IGEP COM Module user. She would
 have to choose a DTB to pass to the kernel on boot.
 
 While using DT overlays the same firmware that provides a minimal DTB
 can be used regardless of the base board used (as long as there are
 all the needed fragment/overlays hooks in the DTS).
 
 After all the SOM has a NAND flash memory and a uSD/MMC slot so a
 minimal DTB is needed to boot and the support for all the peripherals
 present on the base board can be added by triggering a device tree
 overlay load from user-space.

Consider this example. You need to boot your board using NFS over ethernet
dongle connected to USB host. If you need user space to get that to work,
it will be a unnecessary challenge, whereas you can easily do that if you
have a static DT blob.

 
 Or maybe I'm misunderstanding the use case for DT overlays since I had
 just read about it but I don't have practical experience with it.
 

DT overlays is a solution to the problem faced by the beagle bone community.
There they have a relatively large number of accessories (called capes).
Since the capes don't use a dynamically probed interface like USB/MMC, 
the hardware information needs to be hard coded somewhere and loaded
into the DT at runtime whenever a new cape is connected.

Using overlays for a SOM + base board architecture is an overkill IMO. A base 
board
is not an accessory, but the platform board itself, hence qualifies for it's own
dts file.

It is much easier to use a base dts for the SOM which contains all the 
information
for the SOM and leaves the base board details to the base board specific dts.
Each base board can be considered to be a extended variant of the SOM.

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] ARM: dts: omap3-beagle: Adapt USB OTG to generic PHY framework

The generic PHY framewrok expects different properties than the
old USB PHY framework. Supply those properties.

Fixes USB OTG port on beagle after the Generic PHY framework was
merged in greg/usb-next. [1]

[1] - https://lkml.org/lkml/2013/9/27/581

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 7669c16..fa532aa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -173,6 +173,8 @@
 usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
mode = 3;
power = 50;
 };
-- 
1.7.4.1

--
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/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes

On Fri, Oct 04, 2013 at 08:49:43PM +0100, Pekon Gupta wrote:
 OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
 ecc-scheme, like:
 - OMAP_ECC_HAMMING_CODE_DEFAULT
   1-bit hamming ecc code using software library
 - OMAP_ECC_HAMMING_CODE_HW
   1-bit hamming ecc-code using GPMC h/w engine
 - OMAP_ECC_HAMMING_CODE_HW_ROMCODE
   1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible
   to ROM code.
 
 This patch combines above multiple ecc-schemes into single implementation:
 - OMAP_ECC_HAM1_CODE_HW
   1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible
   ecc-layout.

If I have my NAND formatted with one of the existing ECC schemes (e.g.
OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new
OMAP_ECC_HAM1_CODE_HW scheme?

Are they all compatible?

 
 Signed-off-by: Pekon Gupta pe...@ti.com
 ---
  Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 8 
  arch/arm/mach-omap2/board-flash.c   | 2 +-
  arch/arm/mach-omap2/gpmc.c  | 4 +---
  drivers/mtd/nand/omap2.c| 9 +++--
  include/linux/platform_data/mtd-nand-omap2.h| 6 +-
  5 files changed, 10 insertions(+), 19 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
 b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 index df338cb..25ee232 100644
 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 @@ -22,10 +22,10 @@ Optional properties:
   width of 8 is assumed.
  
   - ti,nand-ecc-opt:  A string setting the ECC layout to use. One of:
 -
 - swSoftware method (default)
 - hwHardware method
 - hw-romcodegpmc hamming mode method  romcode layout
 + swdeprecated use ham1 instead
 + hwdeprecated use ham1 instead
 + hw-romcodedeprecated use ham1 instead
 + ham1  1-bit Hamming ecc code
   bch4  4-bit BCH ecc code
   bch8  8-bit BCH ecc code
  
 diff --git a/arch/arm/mach-omap2/board-flash.c 
 b/arch/arm/mach-omap2/board-flash.c
 index fc20a61..ac82512 100644
 --- a/arch/arm/mach-omap2/board-flash.c
 +++ b/arch/arm/mach-omap2/board-flash.c
 @@ -142,7 +142,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, 
 u8 nr_parts, u8 cs,
   board_nand_data.nr_parts= nr_parts;
   board_nand_data.devsize = nand_type;
  
 - board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
 + board_nand_data.ecc_opt = OMAP_ECC_BCH8_CODE_HW;
   gpmc_nand_init(board_nand_data, gpmc_t);
  }
  #endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
 diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
 index 9f4795a..1c45b72 100644
 --- a/arch/arm/mach-omap2/gpmc.c
 +++ b/arch/arm/mach-omap2/gpmc.c
 @@ -1342,9 +1342,7 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
 device_node *np,
  #ifdef CONFIG_MTD_NAND
  
  static const char * const nand_ecc_opts[] = {
 - [OMAP_ECC_HAMMING_CODE_DEFAULT] = sw,
 - [OMAP_ECC_HAMMING_CODE_HW]  = hw,
 - [OMAP_ECC_HAMMING_CODE_HW_ROMCODE]  = hw-romcode,
 + [OMAP_ECC_HAM1_CODE_HW] = ham1,
   [OMAP_ECC_BCH4_CODE_HW] = bch4,
   [OMAP_ECC_BCH8_CODE_HW] = bch8,

Won't this break existing dts which have sw, hw, or hw-romcode?

Someone may try to use a new kernel with an old dt, and we marked them
as deprecated, not removed.

Thanks,
Mark.
--
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 2/6] ARM: OMAP2+: cleaned-up DT support of various ECC schemes

On Fri, Oct 04, 2013 at 08:49:44PM +0100, Pekon Gupta wrote:
 OMAP NAND driver support multiple ECC scheme, which can used in following
 different flavours, depending on in-build Hardware engines supported by SoC.
 
 +---+---+---+
 | ECC scheme|ECC calculation|Error detection|
 +---+---+---+
 |OMAP_ECC_HAM1_CODE_HW  |H/W (GPMC) |S/W|
 +---+---+---+
 |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
 |(requires CONFIG_MTD_NAND_ECC_BCH) |   |   |
 +---+---+---+
 |OMAP_ECC_BCH8_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
 |(requires CONFIG_MTD_NAND_OMAP_BCH   |   |   |
 | ti,elm-id in DT)  |   |   |
 +---+---+---+
 To optimize footprint of omap2-nand driver, selection of some ECC schemes
 also require enabling following Kconfigs, in addition to setting appropriate
 DT bindings
 - Kconfig:CONFIG_MTD_NAND_ECC_BCHerror detection done in software
 - Kconfig:CONFIG_MTD_NAND_OMAP_BCH   error detection done by h/w engine
 
 DT binding updates in this patch are:
 - ti,elm-id: replaces elm_id
 - ti,nand-ecc-opts: supported values ham1, bch4, and bch8
   selection of h/w or s/w implementation depends on ti,elm-id
 
 Signed-off-by: Pekon Gupta pe...@ti.com
 ---
  .../devicetree/bindings/mtd/gpmc-nand.txt  |  8 +++-
  arch/arm/mach-omap2/gpmc.c | 47 
 --
  include/linux/platform_data/mtd-nand-omap2.h   | 14 +--
  3 files changed, 52 insertions(+), 17 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
 b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 index 25ee232..7785666 100644
 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 @@ -36,8 +36,12 @@ Optional properties:
   prefetch-dma  Prefetch enabled sDMA mode
   prefetch-irq  Prefetch enabled irq mode
  
 - - elm_id:   Specifies elm device node. This is required to support BCH
 - error correction using ELM module.
 + - elm_id:   deprecated use ti,elm-id instead
 + - ti,elm-id:Specifies pHandle of the ELM devicetree node.

s/pHandle/phandle/

 + ELM is an on-chip hardware engine on TI SoC which is used for
 + locating ECC errors for BCHx algorithms. SoC devices which have
 + ELM hardware engines should specify this device node in .dtsi
 + Using ELM for ECC error correction frees some CPU cycles.
  
  For inline partiton table parsing (optional):
  
 diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
 index 1c45b72..5a607fa 100644
 --- a/arch/arm/mach-omap2/gpmc.c
 +++ b/arch/arm/mach-omap2/gpmc.c
 @@ -1341,12 +1341,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
 device_node *np,
  
  #ifdef CONFIG_MTD_NAND
  
 -static const char * const nand_ecc_opts[] = {
 - [OMAP_ECC_HAM1_CODE_HW] = ham1,
 - [OMAP_ECC_BCH4_CODE_HW] = bch4,
 - [OMAP_ECC_BCH8_CODE_HW] = bch8,
 -};
 -
  static const char * const nand_xfer_types[] = {
   [NAND_OMAP_PREFETCH_POLLED] = prefetch-polled,
   [NAND_OMAP_POLLED]  = polled,
 @@ -1361,6 +1355,8 @@ static int gpmc_probe_nand_child(struct platform_device 
 *pdev,
   const char *s;
   struct gpmc_timings gpmc_t;
   struct omap_nand_platform_data *gpmc_nand_data;
 + const __be32 *phandle;

I don't think you need this. With of_parse_phandle you should never need
to see the raw phandle value.

 + int lenp;
  
   if (of_property_read_u32(child, reg, val)  0) {
   dev_err(pdev-dev, %s has no 'reg' property\n,
 @@ -1376,12 +1372,39 @@ static int gpmc_probe_nand_child(struct 
 platform_device *pdev,
   gpmc_nand_data-cs = val;
   gpmc_nand_data-of_node = child;
  
 - if (!of_property_read_string(child, ti,nand-ecc-opt, s))
 - for (val = 0; val  ARRAY_SIZE(nand_ecc_opts); val++)
 - if (!strcasecmp(s, nand_ecc_opts[val])) {
 - gpmc_nand_data-ecc_opt = val;
 - break;
 - }
 + /* Detect availability of ELM module */
 + phandle = of_get_property(child, ti,elm-id, lenp);
 + if ((phandle == NULL) || (lenp != sizeof(void *))) {
 + pr_warn(%s: ti,elm-id property not found\n, __func__);
 + gpmc_nand_data-elm_of_node = NULL;
 + } else {
 + gpmc_nand_data-elm_of_node

Re: [PATCH v7 5/6] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt

On Fri, Oct 04, 2013 at 08:49:47PM +0100, Pekon Gupta wrote:
 DT property values for OMAP based gpmc-nand have been updated
 to match changes in commit:
   6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC schemes
 Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt

Doesn't this mean these dts were broken between the changes to the
driver and the changes to the dts?

I think the existing properties need to continue to be supoprted for
backwards compatibility. The dts can be fixed up to have the preferred
binding style, but they shouldn't _have_ to be modified to continue to
function...

Thanks,
Mark.

 
 Signed-off-by: Pekon Gupta pe...@ti.com
 ---
  arch/arm/boot/dts/am335x-evm.dts   | 3 +--
  arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
  2 files changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/boot/dts/am335x-evm.dts 
 b/arch/arm/boot/dts/am335x-evm.dts
 index e8ec875..1aee6ac 100644
 --- a/arch/arm/boot/dts/am335x-evm.dts
 +++ b/arch/arm/boot/dts/am335x-evm.dts
 @@ -269,7 +269,6 @@
   reg = 0 0 0; /* CS0, offset 0 */
   nand-bus-width = 8;
   ti,nand-ecc-opt = bch8;
 - gpmc,device-nand = true;
   gpmc,device-width = 1;
   gpmc,sync-clk-ps = 0;
   gpmc,cs-on-ns = 0;
 @@ -296,7 +295,7 @@
  
   #address-cells = 1;
   #size-cells = 1;
 - elm_id = elm;
 + ti,elm-id = elm;
  
   /* MTD partition table */
   partition@0 {
 diff --git a/arch/arm/boot/dts/omap3430-sdp.dts 
 b/arch/arm/boot/dts/omap3430-sdp.dts
 index e2249bc..501f863 100644
 --- a/arch/arm/boot/dts/omap3430-sdp.dts
 +++ b/arch/arm/boot/dts/omap3430-sdp.dts
 @@ -105,7 +105,7 @@
   reg = 1 0 0x0800;
   nand-bus-width = 8;
  
 - ti,nand-ecc-opt = sw;
 + ti,nand-ecc-opt = ham1;
   gpmc,cs-on-ns = 0;
   gpmc,cs-rd-off-ns = 36;
   gpmc,cs-wr-off-ns = 36;
 -- 
 1.8.1
 
 
--
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/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes

2013-10-07 Thread Gupta, Pekon

Hi,

 From: Mark Rutland [mailto:mark.rutl...@arm.com]
  On Fri, Oct 04, 2013 at 08:49:43PM +0100, Pekon Gupta wrote:
  OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
  ecc-scheme, like:
  - OMAP_ECC_HAMMING_CODE_DEFAULT
  1-bit hamming ecc code using software library
  - OMAP_ECC_HAMMING_CODE_HW
  1-bit hamming ecc-code using GPMC h/w engine
  - OMAP_ECC_HAMMING_CODE_HW_ROMCODE
  1-bit hamming ecc-code using GPMC h/w engin with ecc-layout
 compatible
  to ROM code.
 
  This patch combines above multiple ecc-schemes into single
 implementation:
  - OMAP_ECC_HAM1_CODE_HW
  1-bit hamming ecc-code using GPMC h/w engine with ROM-code
 compatible
  ecc-layout.
 
 If I have my NAND formatted with one of the existing ECC schemes (e.g.
 OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new
 OMAP_ECC_HAM1_CODE_HW scheme?
 
 Are they all compatible?
 
Yes, they all are 1-bit hamming code, the only difference between 
xx_Default and xx_HW was who was doing the ECC calculation.
For xx_DEFAULT: ECC calculation was done on CPU via s/w library
For xx_HW: ECC calculation was done by in-build h/w engine.
So, all HAMMING_xx can be replaced by HAM1_HW.

[snip]

  @@ -1342,9 +1342,7 @@ static void __maybe_unused
 gpmc_read_timings_dt(struct device_node *np,
   #ifdef CONFIG_MTD_NAND
 
   static const char * const nand_ecc_opts[] = {
  -   [OMAP_ECC_HAMMING_CODE_DEFAULT] = sw,
  -   [OMAP_ECC_HAMMING_CODE_HW]  = hw,
  -   [OMAP_ECC_HAMMING_CODE_HW_ROMCODE]  = hw-
 romcode,
  +   [OMAP_ECC_HAM1_CODE_HW] = ham1,
  [OMAP_ECC_BCH4_CODE_HW] = bch4,
  [OMAP_ECC_BCH8_CODE_HW] = bch8,
 
 Won't this break existing dts which have sw, hw, or hw-romcode?
 
 Someone may try to use a new kernel with an old dt, and we marked them
 as deprecated, not removed.
 
HAMMING_xx ECC scheme was used only on legacy platforms, when
BCH8 was not available, I have not seen anyone using this scheme
*from mainline kernel* from quite a long time. So, it's safe to remove them.

This is what was concluded as per below email.
http://lists.infradead.org/pipermail/linux-mtd/2013-September/048876.html

with regards, pekon
--
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 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

On 10/07/2013 12:42 PM, Roger Quadros wrote:
 On 10/07/2013 01:22 PM, Javier Martinez Canillas wrote:
 On Mon, Oct 7, 2013 at 11:13 AM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 On 10/07/2013 11:06 AM, Roger Quadros wrote:

 Well that's a very good question indeed.

 The thing is that the IGEP0030 is a Computer-on-Module [1] that is used in
 conjunction with expansion boards and some of them have USB HOST support 
 such as
 IGEP Paris [2] and IGEP Berlin [3].

 Support for this expansion boards is still not in mainline but there are 
 plans
 to add them using Device Tree overlays [4] once/if this land on mainline.


 Why would your boards need Device Tree overlays? From the looks of it, the 
 configuration
 of SOM + base board don't seem to change at runtime.


 Indeed, a static configuration (DTS) would be enough now that I think about 
 it.

 
 Hi Roger,
 
 Now that I had coffee I remember why I think that even when Device
 Tree overlays are not strictly required for a SOM + base board it
 could be handy to use. If we use a static configuration (DTB) then the
 same firmware can't be used by any IGEP COM Module user. She would
 have to choose a DTB to pass to the kernel on boot.
 
 While using DT overlays the same firmware that provides a minimal DTB
 can be used regardless of the base board used (as long as there are
 all the needed fragment/overlays hooks in the DTS).
 
 After all the SOM has a NAND flash memory and a uSD/MMC slot so a
 minimal DTB is needed to boot and the support for all the peripherals
 present on the base board can be added by triggering a device tree
 overlay load from user-space.
 
 Consider this example. You need to boot your board using NFS over ethernet
 dongle connected to USB host. If you need user space to get that to work,
 it will be a unnecessary challenge, whereas you can easily do that if you
 have a static DT blob.
 
 
 Or maybe I'm misunderstanding the use case for DT overlays since I had
 just read about it but I don't have practical experience with it.
 
 
 DT overlays is a solution to the problem faced by the beagle bone community.
 There they have a relatively large number of accessories (called capes).
 Since the capes don't use a dynamically probed interface like USB/MMC, 
 the hardware information needs to be hard coded somewhere and loaded
 into the DT at runtime whenever a new cape is connected.
 
 Using overlays for a SOM + base board architecture is an overkill IMO. A base 
 board
 is not an accessory, but the platform board itself, hence qualifies for it's 
 own
 dts file.
 
 It is much easier to use a base dts for the SOM which contains all the 
 information
 for the SOM and leaves the base board details to the base board specific dts.
 Each base board can be considered to be a extended variant of the SOM.
 
 cheers,
 -roger
 

Hi Roger,

Thanks a lot for the explanation, is very clear for me now.

Best regards,
Javier
--
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 1/3] ARM: dts: omap3-igep0020: Add USB OTG support

On 10/07/2013 12:43 PM, Roger Quadros wrote:
 Javier,
 
 On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:
 Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ 
 boards)
 added USB OTG support for most OMAP boards but some OMAP3 boards
 such as the IGEPv2 were not updated. This patch adds an USB OTG
 device node to this board.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/omap3-igep0020.dts | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
 b/arch/arm/boot/dts/omap3-igep0020.dts
 index eedf0d8..903e944 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -166,3 +166,10 @@
  smsc,save-mac-address;
  };
  };
 +
 +usb_otg_hs {
 +interface-type = 0;
 +usb-phy = usb2_phy;
 
 With the PHY generic framework in Greg's usb-next branch [1], you will also 
 need to add
 
 +   phys = usb2_phy;
 +   phy-names = usb2-phy;
 
 +mode = 3;
 +power = 50;
 +};
 
 
 So it would be good to test with the usb-next branch.
 
 cheers,
 -roger
 
 [1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
 

Hi Roger,

Thanks for the pointer, I'll add those properties and test using the PHY generic
framework.

Thanks a lot and best regards,
Javier

--
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 1/3] ARM: dts: omap3-igep0020: Add USB OTG support

2013-10-07 Thread Benoit Cousson


Hi Javier,

On 07/10/2013 13:54, Javier Martinez Canillas wrote:

On 10/07/2013 12:43 PM, Roger Quadros wrote:

Javier,

On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:

Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards)
added USB OTG support for most OMAP boards but some OMAP3 boards
such as the IGEPv2 were not updated. This patch adds an USB OTG
device node to this board.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
  arch/arm/boot/dts/omap3-igep0020.dts | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index eedf0d8..903e944 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -166,3 +166,10 @@
smsc,save-mac-address;
};
  };
+
+usb_otg_hs {
+   interface-type = 0;
+   usb-phy = usb2_phy;


With the PHY generic framework in Greg's usb-next branch [1], you will also 
need to add

+   phys = usb2_phy;
+   phy-names = usb2-phy;


+   mode = 3;
+   power = 50;
+};



So it would be good to test with the usb-next branch.

cheers,
-roger

[1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git



Hi Roger,

Thanks for the pointer, I'll add those properties and test using the PHY generic
framework.


Should I expect a v3 then?

Benoit



--
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 1/3] ARM: dts: omap3-igep0020: Add USB OTG support

On 10/07/2013 01:58 PM, Benoit Cousson wrote:
 Hi Javier,
 
 On 07/10/2013 13:54, Javier Martinez Canillas wrote:
 On 10/07/2013 12:43 PM, Roger Quadros wrote:
 Javier,

 On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:
 Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ 
 boards)
 added USB OTG support for most OMAP boards but some OMAP3 boards
 such as the IGEPv2 were not updated. This patch adds an USB OTG
 device node to this board.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
   arch/arm/boot/dts/omap3-igep0020.dts | 7 +++
   1 file changed, 7 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
 b/arch/arm/boot/dts/omap3-igep0020.dts
 index eedf0d8..903e944 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -166,3 +166,10 @@
smsc,save-mac-address;
};
   };
 +
 +usb_otg_hs {
 +  interface-type = 0;
 +  usb-phy = usb2_phy;

 With the PHY generic framework in Greg's usb-next branch [1], you will also 
 need to add

 +   phys = usb2_phy;
 +   phy-names = usb2-phy;

 +  mode = 3;
 +  power = 50;
 +};


 So it would be good to test with the usb-next branch.

 cheers,
 -roger

 [1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git


 Hi Roger,

 Thanks for the pointer, I'll add those properties and test using the PHY 
 generic
 framework.
 
 Should I expect a v3 then?
 

Hi Benoit,

Yes, I'll test it and send a v3 in the next few hours, sorry for not being clear
about that.

 Benoit
 
 
 

Best regards,
Javier

--
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 1/3] ARM: dts: omap3-igep0020: Add USB OTG support

2013-10-07 Thread Benoit Cousson


On 07/10/2013 14:02, Javier Martinez Canillas wrote:

On 10/07/2013 01:58 PM, Benoit Cousson wrote:

Hi Javier,

On 07/10/2013 13:54, Javier Martinez Canillas wrote:

On 10/07/2013 12:43 PM, Roger Quadros wrote:

Javier,

On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:

Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards)
added USB OTG support for most OMAP boards but some OMAP3 boards
such as the IGEPv2 were not updated. This patch adds an USB OTG
device node to this board.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
   arch/arm/boot/dts/omap3-igep0020.dts | 7 +++
   1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index eedf0d8..903e944 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -166,3 +166,10 @@
smsc,save-mac-address;
};
   };
+
+usb_otg_hs {
+   interface-type = 0;
+   usb-phy = usb2_phy;


With the PHY generic framework in Greg's usb-next branch [1], you will also 
need to add

+   phys = usb2_phy;
+   phy-names = usb2-phy;


+   mode = 3;
+   power = 50;
+};



So it would be good to test with the usb-next branch.

cheers,
-roger

[1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git



Hi Roger,

Thanks for the pointer, I'll add those properties and test using the PHY generic
framework.


Should I expect a v3 then?



Hi Benoit,

Yes, I'll test it and send a v3 in the next few hours, sorry for not being clear
about that.



That's OK, I was applying your series when I saw your email ;-)

I'm waiting for the next one.

Thanks,
Benoit

--
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 5/6] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt

2013-10-07 Thread Gupta, Pekon

 From: Mark Rutland [mailto:mark.rutl...@arm.com]
  On Fri, Oct 04, 2013 at 08:49:47PM +0100, Pekon Gupta wrote:
  DT property values for OMAP based gpmc-nand have been updated
  to match changes in commit:
  6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC
 schemes
  Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 
Sorry that's an old commit. I probably missed out updating the commit log.
So please ignore it here, I should remove that from commit log.


 Doesn't this mean these dts were broken between the changes to the
 driver and the changes to the dts?
 
But the DTS updates are kept separate from driver updates because
- DTS updates go into Benoit's tree or Tony's tree
- whereas driver updates go into MTD tree.
So, it was suggested in earlier patch revisions that I keep the driver
and the DTS patches separate, so that there is no merge conflict
between the trees when they are finally accepted.


 I think the existing properties need to continue to be supoprted for
 backwards compatibility. The dts can be fixed up to have the preferred
 binding style, but they shouldn't _have_ to be modified to continue to
 function...
 
However, there should be a way to remove legacy code which can
no longer be maintained. Here following ecc-schemes are such
legacy code, which are neither supported nor encouraged
to use since long time.
- OMAP_ECC_CODE_HAMMING_HW,
- OMAP_ECC_CODE_HAMMING_DEFAULT,
- OMAP_ECC_CODE_HAMMING_HW_ROMCODE

Also backward compatibility is maintained by keeping a common
symbol for all 3 above implementations OMAP_ECC_CODE_HAM1_HW
I don't think there is a point to continue keeping these  symbols
in kernel driver if they are unused, and make driver bulky and unreadable.

In actual it shouldn't matter to user what symbols I use inside
the driver, what matters is backward compatibility right ?


with regards, pekon
--
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 2/6] ARM: OMAP2+: cleaned-up DT support of various ECC schemes

2013-10-07 Thread Gupta, Pekon

 From: Mark Rutland [mailto:mark.rutl...@arm.com]
  On Fri, Oct 04, 2013 at 08:49:44PM +0100, Pekon Gupta wrote:

 [snip]

 
  diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-
 omap2/gpmc.c
  index 1c45b72..5a607fa 100644
  --- a/arch/arm/mach-omap2/gpmc.c
  +++ b/arch/arm/mach-omap2/gpmc.c
  @@ -1341,12 +1341,6 @@ static void __maybe_unused
 gpmc_read_timings_dt(struct device_node *np,
 
   #ifdef CONFIG_MTD_NAND
 
  -static const char * const nand_ecc_opts[] = {
  -   [OMAP_ECC_HAM1_CODE_HW] = ham1,
  -   [OMAP_ECC_BCH4_CODE_HW] = bch4,
  -   [OMAP_ECC_BCH8_CODE_HW] = bch8,
  -};
  -
   static const char * const nand_xfer_types[] = {
  [NAND_OMAP_PREFETCH_POLLED] = prefetch-polled,
  [NAND_OMAP_POLLED]  = polled,
  @@ -1361,6 +1355,8 @@ static int gpmc_probe_nand_child(struct
 platform_device *pdev,
  const char *s;
  struct gpmc_timings gpmc_t;
  struct omap_nand_platform_data *gpmc_nand_data;
  +   const __be32 *phandle;
 
 I don't think you need this. With of_parse_phandle you should never need
 to see the raw phandle value.
 
  +   int lenp;
 
  if (of_property_read_u32(child, reg, val)  0) {
  dev_err(pdev-dev, %s has no 'reg' property\n,
  @@ -1376,12 +1372,39 @@ static int gpmc_probe_nand_child(struct
 platform_device *pdev,
  gpmc_nand_data-cs = val;
  gpmc_nand_data-of_node = child;
 
  -   if (!of_property_read_string(child, ti,nand-ecc-opt, s))
  -   for (val = 0; val  ARRAY_SIZE(nand_ecc_opts); val++)
  -   if (!strcasecmp(s, nand_ecc_opts[val])) {
  -   gpmc_nand_data-ecc_opt = val;
  -   break;
  -   }
  +   /* Detect availability of ELM module */
  +   phandle = of_get_property(child, ti,elm-id, lenp);
  +   if ((phandle == NULL) || (lenp != sizeof(void *))) {
  +   pr_warn(%s: ti,elm-id property not found\n, __func__);
  +   gpmc_nand_data-elm_of_node = NULL;
  +   } else {
  +   gpmc_nand_data-elm_of_node =
  +
   of_find_node_by_phandle(be32_to_cpup(phandle));
  +   }
 
 Use of_parse_handle rather than open-coding it:
 
   gpmc_nand_data-elm_of_node =
   of_parse_phandle(child, ti,elm-id, 0);
 
 Was elm_id ever handled previously? I don't see any code handling it
 being remove or modified.
 
Yes, this piece of code has been moved from omap2.c (nand-driver)
to gpmc.c (GPMC driver), so as to perform all DT related parsing
at single place.  
This change was needed as per feedbacks from Olof to simply
DT bindings so that they include only H/W related stuff.

Please refer omap2.c: omap3_init_bch() in [PATCH 3/6] of same series
where 'elm_id' DT parsing was original present.
-   /* Detect availability of ELM module */
-   parp = of_get_property(info-of_node, elm_id, lenp);
-   if ((parp == NULL)  (lenp != (sizeof(void *) * 2))) {
-   pr_err(Missing elm_id property, fall back to Software BCH\n);
-   info-is_elm_used = false;
-   } else {
-   struct platform_device *pdev;
-
-   elm_node = of_find_node_by_phandle(be32_to_cpup(parp));
-   pdev = of_find_device_by_node(elm_node);
-   info-elm_dev = pdev-dev;
-
-   if (elm_config(info-elm_dev, bch_type) == 0)
-   info-is_elm_used = true;



with regards, pekon
--
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/1] Possibly fix USB OTG on GTA04 and N900

Hi,

USB OTG on these boards might be broken on Greg's usb-next branch [1]
after the Generic PHY framework and associated patches were merged.

This is a probable fix but I'm not able to test these boards. Please
give it a try and your Ack if it works. Thanks.

[1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

cheers,
-roger

Roger Quadros (1):
  ARM: dts: omap3:  Adapt USB OTG to generic PHY framework

 arch/arm/boot/dts/omap3-gta04.dts |2 ++
 arch/arm/boot/dts/omap3-n900.dts  |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

-- 
1.7.4.1

--
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/1] ARM: dts: omap3: Adapt USB OTG to generic PHY framework

The generic PHY framewrok expects different properties than the
old USB PHY framework. Supply those properties.

Fixes USB OTG port on GAT04 and N900 after the Generic PHY framework was
merged in greg/usb-next. [1]

[1] - https://lkml.org/lkml/2013/9/27/581

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap3-gta04.dts |2 ++
 arch/arm/boot/dts/omap3-n900.dts  |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index a84684a..b9b55c9 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -131,6 +131,8 @@
 usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
mode = 3;
power = 50;
 };
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index d64fa04..e13b697 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -87,6 +87,8 @@
 usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
mode = 2;
power = 50;
 };
-- 
1.7.4.1

--
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 1/1] ARM: dts: omap3: Adapt USB OTG to generic PHY framework

2013-10-07 Thread Sebastian Andrzej Siewior

On 10/07/2013 03:28 PM, Roger Quadros wrote:
 The generic PHY framewrok expects different properties than the
 old USB PHY framework. Supply those properties.
 
 Fixes USB OTG port on GAT04 and N900 after the Generic PHY framework was
 merged in greg/usb-next. [1]

Would it be much pain (and do we want this at all) to add a fallback
into the kernel or at least a printk pointing out to update the .dts
for two releases or so? So the user does not need to spent hours to
figure out why it suddenly stopped working.

Sebastian
--
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 1/1] ARM: dts: omap3: Adapt USB OTG to generic PHY framework

On 10/07/2013 04:40 PM, Sebastian Andrzej Siewior wrote:
 On 10/07/2013 03:28 PM, Roger Quadros wrote:
 The generic PHY framewrok expects different properties than the
 old USB PHY framework. Supply those properties.

 Fixes USB OTG port on GAT04 and N900 after the Generic PHY framework was
 merged in greg/usb-next. [1]
 
 Would it be much pain (and do we want this at all) to add a fallback
 into the kernel or at least a printk pointing out to update the .dts
 for two releases or so? So the user does not need to spent hours to
 figure out why it suddenly stopped working.
 

I agree with you. 

Also, figuring out which kernel configs to enable for
USB OTG to work on OMAP is a pain in itself to the user.

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 v4 3/4] v4l: ti-vpe: Add VPE mem to mem driver

On 10/07/2013 12:22 PM, Archit Taneja wrote:
 On Monday 07 October 2013 03:04 PM, Hans Verkuil wrote:
 On 10/07/2013 11:16 AM, Archit Taneja wrote:
 On Monday 07 October 2013 01:25 PM, Hans Verkuil wrote:
 Hi Archit,

 I've got a few comments below...

 On 09/06/2013 12:12 PM, Archit Taneja wrote:
 VPE is a block which consists of a single memory to memory path which can
 perform chrominance up/down sampling, de-interlacing, scaling, and color 
 space
 conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
 interleaved video formats.

 We create a mem2mem driver based primarily on the mem2mem-testdev example.
 The de-interlacer, scaler and color space converter are all bypassed for 
 now
 to keep the driver simple. Chroma up/down sampler blocks are implemented, 
 so
 conversion beteen different YUV formats is possible.

 Each mem2mem context allocates a buffer for VPE MMR values which it will 
 use
 when it gets access to the VPE HW via the mem2mem queue, it also allocates
 a VPDMA descriptor list to which configuration and data descriptors are 
 added.

 Based on the information received via v4l2 ioctls for the source and
 destination queues, the driver configures the values for the MMRs, and 
 stores
 them in the buffer. There are also some VPDMA parameters like frame start 
 and
 line mode which needs to be configured, these are configured by direct 
 register
 writes via the VPDMA helper functions.

 The driver's device_run() mem2mem op will add each descriptor based on 
 how the
 source and destination queues are set up for the given ctx, once the list 
 is
 prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA 
 will
 upload MMR registers, start DMA of video buffers on the various input and 
 output
 clients/ports.

 When the list is parsed completely(and the DMAs on all the output ports 
 done),
 an interrupt is generated which we use to notify that the source and 
 destination
 buffers are done.

 The rest of the driver is quite similar to other mem2mem drivers, we use 
 the
 multiplane v4l2 ioctls as the HW support coplanar formats.

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
drivers/media/platform/Kconfig   |   16 +
drivers/media/platform/Makefile  |2 +
drivers/media/platform/ti-vpe/Makefile   |5 +
drivers/media/platform/ti-vpe/vpe.c  | 1750 
 ++
drivers/media/platform/ti-vpe/vpe_regs.h |  496 +
include/uapi/linux/v4l2-controls.h   |4 +
6 files changed, 2273 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/Makefile
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h


 snip

 +
 +static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format 
 *f)
 +{
 + struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
 + struct vpe_ctx *ctx = file2ctx(file);
 + struct vb2_queue *vq;
 + struct vpe_q_data *q_data;
 + int i;
 +
 + vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
 + if (!vq)
 + return -EINVAL;
 +
 + q_data = get_q_data(ctx, f-type);
 +
 + pix-width = q_data-width;
 + pix-height = q_data-height;
 + pix-pixelformat = q_data-fmt-fourcc;
 + pix-colorspace = q_data-colorspace;
 + pix-num_planes = q_data-fmt-coplanar ? 2 : 1;
 +
 + for (i = 0; i  pix-num_planes; i++) {
 + pix-plane_fmt[i].bytesperline = q_data-bytesperline[i];
 + pix-plane_fmt[i].sizeimage = q_data-sizeimage[i];
 + }
 +
 + return 0;
 +}
 +
 +static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
 +struct vpe_fmt *fmt, int type)
 +{
 + struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
 + struct v4l2_plane_pix_format *plane_fmt;
 + int i;
 +
 + if (!fmt || !(fmt-types  type)) {
 + vpe_err(ctx-dev, Fourcc format (0x%08x) invalid.\n,
 + pix-pixelformat);
 + return -EINVAL;
 + }
 +
 + pix-field = V4L2_FIELD_NONE;
 +
 + v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
 +   pix-height, MIN_H, MAX_H, H_ALIGN,
 +   S_ALIGN);
 +
 + pix-num_planes = fmt-coplanar ? 2 : 1;
 + pix-pixelformat = fmt-fourcc;
 + pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?

 You do this only for capture. Output sets the colorspace, so try_fmt should
 leave the colorspace field untouched for the output direction.

 + V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;

 The input to the VPE block can be various YUV formats, and the VPE can
 generate both RGB and YUV formats.

 So, I guess the output(V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) side has
 choice only to set V4L2_COLORSPACE_SMPTE170M. And in the
 capture(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) capture side we have both
 SRG and SMPTE170M options.

 One thing I am not clear about is whether the userspace application has
 to set the colorspace in the v4l2 format for OUTPUT or CAPTURE or both?

 The spec today says that the colorspace field

Re: [PATCH v4 3/4] v4l: ti-vpe: Add VPE mem to mem driver


On Monday 07 October 2013 07:32 PM, Hans Verkuil wrote:

On 10/07/2013 12:22 PM, Archit Taneja wrote:

On Monday 07 October 2013 03:04 PM, Hans Verkuil wrote:

On 10/07/2013 11:16 AM, Archit Taneja wrote:

On Monday 07 October 2013 01:25 PM, Hans Verkuil wrote:

Hi Archit,

I've got a few comments below...

On 09/06/2013 12:12 PM, Archit Taneja wrote:

VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.

We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.

Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are added.

Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and stores
them in the buffer. There are also some VPDMA parameters like frame start and
line mode which needs to be configured, these are configured by direct register
writes via the VPDMA helper functions.

The driver's device_run() mem2mem op will add each descriptor based on how the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
upload MMR registers, start DMA of video buffers on the various input and output
clients/ports.

When the list is parsed completely(and the DMAs on all the output ports done),
an interrupt is generated which we use to notify that the source and destination
buffers are done.

The rest of the driver is quite similar to other mem2mem drivers, we use the
multiplane v4l2 ioctls as the HW support coplanar formats.

Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/Kconfig   |   16 +
drivers/media/platform/Makefile  |2 +
drivers/media/platform/ti-vpe/Makefile   |5 +
drivers/media/platform/ti-vpe/vpe.c  | 1750 
++
drivers/media/platform/ti-vpe/vpe_regs.h |  496 +
include/uapi/linux/v4l2-controls.h   |4 +
6 files changed, 2273 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/Makefile
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h



snip


+
+static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
+   struct vpe_ctx *ctx = file2ctx(file);
+   struct vb2_queue *vq;
+   struct vpe_q_data *q_data;
+   int i;
+
+   vq = v4l2_m2m_get_vq(ctx-m2m_ctx, f-type);
+   if (!vq)
+   return -EINVAL;
+
+   q_data = get_q_data(ctx, f-type);
+
+   pix-width = q_data-width;
+   pix-height = q_data-height;
+   pix-pixelformat = q_data-fmt-fourcc;
+   pix-colorspace = q_data-colorspace;
+   pix-num_planes = q_data-fmt-coplanar ? 2 : 1;
+
+   for (i = 0; i  pix-num_planes; i++) {
+   pix-plane_fmt[i].bytesperline = q_data-bytesperline[i];
+   pix-plane_fmt[i].sizeimage = q_data-sizeimage[i];
+   }
+
+   return 0;
+}
+
+static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
+  struct vpe_fmt *fmt, int type)
+{
+   struct v4l2_pix_format_mplane *pix = f-fmt.pix_mp;
+   struct v4l2_plane_pix_format *plane_fmt;
+   int i;
+
+   if (!fmt || !(fmt-types  type)) {
+   vpe_err(ctx-dev, Fourcc format (0x%08x) invalid.\n,
+   pix-pixelformat);
+   return -EINVAL;
+   }
+
+   pix-field = V4L2_FIELD_NONE;
+
+   v4l_bound_align_image(pix-width, MIN_W, MAX_W, W_ALIGN,
+ pix-height, MIN_H, MAX_H, H_ALIGN,
+ S_ALIGN);
+
+   pix-num_planes = fmt-coplanar ? 2 : 1;
+   pix-pixelformat = fmt-fourcc;
+   pix-colorspace = fmt-fourcc == V4L2_PIX_FMT_RGB24 ?


You do this only for capture. Output sets the colorspace, so try_fmt should
leave the colorspace field untouched for the output direction.


+   V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;


The input to the VPE block can be various YUV formats, and the VPE can
generate both RGB and YUV formats.

So, I guess the output(V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) side has
choice only to set V4L2_COLORSPACE_SMPTE170M. And in the
capture(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) capture side we have both
SRG and SMPTE170M options.

One thing I am not clear about is

[PATCH v3 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

Add device nodes for the HS USB Host port 1, USB PHY and its
required regulator and also pin mux setup for HS USB1 pins.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Acked-by: Roger Quadros rog...@ti.com
---

Changes since v2:
 - None

Changes since v1:
 - Add HST USB port 1 pinmux setup in omap3-igep0020 instead of
   omap3-igep.dtsi since is not used by IGEP COM; suggested by Roger Quadros

 arch/arm/boot/dts/omap3-igep0020.dts | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index eedf0d8..35346f2 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -55,6 +55,47 @@
regulator-name = vdd33a;
regulator-always-on;
};
+
+   /* HS USB Port 1 Power */
+   hsusb1_power: hsusb1_power_reg {
+   compatible = regulator-fixed;
+   regulator-name = hsusb1_vbus;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   gpio = twl_gpio 18 GPIO_ACTIVE_LOW;  /* GPIO LEDA */
+   startup-delay-us = 7;
+   };
+
+   /* HS USB Host PHY on PORT 1 */
+   hsusb1_phy: hsusb1_phy {
+   compatible = usb-nop-xceiv;
+   reset-gpios = gpio1 24 GPIO_ACTIVE_LOW; /* gpio_24 */
+   vcc-supply = hsusb1_power;
+   };
+};
+
+omap3_pmx_core {
+   pinctrl-names = default;
+   pinctrl-0 = 
+   hsusbb1_pins
+   ;
+
+   hsusbb1_pins: pinmux_hsusbb1_pins {
+   pinctrl-single,pins = 
+   0x5aa (PIN_OUTPUT | MUX_MODE3)  /* 
etk_ctl.hsusb1_clk */
+   0x5a8 (PIN_OUTPUT | MUX_MODE3)  /* 
etk_clk.hsusb1_stp */
+   0x5bc (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d8.hsusb1_dir */
+   0x5be (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d9.hsusb1_nxt */
+   0x5ac (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d0.hsusb1_data0 */
+   0x5ae (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d1.hsusb1_data1 */
+   0x5b0 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d2.hsusb1_data2 */
+   0x5b2 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d3.hsusb1_data7 */
+   0x5b4 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d4.hsusb1_data4 */
+   0x5b6 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d5.hsusb1_data5 */
+   0x5b8 (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d6.hsusb1_data6 */
+   0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3)  /* 
etk_d7.hsusb1_data3 */
+   ;
+   };
 };
 
 leds_pins {
@@ -166,3 +207,11 @@
smsc,save-mac-address;
};
 };
+
+usbhshost {
+   port1-mode = ehci-phy;
+};
+
+usbhsehci {
+   phys = hsusb1_phy;
+};
-- 
1.8.4.rc3

--
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 0/3] ARM: dts: omap3-igep: improvements for v3.13

Hi Benoit,

This series are some enhancements and cleanups for IGEP boards
that it would be great if can make it for v3.13.

This is a third version of the patch-set that addresses some issues
raised by Roger Quadros and is composed of the following patches:

[PATCH v3 1/3] ARM: dts: omap3-igep: Add USB OTG support
[PATCH v3 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support
[PATCH v3 3/3] ARM: dts: omap3-igep0020: use standard constant for IRQ

The patches were tested using the new generic PHY framework that are
currently on usb-next branch and will be part of v3.13

Thanks a lot and best regards,
Javier
--
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 3/3] ARM: dts: omap3-igep0020: use standard constant for IRQ flags

Commit 840ef8b7 (ARM: dt: add header to define IRQ flags) added
constants for IRQ edge/level triggered types so use it instead of
a magic number to enhance the DT readability.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Changes since v2:
 - None

Changes since v1:
 - None

 arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index 35346f2..750ce84 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -199,7 +199,7 @@
gpmc,cycle2cycle-diffcsen;
 
interrupt-parent = gpio6;
-   interrupts = 16 8;
+   interrupts = 16 IRQ_TYPE_LEVEL_LOW;
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
reg-io-width = 4;
-- 
1.8.4.rc3

--
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 1/3] ARM: dts: omap3-igep: Add USB OTG support

Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to O
added USB OTG support for most OMAP boards but some OMAP3 boards
such as IGEP boards were not updated. This patch adds an USB OTG
device node to these board.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---

Changes since v2:
 - Add phys and phy-names properties as required by the new
   generic PHY framework; suggested by Roger Quadros

Changes since v1:
 - Add USB OTG support for both IGEPv2 and IGEP COM and not only to IGEPv2 

 arch/arm/boot/dts/omap3-igep.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index 0f92224..ba1e58b 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -143,3 +143,12 @@
 twl_gpio {
ti,use-leds;
 };
+
+usb_otg_hs {
+   interface-type = 0;
+   usb-phy = usb2_phy;
+   phys = usb2_phy;
+   phy-names = usb2-phy;
+   mode = 3;
+   power = 50;
+};
-- 
1.8.4.rc3

--
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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT

* Tero Kristo t-kri...@ti.com [131006 23:43]:
On 10/07/2013 05:15 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [131004 08:42]:
Hi,

Just a gentle reminder, anybody have any comments on this series or
should we start queuing stuff?

Well omap4 seems to work for me just fine, and omap3 in legacy
mode. But looks like omap3 device tree based booting is breaking
after I pulled in your test branch. I get the following on
3630 based dm3730.

Uart4 breaks because of the issue with basic DT blobs. You need at
least this patch:

http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-ARM-OMAP3630-Add-generic-machine-descriptor-td722791.html

... from Nishanth to get it to work right. Otherwise the clock init
tries to use omap3430 clock data for omap3630 which leaves uart4
nodes out.

OK thanks yes that solves it, I was missing the compatible flag
for my not quite ready test boards (3730-evm and zoom3).
I'll apply Nishant's fix with some changes.

Then for this series, once you have the necessary acks, can you
please split into following two separate immutable branches
against v3.12-rc3:

1. clock code changes

2. dts changes

Then those can be pulled in as needed by Benoit, Mike and I.

For the whole series, I think this quite nicely removes some
nasty kernel data dependencies for omaps, so feel free to add:

Acked-by: Tony Lindgren t...@atomide.com

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 1/3] ARM: dts: omap3-igep0020: Add USB OTG support

On Mon, Oct 7, 2013 at 2:09 PM, Benoit Cousson bcous...@baylibre.com wrote:
 On 07/10/2013 14:02, Javier Martinez Canillas wrote:

 On 10/07/2013 01:58 PM, Benoit Cousson wrote:

 Hi Javier,

 On 07/10/2013 13:54, Javier Martinez Canillas wrote:

 On 10/07/2013 12:43 PM, Roger Quadros wrote:

 Javier,

 On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:

 Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+
 boards)
 added USB OTG support for most OMAP boards but some OMAP3 boards
 such as the IGEPv2 were not updated. This patch adds an USB OTG
 device node to this board.

 Signed-off-by: Javier Martinez Canillas
 javier.marti...@collabora.co.uk
 ---
arch/arm/boot/dts/omap3-igep0020.dts | 7 +++
1 file changed, 7 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
 b/arch/arm/boot/dts/omap3-igep0020.dts
 index eedf0d8..903e944 100644
 --- a/arch/arm/boot/dts/omap3-igep0020.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020.dts
 @@ -166,3 +166,10 @@
 smsc,save-mac-address;
 };
};
 +
 +usb_otg_hs {
 +   interface-type = 0;
 +   usb-phy = usb2_phy;


 With the PHY generic framework in Greg's usb-next branch [1], you will
 also need to add

 +   phys = usb2_phy;
 +   phy-names = usb2-phy;

 +   mode = 3;
 +   power = 50;
 +};


 So it would be good to test with the usb-next branch.

 cheers,
 -roger

 [1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git


 Hi Roger,

 Thanks for the pointer, I'll add those properties and test using the PHY
 generic
 framework.


 Should I expect a v3 then?


 Hi Benoit,

 Yes, I'll test it and send a v3 in the next few hours, sorry for not being
 clear
 about that.



 That's OK, I was applying your series when I saw your email ;-)


Yes, fortunately Roger pointed out that OMAP otg device node required additional
properties to work with the new generic PHY framework that will land on v3.13.
Otherwise it would only work until Greg send his pull request to Linus :)

 I'm waiting for the next one.


Great, I had already sent the v3 [1] that has the necessary changes for the PHY
framework and tested it using usb-next

 Thanks,
 Benoit


Thanks a lot and best regards,
Javier

[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg96583.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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT

On 10/07/2013 10:41 AM, Tony Lindgren wrote:
 * Tero Kristo t-kri...@ti.com [131006 23:43]:
 On 10/07/2013 05:15 AM, Tony Lindgren wrote:
 * Tero Kristo t-kri...@ti.com [131004 08:42]:
 Hi,

 Just a gentle reminder, anybody have any comments on this series or
 should we start queuing stuff?

 Well omap4 seems to work for me just fine, and omap3 in legacy
 mode. But looks like omap3 device tree based booting is breaking
 after I pulled in your test branch. I get the following on
 3630 based dm3730.

 Uart4 breaks because of the issue with basic DT blobs. You need at
 least this patch:

 http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-ARM-OMAP3630-Add-generic-machine-descriptor-td722791.html

 ... from Nishanth to get it to work right. Otherwise the clock init
 tries to use omap3430 clock data for omap3630 which leaves uart4
 nodes out.
 
 OK thanks yes that solves it, I was missing the compatible flag
 for my not quite ready test boards (3730-evm and zoom3).
 I'll apply Nishant's fix with some changes.
 
I will post out an RFC based on Olof's suggestion in a few mins. will
be nice to see any deltas needed.


-- 
Regards,
Nishanth Menon
--
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 v2 1/2] ARM: dts: dra7-evm: Add mmc1 node for micro-sd support

2013-10-07 Thread Balaji T K

Add mmc1 dt node to dra7-evm board.
Input for ldo1 regulator is controlled by gpio 5 of pcf8575 chip (0x21)
on i2c1 bus. When dt support for gpio-pcf857x is available, input supply
will be modelled as cascaded regulator.

Signed-off-by: Balaji T K balaj...@ti.com
---
Rebase to for_3.13/dts

 arch/arm/boot/dts/dra7-evm.dts |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index fbbe406..65cd15a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -250,3 +250,9 @@
pinctrl-names = default;
pinctrl-0 = uart3_pins;
 };
+
+mmc1 {
+   status = okay;
+   vmmc-supply = ldo1_reg;
+   bus-width = 4;
+};
-- 
1.7.5.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 2/2] ARM: dts: dra7-evm: Add mmc2 node for eMMC support

2013-10-07 Thread Balaji T K

Add mmc2 dt node to dra7-evm board
and model eMMC vcc as fixed regulator.

Signed-off-by: Balaji T K balaj...@ti.com
---
Rebase to for_3.13/dts
and removed ti,non-removable

 arch/arm/boot/dts/dra7-evm.dts |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 65cd15a..3abf5f4 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,13 @@
device_type = memory;
reg = 0x8000 0x6000; /* 1536 MB */
};
+
+   mmc2_3v3: fixedregulator-mmc2 {
+   compatible = regulator-fixed;
+   regulator-name = mmc2_3v3;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   };
 };
 
 dra7_pmx_core {
@@ -256,3 +263,9 @@
vmmc-supply = ldo1_reg;
bus-width = 4;
 };
+
+mmc2 {
+   status = okay;
+   vmmc-supply = mmc2_3v3;
+   bus-width = 8;
+};
-- 
1.7.5.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: [RFC] ARM: kernel: irq: Simplify allocation of stack frame

2013-10-07 Thread Joel Fernandes

On 10/06/2013 05:41 PM, Russell King - ARM Linux wrote:
 On Sun, Oct 06, 2013 at 05:30:47PM -0500, Joel Fernandes wrote:
 On receiving IRQ exception in SVC mode, all the SVC mode registers are saved
 onto the stack very early on.

 The stack frame allocation code for IRQ entry during SVC mode (svc_entry) is
 hard to read as 4-less is allocated initially only to be allocated later
 implicity using the mov r3, [sp, #-4]! instruction. We make code easier to 
 read
 by allocating the 4 bytes on the stack frame in the beginning itself and 
 remove
 all instances where 4 bytes is adjusted.
 
 You omit to say that this results in saving one additional register
 unnecessarily in the stmia.  We could use a stmib there instead which
 would avoid that issue while keeping the rest of the change.
 

Hi Russel,

BTW I used ETM to check the number of cycles used to store the extra register
with and without this patch and with both cases it takes 7 cycles.

My platform uses Cortex-A8 (AM335x SoC).

Thanks,

-Joel
--
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/2] ARM: dts: omap3-beagle: use 3630 definitions

beagle-xm currently would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. So add
compatiblity for 3630 to allow match

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0f7cfc5..2079e22 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
 
 / {
model = TI OMAP3 BeagleBoard xM;
-   compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+   compatible = ti,omap3-beagle-xm, ti,omap363x, ti,omap3-beagle, 
ti,omap3;
 
cpus {
cpu@0 {
-- 
1.7.9.5

--
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/2] ARM: dts: OMAP: standardize SoC specific bindings

This is a respin of [1] based on of Olof's comments to introduce a
generic SoC binding. This standardizes the binding definitions for
SoCs based on existing implied bindings and based on existing usage
in arch/arm/mach-omap2/soc.h. Eventually we should be able to get rid
of soc_is_xyz() functions and allow machine descriptors to seamlessly
handle the deltas.

The series is based on [2] and was triggered primarily due to the bug
seen with [3] - clock dts conversion.

Nishanth Menon (2):
  Documentation: dt: OMAP: standardize SoC naming definition
  ARM: dts: omap3-beagle: use 3630 definitions

 .../devicetree/bindings/arm/omap/omap.txt  |   45 
 arch/arm/boot/dts/omap3-beagle-xm.dts  |2 +-
 arch/arm/mach-omap2/board-generic.c|   23 ++
 3 files changed, 69 insertions(+), 1 deletion(-)

[1] https://patchwork.kernel.org/patch/2919661/
[2] 
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
[3] http://marc.info/?t=13800989941r=1w=2
-- 
1.7.9.5

--
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/2] Documentation: dt: OMAP: standardize SoC naming definition

SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.

Eventually, we will have descriptors match only with SoC types and
should not contain anything specific to board handling.

Signed-off-by: Nishanth Menon n...@ti.com
---
 .../devicetree/bindings/arm/omap/omap.txt  |   45 
 arch/arm/mach-omap2/board-generic.c|   23 ++
 2 files changed, 68 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 91b7049..28b20a2 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -30,6 +30,51 @@ spinlock@1 {
 ti,hwmods = spinlock;
 };
 
+SoC Type(optional):
+- ti,gp- General Purpose devices
+- ti,hs- High Security devices
+
+SoC Families:
+
+- OMAP2 generic - defaults to OMAP2420
+  compatible = ti,omap2
+- OMAP3 generic - defaults to OMAP3430
+  compatible = ti,omap3
+- OMAP4 generic - defaults to OMAP4430
+  compatible = ti,omap4
+- OMAP5 generic - defaults to OMAP5430
+  compatible = ti,omap5
+- DRA7 generic - defaults to DRA742
+  compatible = ti,dra7
+- AM43x generic - defaults to AM437x
+  compatible = ti,am43
+
+SoCs:
+
+- OMAP2420
+  compatible = ti,omap2420, ti,omap2
+- OMAP2430
+  compatible = ti,omap2430, ti,omap2
+
+- OMAP3430
+  compatible = ti,omap343x, ti,omap3
+- OMAP3630
+  compatible = ti,omap363x, ti,omap3
+- AM33xx
+  compatible = ti,am33xx, ti,omap3
+
+- OMAP4430
+  compatible = ti,omap443x, ti,omap4
+- OMAP4460
+  compatible = ti,omap446x, ti,omap4
+
+- OMAP5430
+  compatible = ti,omap5430, ti,omap5
+- OMAP5432
+  compatible = ti,omap5432, ti,omap5
+
+- DRA742
+  compatible = ti,dra7xx, ti,dra7
 
 Boards:
 
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..c78b070 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
 #ifdef CONFIG_ARCH_OMAP3
 static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+   ti,omap343x,
NULL,
 };
 
@@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened 
Device Tree))
.restart= omap3xxx_restart,
 MACHINE_END
 
+static const char *omap36xx_boards_compat[] __initdata = {
+   ti,omap363x,
+   NULL,
+};
+
+DT_MACHINE_START(OMAP36xx_DT, Generic OMAP363x (Flattened Device Tree))
+   .reserve= omap_reserve,
+   .map_io = omap3_map_io,
+   .init_early = omap3630_init_early,
+   .init_irq   = omap_intc_of_init,
+   .handle_irq = omap3_intc_handle_irq,
+   .init_machine   = omap_generic_init,
+   .init_late  = omap3_init_late,
+   .init_time  = omap3_sync32k_timer_init,
+   .dt_compat  = omap36xx_boards_compat,
+   .restart= omap3xxx_restart,
+MACHINE_END
+
 static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
timll,omap3-devkit8000,
@@ -171,6 +190,8 @@ MACHINE_END
 #ifdef CONFIG_ARCH_OMAP4
 static const char *omap4_boards_compat[] __initdata = {
ti,omap4,
+   ti,omap4430,
+   ti,omap4460,
NULL,
 };
 
@@ -191,6 +212,8 @@ MACHINE_END
 #ifdef CONFIG_SOC_OMAP5
 static const char *omap5_boards_compat[] __initdata = {
ti,omap5,
+   ti,omap5430,
+   ti,omap5432,
NULL,
 };
 
-- 
1.7.9.5

--
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 1/3] ARM: dts: omap3-igep: Add USB OTG support

On 10/07/2013 06:12 PM, Javier Martinez Canillas wrote:
 Commit ad871c10b (ARM: dts: OMAP: Add usb_otg and glue data to O
 added USB OTG support for most OMAP boards but some OMAP3 boards
 such as IGEP boards were not updated. This patch adds an USB OTG
 device node to these board.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Tested-by: Enric Balletbo i Serra eballe...@gmail.com

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

 ---
 
 Changes since v2:
  - Add phys and phy-names properties as required by the new
generic PHY framework; suggested by Roger Quadros
 
 Changes since v1:
  - Add USB OTG support for both IGEPv2 and IGEP COM and not only to IGEPv2 
 
  arch/arm/boot/dts/omap3-igep.dtsi | 9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
 b/arch/arm/boot/dts/omap3-igep.dtsi
 index 0f92224..ba1e58b 100644
 --- a/arch/arm/boot/dts/omap3-igep.dtsi
 +++ b/arch/arm/boot/dts/omap3-igep.dtsi
 @@ -143,3 +143,12 @@
  twl_gpio {
   ti,use-leds;
  };
 +
 +usb_otg_hs {
 + interface-type = 0;
 + usb-phy = usb2_phy;
 + phys = usb2_phy;
 + phy-names = usb2-phy;
 + mode = 3;
 + power = 50;
 +};
 

--
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 3/6] pinctrl: single: Prepare for supporting SoC specific features

Hi Linus W,

Any comments on the pinctrl patches 3 - 5 in this series?

These are badly needed to not break omap3 PM support when
we're moving to device tree based booting.

* Tony Lindgren t...@atomide.com [131002 22:50]:
 Let's replace is_pinconf with flags and add struct pcs_soc_data
 so we can support SoC specific features like pin wake-up events.
 
 Done in collaboration with Roger Quadros rog...@ti.com.
 
 Cc: Peter Ujfalusi peter.ujfal...@ti.com
 Cc: Grygorii Strashko grygorii.stras...@ti.com
 Cc: Prakash Manjunathappa prakash...@ti.com
 Cc: Haojian Zhuang haojian.zhu...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Cc: linux-ker...@vger.kernel.org
 Signed-off-by: Roger Quadros rog...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  drivers/pinctrl/pinctrl-single.c |   38 
 +-
  1 file changed, 29 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/pinctrl/pinctrl-single.c 
 b/drivers/pinctrl/pinctrl-single.c
 index a82ace4..f88d3d1 100644
 --- a/drivers/pinctrl/pinctrl-single.c
 +++ b/drivers/pinctrl/pinctrl-single.c
 @@ -150,19 +150,27 @@ struct pcs_name {
  };
  
  /**
 + * struct pcs_soc_data - SoC specific settings
 + * @flags:   initial SoC specific PCS_FEAT_xxx values
 + */
 +struct pcs_soc_data {
 + unsigned flags;
 +};
 +
 +/**
   * struct pcs_device - pinctrl device instance
   * @res: resources
   * @base:virtual address of the controller
   * @size:size of the ioremapped area
   * @dev: device entry
   * @pctl:pin controller device
 + * @flags:   mask of PCS_FEAT_xxx values
   * @mutex:   mutex protecting the lists
   * @width:   bits per mux register
   * @fmask:   function register mask
   * @fshift:  function register shift
   * @foff:value to turn mux off
   * @fmax:max number of functions in fmask
 - * @is_pinconf:  whether supports pinconf
   * @bits_per_pin:number of bits per pin
   * @names:   array of register names for pins
   * @pins:physical pins on the SoC
 @@ -183,6 +191,8 @@ struct pcs_device {
   unsigned size;
   struct device *dev;
   struct pinctrl_dev *pctl;
 + unsigned flags;
 +#define PCS_FEAT_PINCONF (1  0)
   struct mutex mutex;
   unsigned width;
   unsigned fmask;
 @@ -190,7 +200,6 @@ struct pcs_device {
   unsigned foff;
   unsigned fmax;
   bool bits_per_mux;
 - bool is_pinconf;
   unsigned bits_per_pin;
   struct pcs_name *names;
   struct pcs_data pins;
 @@ -206,6 +215,8 @@ struct pcs_device {
   void (*write)(unsigned val, void __iomem *reg);
  };
  
 +#define PCS_HAS_PINCONF  (pcs-flags  PCS_FEAT_PINCONF)
 +
  static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
  unsigned long *config);
  static int pcs_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
 @@ -1060,7 +1071,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, 
 struct device_node *np,
   };
  
   /* If pinconf isn't supported, don't parse properties in below. */
 - if (!pcs-is_pinconf)
 + if (!PCS_HAS_PINCONF)
   return 0;
  
   /* cacluate how much properties are supported in current node */
 @@ -1184,7 +1195,7 @@ static int pcs_parse_one_pinctrl_entry(struct 
 pcs_device *pcs,
   (*map)-data.mux.group = np-name;
   (*map)-data.mux.function = np-name;
  
 - if (pcs-is_pinconf) {
 + if (PCS_HAS_PINCONF) {
   res = pcs_parse_pinconf(pcs, np, function, map);
   if (res)
   goto free_pingroups;
 @@ -1305,7 +1316,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct 
 pcs_device *pcs,
   (*map)-data.mux.group = np-name;
   (*map)-data.mux.function = np-name;
  
 - if (pcs-is_pinconf) {
 + if (PCS_HAS_PINCONF) {
   dev_err(pcs-dev, pinconf not supported\n);
   goto free_pingroups;
   }
 @@ -1525,6 +1536,7 @@ static int pcs_probe(struct platform_device *pdev)
   const struct of_device_id *match;
   struct resource *res;
   struct pcs_device *pcs;
 + const struct pcs_soc_data *soc;
   int ret;
  
   match = of_match_device(pcs_of_match, pdev-dev);
 @@ -1541,7 +1553,8 @@ static int pcs_probe(struct platform_device *pdev)
   INIT_LIST_HEAD(pcs-pingroups);
   INIT_LIST_HEAD(pcs-functions);
   INIT_LIST_HEAD(pcs-gpiofuncs);
 - pcs-is_pinconf = match-data;
 + soc = match-data;
 + pcs-flags = soc-flags;
  
   PCS_GET_PROP_U32(pinctrl-single,register-width, pcs-width,
register width not specified\n);
 @@ -1610,7 +1623,7 @@ static int pcs_probe(struct platform_device *pdev)
   pcs-desc.name = DRIVER_NAME;
   pcs-desc.pctlops = pcs_pinctrl_ops;
   pcs-desc.pmxops = pcs_pinmux_ops;
 - if (pcs-is_pinconf)
 + if (PCS_HAS_PINCONF)
   pcs-desc.confops = pcs_pinconf_ops;
   pcs-desc.owner = THIS_MODULE;
  
 @@ -1652,9 +1665,16 @@ static int

Re: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT

* Tony Lindgren t...@atomide.com [131007 08:49]:
* Tero Kristo t-kri...@ti.com [131006 23:43]:
On 10/07/2013 05:15 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [131004 08:42]:
Hi,

Just a gentle reminder, anybody have any comments on this series or
should we start queuing stuff?

Uart4 breaks because of the issue with basic DT blobs. You need at
least this patch:

http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-ARM-OMAP3630-Add-generic-machine-descriptor-td722791.html

... from Nishanth to get it to work right. Otherwise the clock init
tries to use omap3430 clock data for omap3630 which leaves uart4
nodes out.

OK thanks yes that solves it, I was missing the compatible flag
for my not quite ready test boards (3730-evm and zoom3).
I'll apply Nishant's fix with some changes.

Then for this series, once you have the necessary acks, can you
please split into following two separate immutable branches
against v3.12-rc3:

1. clock code changes

2. dts changes

Then those can be pulled in as needed by Benoit, Mike and I.

And Paul too natuarlly if these patches conflict with stuff
that's he's merging. And assuming Paul is OK with these patches
in general.

For the whole series, I think this quite nicely removes some
nasty kernel data dependencies for omaps, so feel free to add:

Acked-by: Tony Lindgren t...@atomide.com

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
--
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 1/2] Documentation: dt: OMAP: standardize SoC naming definition

Hi,

Few comments below.

* Nishanth Menon n...@ti.com [131007 09:57]:
 SoC family definitions at the moment are reactive to board needs
 as a result, beagle-xm would matchup with ti,omap3 which invokes
 omap3430_init_early instead of omap3630_init_early. Obviously, this is
 the wrong behavior.

It seems that we should try to queue this as a fix to avoid
debugging it multiple times as it's actually quite easy to hit this
one.

So maybe use a subject along lines of:

ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree

And also include these warnings you can get:

omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434 
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126 
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from initialized, idle, 
or disabled state
...

WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224 
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126 
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or 
disabled state

And also describe that the outcome is that the system fails to boot.
 
 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
 @@ -30,6 +30,51 @@ spinlock@1 {
  ti,hwmods = spinlock;
  };
  
 +SoC Type(optional):
 +- ti,gp  - General Purpose devices
 +- ti,hs  - High Security devices
 +
 +SoC Families:
 +
 +- OMAP2 generic - defaults to OMAP2420
 +  compatible = ti,omap2
 +- OMAP3 generic - defaults to OMAP3430
 +  compatible = ti,omap3
 +- OMAP4 generic - defaults to OMAP4430
 +  compatible = ti,omap4
 +- OMAP5 generic - defaults to OMAP5430
 +  compatible = ti,omap5
 +- DRA7 generic - defaults to DRA742
 +  compatible = ti,dra7
 +- AM43x generic - defaults to AM437x
 +  compatible = ti,am43
 +
 +SoCs:
 +
 +- OMAP2420
 +  compatible = ti,omap2420, ti,omap2
 +- OMAP2430
 +  compatible = ti,omap2430, ti,omap2
 +
 +- OMAP3430
 +  compatible = ti,omap343x, ti,omap3
 +- OMAP3630
 +  compatible = ti,omap363x, ti,omap3
 +- AM33xx
 +  compatible = ti,am33xx, ti,omap3
 +
 +- OMAP4430
 +  compatible = ti,omap443x, ti,omap4
 +- OMAP4460
 +  compatible = ti,omap446x, ti,omap4
 +
 +- OMAP5430
 +  compatible = ti,omap5430, ti,omap5
 +- OMAP5432
 +  compatible = ti,omap5432, ti,omap5
 +
 +- DRA742
 +  compatible = ti,dra7xx, ti,dra7
  
  Boards:

And I would leave the documentation parts out of the fix as
we're pretty late into the -rc cycle.
  
 +++ b/arch/arm/mach-omap2/board-generic.c
 @@ -113,6 +113,7 @@ MACHINE_END
  #ifdef CONFIG_ARCH_OMAP3
  static const char *omap3_boards_compat[] __initdata = {
   ti,omap3,
 + ti,omap343x,
   NULL,
  };
  
 @@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened 
 Device Tree))
   .restart= omap3xxx_restart,
  MACHINE_END
  
 +static const char *omap36xx_boards_compat[] __initdata = {
 + ti,omap363x,
 + NULL,
 +};

Why not make it just ti,omap36xx? This also applies to 3703
where the 3 is missing as it does not have the DSP.

 +DT_MACHINE_START(OMAP36xx_DT, Generic OMAP363x (Flattened Device Tree))

Upper case OMAP36XX_DT here please like the others have.

 + .reserve= omap_reserve,
 + .map_io = omap3_map_io,
 + .init_early = omap3630_init_early,
 + .init_irq   = omap_intc_of_init,
 + .handle_irq = omap3_intc_handle_irq,
 + .init_machine   = omap_generic_init,
 + .init_late  = omap3_init_late,
 + .init_time  = omap3_sync32k_timer_init,

Looks like this version has the correct init_time function too :)

 + .dt_compat  = omap36xx_boards_compat,
 + .restart= omap3xxx_restart,
 +MACHINE_END

This looks correct to me.

  static const char *omap3_gp_boards_compat[] __initdata = {
   ti,omap3-beagle,
   timll,omap3-devkit8000,
 @@ -171,6 +190,8 @@ MACHINE_END
  #ifdef CONFIG_ARCH_OMAP4
  static const char *omap4_boards_compat[] __initdata = {
   ti,omap4,
 + ti,omap4430,
 + ti,omap4460,
   NULL,
  };
  
 @@ -191,6 +212,8 @@ MACHINE_END
  #ifdef CONFIG_SOC_OMAP5
  static const char *omap5_boards_compat[] __initdata = {
   ti,omap5,
 + ti,omap5430,
 + ti,omap5432,
   NULL,
  };

I would leave these parts for later, maybe with the documentation
changes?

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 2/2] ARM: dts: omap3-beagle: use 3630 definitions

* Nishanth Menon n...@ti.com [131007 09:57]:
 beagle-xm currently would matchup with ti,omap3 which invokes
 omap3430_init_early instead of omap3630_init_early. So add
 compatiblity for 3630 to allow match
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm.dts
 index 0f7cfc5..2079e22 100644
 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
 +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
 @@ -11,7 +11,7 @@
  
  / {
   model = TI OMAP3 BeagleBoard xM;
 - compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
 + compatible = ti,omap3-beagle-xm, ti,omap363x, ti,omap3-beagle, 
 ti,omap3;
  
   cpus {
   cpu@0 {

This compatible string looks hacky.. How about just make it

ti,omap3-beagle-xm, ti,omap363x, ti,omap3;

How about just leave out ti,omap3-beagle here?

And I would fold this change into the fix part of your first
patch in this series.

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

[PATCH V2] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree

SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.

With clock node dts conversion, we get the following warnings as a
result and 3630 based platforms fails to boot (uart4 clocks are only
present in OMAP3630 and not present in OMAP3430):

...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...

WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state

So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.

Signed-off-by: Nishanth Menon n...@ti.com
---

Changes in V2 (since v1):
- based on v3.12-rc4 tag
- Update based on Tony's review comments.

V1: http://marc.info/?l=linux-omapm=138117342909375w=2

RFC: https://patchwork.kernel.org/patch/2919661/

 arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
 arch/arm/mach-omap2/board-generic.c   |   19 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..02dd4a9 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
 
 / {
model = TI OMAP3 BeagleBoard xM;
-   compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+   compatible = ti,omap3-beagle-xm, ti,omap363x, ti,omap3;
 
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
 #ifdef CONFIG_ARCH_OMAP3
 static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+   ti,omap343x,
NULL,
 };
 
@@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened 
Device Tree))
.restart= omap3xxx_restart,
 MACHINE_END
 
+static const char *omap36xx_boards_compat[] __initdata = {
+   ti,omap36xx,
+   NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, Generic OMAP363x (Flattened Device Tree))
+   .reserve= omap_reserve,
+   .map_io = omap3_map_io,
+   .init_early = omap3630_init_early,
+   .init_irq   = omap_intc_of_init,
+   .handle_irq = omap3_intc_handle_irq,
+   .init_machine   = omap_generic_init,
+   .init_late  = omap3_init_late,
+   .init_time  = omap3_sync32k_timer_init,
+   .dt_compat  = omap36xx_boards_compat,
+   .restart= omap3xxx_restart,
+MACHINE_END
+
 static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
timll,omap3-devkit8000,
-- 
1.7.9.5

--
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 V2] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree

On 10/07/2013 03:30 PM, Nishanth Menon wrote:
[...]
 diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm.dts
 index 0c514dc..02dd4a9 100644
 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
 +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
 @@ -11,7 +11,7 @@
  
  / {
   model = TI OMAP3 BeagleBoard xM;
 - compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
 + compatible = ti,omap3-beagle-xm, ti,omap363x, ti,omap3;

^^^ yikes - should have been ti,omap36xx - apologies, my fix was not
committed in local branch :( - will update and resend - grr..


-- 
Regards,
Nishanth Menon
--
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] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree

SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.

With clock node dts conversion, we get the following warnings as a
result and 3630 based platforms fails to boot (uart4 clocks are only
present in OMAP3630 and not present in OMAP3430):

...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...

WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state

So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.

Signed-off-by: Nishanth Menon n...@ti.com
---

Changes in V3 (since v2):
- Fix typo in dts :(

V2: https://patchwork.kernel.org/patch/2999111/
- based on v3.12-rc4 tag
- Update based on Tony's review comments.

V1: http://marc.info/?l=linux-omapm=138117342909375w=2

RFC: https://patchwork.kernel.org/patch/2919661/

 arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
 arch/arm/mach-omap2/board-generic.c   |   19 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..2816bf6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
 
 / {
model = TI OMAP3 BeagleBoard xM;
-   compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+   compatible = ti,omap3-beagle-xm, ti,omap36xx, ti,omap3;
 
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
 #ifdef CONFIG_ARCH_OMAP3
 static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+   ti,omap343x,
NULL,
 };
 
@@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened 
Device Tree))
.restart= omap3xxx_restart,
 MACHINE_END
 
+static const char *omap36xx_boards_compat[] __initdata = {
+   ti,omap36xx,
+   NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, Generic OMAP36xx (Flattened Device Tree))
+   .reserve= omap_reserve,
+   .map_io = omap3_map_io,
+   .init_early = omap3630_init_early,
+   .init_irq   = omap_intc_of_init,
+   .handle_irq = omap3_intc_handle_irq,
+   .init_machine   = omap_generic_init,
+   .init_late  = omap3_init_late,
+   .init_time  = omap3_sync32k_timer_init,
+   .dt_compat  = omap36xx_boards_compat,
+   .restart= omap3xxx_restart,
+MACHINE_END
+
 static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
timll,omap3-devkit8000,
-- 
1.7.9.5

--
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] ARM: OMAP2+: hwmod: check for module address space during init

On 10/03/2013 11:59 AM, Suman Anna wrote:
 The hwmod init sequence involves initializing and idling all the
 hwmods during bootup. If a module class has sysconfig, the init
 sequence utilizes the module register base for performing any
 sysc configuration.
 
 The module address space is being removed from hwmod database and
 retrieved from the reg property of the corresponding DT node.
 If a hwmod does not have its corresponding DT node defined and the
 memory address space is not defined in the corresponding
 omap_hwmod_ocp_if, then the module register target address space
 would be NULL and any sysc programming would result in a NULL
 pointer dereference and a kernel boot hang.
 
 Handle this scenario by checking for a valid module address space
 during the _init of each hwmod, and leaving it in the registered
 state if no module register address base is defined in either of
 the hwmod data or the DT data.
 
 Signed-off-by: Suman Anna s-a...@ti.com
 ---
 This patch helps break the dependencies between hwmod entries and
 corresponding DT entries (especially on OMAP5, where most of the
 address spaces are already cleaned up and the current data files
 have minimal entries) and fixes any boot issues due to missing
 addresses. See for reference,
 http://marc.info/?t=13800542143r=1w=2
 
 Tested on BeagleXM, Panda4, BeagleBone Black and Panda5 using
 Tero's v7 clk DT patches and Benoit's for-3.13/dts on top of
 3.12-rc3
 
  arch/arm/mach-omap2/omap_hwmod.c | 29 +++--
  1 file changed, 19 insertions(+), 10 deletions(-)

Mandatory to have this patch for OMAP5uEVM to boot after Tero's v7 [1]
series is merged else the delta between dts and hwmod entries cause
OMAP5 platforms to croak and die - at least worked around as seen in
[2] :(

Tested-by: Nishanth Menon n...@ti.com

[1] http://marc.info/?t=13800989941r=1w=2
[2] OMAP5uEVM: http://pastebin.com/jtEMwTY5

-- 
Regards,
Nishanth Menon
--
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: [RESEND PATCH v3 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT

Hello,

On Thu, Sep 26, 2013 at 08:18:28PM +0100, Jyri Sarha wrote:
 This patch adds DMA register location to mcasp DT bindings. On am33xx
 SoCs the McASP registers are mapped trough L4 interconnect, which is
 not accessible by the DMA controller, so McASP data port is mapped
 trough L3 to a different location.
 
 Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
 Signed-off-by: Darren Etheridge detheri...@ti.com
 Signed-off-by: Jyri Sarha jsa...@ti.com
 ---
  .../bindings/sound/davinci-mcasp-audio.txt |8 ++-
  sound/soc/davinci/davinci-mcasp.c  |   59 
 +---
  2 files changed, 46 insertions(+), 21 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt 
 b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 index 374e145..63b67ae 100644
 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 @@ -6,7 +6,11 @@ Required properties:
   ti,da830-mcasp-audio  : for both DA830  DA850 platforms
   ti,omap2-mcasp-audio  : for OMAP2 platforms (TI81xx, AM33xx)
  
 -- reg : Should contain McASP registers offset and length
 +- reg : Should contain McASP registers address and length for mpu and
 + optionally for dma controller access.
 +- reg-names : The mandatory reg-range must be named mpu and the optional 
 DMA
 +   reg-range must be named dma. For backward compatibility it is
 +   good to keep mpu first in the list.

I've never heard the term reg-range before. The should probably be something
like reg entry. How about something like the following instead:

- reg: Should contain reg specifiers for the entries in the reg-names property.

- reg-names: Should contain:
 * mpu for the main registers (required). For compatibility with
   existing software, it is recommended this is the first entry.
 * dma for the DMA registers (optional).

That way we don't end up describing each reg entry twice.

I have some questions however. I took a look at the McASP (TMS320C6000)
reference guide, and the registers appeared to all be in one contiguous bank,
and mpu and dma don't appear to be names of particular registers or names
of banks of particular registers. Am I looking in the wrong place? Is there
up-to-date documentation I can look at?

Why are these split across two reg entries, and which particular registers do
they actually cover?

I have some concern about the description of other properties too. If we're
going to amend the binding, they should be fixed up too.

  - interrupts : Interrupt number for McASP

The device also seems to be able to generate multiple interrupts -- which
interrupt does this actually cover?

The driver doesn't seem to use it (by a grep of irq|interrupt). Have I missed
something?

  - op-mode : I2S/DIT ops mode.

What type is this?

What are valid values?

  - tdm-slots : Slots for TDM operation.

Here too. This description is completely opaque.

Taking a look at the version in kernel sources this appears to be a list of
values, in groups of four?

What is the format of this property?

 @@ -15,7 +19,6 @@ Required properties:
   to num-serializer parameter. Each entry is a number indication
   serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
  
 -
  Optional properties:
  
  - ti,hwmods : Must be mcaspn, n is controller instance starting 0
 @@ -31,6 +34,7 @@ mcasp0: mcasp0@1d0 {
   #address-cells = 1;
   #size-cells = 0;

Why does this have #address-cells and #size-cells? There are no children in the
example.

   reg = 0x10 0x3000;
 + reg-names mpu;
   interrupts = 82 83;
   op-mode = 0;  /* MCASP_IIS_MODE */
   tdm-slots = 2;

A few questions from a brief skim of the documentation:

There seem to be external clocks (AHCLKR and ACLKR), but they aren't described.
Are we always able to use an internal clock instead? Is no external reference
clock needed?

The err_release_clk label in the error path confuses me -- which clock(s) does
the preceding pm_runtime_get ensure remains active? One internal to the McASP?

It looks like some pins can be used as GPIO -- is there not a need for something
like pinctrl for configuring this?

Cheers,
Mark.

 diff --git a/sound/soc/davinci/davinci-mcasp.c 
 b/sound/soc/davinci/davinci-mcasp.c
 index 32ddb7f..a056fc5 100644
 --- a/sound/soc/davinci/davinci-mcasp.c
 +++ b/sound/soc/davinci/davinci-mcasp.c
 @@ -1001,18 +1001,40 @@ static const struct snd_soc_component_driver 
 davinci_mcasp_component = {
   .name   = davinci-mcasp,
  };
  
 +/* Some HW specific values and defaults. The rest is filled in from DT. */
 +static struct snd_platform_data dm646x_mcasp_pdata = {
 + .tx_dma_offset = 0x400,
 + .rx_dma_offset = 0x400,
 + .asp_chan_q = EVENTQ_0,
 + .version = MCASP_VERSION_1,
 +};
 +
 +static struct snd_platform_data

Re: [RESEND PATCH v3 04/11] ASoC: davinci-mcasp: Extract DMA channels directly from DT

On Thu, Sep 26, 2013 at 08:18:29PM +0100, Jyri Sarha wrote:
 Extract DMA channels directly from DT as they can not be found from
 platform resources anymore. This is a work-around until davinci audio
 driver is updated to use dmaengine.

How long will this conversion take?

 
 Signed-off-by: Jyri Sarha jsa...@ti.com
 ---
  .../bindings/sound/davinci-mcasp-audio.txt |5 +++
  include/linux/platform_data/davinci_asp.h  |2 +
  sound/soc/davinci/davinci-mcasp.c  |   47 
 +---
  3 files changed, 39 insertions(+), 15 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt 
 b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 index 63b67ae..68e0f47 100644
 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 @@ -18,6 +18,11 @@ Required properties:
  - serial-dir : A list of serializer pin mode. The list number should be equal
   to num-serializer parameter. Each entry is a number indication
   serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
 +- dmas: two element list of DMA controller phandles and DMA request line
 +ordered pairs.

Please describe this in terms of dma-names. That makes it clear that elements
cannot be retrieved consistently by index, and prevents duplicate descriptions.

I'd prefer for the sake of consistent terminology that these were referred to
as phandles + dma-specifiers rather than phandles and DMA request lines --
#dma-cells may be an arbitrary number of cells and encode arbitrary information
for some abstract DMA engine.

 +- dma-names: identifier string for each DMA request line in the dmas 
 property.
 +  These strings correspond 1:1 with the ordered pairs in dmas. The 
 dma
 +  identifiers must be rx and tx.

For consistency and future expandability:

s/must be/should contain/

Cheers,
Mark.

  
  Optional properties:
  
 diff --git a/include/linux/platform_data/davinci_asp.h 
 b/include/linux/platform_data/davinci_asp.h
 index 8db5ae0..689a856 100644
 --- a/include/linux/platform_data/davinci_asp.h
 +++ b/include/linux/platform_data/davinci_asp.h
 @@ -84,6 +84,8 @@ struct snd_platform_data {
   u8 version;
   u8 txnumevt;
   u8 rxnumevt;
 + int tx_dma_channel;
 + int rx_dma_channel;
  };
  
  enum {
 diff --git a/sound/soc/davinci/davinci-mcasp.c 
 b/sound/soc/davinci/davinci-mcasp.c
 index a056fc5..acbf5f8 100644
 --- a/sound/soc/davinci/davinci-mcasp.c
 +++ b/sound/soc/davinci/davinci-mcasp.c
 @@ -1047,6 +1047,7 @@ static struct snd_platform_data 
 *davinci_mcasp_set_pdata_from_of(
   struct snd_platform_data *pdata = NULL;
   const struct of_device_id *match =
   of_match_device(mcasp_dt_ids, pdev-dev);
 + struct of_phandle_args dma_spec;
  
   const u32 *of_serial_dir32;
   u8 *of_serial_dir;
 @@ -1109,6 +1110,28 @@ static struct snd_platform_data 
 *davinci_mcasp_set_pdata_from_of(
   pdata-serial_dir = of_serial_dir;
   }
  
 + ret = of_property_match_string(np, dma-names, tx);
 + if (ret  0)
 + goto nodata;
 +
 + ret = of_parse_phandle_with_args(np, dmas, #dma-cells, ret,
 +  dma_spec);
 + if (ret  0)
 + goto nodata;
 +
 + pdata-tx_dma_channel = dma_spec.args[0];
 +
 + ret = of_property_match_string(np, dma-names, rx);
 + if (ret  0)
 + goto nodata;
 +
 + ret = of_parse_phandle_with_args(np, dmas, #dma-cells, ret,
 +  dma_spec);
 + if (ret  0)
 + goto nodata;
 +
 + pdata-rx_dma_channel = dma_spec.args[0];
 +
   ret = of_property_read_u32(np, tx-num-evt, val);
   if (ret = 0)
   pdata-txnumevt = val;
 @@ -1139,7 +1162,7 @@ nodata:
  static int davinci_mcasp_probe(struct platform_device *pdev)
  {
   struct davinci_pcm_dma_params *dma_data;
 - struct resource *mem, *ioarea, *res;
 + struct resource *mem, *ioarea, *res, *dma;
   struct snd_platform_data *pdata;
   struct davinci_audio_dev *dev;
   int ret;
 @@ -1213,15 +1236,11 @@ static int davinci_mcasp_probe(struct platform_device 
 *pdev)
   dma_data-sram_size = pdata-sram_size_playback;
   dma_data-dma_addr = dma-start + pdata-tx_dma_offset;
  
 - /* first TX, then RX */
   res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
 - if (!res) {
 - dev_err(pdev-dev, no DMA resource\n);
 - ret = -ENODEV;
 - goto err_release_clk;
 - }
 -
 - dma_data-channel = res-start;
 + if (res)
 + dma_data-channel = res-start;
 + else
 + dma_data-channel = pdata-tx_dma_channel;
  
   dma_data = dev-dma_params[SNDRV_PCM_STREAM_CAPTURE];
   dma_data-asp_chan_q = pdata-asp_chan_q;
 @@ -1231,13 +1250,11 @@ static int

Re: [RESEND PATCH v3 05/11] ASoC: davinci-mcasp: Interrupts property to optional and add interrupt-names

On Thu, Sep 26, 2013 at 08:18:30PM +0100, Jyri Sarha wrote:
 Makes interrupts property optional as the interrupts are not currently
 used by the driver and adds interrupt-names property to name listed
 interrupts. Currently know interrupt names are tx and rx.
 
 Signed-off-by: Jyri Sarha jsa...@ti.com
 ---
  .../bindings/sound/davinci-mcasp-audio.txt |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt 
 b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 index 68e0f47..2fd0bf2 100644
 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
 @@ -11,7 +11,6 @@ Required properties:
  - reg-names : The mandatory reg-range must be named mpu and the optional 
 DMA
 reg-range must be named dma. For backward compatibility it is
 good to keep mpu first in the list.
 -- interrupts : Interrupt number for McASP
  - op-mode : I2S/DIT ops mode.
  - tdm-slots : Slots for TDM operation.
  - num-serializer : Serializers used by McASP.
 @@ -31,6 +30,8 @@ Optional properties:
  - rx-num-evt : FIFO levels.
  - sram-size-playback : size of sram to be allocated during playback
  - sram-size-capture  : size of sram to be allocated during capture
 +- interrupts : Interrupt numbers for McASP, currently not used by the driver
 +- interrupt-names : Known interrupt names are tx and rx

Are these _all_ the interrupts the McASP may generate? I was under the
impression there were also separate interrupts for errors.

Cheers,
Mark.

  
  Example:
  
 @@ -41,6 +42,7 @@ mcasp0: mcasp0@1d0 {
   reg = 0x10 0x3000;
   reg-names mpu;
   interrupts = 82 83;
 + interrupts-names = tx, rx;
   op-mode = 0;  /* MCASP_IIS_MODE */
   tdm-slots = 2;
   num-serializer = 16;
 -- 
 1.7.9.5
 
 --
 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

Re: [RESEND PATCH v3 10/11] ARM/dts: am33xx: mcasp: Add new dma register location to reg-property

On Thu, Sep 26, 2013 at 08:18:35PM +0100, Jyri Sarha wrote:
 This patch adds an optional address range to reg property. The range
 describes the register location for DMA controller on am33xx. The both
 address ranges are named accordingly in the reg-names property.
 
 Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
 Signed-off-by: Darren Etheridge detheri...@ti.com
 Signed-off-by: Jyri Sarha jsa...@ti.com
 ---
  arch/arm/boot/dts/am33xx.dtsi |   14 --
  1 file changed, 12 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index fe53ce0..4dc388a 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -556,19 +556,29 @@
   mcasp0: mcasp@48038000 {
   compatible = ti,omap2-mcasp-audio;
   ti,hwmods = mcasp0;
 - reg = 0x48038000 0x2000;
 + reg = 0x48038000 0x2000,
 +   0x4640 0x40;
 + reg-names = mpu, dma;
   interrupts = 80 81;
   interrupts-names = tx, rx;
   status = disabled;
 + dmas = edma 8
 + edma 9;

For consistency with reg and other composite value properties, I'd prefer that
each entry in the list were individually bracketed:

dmas = edma 8,
   edma 9;

It would also be nice if interrupts were written this way.

 + dma-names = tx, rx;
   };
  
   mcasp1: mcasp@4803C000 {
   compatible = ti,omap2-mcasp-audio;
   ti,hwmods = mcasp1;
 - reg = 0x4803C000 0x2000;
 + reg = 0x4803C000 0x2000,
 +   0x4640 0x40;
 + reg-names = mpu, dma;
   interrupts = 82 83;
   interrupts-names = tx, rx;
   status = disabled;
 + dmas = edma 10
 + edma 11;

Similarly here.

Cheers,
Mark.
--
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: [RESEND PATCH v3 11/11] ARM/dts: am335x-evm: Add audio support for am335x-evm.dts