Re: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion

[Hans Verkuil]

On 12/12/2013 09:35 AM, Archit Taneja wrote:
 The VPE and VIP IPs in DRA7x contain common scaler and color conversion 
 hardware
 blocks. We create libraries for these components such that the vpe driver and
 the vip driver(in future) can use these library funcs to configure the blocks.
 
 There are some points for which I would like comments:
 
 - For VPE, setting the format and colorspace for the source and destination
   queues is enough to determine how these blocks need to be configured and
   whether they need to be bypassed or not. So it didn't make sense to 
 represent
   them as media controller entities. For VIP(driver not upstream yet), it's
   possible that there are multiple data paths which may or may not include 
 these
   blocks. However, the current use cases don't require such flexibility. There
   may be a need to re-consider a media controller like setup once we work on 
 the
   VIP driver. Is it a good idea in terms of user-space compatibilty if we use
   media controller framework in the future.

As long as you don't need the mc, then there is no need to implement it.

 - These blocks will also require some custom control commands later on. For
   example, we may want to tell the scaler later on to perform bi-linear
   scaling, or perform peaking at a particular frequency.
 
 - The current series keeps the default scaler coefficients in a header file.
   These coefficients add a lot of lines of code in the kernel. Does it make 
 more
   sense for the user application to pass the co-efficients to the kernel using
   an ioctl? Is there any driver which currenlty does this?

I think it is good to keep it in the driver. Otherwise apps would be forced to
set up the table. It's about 11 kilobyte in memory, which isn't that bad.

 
 The series is based on the branch:
 
 git://linuxtv.org/media_tree.git master
 
 Archit Taneja (8):
   v4l: ti-vpe: create a scaler block library
   v4l: ti-vpe: support loading of scaler coefficients
   v4l: ti-vpe: make vpe driver load scaler coefficients
   v4l: ti-vpe: enable basic scaler support
   v4l: ti-vpe: create a color space converter block library
   v4l: ti-vpe: Add helper to perform color conversion
   v4l: ti-vpe: enable CSC support for VPE
   v4l: ti-vpe: Add a type specifier to describe vpdma data format type
 
  drivers/media/platform/ti-vpe/Makefile   |2 +-
  drivers/media/platform/ti-vpe/csc.c  |  196 +
  drivers/media/platform/ti-vpe/csc.h  |   68 ++
  drivers/media/platform/ti-vpe/sc.c   |  311 +++
  drivers/media/platform/ti-vpe/sc.h   |  208 +
  drivers/media/platform/ti-vpe/sc_coeff.h | 1342 
 ++
  drivers/media/platform/ti-vpe/vpdma.c|   36 +-
  drivers/media/platform/ti-vpe/vpdma.h|7 +
  drivers/media/platform/ti-vpe/vpe.c  |  251 --
  drivers/media/platform/ti-vpe/vpe_regs.h |  187 -
  10 files changed, 2335 insertions(+), 273 deletions(-)
  create mode 100644 drivers/media/platform/ti-vpe/csc.c
  create mode 100644 drivers/media/platform/ti-vpe/csc.h
  create mode 100644 drivers/media/platform/ti-vpe/sc.c
  create mode 100644 drivers/media/platform/ti-vpe/sc.h
  create mode 100644 drivers/media/platform/ti-vpe/sc_coeff.h
 

For this patch series:

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

Regards,

Hans
--
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 0/2] v4l: ti-vpe: Some VPE fixes

[Hans Verkuil]

On 12/17/2013 08:52 AM, Hans Verkuil wrote:
 On 12/03/2013 12:51 PM, Archit Taneja wrote:
 This series fixes 2 issues in the VPE driver. The first fix allows us to use
 UYVY color format for source and destination buffers. The second fix makes 
 sure
 we don't set pixel format widths which the VPDMA HW can't support. None of 
 these
 fixes are fatal, so they don't necessarily need to go in for the 3.13-rc 
 fixes.

 Archit Taneja (2):
   v4l: ti-vpe: Fix the data_type value for UYVY VPDMA format
   v4l: ti-vpe: make sure VPDMA line stride constraints are met

  drivers/media/platform/ti-vpe/vpdma.c  |  4 +--
  drivers/media/platform/ti-vpe/vpdma.h  |  5 ++-
  drivers/media/platform/ti-vpe/vpdma_priv.h |  2 +-
  drivers/media/platform/ti-vpe/vpe.c| 53 
 ++
  4 files changed, 47 insertions(+), 17 deletions(-)

 
 For this patch series:
 
 Acked-by: Hans Verkuil hans.verk...@cisco.com

Ah, it's already merged. I missed that :-)

Regards,

Hans

--
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: [PATCHv10 03/41] CLK: ti: add init support for clock IP blocks

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 ti_dt_clk_init_provider() can now be used to initialize the contents of
 a single clock IP block. This parses all the clocks under the IP block
 and calls the corresponding init function for them.
 
 This patch also introduces a helper function for the TI clock drivers
 to get register info from DT and append the master IP info to this.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com

...

 diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
 index ef1a7cd..63f85e9 100644
 --- a/drivers/clk/ti/clk.c
 +++ b/drivers/clk/ti/clk.c
 @@ -19,10 +19,15 @@
  #include linux/clkdev.h
  #include linux/clk/ti.h
  #include linux/of.h
 +#include linux/of_address.h
 +#include linux/list.h
  
  #undef pr_fmt
  #define pr_fmt(fmt) %s:  fmt, __func__
  
 +extern struct of_device_id __clk_of_table[];

This results in a checkpatch.pl warning:

WARNING: externs should be avoided in .c files
#33: FILE: drivers/clk/ti/clk.c:28:
+extern struct of_device_id __clk_of_table[];

Please make sure your patches are checkpatch.pl-clean, with the exception 
of the 80-column warnings and any const-related warnings related to the 
clock framework.

 +static int ti_dt_clk_regmap_index;
 +
  /**
   * ti_dt_clocks_register - register DT alias clocks during boot
   * @oclks: list of clocks to register
 @@ -53,3 +58,96 @@ void __init ti_dt_clocks_register(struct ti_dt_clk oclks[])
   }
   }
  }
 +
 +typedef int (*ti_of_clk_init_cb_t)(struct device_node *);

Normally typedefs should be a red flag to reviewers due to 
Documentation/CodingStyle chapter 5.  Still it seems this patch is just 
duplicating the way that the CCF does it, so I'm not too worried about it.

 +
 +struct clk_init_item {
 + int index;
 + struct device_node *np;
 + ti_of_clk_init_cb_t init_cb;
 + struct list_head node;
 +};
 +
 +static LIST_HEAD(retry_list);
 +
 +/**
 + * ti_clk_get_reg_addr - get register address for a clock register
 + * @node: device node for the clock
 + * @index: register index from the clock node
 + *
 + * Builds clock register address from device tree information. This
 + * is a struct of type clk_omap_reg.
 + */
 +void __iomem *ti_clk_get_reg_addr(struct device_node *node, int index)
 +{
 + struct clk_omap_reg *reg;
 + u32 val;
 + u32 tmp;
 +
 + reg = (struct clk_omap_reg *)tmp;
 + reg-index = ti_dt_clk_regmap_index;
 +
 + if (of_property_read_u32_index(node, reg, index, val)) {
 + pr_err(%s must have reg[%d]!\n, node-name, index);
 + return NULL;
 + }
 +
 + reg-offset = val;
 +
 + return (void __iomem *)tmp;
 +}
 +
 +/**
 + * ti_dt_clk_init_provider - init master clock provider
 + * @parent: master node
 + * @index: internal index for clk_reg_ops
 + *
 + * Initializes a master clock IP block and its child clock nodes.
 + * Regmap is provided for accessing the register space for the
 + * IP block and all the clocks under it.
 + */
 +void ti_dt_clk_init_provider(struct device_node *parent, int index)
 +{
 + const struct of_device_id *match;
 + struct device_node *np;
 + ti_of_clk_init_cb_t clk_init_cb;
 + struct clk_init_item *retry;
 + struct clk_init_item *tmp;
 + int ret;
 +
 + ti_dt_clk_regmap_index = index;
 +
 + for_each_child_of_node(parent, np) {
 + match = of_match_node(__clk_of_table, np);
 + if (!match)
 + continue;
 + clk_init_cb = (ti_of_clk_init_cb_t)match-data;
 + pr_debug(%s: initializing: %s\n, __func__, np-name);
 + ret = clk_init_cb(np);
 + if (ret == -EAGAIN) {
 + pr_debug(%s: adding to again list...\n, np-name);
 + retry = kzalloc(sizeof(*retry), GFP_KERNEL);
 + retry-np = np;
 + retry-init_cb = clk_init_cb;
 + list_add(retry-node, retry_list);
 + } else if (ret) {
 + pr_err(%s: clock init failed for %s (%d)!\n, __func__,
 +np-name, ret);
 + }
 + }
 +
 + list_for_each_entry_safe(retry, tmp, retry_list, node) {
 + pr_debug(%s: retry-init: %s\n, __func__, retry-np-name);
 + ti_dt_clk_regmap_index = retry-index;
 + ret = retry-init_cb(retry-np);
 + if (ret == -EAGAIN) {
 + pr_debug(%s failed again?\n, retry-np-name);

This is presumably a serious error condition and should be a pr_warn() or 
pr_err(), right?

If retry_list won't be walked again, then it seems best to delete and free 
the list_entry no matter what the return value is from retry-init_cb(), 
since it's not like it will be retried.  Otherwise the code will leak 
memory.

 + } else {
 + if (ret)
 + pr_err(%s: clock init failed for %s (%d)!\n,
 +__func__, retry-np-name, ret);
 + 

Re: [PATCHv10 03/41] CLK: ti: add init support for clock IP blocks

[Tero Kristo]

On 12/17/2013 10:14 AM, Paul Walmsley wrote:

On Tue, 26 Nov 2013, Tero Kristo wrote:


ti_dt_clk_init_provider() can now be used to initialize the contents of
a single clock IP block. This parses all the clocks under the IP block
and calls the corresponding init function for them.

This patch also introduces a helper function for the TI clock drivers
to get register info from DT and append the master IP info to this.

Signed-off-by: Tero Kristo t-kri...@ti.com


...


diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index ef1a7cd..63f85e9 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -19,10 +19,15 @@
  #include linux/clkdev.h
  #include linux/clk/ti.h
  #include linux/of.h
+#include linux/of_address.h
+#include linux/list.h

  #undef pr_fmt
  #define pr_fmt(fmt) %s:  fmt, __func__

+extern struct of_device_id __clk_of_table[];


This results in a checkpatch.pl warning:

WARNING: externs should be avoided in .c files
#33: FILE: drivers/clk/ti/clk.c:28:
+extern struct of_device_id __clk_of_table[];


This extern is only needed from this single file, and this code is 
duplicated from drivers/clk/clk.c.



Please make sure your patches are checkpatch.pl-clean, with the exception
of the 80-column warnings and any const-related warnings related to the
clock framework.


+static int ti_dt_clk_regmap_index;
+
  /**
   * ti_dt_clocks_register - register DT alias clocks during boot
   * @oclks: list of clocks to register
@@ -53,3 +58,96 @@ void __init ti_dt_clocks_register(struct ti_dt_clk oclks[])
}
}
  }
+
+typedef int (*ti_of_clk_init_cb_t)(struct device_node *);


Normally typedefs should be a red flag to reviewers due to
Documentation/CodingStyle chapter 5.  Still it seems this patch is just
duplicating the way that the CCF does it, so I'm not too worried about it.


This will be removed in next rev, and the standard typedef done by CCF 
will be used instead.





+
+struct clk_init_item {
+   int index;
+   struct device_node *np;
+   ti_of_clk_init_cb_t init_cb;
+   struct list_head node;
+};
+
+static LIST_HEAD(retry_list);
+
+/**
+ * ti_clk_get_reg_addr - get register address for a clock register
+ * @node: device node for the clock
+ * @index: register index from the clock node
+ *
+ * Builds clock register address from device tree information. This
+ * is a struct of type clk_omap_reg.
+ */
+void __iomem *ti_clk_get_reg_addr(struct device_node *node, int index)
+{
+   struct clk_omap_reg *reg;
+   u32 val;
+   u32 tmp;
+
+   reg = (struct clk_omap_reg *)tmp;
+   reg-index = ti_dt_clk_regmap_index;
+
+   if (of_property_read_u32_index(node, reg, index, val)) {
+   pr_err(%s must have reg[%d]!\n, node-name, index);
+   return NULL;
+   }
+
+   reg-offset = val;
+
+   return (void __iomem *)tmp;
+}
+
+/**
+ * ti_dt_clk_init_provider - init master clock provider
+ * @parent: master node
+ * @index: internal index for clk_reg_ops
+ *
+ * Initializes a master clock IP block and its child clock nodes.
+ * Regmap is provided for accessing the register space for the
+ * IP block and all the clocks under it.
+ */
+void ti_dt_clk_init_provider(struct device_node *parent, int index)
+{
+   const struct of_device_id *match;
+   struct device_node *np;
+   ti_of_clk_init_cb_t clk_init_cb;
+   struct clk_init_item *retry;
+   struct clk_init_item *tmp;
+   int ret;
+
+   ti_dt_clk_regmap_index = index;
+
+   for_each_child_of_node(parent, np) {
+   match = of_match_node(__clk_of_table, np);
+   if (!match)
+   continue;
+   clk_init_cb = (ti_of_clk_init_cb_t)match-data;
+   pr_debug(%s: initializing: %s\n, __func__, np-name);
+   ret = clk_init_cb(np);
+   if (ret == -EAGAIN) {
+   pr_debug(%s: adding to again list...\n, np-name);
+   retry = kzalloc(sizeof(*retry), GFP_KERNEL);
+   retry-np = np;
+   retry-init_cb = clk_init_cb;
+   list_add(retry-node, retry_list);
+   } else if (ret) {
+   pr_err(%s: clock init failed for %s (%d)!\n, __func__,
+  np-name, ret);
+   }
+   }
+
+   list_for_each_entry_safe(retry, tmp, retry_list, node) {
+   pr_debug(%s: retry-init: %s\n, __func__, retry-np-name);
+   ti_dt_clk_regmap_index = retry-index;
+   ret = retry-init_cb(retry-np);
+   if (ret == -EAGAIN) {
+   pr_debug(%s failed again?\n, retry-np-name);


This is presumably a serious error condition and should be a pr_warn() or
pr_err(), right?


Not a serious, I think this can happen still if we have dependencies 
towards clocks from other IP blocks which provide clocks (e.g. DPLL uses 
source clocks from both PRM + CM IPs.)



If 

Re: [PATCHv10 03/41] CLK: ti: add init support for clock IP blocks

[Paul Walmsley]

On Tue, 17 Dec 2013, Tero Kristo wrote:

 On 12/17/2013 10:14 AM, Paul Walmsley wrote:
  On Tue, 26 Nov 2013, Tero Kristo wrote:
  
   ti_dt_clk_init_provider() can now be used to initialize the contents of
   a single clock IP block. This parses all the clocks under the IP block
   and calls the corresponding init function for them.
   
   This patch also introduces a helper function for the TI clock drivers
   to get register info from DT and append the master IP info to this.
   
   Signed-off-by: Tero Kristo t-kri...@ti.com
  
  ...
  
   diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
   index ef1a7cd..63f85e9 100644
   --- a/drivers/clk/ti/clk.c
   +++ b/drivers/clk/ti/clk.c
   @@ -19,10 +19,15 @@
 #include linux/clkdev.h
 #include linux/clk/ti.h
 #include linux/of.h
   +#include linux/of_address.h
   +#include linux/list.h
   
 #undef pr_fmt
 #define pr_fmt(fmt) %s:  fmt, __func__
   
   +extern struct of_device_id __clk_of_table[];
  
  This results in a checkpatch.pl warning:
  
  WARNING: externs should be avoided in .c files
  #33: FILE: drivers/clk/ti/clk.c:28:
  +extern struct of_device_id __clk_of_table[];
 
 This extern is only needed from this single file, and this code is duplicated
 from drivers/clk/clk.c.

So the right thing to do here is to move it into a separate header file 
that both drivers/clk/clk.c and drivers/clk/ti/clk.c either already 
#include, or can add a new #include for.


- 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: [PATCHv10 04/41] CLK: TI: Add DPLL clock support

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 The OMAP clock driver now supports DPLL clock type. This patch also
 adds support for DT DPLL nodes.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com

...

 +/*
 + * struct clk_hw_omap.flags possibilities
 + *
 + * XXX document the rest of the clock flags here
 + *
 + * ENABLE_REG_32BIT: (OMAP1 only) clock control register must be accessed
 + * with 32bit ops, by default OMAP1 uses 16bit ops.
 + * CLOCK_IDLE_CONTROL: (OMAP1 only) clock has autoidle support.
 + * CLOCK_NO_IDLE_PARENT: (OMAP1 only) when clock is enabled, its parent
 + * clock is put to no-idle mode.
 + * ENABLE_ON_INIT: Clock is enabled on init.
 + * INVERT_ENABLE: By default, clock enable bit behavior is '1' enable, '0'
 + * disable. This inverts the behavior making '0' enable and '1' disable.
 + * CLOCK_CLKOUTX2: (OMAP4 only) DPLL CLKOUT and CLKOUTX2 GATE_CTRL
 + * bits share the same register.  This flag allows the
 + * omap4_dpllmx*() code to determine which GATE_CTRL bit field
 + * should be used.  This is a temporary solution - a better approach
 + * would be to associate clock type-specific data with the clock,
 + * similar to the struct dpll_data approach.
 + * REGMAP_ADDRESSING: Use regmap addressing to access clock registers.
 + */

Nice work adding the additional flag documentation here.


- 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: [PATCHv10 04/41] CLK: TI: Add DPLL clock support

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 The OMAP clock driver now supports DPLL clock type. This patch also
 adds support for DT DPLL nodes.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com

...

 diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
 new file mode 100644
 index 000..921a409
 --- /dev/null
 +++ b/drivers/clk/ti/dpll.c
 @@ -0,0 +1,597 @@

...

 +/**
 + * of_ti_dpll_setup - Setup function for OMAP DPLL clocks
 + *
 + * @node: device node containing the DPLL info
 + * @ops: ops for the DPLL
 + * @ddt: DPLL data template to use
 + * @init_flags: flags for controlling init types
 + */

The kerneldoc-nano for this function isn't right.  The blank line
before the arguments should be removed.


- 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: [PATCHv10 12/41] CLK: TI: add omap4 clock init file

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 clk-44xx.c now contains the clock init functionality for omap4, including
 DT clock registration and adding of static clkdev entries.

...

 diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
 new file mode 100644
 index 000..3e2090b
 --- /dev/null
 +++ b/drivers/clk/ti/clk-44xx.c
 @@ -0,0 +1,328 @@
 +/*
 + * OMAP4 Clock data
 + *
 + * Copyright (C) 2009-2012 Texas Instruments, Inc.
 + * Copyright (C) 2009-2010 Nokia Corporation
 + *
 + * Paul Walmsley (p...@pwsan.com)

Please remove my name and E-mail address from this file.


- 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: [PATCHv10 21/41] ARM: dts: omap4 clock data

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 This patch creates a unique node for each clock in the OMAP4 power,
 reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
 different clock tree which is taken into account in the data.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com

...

 diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
 index a1e0585..c2e3993 100644
 --- a/arch/arm/boot/dts/omap4.dtsi
 +++ b/arch/arm/boot/dts/omap4.dtsi
 @@ -107,6 +107,34 @@
   interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
  
 + cm1: cm1@4a004000 {
 + compatible = ti,clock-master;

These devices are low-level IP blocks, and should have accurate compatible 
strings like any other low-level IP block.  At some point in the future, 
these IP blocks will have device driver code that matches up with these DT 
nodes, and is probed via these compatible strings.  These should be 
corrected now, so unnecessary DT data synchronization problems don't 
appear with later kernels.

So this should be something like:

compatible = ti,omap4-cm1;

 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0x4a004000 0x2000;
 + };
 +
 + prm: prm@4a306000 {
 + compatible = ti,clock-master;

Similarly this should be 

compatible = ti,omap4-prm;

 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0x4a306000 0x3000;
 + };
 +
 + cm2: cm2@4a008000 {
 + compatible = ti,clock-master;

compatible = ti,omap4-cm2;

 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0x4a008000 0x3000;
 + };
 +
 + scrm: scrm@4a30a000 {
 + compatible = ti,clock-master;

compatible = ti,omap4-scrm;


...

 diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi 
 b/arch/arm/boot/dts/omap443x-clocks.dtsi
 new file mode 100644
 index 000..643755b
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
 @@ -0,0 +1,18 @@
 +/*
 + * Device Tree Source for OMAP4 clock data
 + *
 + * Copyright (C) 2013 Texas Instruments, Inc.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +prm {
 + bandgap_fclk: bandgap_fclk {
 + #clock-cells = 0;
 + compatible = ti,gate-clock;
 + clocks = sys_32k_ck;
 + ti,bit-shift = 8;
 + reg = 0x1888;
 + };

So we've already discussed that clocks should be moved underneath
separate clocks { node in the IP block data.  And similarly...

 diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi 
 b/arch/arm/boot/dts/omap44xx-clocks.dtsi
 new file mode 100644
 index 000..2b59d54
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi

...

 + emu_sys_clkdm: emu_sys_clkdm {
 + compatible = ti,clockdomain;
 + clocks = trace_clk_div_ck;
 + };

... all of the clockdomains should be moved underneath clockdomains {
nodes in the IP block DT data.


- 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: [PATCHv10 23/41] ARM: dts: dra7 clock data

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 This patch creates a unique node for each clock in the DRA7 power,
 reset and clock manager (PRCM).
 
 TODO: apll_pcie clock node is still a dummy in this version, and
 proper support for the APLL should be added.

...

 ---
  arch/arm/boot/dts/dra7.dtsi  |   23 +
  arch/arm/boot/dts/dra7xx-clocks.dtsi | 1983 
 ++
  2 files changed, 2006 insertions(+)
  create mode 100644 arch/arm/boot/dts/dra7xx-clocks.dtsi
 
 diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
 index d0df4c4..6cf1c76 100644
 --- a/arch/arm/boot/dts/dra7.dtsi
 +++ b/arch/arm/boot/dts/dra7.dtsi
 @@ -104,6 +104,27 @@
   interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
  
 + prm: prm@4ae06000 {
 + compatible = ti,clock-master;


Likewise, same issues here with the compatible strings and
separating out the clocks and clockdomain data into separate DT
nodes, as discussed with the OMAP4 data patch.


- 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: [PATCHv10 27/41] ARM: dts: am33xx clock data

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 This patch creates a unique node for each clock in the AM33xx power,
 reset and clock manager (PRCM).
 
 Signed-off-by: Tero Kristo t-kri...@ti.com

...

 ---
  arch/arm/boot/dts/am33xx-clocks.dtsi |  662 
 ++
  arch/arm/boot/dts/am33xx.dtsi|   16 +
  2 files changed, 678 insertions(+)
  create mode 100644 arch/arm/boot/dts/am33xx-clocks.dtsi
 

...

 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index f6d8ffe..52c46e1 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -102,6 +102,20 @@
   ranges;
   ti,hwmods = l3_main;
  
 + prcm: prcm@44e0 {
 + compatible = ti,clock-master;

Same issues here with the compatible strings and separating out the
clocks and clockdomain data into separate DT nodes, as discussed with
the OMAP4 data patch.


- 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: [PATCHv10 22/41] ARM: dts: omap5 clock data

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 This patch creates a unique node for each clock in the OMAP5 power,
 reset and clock manager (PRCM).
 
 Signed-off-by: Tero Kristo t-kri...@ti.com

...

 diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
 index 17fe896..3920087 100644
 --- a/arch/arm/boot/dts/omap5.dtsi
 +++ b/arch/arm/boot/dts/omap5.dtsi
 @@ -107,6 +107,34 @@
   interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
  
 + prm: prm@4ae06000 {
 + compatible = ti,clock-master;

Same issues here with the compatible strings and separating out the clocks 
and clockdomain data into separate DT nodes, as discussed with the OMAP4 
data patch.


- 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: [PATCHv10 28/41] ARM: dts: omap3 clock data

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 This patch creates a unique node for each clock in the OMAP3 power,
 reset and clock manager (PRCM).
 
 Signed-off-by: Tero Kristo t-kri...@ti.com


 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index f3a0c26..9e6ea02 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -82,6 +82,27 @@
   ranges;
   ti,hwmods = l3_main;
  
 + prm: prm@48306000 {
 + compatible = ti,clock-master;

Likewise, same issues here with the compatible strings and
separating out the clocks and clockdomain data into separate DT
nodes, as discussed with the OMAP4 data patch.



- 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: [PATCHv10 30/41] ARM: dts: am43xx clock data

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 This patch creates a unique node for each clock in the AM43xx power,
 reset and clock manager (PRCM).
 
 Signed-off-by: Tero Kristo t-kri...@ti.com

...

 diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
 index 974d103..18f2401 100644
 --- a/arch/arm/boot/dts/am4372.dtsi
 +++ b/arch/arm/boot/dts/am4372.dtsi
 @@ -67,6 +67,20 @@
   ranges;
   ti,hwmods = l3_main;
  
 + prcm: prcm@44df {
 + compatible = ti,clock-master;
 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0x44df 0x11000;
 + };
 +
 + scrm: scrm@44e1 {
 + compatible = ti,clock-master;
 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0x44e1 0x2000;
 + };

Same issues here with the compatible strings and
separating out the clocks and clockdomain data into separate DT
nodes, as discussed with the OMAP4 data patch.


- 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: [PATCHv10 21/41] ARM: dts: omap4 clock data

[Tero Kristo]

On 12/17/2013 11:44 AM, Paul Walmsley wrote:

On Tue, 26 Nov 2013, Tero Kristo wrote:


This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
different clock tree which is taken into account in the data.

Signed-off-by: Tero Kristo t-kri...@ti.com


...


diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e0585..c2e3993 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,6 +107,34 @@
interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
 GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;

+   cm1: cm1@4a004000 {
+   compatible = ti,clock-master;


These devices are low-level IP blocks, and should have accurate compatible
strings like any other low-level IP block.  At some point in the future,
these IP blocks will have device driver code that matches up with these DT
nodes, and is probed via these compatible strings.  These should be
corrected now, so unnecessary DT data synchronization problems don't
appear with later kernels.

So this should be something like:

compatible = ti,omap4-cm1;


+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 0x4a004000 0x2000;
+   };
+
+   prm: prm@4a306000 {
+   compatible = ti,clock-master;


Similarly this should be

compatible = ti,omap4-prm;


How about just adding dual compatible strings? Keep the current one and 
add the other as extra.


compatible = ti,clock-master, ti,omap4-prm;

Easier to handle it this way.




+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 0x4a306000 0x3000;
+   };
+
+   cm2: cm2@4a008000 {
+   compatible = ti,clock-master;


compatible = ti,omap4-cm2;


+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 0x4a008000 0x3000;
+   };
+
+   scrm: scrm@4a30a000 {
+   compatible = ti,clock-master;


compatible = ti,omap4-scrm;


...


diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi 
b/arch/arm/boot/dts/omap443x-clocks.dtsi
new file mode 100644
index 000..643755b
--- /dev/null
+++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+prm {
+   bandgap_fclk: bandgap_fclk {
+   #clock-cells = 0;
+   compatible = ti,gate-clock;
+   clocks = sys_32k_ck;
+   ti,bit-shift = 8;
+   reg = 0x1888;
+   };


So we've already discussed that clocks should be moved underneath
separate clocks { node in the IP block data.  And similarly...


Yeah, I have actually wip v11 which has this done. I ended up creating 
this though:


...
   prm {
  prm_clocks: clocks {

  };
   };

... and references like:

prm_clocks {

};

It seems the references to existing clocks {} nodes is impossible 
otherwise as I need to add some extra clocks to these.





diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi 
b/arch/arm/boot/dts/omap44xx-clocks.dtsi
new file mode 100644
index 000..2b59d54
--- /dev/null
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi


...


+   emu_sys_clkdm: emu_sys_clkdm {
+   compatible = ti,clockdomain;
+   clocks = trace_clk_div_ck;
+   };


... all of the clockdomains should be moved underneath clockdomains {
nodes in the IP block DT data.


Ok that can be done.




- 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

[PATCH v5 0/2] DMM DT adaptation

[Archit Taneja]

The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the
removal of address and irq data from the omap4 hwmods, the probe of DMM driver
fails and omapdrm isn't able to utilize the DMM hardware.

Add DMM bindings for OMAP4 and OMAP5 and DRA7x.

Changes in v5:
- Use of_match_ptr() in the dmm driver.
- Add DT node for DRA7x as dra7.dtsi is now in mainline.

Changes in v4:
- Clean up documentation further.

Changes in v3:
- Fix mistakes in documentation and remove aliases for dmm nodes.

Changes in v2:
- No changes, split out into a separate series containing only DT related parts.


Archit Taneja (2):
  arm: dts: omap4+: Add DMM bindings
  drm: omap: Enable DT support for DMM

 Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
 arch/arm/boot/dts/dra7.dtsi|  7 +++
 arch/arm/boot/dts/omap4.dtsi   |  7 +++
 arch/arm/boot/dts/omap5.dtsi   |  7 +++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |  7 +++
 5 files changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

-- 
1.8.3.2

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

[PATCH v5 2/2] drm: omap: Enable DT support for DMM

[Archit Taneja]

Enable use of DT for DMM/Tiler.

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

Cc: Andy Gross andy...@gmail.com
Cc: DRI Development dri-de...@lists.freedesktop.org
Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 701c4c1..1b782aa 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -969,12 +969,19 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
 };
 #endif
 
+static const struct of_device_id dmm_of_match[] = {
+   { .compatible = ti,omap4-dmm, },
+   { .compatible = ti,omap5-dmm, },
+   {},
+};
+
 struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+   .of_match_table = of_match_ptr(dmm_of_match),
 #ifdef CONFIG_PM
.pm = omap_dmm_pm_ops,
 #endif
-- 
1.8.3.2

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

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

[Archit Taneja]

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

Add documentation for the DMM bindings.

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

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

diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..8bd6d0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,22 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+The dynamic memory manager (DMM) is a module located immediately in front of 
the
+SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory
+accesses such as priority generation amongst initiators, configuration of SDRAM
+interleaving, optimizing transfer of 2D block objects, and provide MMU-like 
page
+translation for initiators which need contiguous dma bus addresses.
+
+Required properties:
+- compatible:  Should contain ti,omap4-dmm for OMAP4 family
+   Should contain ti,omap5-dmm for OMAP5 and DRA7x family
+- reg: Contains DMM register address range (base address and length)
+- interrupts:  Should contain an interrupt-specifier for DMM_IRQ.
+- ti,hwmods:   Name of the hwmod associated to DMM, which is typically dmm
+
+Example:
+
+dmm@4e00 {
+   compatible = ti,omap4-dmm;
+   reg = 0x4e00 0x800;
+   ti,hwmods = dmm;
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d0df4c4..c9bb006 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -425,6 +425,13 @@
ti,hwmods = wd_timer2;
};
 
+   dmm@4e00 {
+   compatible = ti,omap5-dmm;
+   reg = 0x4e00 0x800;
+   interrupts = 0 113 0x4;
+   ti,hwmods = dmm;
+   };
+
i2c1: i2c@4807 {
compatible = ti,omap4-i2c;
reg = 0x4807 0x100;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e0585..3c67b2f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -502,6 +502,13 @@
ti,hwmods = kbd;
};
 
+   dmm@4e00 {
+   compatible = ti,omap4-dmm;
+   reg = 0x4e00 0x800;
+   interrupts = 0 113 0x4;
+   ti,hwmods = dmm;
+   };
+
emif1: emif@4c00 {
compatible = ti,emif-4d;
reg = 0x4c00 0x100;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc3fad5..878f635 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -621,6 +621,13 @@
ti,hwmods = wd_timer2;
};
 
+   dmm@4e00 {
+   compatible = ti,omap5-dmm;
+   reg = 0x4e00 0x800;
+   interrupts = 0 113 0x4;
+   ti,hwmods = dmm;
+   };
+
emif1: emif@4c00 {
compatible  = ti,emif-4d5;
ti,hwmods   = emif1;
-- 
1.8.3.2

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

Re: [PATCH 07/10] mfd: menelaus: Start to use irqdomain

[Lee Jones]

On Mon, 16 Dec 2013, Felipe Balbi wrote:

 Introduce an irq_chip and irq_domain for menelaus driver. Following
 patches will convert uses to traditional request_threaded_irq().
 
 While at that, some better error handling had to be added, so we could
 free irq descs we allocated.
 
 Tested-by: Aaro Koskinen aaro.koski...@iki.fi
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  drivers/mfd/menelaus.c | 123 
 +++--
  1 file changed, 119 insertions(+), 4 deletions(-)
 

snip

 +static void menelaus_irq_ack(struct irq_data *data)
 +{
 + struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
 + int irq = data-irq - m-irq_base;

Shoudn't this now be?
  int irq = data-hwirq;

 + if (irq  7) {
 + m-ack2 |= BIT(irq);
 + m-ack2_pending = true;
 + } else {
 + m-ack1 |= BIT(irq);
 + m-ack1_pending = true;
 + }
 +}
 +
 +static void menelaus_irq_mask(struct irq_data *data)
 +{
 + struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
 + int irq = data-irq - m-irq_base;

Same for here, and all the others.

snip

 + irq_domain_add_legacy(node, MENELAUS_NR_IRQS, irq_base, 0,
 + irq_domain_simple_ops, m);

Please use irq_domain_add_simple() here.

 + m-irq_base = irq_base;

I don't think you need this.

 + for (i = irq_base; i  irq_base + MENELAUS_NR_IRQS; i++) {
 + irq_set_chip_data(i, m);
 + irq_set_chip_and_handler(i, menelaus_irq_chip,
 + handle_simple_irq);
 + irq_set_nested_thread(i, 1);
 + set_irq_flags(i, IRQF_VALID);
 + }

You should put this in the .map() operation and the reverse in .unmap().

  fail:
 + irq_free_descs(irq_base, MENELAUS_NR_IRQS);

I don't think you need to do this.

  
  static int menelaus_remove(struct i2c_client *client)
  {
 + struct menelaus_chip*m = i2c_get_clientdata(client);
 +
 + irq_free_descs(m-irq_base, MENELAUS_NR_IRQS);

Nor here.

   the_menelaus = NULL;

Shouldn't this have been removed in patch 6?

   return 0;
  }
  

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

Re: [PATCH 08/10] mfd: menelaus: Switch all children to threaded_irq

[Lee Jones]

 Now that we have our own irq_chip, all children can use traditional
 request_threaded_irq().

Is it possible to convert these to managed resources (*_devm)?

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

[PATCH] omapdss: dispc: Preload more data in pipeline DMAs for OMAP4+ SoCs

[Archit Taneja]

DISPC pipeline DMAs preload some bytes of pixel data in the vertical blanking
region before the start of each frame. The preload ensures the pipeline doesn't
underflow when the active region of the display starts.

DISPC_GFX/VIDp_PRELOAD registers allow us to program how many bytes of data
should be preloaded for each pipeline. Calculating a precise preload value
would be a complex function of the pixel clock of the connected display, the
vertical blanking duration and the interconnect traffic at that instance. If
the register is left untouched, a default value is preloaded.

We observe underflows for OMAP4+ SoCs for certain bandwidth intensive use cases
with many other initiators active, and in situations where memory access isn't
very efficient(like accessing Tiler mapped buffers and EMIF configured in
non-interleaved more). The cause of the underflow is because the default preload
value isn't sufficient for the DMA to reach a steady state. We configure the
PRELOAD register such that the pipelines preload data up to the high threshold
of the FIFO.

Preloading lot of data for older SoCs can have a negative impact. Due to slower
interconnects, it's possible that the DISPC DMA cannot preload up to the high
threshold within the vertical blanking region of the panel. We leave the PRELOAD
registers to their reset values since we haven't faced underflows with these
SoCs because of low value of PRELOAD.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6578540..ace179e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -90,6 +90,8 @@ struct dispc_features {
 
/* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
bool mstandby_workaround:1;
+
+   bool set_max_preload:1;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -1200,6 +1202,15 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, 
u32 low, u32 high)
dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
FLD_VAL(high, hi_start, hi_end) |
FLD_VAL(low, lo_start, lo_end));
+
+   /*
+* configure the preload to the pipeline's high threhold, if HT it's too
+* large for the preload field, set the threshold to the maximum value
+* that can be held by the preload register
+*/
+   if (dss_has_feature(FEAT_PRELOAD)  dispc.feat-set_max_preload 
+   plane != OMAP_DSS_WB)
+   dispc_write_reg(DISPC_OVL_PRELOAD(plane), min(high, 0xfff));
 }
 EXPORT_SYMBOL(dispc_ovl_set_fifo_threshold);
 
@@ -3525,6 +3536,7 @@ static const struct dispc_features omap24xx_dispc_feats 
__initconst = {
.calc_core_clk  =   calc_core_clk_24xx,
.num_fifos  =   3,
.no_framedone_tv=   true,
+   .set_max_preload=   false,
 };
 
 static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -3544,6 +3556,7 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats __initconst = {
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
.no_framedone_tv=   true,
+   .set_max_preload=   false,
 };
 
 static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -3563,6 +3576,7 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats __initconst = {
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
.no_framedone_tv=   true,
+   .set_max_preload=   false,
 };
 
 static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -3582,6 +3596,7 @@ static const struct dispc_features omap44xx_dispc_feats 
__initconst = {
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
.gfx_fifo_workaround=   true,
+   .set_max_preload=   true,
 };
 
 static const struct dispc_features omap54xx_dispc_feats __initconst = {
@@ -3602,6 +3617,7 @@ static const struct dispc_features omap54xx_dispc_feats 
__initconst = {
.num_fifos  =   5,
.gfx_fifo_workaround=   true,
.mstandby_workaround=   true,
+   .set_max_preload=   true,
 };
 
 static int __init dispc_init_features(struct platform_device *pdev)
-- 
1.8.3.2

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

Re: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion

[Archit Taneja]

Hi Hans,

On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote:

On 12/12/2013 09:35 AM, Archit Taneja wrote:

The VPE and VIP IPs in DRA7x contain common scaler and color conversion hardware
blocks. We create libraries for these components such that the vpe driver and
the vip driver(in future) can use these library funcs to configure the blocks.

There are some points for which I would like comments:

- For VPE, setting the format and colorspace for the source and destination
   queues is enough to determine how these blocks need to be configured and
   whether they need to be bypassed or not. So it didn't make sense to represent
   them as media controller entities. For VIP(driver not upstream yet), it's
   possible that there are multiple data paths which may or may not include 
these
   blocks. However, the current use cases don't require such flexibility. There
   may be a need to re-consider a media controller like setup once we work on 
the
   VIP driver. Is it a good idea in terms of user-space compatibilty if we use
   media controller framework in the future.


As long as you don't need the mc, then there is no need to implement it.


The thing is that we want to use these blocks for a future capture 
hardware called VIP. A VIP port can capture multiple streams from 
different sensors in time slices, and each of those streams might be 
sharing the same hardware, but probably in different configurations. I'm 
not completely aware of media controller details, and whether it can 
help us here.


I was just wondering if it would be a problem if we later realise that 
mc might be useful for some use cases. Would implementing it then break 
previous user space applications which don't call mc ioctls?






- These blocks will also require some custom control commands later on. For
   example, we may want to tell the scaler later on to perform bi-linear
   scaling, or perform peaking at a particular frequency.

- The current series keeps the default scaler coefficients in a header file.
   These coefficients add a lot of lines of code in the kernel. Does it make 
more
   sense for the user application to pass the co-efficients to the kernel using
   an ioctl? Is there any driver which currenlty does this?


I think it is good to keep it in the driver. Otherwise apps would be forced to
set up the table. It's about 11 kilobyte in memory, which isn't that bad.


Okay.





The series is based on the branch:

git://linuxtv.org/media_tree.git master

Archit Taneja (8):
   v4l: ti-vpe: create a scaler block library
   v4l: ti-vpe: support loading of scaler coefficients
   v4l: ti-vpe: make vpe driver load scaler coefficients
   v4l: ti-vpe: enable basic scaler support
   v4l: ti-vpe: create a color space converter block library
   v4l: ti-vpe: Add helper to perform color conversion
   v4l: ti-vpe: enable CSC support for VPE
   v4l: ti-vpe: Add a type specifier to describe vpdma data format type

  drivers/media/platform/ti-vpe/Makefile   |2 +-
  drivers/media/platform/ti-vpe/csc.c  |  196 +
  drivers/media/platform/ti-vpe/csc.h  |   68 ++
  drivers/media/platform/ti-vpe/sc.c   |  311 +++
  drivers/media/platform/ti-vpe/sc.h   |  208 +
  drivers/media/platform/ti-vpe/sc_coeff.h | 1342 ++
  drivers/media/platform/ti-vpe/vpdma.c|   36 +-
  drivers/media/platform/ti-vpe/vpdma.h|7 +
  drivers/media/platform/ti-vpe/vpe.c  |  251 --
  drivers/media/platform/ti-vpe/vpe_regs.h |  187 -
  10 files changed, 2335 insertions(+), 273 deletions(-)
  create mode 100644 drivers/media/platform/ti-vpe/csc.c
  create mode 100644 drivers/media/platform/ti-vpe/csc.h
  create mode 100644 drivers/media/platform/ti-vpe/sc.c
  create mode 100644 drivers/media/platform/ti-vpe/sc.h
  create mode 100644 drivers/media/platform/ti-vpe/sc_coeff.h



For this patch series:

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


Thanks for the review.

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 0/8] v4l: ti-vpe: Add support for scaling and color conversion

[Hans Verkuil]

On 12/17/13 12:19, Archit Taneja wrote:
 Hi Hans,
 
 On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote:
 On 12/12/2013 09:35 AM, Archit Taneja wrote:
 The VPE and VIP IPs in DRA7x contain common scaler and color
 conversion hardware blocks. We create libraries for these
 components such that the vpe driver and the vip driver(in future)
 can use these library funcs to configure the blocks.
 
 There are some points for which I would like comments:
 
 - For VPE, setting the format and colorspace for the source and
 destination queues is enough to determine how these blocks need
 to be configured and whether they need to be bypassed or not. So
 it didn't make sense to represent them as media controller
 entities. For VIP(driver not upstream yet), it's possible that
 there are multiple data paths which may or may not include these 
 blocks. However, the current use cases don't require such
 flexibility. There may be a need to re-consider a media
 controller like setup once we work on the VIP driver. Is it a
 good idea in terms of user-space compatibilty if we use media
 controller framework in the future.
 
 As long as you don't need the mc, then there is no need to
 implement it.
 
 The thing is that we want to use these blocks for a future capture
 hardware called VIP. A VIP port can capture multiple streams from
 different sensors in time slices, and each of those streams might be
 sharing the same hardware, but probably in different configurations.
 I'm not completely aware of media controller details, and whether it
 can help us here.
 
 I was just wondering if it would be a problem if we later realise
 that mc might be useful for some use cases. Would implementing it
 then break previous user space applications which don't call mc
 ioctls?

My understanding is that in the current vpe driver the mc won't be
needed, so there is no point adding it. When implementing the vip
capture driver the mc might be needed, but that should not require
the vpe to add the mc API as well. It's a decision that has to be
made per driver.

When you start work on the vip driver it is probably a good idea to
talk to Laurent and myself first to see whether the mc is needed or
not.

If you have a block diagram of the video hardware that you can share,
then that will be quite useful.

Regards,

Hans
--
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 0/8] v4l: ti-vpe: Add support for scaling and color conversion

[Archit Taneja]

Hi,

On Tuesday 17 December 2013 05:19 PM, Hans Verkuil wrote:

On 12/17/13 12:19, Archit Taneja wrote:

Hi Hans,

On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote:

On 12/12/2013 09:35 AM, Archit Taneja wrote:

The VPE and VIP IPs in DRA7x contain common scaler and color
conversion hardware blocks. We create libraries for these
components such that the vpe driver and the vip driver(in future)
can use these library funcs to configure the blocks.

There are some points for which I would like comments:

- For VPE, setting the format and colorspace for the source and
destination queues is enough to determine how these blocks need
to be configured and whether they need to be bypassed or not. So
it didn't make sense to represent them as media controller
entities. For VIP(driver not upstream yet), it's possible that
there are multiple data paths which may or may not include these
blocks. However, the current use cases don't require such
flexibility. There may be a need to re-consider a media
controller like setup once we work on the VIP driver. Is it a
good idea in terms of user-space compatibilty if we use media
controller framework in the future.


As long as you don't need the mc, then there is no need to
implement it.


The thing is that we want to use these blocks for a future capture
hardware called VIP. A VIP port can capture multiple streams from
different sensors in time slices, and each of those streams might be
sharing the same hardware, but probably in different configurations.
I'm not completely aware of media controller details, and whether it
can help us here.

I was just wondering if it would be a problem if we later realise
that mc might be useful for some use cases. Would implementing it
then break previous user space applications which don't call mc
ioctls?


My understanding is that in the current vpe driver the mc won't be
needed, so there is no point adding it. When implementing the vip
capture driver the mc might be needed, but that should not require
the vpe to add the mc API as well. It's a decision that has to be
made per driver.


That's right, vpe doesn't need mc. It might be needed for vip. The 
reason I brought it up now is because some of the blocks like SC/CSC are 
replicated in VIP hardware, and I created them in a 'library' sort of 
way in this series. If vip driver uses mc, these blocks might need to 
become media entities.




When you start work on the vip driver it is probably a good idea to
talk to Laurent and myself first to see whether the mc is needed or
not.


Thanks, that'll be quite useful. I'll look up some mc documentation and 
drivers using mc myself as well.




If you have a block diagram of the video hardware that you can share,
then that will be quite useful.


Thanks for the clarification. I don't think the DRA7x documentation is 
public yet. I'll try to look for a block diagram(or create one) and 
share it with the list.


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: [PATCHv10 01/41] clk: add support for platform specific clock I/O wrapper functions

[Paul Walmsley]

On Tue, 26 Nov 2013, Tero Kristo wrote:

 Current clock wrappers assume simple and direct mapped hardware register
 access. Improve this support by adding functionality for registering
 platform specific clock I/O wrappers, which can be used to support
 various features needed like endianess conversions, indexed regmap support,
 etc. Default I/O wrapper provided also which uses the existing direct
 I/O mapped behavior.

I think it makes more sense to define per-SoC register read and write 
functions, for the same reason that I think it makes more sense to define 
clock data as part of the IP blocks that contain the clocks' registers.  
The register read and write functions should be implemented by the drivers 
for the IP blocks that the clocks are contained in.  That way the register 
read and write functions can take whatever steps are necessary to ensure 
that the IP block registers are accessible before performing the 
read/write; can implement non-MMIO register accesses if needed; and can 
operate on register offsets, rather than absolute addresses.

Something like the following draft implementation.  Also needed would be a 
way for clock providers that rely on the common clock providers (e.g., 
divider, mux, etc.) to pass in the struct clk_ll_ops pointer.  I guess the 
simplest way to implement this would be to add another set of registration 
functions - e.g., clk_register_divider_ipb() or clk_register_divider2() or 
something similar.  These functions would be similar to 
clk_register_divider(), but would take a pointer to a struct clk_ll_ops 
and pass that along to the CCF core.


- Paul

---
 drivers/clk/clk-divider.c|  6 +++---
 drivers/clk/clk-gate.c   |  6 +++---
 drivers/clk/clk-mux.c|  6 +++---
 drivers/clk/clk.c| 18 ++
 include/linux/clk-provider.h | 28 +---
 5 files changed, 40 insertions(+), 24 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 8d3009e44fba..55ad7170a6e2 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw 
*hw,
struct clk_divider *divider = to_clk_divider(hw);
unsigned int div, val;
 
-   val = clk_readl(divider-reg)  divider-shift;
+   val = hw-ll_ops-clk_readl(divider-reg)  divider-shift;
val = div_mask(divider);
 
div = _get_div(divider, val);
@@ -230,11 +230,11 @@ static int clk_divider_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (divider-flags  CLK_DIVIDER_HIWORD_MASK) {
val = div_mask(divider)  (divider-shift + 16);
} else {
-   val = clk_readl(divider-reg);
+   val = hw-ll_ops-clk_readl(divider-reg);
val = ~(div_mask(divider)  divider-shift);
}
val |= value  divider-shift;
-   clk_writel(val, divider-reg);
+   hw-ll_ops-clk_writel(val, divider-reg);
 
if (divider-lock)
spin_unlock_irqrestore(divider-lock, flags);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 4a58c55255bd..a60177c7f418 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -58,7 +58,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
if (set)
reg |= BIT(gate-bit_idx);
} else {
-   reg = clk_readl(gate-reg);
+   reg = hw-ll_ops-clk_readl(gate-reg);
 
if (set)
reg |= BIT(gate-bit_idx);
@@ -66,7 +66,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
reg = ~BIT(gate-bit_idx);
}
 
-   clk_writel(reg, gate-reg);
+   hw-ll_ops-clk_writel(reg, gate-reg);
 
if (gate-lock)
spin_unlock_irqrestore(gate-lock, flags);
@@ -89,7 +89,7 @@ static int clk_gate_is_enabled(struct clk_hw *hw)
u32 reg;
struct clk_gate *gate = to_clk_gate(hw);
 
-   reg = clk_readl(gate-reg);
+   reg = hw-ll_ops-clk_readl(gate-reg);
 
/* if a set bit disables this clk, flip it before masking */
if (gate-flags  CLK_GATE_SET_TO_DISABLE)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 4f96ff3ba728..5b808ef5a47b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -42,7 +42,7 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
 * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
 * val = 0x4 really means bit 2, index starts at bit 0
 */
-   val = clk_readl(mux-reg)  mux-shift;
+   val = hw-ll_ops-clk_readl(mux-reg)  mux-shift;
val = mux-mask;
 
if (mux-table) {
@@ -89,11 +89,11 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
if (mux-flags  CLK_MUX_HIWORD_MASK) {
val = mux-mask  (mux-shift + 16);
} else {
-   val = clk_readl(mux-reg);
+   val = 

[PATCH 4/7] iommu/omap: Allow enable/disable even without pdata

[Florian Vaussard]

When booting with a devietree, no platform data is provided. Do not prematurely
exit iommu_enable() and iommu_disable() in such a case.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 drivers/iommu/omap-iommu.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 51efcc4..0a9854d 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -149,13 +149,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
 
-   if (!pdata)
-   return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
 
-   if (pdata-deassert_reset) {
+   if (pdata  pdata-deassert_reset) {
err = pdata-deassert_reset(pdev, pdata-reset_name);
if (err) {
dev_err(obj-dev, deassert_reset failed: %d\n, err);
@@ -175,14 +172,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
 
-   if (!pdata)
-   return;
-
arch_iommu-disable(obj);
 
pm_runtime_put_sync(obj-dev);
 
-   if (pdata-assert_reset)
+   if (pdata  pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
 }
 
-- 
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 1/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds

[Florian Vaussard]

Currently, bus_set_iommu() is done in omap_iommu_init(). However,
omap_iommu_probe() can fail in a number of ways, leaving the platform
bus with a dangling reference to a non-initialized iommu. Perform
bus_set_iommu() only if omap_iommu_probe() succeed.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 drivers/iommu/omap-iommu.c | 207 +++--
 1 file changed, 104 insertions(+), 103 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..ee83bcc 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -930,107 +930,6 @@ static void omap_iommu_detach(struct omap_iommu *obj)
dev_dbg(obj-dev, %s: %s\n, __func__, obj-name);
 }
 
-/*
- * OMAP Device MMU(IOMMU) detection
- */
-static int omap_iommu_probe(struct platform_device *pdev)
-{
-   int err = -ENODEV;
-   int irq;
-   struct omap_iommu *obj;
-   struct resource *res;
-   struct iommu_platform_data *pdata = pdev-dev.platform_data;
-
-   obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
-   if (!obj)
-   return -ENOMEM;
-
-   obj-nr_tlb_entries = pdata-nr_tlb_entries;
-   obj-name = pdata-name;
-   obj-dev = pdev-dev;
-   obj-ctx = (void *)obj + sizeof(*obj);
-   obj-da_start = pdata-da_start;
-   obj-da_end = pdata-da_end;
-
-   spin_lock_init(obj-iommu_lock);
-   mutex_init(obj-mmap_lock);
-   spin_lock_init(obj-page_table_lock);
-   INIT_LIST_HEAD(obj-mmap);
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   err = -ENODEV;
-   goto err_mem;
-   }
-
-   res = request_mem_region(res-start, resource_size(res),
-dev_name(pdev-dev));
-   if (!res) {
-   err = -EIO;
-   goto err_mem;
-   }
-
-   obj-regbase = ioremap(res-start, resource_size(res));
-   if (!obj-regbase) {
-   err = -ENOMEM;
-   goto err_ioremap;
-   }
-
-   irq = platform_get_irq(pdev, 0);
-   if (irq  0) {
-   err = -ENODEV;
-   goto err_irq;
-   }
-   err = request_irq(irq, iommu_fault_handler, IRQF_SHARED,
- dev_name(pdev-dev), obj);
-   if (err  0)
-   goto err_irq;
-   platform_set_drvdata(pdev, obj);
-
-   pm_runtime_irq_safe(obj-dev);
-   pm_runtime_enable(obj-dev);
-
-   dev_info(pdev-dev, %s registered\n, obj-name);
-   return 0;
-
-err_irq:
-   iounmap(obj-regbase);
-err_ioremap:
-   release_mem_region(res-start, resource_size(res));
-err_mem:
-   kfree(obj);
-   return err;
-}
-
-static int omap_iommu_remove(struct platform_device *pdev)
-{
-   int irq;
-   struct resource *res;
-   struct omap_iommu *obj = platform_get_drvdata(pdev);
-
-   iopgtable_clear_entry_all(obj);
-
-   irq = platform_get_irq(pdev, 0);
-   free_irq(irq, obj);
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   release_mem_region(res-start, resource_size(res));
-   iounmap(obj-regbase);
-
-   pm_runtime_disable(obj-dev);
-
-   dev_info(pdev-dev, %s removed\n, obj-name);
-   kfree(obj);
-   return 0;
-}
-
-static struct platform_driver omap_iommu_driver = {
-   .probe  = omap_iommu_probe,
-   .remove = omap_iommu_remove,
-   .driver = {
-   .name   = omap-iommu,
-   },
-};
-
 static void iopte_cachep_ctor(void *iopte)
 {
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
@@ -1265,6 +1164,110 @@ static struct iommu_ops omap_iommu_ops = {
.pgsize_bitmap  = OMAP_IOMMU_PGSIZES,
 };
 
+/*
+ * OMAP Device MMU(IOMMU) detection
+ */
+static int omap_iommu_probe(struct platform_device *pdev)
+{
+   int err = -ENODEV;
+   int irq;
+   struct omap_iommu *obj;
+   struct resource *res;
+   struct iommu_platform_data *pdata = pdev-dev.platform_data;
+
+   obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
+   if (!obj)
+   return -ENOMEM;
+
+   obj-nr_tlb_entries = pdata-nr_tlb_entries;
+   obj-name = pdata-name;
+   obj-dev = pdev-dev;
+   obj-ctx = (void *)obj + sizeof(*obj);
+   obj-da_start = pdata-da_start;
+   obj-da_end = pdata-da_end;
+
+   spin_lock_init(obj-iommu_lock);
+   mutex_init(obj-mmap_lock);
+   spin_lock_init(obj-page_table_lock);
+   INIT_LIST_HEAD(obj-mmap);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   err = -ENODEV;
+   goto err_mem;
+   }
+
+   res = request_mem_region(res-start, resource_size(res),
+dev_name(pdev-dev));
+   if (!res) {
+   err = -EIO;
+   goto err_mem;
+   }
+
+   obj-regbase = ioremap(res-start, resource_size(res));
+   if (!obj-regbase) {
+   err = 

[PATCH 2/7] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL

[Florian Vaussard]

omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value (in
case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.

In such case, omap_iommu_attach() should return ENODEV, not NULL.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 drivers/iommu/omap-iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index ee83bcc..385bf5e 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev, void 
*data)
  **/
 static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
 {
-   int err = -ENOMEM;
+   int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
 
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const char 
*name, u32 *iopgd)
(void *)name,
device_match_by_alias);
if (!dev)
-   return NULL;
+   return ERR_PTR(err);
 
obj = to_iommu(dev);
 
-- 
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 5/7] ARM: dts: Complete data for isp iommu

[Florian Vaussard]

Add missing information required to probe the iommu for the camera
subsystem.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap3.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99..610d084 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -371,11 +371,13 @@
dma-names = tx, rx;
};
 
-   mmu_isp: mmu@480bd400 {
+   mmu_isp: mmu_isp@480bd400 {
compatible = ti,omap3-mmu-isp;
ti,hwmods = mmu_isp;
reg = 0x480bd400 0x80;
interrupts = 8;
+   ti,#tlb-entries = 8;
+   dma-window = 0 0xf000;/* IOVA start  length 
*/
};
 
wdt2: wdt@48314000 {
-- 
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 6/7] ARM: OMAP2+: Remove legacy data from hwmod for omap3 isp iommu

[Florian Vaussard]

The data are now passed using the devicetree.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0477131..6dccd46 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2469,15 +2469,8 @@ static struct omap_hwmod_class omap3xxx_mmu_hwmod_class 
= {
 
 /* mmu isp */
 
-static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
-   .da_start   = 0x0,
-   .da_end = 0xf000,
-   .nr_tlb_entries = 8,
-};
-
 static struct omap_hwmod omap3xxx_mmu_isp_hwmod;
 
-
 /* l4_core - mmu isp */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = {
.master = omap3xxx_l4_core_hwmod,
@@ -2489,7 +2482,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.name   = mmu_isp,
.class  = omap3xxx_mmu_hwmod_class,
.main_clk   = cam_ick,
-   .dev_attr   = mmu_isp_dev_attr,
.flags  = HWMOD_NO_IDLEST,
 };
 
-- 
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 7/7] ARM: OMAP2+: Remove platform-specific omap-iommu

[Florian Vaussard]

With full DT boot, the platform specific part of the OMAP iommu
is not useful anymore.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/mach-omap2/Makefile |  3 --
 arch/arm/mach-omap2/omap-iommu.c | 79 
 2 files changed, 82 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/omap-iommu.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 35be79f..4e01b61 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -219,9 +219,6 @@ obj-$(CONFIG_SOC_DRA7XX)+= omap_hwmod_7xx_data.o
 obj-$(CONFIG_OMAP3_EMU)+= emu.o
 obj-$(CONFIG_HW_PERF_EVENTS)   += pmu.o
 
-iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
-obj-y  += $(iommu-m) $(iommu-y)
-
 ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y  += dsp.o
 endif
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
deleted file mode 100644
index f1fab56..000
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ /dev/null
@@ -1,79 +0,0 @@
-/*
- * omap iommu: omap device registration
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/of.h
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/err.h
-#include linux/slab.h
-
-#include linux/platform_data/iommu-omap.h
-#include soc.h
-#include omap_hwmod.h
-#include omap_device.h
-
-static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
-{
-   struct platform_device *pdev;
-   struct iommu_platform_data *pdata;
-   struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
-   static int i;
-
-   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
-   if (!pdata)
-   return -ENOMEM;
-
-   pdata-name = oh-name;
-   pdata-nr_tlb_entries = a-nr_tlb_entries;
-   pdata-da_start = a-da_start;
-   pdata-da_end = a-da_end;
-
-   if (oh-rst_lines_cnt == 1) {
-   pdata-reset_name = oh-rst_lines-name;
-   pdata-assert_reset = omap_device_assert_hardreset;
-   pdata-deassert_reset = omap_device_deassert_hardreset;
-   }
-
-   pdev = omap_device_build(omap-iommu, i, oh, pdata, sizeof(*pdata));
-
-   kfree(pdata);
-
-   if (IS_ERR(pdev)) {
-   pr_err(%s: device build err: %ld\n, __func__, PTR_ERR(pdev));
-   return PTR_ERR(pdev);
-   }
-
-   i++;
-
-   return 0;
-}
-
-static int __init omap_iommu_init(void)
-{
-   /* If dtb is there, the devices will be created dynamically */
-   if (of_have_populated_dt())
-   return -ENODEV;
-
-   return omap_hwmod_for_each_by_class(mmu, omap_iommu_dev_init, NULL);
-}
-/* must be ready before omap3isp is probed */
-omap_subsys_initcall(omap_iommu_init);
-
-static void __exit omap_iommu_exit(void)
-{
-   /* Do nothing */
-}
-module_exit(omap_iommu_exit);
-
-MODULE_AUTHOR(Hiroshi DOYU);
-MODULE_DESCRIPTION(omap iommu: omap device registration);
-MODULE_LICENSE(GPL v2);
-- 
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 0/7] Fix omap-iommu probe and convert to DT for 3.14

[Florian Vaussard]

OMAP2+ is heading towards a full device tree boot for 3.14. Currently,
the iommu used by the OMAP3 camera subsystem is not yet converted. It
cannot be probed as necessary data are only passed through device tree.

Patches 1 and 2 are small fixes for problems encountered while developing
this series.

Patches 3 to 5 add the device tree logic to omap-iommu, and complete iommu
data in omap3.dtsi. Patches 6 and 7 remove unused iommu hwmod data and
platform code from OMAP2+.

This was tested on Overo (OMAP36xx) with an MT9V032 sensor connected
to the isp interface. The full testing tree can be found here [2] (not
safe for merging).

Patches are based on 3.13-rc3. OMAP-related patches are based on Tony's
omap-for-v3.14/omap3-board-removal branch [1].

Regards,

Florian

[1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
  omap-for-v3.14/omap3-board-removal
[2] g...@github.com:vaussard/linux.git overo-for-3.14/iommu/dt

Florian Vaussard (7):
  iommu/omap: Do bus_set_iommu() only if probe() succeeds
  iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
  iommu/omap: Convert to devicetree
  iommu/omap: Allow enable/disable even without pdata
  ARM: dts: Complete data for isp iommu
  ARM: OMAP2+: Remove legacy data from hwmod for omap3 isp iommu
  ARM: OMAP2+: Remove platform-specific omap-iommu

 .../devicetree/bindings/iommu/ti,omap-iommu.txt|  19 ++
 arch/arm/boot/dts/omap3.dtsi   |   4 +-
 arch/arm/mach-omap2/Makefile   |   3 -
 arch/arm/mach-omap2/omap-iommu.c   |  74 --
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   8 -
 drivers/iommu/omap-iommu.c | 247 +++--
 6 files changed, 156 insertions(+), 199 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
 delete mode 100644 arch/arm/mach-omap2/omap-iommu.c

-- 
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 3/7] iommu/omap: Convert to devicetree

[Florian Vaussard]

As OMAP2+ is moving to a full DT boot for 3.14, commit 7ce93f3
ARM: OMAP2+: Fix more missing data for omap3.dtsi file adds
basic DT bits. But the driver is not yet converted, so this will
not work and driver will not be probed. Convert it!

Apart from standard bindings, this patch uses 'dma-window' (already
used by Tegra SMMU) and adds a custom 'ti,#tlb-entries' binding.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 .../devicetree/bindings/iommu/ti,omap-iommu.txt| 19 
 arch/arm/mach-omap2/omap-iommu.c   |  5 +++
 drivers/iommu/omap-iommu.c | 36 +++---
 3 files changed, 55 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt 
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
new file mode 100644
index 000..4e5027c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,19 @@
+OMAP3 IOMMU used by camera subsystem
+
+Required properties:
+- compatible : ti,omap3-mmu-isp
+- ti,hwmods : mmu_isp
+- reg : address space for the configuration registers
+- interrupts : interrupt line
+- dma-window : IOVA start address and length.
+- ti,#tlb-entries : number of entries in the translation look-aside buffer
+
+Example:
+   mmu_isp: mmu_isp@480bd400 {
+   compatible = ti,omap3-mmu-isp;
+   ti,hwmods = mmu_isp;
+   reg = 0x480bd400 0x80;
+   interrupts = 8;
+   dma-window = 0 0xf000;
+   ti,#tlb-entries = 8;
+   };
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f6daae8..f1fab56 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
  */
 
+#include linux/of.h
 #include linux/module.h
 #include linux/platform_device.h
 #include linux/err.h
@@ -58,6 +59,10 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, 
void *unused)
 
 static int __init omap_iommu_init(void)
 {
+   /* If dtb is there, the devices will be created dynamically */
+   if (of_have_populated_dt())
+   return -ENODEV;
+
return omap_hwmod_for_each_by_class(mmu, omap_iommu_dev_init, NULL);
 }
 /* must be ready before omap3isp is probed */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 385bf5e..51efcc4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -23,6 +23,9 @@
 #include linux/spinlock.h
 #include linux/io.h
 #include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_iommu.h
+#include linux/of_irq.h
 
 #include asm/cacheflush.h
 
@@ -1171,20 +1174,30 @@ static int omap_iommu_probe(struct platform_device 
*pdev)
 {
int err = -ENODEV;
int irq;
+   size_t len;
struct omap_iommu *obj;
struct resource *res;
struct iommu_platform_data *pdata = pdev-dev.platform_data;
+   struct device_node *of = pdev-dev.of_node;
 
obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
 
-   obj-nr_tlb_entries = pdata-nr_tlb_entries;
-   obj-name = pdata-name;
+   if (of) {
+   obj-name = of-name;
+   of_property_read_u32(of, ti,#tlb-entries,
+obj-nr_tlb_entries);
+   of_get_dma_window(of, NULL, 0, NULL, obj-da_start, len);
+   obj-da_end = obj-da_start + len;
+   } else {
+   obj-nr_tlb_entries = pdata-nr_tlb_entries;
+   obj-name = pdata-name;
+   obj-da_start = pdata-da_start;
+   obj-da_end = pdata-da_end;
+   }
obj-dev = pdev-dev;
obj-ctx = (void *)obj + sizeof(*obj);
-   obj-da_start = pdata-da_start;
-   obj-da_end = pdata-da_end;
 
spin_lock_init(obj-iommu_lock);
mutex_init(obj-mmap_lock);
@@ -1210,7 +1223,11 @@ static int omap_iommu_probe(struct platform_device *pdev)
goto err_ioremap;
}
 
-   irq = platform_get_irq(pdev, 0);
+   if (of)
+   irq = irq_of_parse_and_map(of, 0);
+   else
+   irq = platform_get_irq(pdev, 0);
+
if (irq  0) {
err = -ENODEV;
goto err_irq;
@@ -1260,11 +1277,20 @@ static int omap_iommu_remove(struct platform_device 
*pdev)
return 0;
 }
 
+#if defined(CONFIG_OF)
+static struct of_device_id omap_iommu_of_match[] = {
+   { .compatible = ti,omap3-mmu-isp },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+#endif
+
 static struct platform_driver omap_iommu_driver = {
.probe  = omap_iommu_probe,
.remove = omap_iommu_remove,
.driver = {
.name   = omap-iommu,
+   .of_match_table = omap_iommu_of_match,

mmc only working when used in U-Boot

[Stefan Roese]

Hi!

I've noticed on a custom OMAP3530 board, that the SDcard (mmc1) is only
detected, when its previously used in U-Boot (e.g. by mmc rescan). So
I tested on beagleboard and it behaved identical. 

Here the boot log with U-Boot scanning mmc before Linux booting:

root@generic-armv7a:~# dmesg | grep mmc
[2.225006] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.234100] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.260040] omap_hsmmc 4809c000.mmc: pins are not configured from the driver
[2.398071] mmc0: host does not support reading read-only switch. assuming 
write-enable.
[2.408416] mmc0: new high speed SD card at address 0007
[2.419128] mmcblk0: mmc0:0007 SD02G 1.90 GiB 
[2.426025]  mmcblk0: p1 p2
[   10.241638] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. 
Opts: (null)
[   10.256011] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data 
may be corrupt. Please run fsck.

Here the boot log without U-Boot touching mmc before Linux booting:

root@generic-armv7a:~# dmesg | grep mmc
[2.162689] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.171936] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.197906] omap_hsmmc 4809c000.mmc: pins are not configured from the driver

I also added the pin mux'es for the mmc to the dts and the last message
is gone. But this doesn't help with mmc detection.

BTW: This is on latest mainline Linux.

Somehow U-Boot configured/enables something that is missing in the
Linux driver. Is this a known issue? Any ideas?

Thanks,
Stefan
--
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: mmc only working when used in U-Boot

[Balaji T K]

On Tuesday 17 December 2013 07:11 PM, Stefan Roese wrote:

Hi!

I've noticed on a custom OMAP3530 board, that the SDcard (mmc1) is only
detected, when its previously used in U-Boot (e.g. by mmc rescan). So
I tested on beagleboard and it behaved identical.

Here the boot log with U-Boot scanning mmc before Linux booting:

root@generic-armv7a:~# dmesg | grep mmc
[2.225006] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.234100] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.260040] omap_hsmmc 4809c000.mmc: pins are not configured from the driver
[2.398071] mmc0: host does not support reading read-only switch. assuming 
write-enable.
[2.408416] mmc0: new high speed SD card at address 0007
[2.419128] mmcblk0: mmc0:0007 SD02G 1.90 GiB
[2.426025]  mmcblk0: p1 p2
[   10.241638] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. 
Opts: (null)
[   10.256011] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data 
may be corrupt. Please run fsck.

Here the boot log without U-Boot touching mmc before Linux booting:

root@generic-armv7a:~# dmesg | grep mmc
[2.162689] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.171936] of_get_named_gpiod_flags: can't parse gpios property of node 
'/ocp/mmc@4809c000[0]'
[2.197906] omap_hsmmc 4809c000.mmc: pins are not configured from the driver

I also added the pin mux'es for the mmc to the dts and the last message
is gone. But this doesn't help with mmc detection.

BTW: This is on latest mainline Linux.

Somehow U-Boot configured/enables something that is missing in the
Linux driver. Is this a known issue? Any ideas?



If you are using dt boot, mostly likely it is because of missing pbias
configuration.


Thanks,
Stefan



--
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: mmc only working when used in U-Boot

[Stefan Roese]

On 17.12.2013 14:48, Balaji T K wrote:
 On Tuesday 17 December 2013 07:11 PM, Stefan Roese wrote:
 Hi!

 I've noticed on a custom OMAP3530 board, that the SDcard (mmc1) is only
 detected, when its previously used in U-Boot (e.g. by mmc rescan). So
 I tested on beagleboard and it behaved identical.

 Here the boot log with U-Boot scanning mmc before Linux booting:

 root@generic-armv7a:~# dmesg | grep mmc
 [2.225006] of_get_named_gpiod_flags: can't parse gpios property of node 
 '/ocp/mmc@4809c000[0]'
 [2.234100] of_get_named_gpiod_flags: can't parse gpios property of node 
 '/ocp/mmc@4809c000[0]'
 [2.260040] omap_hsmmc 4809c000.mmc: pins are not configured from the 
 driver
 [2.398071] mmc0: host does not support reading read-only switch. 
 assuming write-enable.
 [2.408416] mmc0: new high speed SD card at address 0007
 [2.419128] mmcblk0: mmc0:0007 SD02G 1.90 GiB
 [2.426025]  mmcblk0: p1 p2
 [   10.241638] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
 mode. Opts: (null)
 [   10.256011] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some 
 data may be corrupt. Please run fsck.

 Here the boot log without U-Boot touching mmc before Linux booting:

 root@generic-armv7a:~# dmesg | grep mmc
 [2.162689] of_get_named_gpiod_flags: can't parse gpios property of node 
 '/ocp/mmc@4809c000[0]'
 [2.171936] of_get_named_gpiod_flags: can't parse gpios property of node 
 '/ocp/mmc@4809c000[0]'
 [2.197906] omap_hsmmc 4809c000.mmc: pins are not configured from the 
 driver

 I also added the pin mux'es for the mmc to the dts and the last message
 is gone. But this doesn't help with mmc detection.

 BTW: This is on latest mainline Linux.

 Somehow U-Boot configured/enables something that is missing in the
 Linux driver. Is this a known issue? Any ideas?

 
 If you are using dt boot, mostly likely it is because of missing pbias
 configuration.

Ah, yes. I had already tried with your 7 patches series (v4). But it
seems that I forgot to add CONFIG_MFD_SYSCON and CONFIG_REGULATOR_PBIAS.
With this now, the SD card is detected even without any U-Boot activity.

Thanks,
Stefan

--
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: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support

[Laurent Pinchart]

Hi Tomi,

On Tuesday 17 December 2013 09:15:58 Tomi Valkeinen wrote:
 On 2013-12-17 09:05, Sascha Hauer wrote:
  On Mon, Dec 16, 2013 at 04:56:30PM +0200, Tomi Valkeinen wrote:
  Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
  ---
  
   drivers/video/omap2/displays-new/connector-dvi.c | 43 ++
   1 file changed, 43 insertions(+)
  
  diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
  b/drivers/video/omap2/displays-new/connector-dvi.c index
  b6c50904038e..d1204b1c5182 100644
  
  +static const struct of_device_id dvic_of_match[] = {
  +  { .compatible = dvi-connector, },
  
  Either the driver is too specific or the binding is too generic, but
  having such a generic name for an omap specific driver seems wrong. Same
  for panel-dpi, svideo-connector, composite-video-connector and
  hdmi-connector,

 Hmm. Good point. I was thinking that the driver is only used on OMAP, but of
 course that's not true, the driver is there for all platforms if the kernel
 just happens to be compiled with the driver.
 
 And it's not just about those drivers you mention. The same issue is there
 for, say, ti,tpd12s015. I have an omapdss specific driver for that, but if
 some other platform uses the same chip, they'll have a driver for it also...
 
 Sigh. I wonder how this should be handled... The only solution that comes to
 my mind is to have all the compatible strings as ti, But that's not
 correct, as they are not TI components, but some are generic ones and some
 from another vendor.
 
 And even ti,... is not good, as there are other TI SoCs with other display
 drivers. So I'd need to prepend the compatible strings with omapdss,...,
 making the hardware components driver specific.
 
 The long term plan is to make the drivers generic (or implement the same
 driver for common display framework). But for now I need to have future
 proof DT bindings with omapdss specific drivers...

I'll refrain from mentioning that the problem has been identified more than a 
year ago. Oh, wait, I've metioned it, sorry :-D

We really want to make drivers generic enough to be shared by multiple display 
controllers. I would vote for making the DT bindings generic now already, 
which would be enough to buy some time to fix the problem properly. If we 
start prepending driver-specific prefixes such as omapdss, to compatible 
string we'll just make the mess even larger and reduce the incentive to fix 
it. It would be the worst decision we could make.

-- 
Regards,

Laurent Pinchart


signature.asc
Description: This is a digitally signed message part.

Re: [GIT PULL] make mach-omap2 boot with device tree only for v3.14

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [131216 23:16]:
 On Fri, 13 Dec 2013, Tony Lindgren wrote:
 
  OK posted a patch for the SBC-T3730 with minimal support also for
  SBC-3530 and SBC-3517 that should boot far enough to start adding
  more devices. Paul, care to try it on the CM-T3517, the patch is:
  
  [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
 
 Didn't get anything out of the serial port:
 
 http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/cmt3517/cmt3517_log.txt

OK thanks for testing. Looks like the CompuLab guys will need to
take a look at it. I'll update my patch for SBC-T3730 only with the
comments from Igor.
 
 As a partial sanity check, AM3517 EVM was included as part of the run 
 (with a separate uImage+dtb of course) and that seems to boot OK:
 
 http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/3517evm/3517evm_log.txt

Hmm OK, weird that the 3517 EVM boots but not the CM-T3517.
 
 In case it's useful, here's a CM-T3517 boot log from v3.13-rc4:
 
 http://www.pwsan.com/omap/testlogs/test_v3.13-rc4/20131215195251/boot/cmt3517/cmt3517_log.txt

OK thanks.

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: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack

[Tony Lindgren]

* Tomi Valkeinen tomi.valkei...@ti.com [131216 22:47]:
 On 2013-12-16 20:41, Tony Lindgren wrote:
  * Tomi Valkeinen tomi.valkei...@ti.com [131216 06:59]:
  As a temporary solution to enable DSS for selected boards when booting
  with DT, a hack was added to board-generic.c in
  63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
  DSS for panda  sdp boards).
 
  We're now adding proper DT support, so the hack can be removed.
  
  I guess this patch should be merged later on after we have the DT support
  working?
 
 I'll move this patch also to the end of the series.
 
 Merged later sounds like you mean this could be merged in a separate
 series. I think this and the other removal can be in this series, they
 just need to be at the end.

Well yeah let's keep those separate still as at least Russell needed
some more time with the legacy booting. The point we can drop the
legacy booting for omap3 may still need to wait a bit, maybe even
until v3.15 to keep things working.

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 V3] usb: musb: Fix unstable init of OTG_INTERFSEL.

[anaumann]

From: Andreas Naumann anaum...@ultratronik.de

This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.

Fix it by not writing the value on runtime resume if it has not been
initialized yet.

Signed-off-by: Andreas Naumann anaum...@ultratronik.de
---
Even though I find the implementation a bit awkward this should fix
the issue without breaking anything else. Hope everyone is happy 
with this.

 drivers/usb/musb/omap2430.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 4315d35..fbe2c08 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -48,6 +48,7 @@ struct omap2430_glue {
enum omap_musb_vbus_id_status status;
struct work_struct  omap_musb_mailbox_work;
struct device   *control_otghs;
+   u8  initialized;
 };
 #define glue_to_musb(g)platform_get_drvdata(g-musb)
 
@@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
}
 
musb_writel(musb-mregs, OTG_INTERFSEL, l);
+   glue-initialized = 1;
 
pr_debug(HS USB OTG: revision 0x%x, sysconfig 0x%02x, 
sysstatus 0x%x, intrfsel 0x%x, simenable  0x%x\n,
@@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device *pdev)
glue-dev   = pdev-dev;
glue-musb  = musb;
glue-status= OMAP_MUSB_UNKNOWN;
+   glue-initialized   = 0;
 
if (np) {
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
@@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device *dev)
 
if (musb) {
omap2430_low_level_init(musb);
-   musb_writel(musb-mregs, OTG_INTERFSEL,
+   if(glue-initialized)
+   musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
 
usb_phy_set_suspend(musb-xceiv, 0);
-- 
1.8.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: [PATCHv2 17/27] ARM: omap3-tobi.dts: add lcd (TEST)

[Florian Vaussard]

Hello

On 12/16/2013 03:56 PM, Tomi Valkeinen wrote:
 This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
 doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
 it as a test.
 
 Not to be merged.
 

FYI, I got the DVI (HDMI connector) on the Overo/Tobi to work with the patch
below (not to be merged, and probably corrupted by our mail server), until a
framebuffer console. So for me:

Tested-by: Florian Vaussard florian.vauss...@epfl.ch

Regards,
Florian

8 
From 29237c38d35b833efe304b1a58463127555c4748 Mon Sep 17 00:00:00 2001
From: Florian Vaussard florian.vauss...@epfl.ch
Date: Tue, 17 Dec 2013 17:47:04 +0100
Subject: [PATCH] ARM: omap3-tobi.dts: add dvi output

Add DVI output to Overo/Tobi board.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
 arch/arm/boot/dts/omap3-overo.dtsi | 33 +++
 arch/arm/boot/dts/omap3-tobi.dts   | 54
++
 2 files changed, 87 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index a461d2f..90b08f6 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -89,6 +89,39 @@
0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx */
;
};
+
+   dss_dpi_pins: pinmux_dss_dpi_pins {
+   pinctrl-single,pins = 
+   0x0a4 (PIN_OUTPUT | MUX_MODE0)   /*
dss_pclk.dss_pclk */
+   0x0a6 (PIN_OUTPUT | MUX_MODE0)   /*
dss_hsync.dss_hsync */
+   0x0a8 (PIN_OUTPUT | MUX_MODE0)   /*
dss_vsync.dss_vsync */
+   0x0aa (PIN_OUTPUT | MUX_MODE0)   /*
dss_acbias.dss_acbias */
+   0x0ac (PIN_OUTPUT | MUX_MODE0)   /*
dss_data0.dss_data0 */
+   0x0ae (PIN_OUTPUT | MUX_MODE0)   /*
dss_data1.dss_data1 */
+   0x0b0 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data2.dss_data2 */
+   0x0b2 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data3.dss_data3 */
+   0x0b4 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data4.dss_data4 */
+   0x0b6 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data5.dss_data5 */
+   0x0b8 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data6.dss_data6 */
+   0x0ba (PIN_OUTPUT | MUX_MODE0)   /*
dss_data7.dss_data7 */
+   0x0bc (PIN_OUTPUT | MUX_MODE0)   /*
dss_data8.dss_data8 */
+   0x0be (PIN_OUTPUT | MUX_MODE0)   /*
dss_data9.dss_data9 */
+   0x0c0 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data10.dss_data10 */
+   0x0c2 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data11.dss_data11 */
+   0x0c4 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data12.dss_data12 */
+   0x0c6 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data13.dss_data13 */
+   0x0c8 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data14.dss_data14 */
+   0x0ca (PIN_OUTPUT | MUX_MODE0)   /*
dss_data15.dss_data15 */
+   0x0cc (PIN_OUTPUT | MUX_MODE0)   /*
dss_data16.dss_data16 */
+   0x0ce (PIN_OUTPUT | MUX_MODE0)   /*
dss_data17.dss_data17 */
+   0x0d0 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data18.dss_data18 */
+   0x0d2 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data19.dss_data19 */
+   0x0d4 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data20.dss_data20 */
+   0x0d6 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data21.dss_data21 */
+   0x0d8 (PIN_OUTPUT | MUX_MODE0)   /*
dss_data22.dss_data22 */
+   0x0da (PIN_OUTPUT | MUX_MODE0)   /*
dss_data23.dss_data23 */
+   ;
+   };
 };

 uart3 {
diff --git a/arch/arm/boot/dts/omap3-tobi.dts
b/arch/arm/boot/dts/omap3-tobi.dts
index 7e4ad2a..bfb1a1d 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -81,3 +81,57 @@
 mmc3 {
status = disabled;
 };
+
+dss {
+   pinctrl-names = default;
+   pinctrl-0 = dss_dpi_pins;
+
+   vdds_dsi-supply = vpll2;
+
+   dpi_out: endpoint {
+   remote-endpoint = tfp410_in;
+   data-lines = 24;
+   };
+};
+
+/ {
+   aliases {
+   display0 = dvi0;
+   };
+
+   tfp410: encoder@0 {
+   compatible = ti,tfp410;
+
+   ports {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   port@0 {
+   reg = 0;
+
+   tfp410_in: endpoint@0 {
+   remote-endpoint = dpi_out;
+   };
+   };
+
+   port@1 {
+   reg = 1;
+
+   tfp410_out: endpoint@0 {
+  

Re: [PATCH 0/4] OMAPDSS: DT support for N900 panel

[Sebastian Reichel]

On Tue, Dec 17, 2013 at 09:37:35AM +0200, Tomi Valkeinen wrote:
 Hi,
 
 On 2013-12-13 20:17, Sebastian Reichel wrote:
  Hi,
  
  This patchset adds DT support for the N900 panel. The patchset is based on
  Tomi's work/dss-dt-2 branch [0]. I suggest to send the DT changes through
  Benoits queue, since I have more N900 DT changes for 3.14. Also the patch
  editing the rx51 boardcode can be dropped, since the file is removed in 
  3.14.
  I included those two with this patchset, since they are needed to test the
  other two patches.
  
  I did not include a documentation for the DT API, since the omapdss
  documentation is still missing.
  
  I have successfully tested this on the N900.
  
  [0] 
  https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=work/dss-dt-2
 
 I added N900 display DT support on top of my v2 series, including
 pinmuxing. Can you check if it looks right and works?
 
 git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt

I just tried it and it does not work. On a first look the pinmuxing
looks fishy: 0x0d4 is muxed two times.

I will have a more detailed look into this later.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 0/4] OMAPDSS: DT support for N900 panel

[Tomi Valkeinen]

On 2013-12-17 19:14, Sebastian Reichel wrote:
 On Tue, Dec 17, 2013 at 09:37:35AM +0200, Tomi Valkeinen wrote:
 Hi,

 On 2013-12-13 20:17, Sebastian Reichel wrote:
 Hi,

 This patchset adds DT support for the N900 panel. The patchset is based on
 Tomi's work/dss-dt-2 branch [0]. I suggest to send the DT changes through
 Benoits queue, since I have more N900 DT changes for 3.14. Also the patch
 editing the rx51 boardcode can be dropped, since the file is removed in 
 3.14.
 I included those two with this patchset, since they are needed to test the
 other two patches.

 I did not include a documentation for the DT API, since the omapdss
 documentation is still missing.

 I have successfully tested this on the N900.

 [0] 
 https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=work/dss-dt-2

 I added N900 display DT support on top of my v2 series, including
 pinmuxing. Can you check if it looks right and works?

 git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
 
 I just tried it and it does not work. On a first look the pinmuxing
 looks fishy: 0x0d4 is muxed two times.

Hmm, so it is.

I'm not really familiar with SDI, I just muxed all the SDI pins, except
datapair3. I previously thought that there's only the data and clock
pairs for SDI, but the TRM revealed more sdi pins, so I included them.
It is well possible that these can be removed:

0x0d0 (PIN_OUTPUT | MUX_MODE1)   /* dss_data18.sdi_vsync */
0x0d2 (PIN_OUTPUT | MUX_MODE1)   /* dss_data19.sdi_hsync */
0x0d4 (PIN_OUTPUT | MUX_MODE1)   /* dss_data20.sdi_den */
0x0d6 (PIN_OUTPUT | MUX_MODE1)   /* dss_data21.sdi_stp */

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.

[David Cohen]

On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:
 From: Andreas Naumann anaum...@ultratronik.de
 
 This is a hard to reproduce problem which leads to non-functional
 USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
 e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
 of OTG_INTERFSEL over suspend.
 Since the resume function is also called early in driver init, it uses a
 non-initialized value (which is 0 and a non-supported setting in DM37xx
 for INTERFSEL). Shortly after the correct value is set. Apparently this
 works most time, but not always.
 
 Fix it by not writing the value on runtime resume if it has not been
 initialized yet.
 
 Signed-off-by: Andreas Naumann anaum...@ultratronik.de
 ---
 Even though I find the implementation a bit awkward this should fix
 the issue without breaking anything else. Hope everyone is happy 
 with this.
 
  drivers/usb/musb/omap2430.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
 index 4315d35..fbe2c08 100644
 --- a/drivers/usb/musb/omap2430.c
 +++ b/drivers/usb/musb/omap2430.c
 @@ -48,6 +48,7 @@ struct omap2430_glue {
   enum omap_musb_vbus_id_status status;
   struct work_struct  omap_musb_mailbox_work;
   struct device   *control_otghs;
 + u8  initialized;
  };
  #define glue_to_musb(g)  platform_get_drvdata(g-musb)
  
 @@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
   }
  
   musb_writel(musb-mregs, OTG_INTERFSEL, l);
 + glue-initialized = 1;
  
   pr_debug(HS USB OTG: revision 0x%x, sysconfig 0x%02x, 
   sysstatus 0x%x, intrfsel 0x%x, simenable  0x%x\n,
 @@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device *pdev)
   glue-dev   = pdev-dev;
   glue-musb  = musb;
   glue-status= OMAP_MUSB_UNKNOWN;
 + glue-initialized   = 0;

You don't need to do this. 'glue' was already allocated with kzalloc().

  
   if (np) {
   pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
 @@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device *dev)
  
   if (musb) {
   omap2430_low_level_init(musb);
 - musb_writel(musb-mregs, OTG_INTERFSEL,
 + if(glue-initialized)

Are you sure this is thread safe?
If you're sending this patch it means runtime_resume can be called
before omap2430_must_init(), but how about at the same time?
You defined 'initialized' as u8 type, then read/write operations won't
be atomic in ARM.

Br, David Cohen

 + musb_writel(musb-mregs, OTG_INTERFSEL,
   musb-context.otg_interfsel);
  
   usb_phy_set_suspend(musb-xceiv, 0);
 -- 
 1.8.4.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb 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: Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver

[Ivajlo Dimitrov]

On 16.12.2013 20:34, Sebastian Reichel wrote:

Hi,

On Mon, Dec 16, 2013 at 02:31:53PM +0100, Linus Walleij wrote:

I am very reluctant in letting device trees specify exports of GPIOs
to userspace, not so much because it's Linux-specific but for
the fact that people are doing things in userspace that should not
be done in userspace.

Last time it was proposed I asked to the specific usecase,
exactly why userspace needed this handle on a physical
GPIO line, and why it can't use another userspace interface
(example: leds, keys etc.)

There are a couple of lines (cmt_apeslpx, cmt_rst_rq, cmt_en,
cmt_rst, cmt_bsi), which are handled by ofono to do the correct
power sequence for the modem. The relevant ofono code is here:

https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c

In MeeGo etc. they have a little board specific init script, which
exports the gpio lines and setups some symlinks. IMHO at least the
board specific stuff should be handled by the kernel, thus I added
this code to the driver. I guess you prefer to move the power
sequencing completly to the kernel?


Don't forget there is not only ofono, but rtcom-call-ui and all the 
telephony stack in Maemo 5 :). However, power sequencing and control is 
specific not only to the modem model, but to the firmware version the 
modem is running as well (afaik). IMO you can't simply move the modem 
power/reset/sleep control to the kernel and hope for the best, I am not 
sure there is enough documentation (if any) for this to be done 
reliably, esp on n900 with its BB5 modem. The point is that those gpios 
are used not only for the initial power-up, but for control of the modem 
state and reset (if needed) during normal usage. The APE reset line is 
an example of stuff that can't be moved to the kernel without providing 
some interface/feedback to/from the userspace IMO - what if she is 
dialing 112 at the moment the modem decides it is too hot and wants a 
device reset (or whatever reason there could be for a modem to request a 
device reset)? The same goes for the APE sleep request line 
(cmt_apeslpx) - based on what should the kernel decide whether to put 
the modem in sleep?


Sure, exporting gpios to userspace might not be the best way to achieve 
the required functionality, but every way could be argued if it is the 
best. And for sure labeling a modem LED won't make it such.


Regards,
Ivo
--
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: [net PATCH v2 1/1] drivers: net : cpsw: pass proper device name while requesting irq

[David Miller]

From: Mugunthan V N mugunthan...@ti.com
Date: Fri, 13 Dec 2013 14:35:27 +0530

 During checking the interrupts with cat /proc/interrupts, it is showing
 device name as (null), this change was done with commit id aa1a15e2d where
 request_irq is changed to devm_request_irq also changing the irq name from
 platform device name to net device name, but the net device is not
 registered at this point with the network frame work, so devm_request_irq
 is called with device name as NULL, by which it is showed as (null) in
 cat /proc/interrupts. So this patch moved the devm_request_irq after
 the net device register so that the device name shows as eth*.

This change is buggy.

If the request irq fails, you have to unregister the network device,
branching to clean_ale_ret is insufficient.

And this shows the more fundamental problem with your change, you
cannot register the network device before you request the IRQs
if your -open() method assumes that the IRQs are registered already.

Which this driver does.

The very moment you call request_irq(), the interface can be brought
up and then -open() method invoked.

Therefore, register_netdevice() absolutely must be the very last
action during the probe function.

Why don't you just use the platform device name as the interrupt
name?  The other alternative is to only register the IRQs in the
-open() routine and free the IRQ in the -close() method.

I can't apply this, sorry.
--
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: dts: Add support for sbc-3xxx with cm-t3730

[Tony Lindgren]

* Igor Grinberg grinb...@compulab.co.il [131216 23:16]:
 On 12/16/13 21:17, Tony Lindgren wrote:
  * Igor Grinberg grinb...@compulab.co.il [131216 05:57]:
  On 12/13/13 21:22, Tony Lindgren wrote:

 Ok. So what do you think, is it fine to have something like:
 omap3-cm-t3x.dtsi - common to cm-t3x cpu boards
 omap3-cm-t3x30.dtsi   - common to cm-t3730 and cm-t3530
 omap3-cm-t3730.dtsi   - cm-t3730 specific
 omap3-cm-t3530.dtsi   - cm-t3530 specific
 omap3-cm-t3517.dtsi   - cm-t3517 specific
 omap3-sb-t35.dtsi - sb-t35 specific
 omap3-cb-t3.dtsi  - cb-t3 specific
 omap3-sbc-t3730-256mb.dts - sb-t35 with cm-t3730 and 256MB memory size
 omap3-sbc-t3730-128mb.dts - sb-t35 with cm-t3730 and 128MB memory size
 omap3-sbc-t3730-64mb.dts  - sb-t35 with cm-t3730 and 64MB memory size
 omap3-sbc-t3530-256mb.dts - sb-t35 with cm-t3530 and 256MB memory size
 omap3-sbc-t3530-128mb.dts - sb-t35 with cm-t3530 and 128MB memory size
 omap3-sbc-t3530-64mb.dts  - sb-t35 with cm-t3530 and 64MB memory size
 omap3-sbc-t3517-256mb.dts - sb-t35 with cm-t3517 and 256MB memory size
 omap3-sbc-t3517-128mb.dts - sb-t35 with cm-t3517 and 128MB memory size
 omap3-em-t3730-256mb.dts  - cb-t3 with cm-t3730 and 256MB memory size
 omap3-em-t3730-128mb.dts  - cb-t3 with cm-t3730 and 128MB memory size
 omap3-em-t3730-64mb.dts   - cb-t3 with cm-t3730 and 64MB memory 
 size
 omap3-em-t3530-256mb.dts  - cb-t3 with cm-t3530 and 256MB memory size
 omap3-em-t3530-128mb.dts  - cb-t3 with cm-t3530 and 128MB memory size
 omap3-em-t3530-64mb.dts   - cb-t3 with cm-t3530 and 64MB memory 
 size
 
 or is it too much... ;-)))
 The above gives the full coverage of the 2x3 boards.

Yeah probably best to patch in the size of the RAM in u-boot :)
 
 I think we can drop the different memory sizes and
 let boot loader adjust the blob. This will make the list shorter:
 omap3-cm-t3x.dtsi - common to cm-t3x cpu boards
 omap3-cm-t3x30.dtsi   - common to cm-t3730 and cm-t3530
 omap3-cm-t3730.dtsi   - cm-t3730 specific
 omap3-cm-t3530.dtsi   - cm-t3530 specific
 omap3-cm-t3517.dtsi   - cm-t3517 specific
 omap3-sb-t35.dtsi - sb-t35 specific
 omap3-cb-t3.dtsi  - cb-t3 specific
 omap3-sbc-t3730.dts   - sb-t35 with cm-t3730 and default memory size
 omap3-sbc-t3530.dts   - sb-t35 with cm-t3530 and default memory size
 omap3-sbc-t3517.dts   - sb-t35 with cm-t3517 and default memory size
 omap3-em-t3730.dts- cb-t3 with cm-t3730 and default memory size
 omap3-em-t3530.dts- cb-t3 with cm-t3530 and default memory size
 
 So what do you think?
 
Makes sense to me. I've updated the patch below to use the following:

omap3-cm-t3x30.dtsi - common to cm-t3730 and cm-t3530
omap3-cm-t3730.dts  - cm-t3730 specific, should work on it's own too, not a 
.dtsi
omap3-sb-t35.dtsi   - sb-t35 specific
omap3-sbc-t3730.dts - sb-t35 with cm-t3730 and default memory size

So the only changes compared to your naming are to not use .dtsi
extension for omap3-cm-t3730.dts, and I did not add omap3-cm-t3x.dtsi
as I don't know the details.

It's probably best that you guys take over this patch from here and
add omap3-cm-t3x30.dtsi if needed.

I got the basic stuff working for what I need right now for my router
to work, which is MMC, both Ethernet controllers and wl12xx. So I'm
not going to tweak this patch further. Of course having the battery
charging working would be nice for a router to have a backup battery :)

There are still some issues I've noticed:

1. Removing and reinserting the wl12xx modules seems to kill the
   WLAN

2. Ethernet interfaces only come up if there's a cable connected
  
  + mmc1_pins: pinmux_mmc1_pins {
  + pinctrl-single,pins = 
  + 0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0)   /* 
  sdmmc1_clk.sdmmc1_clk */
  + 0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_cmd.sdmmc1_cmd */
  + 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat0.sdmmc1_dat0 */
  + 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat1.sdmmc1_dat1 */
  + 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat2.sdmmc1_dat2 */
  + 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat3.sdmmc1_dat3 */
  + 0x120 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat4.sdmmc1_dat4 */
  + 0x122 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat5.sdmmc1_dat5 */
  + 0x124 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat6.sdmmc1_dat6 */
  + 0x126 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
  sdmmc1_dat7.sdmmc1_dat7 */
 
  The dat{4,5,6,7} pins are not used either on cm-t3530, or cm-t3730.
  
  But it seems to work and makes MMC1 faster :) Might be worth checking
  though, maybe those pins have multiple optional routings available?
 
 They are routed to the connector of the base 

Re: [PATCH] ARM: dts: Add basic devices for AM3517-craneboard

[Nishanth Menon]

On 12/09/2013 03:55 PM, Nishanth Menon wrote:
 Craneboard is a hardware development platform based on the Sitara
 AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
 details. Add basic devices for craneboard as replacement for the board
 file scheduled for removal as part of device tree conversion
 
 [1] http://craneboard.org
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---

gentle ping.. had'nt seen a response on this patch. Could we queue
this up for v3.14-rc1?

 Based on:
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
 branch: omap-for-v3.14/omap3-board-removal 736e812 ARM: OMAP2+: Remove unused 
 platform init code and headers
 
 Bootlog: http://pastebin.mozilla.org/3744412
 
  arch/arm/boot/dts/Makefile  |1 +
  arch/arm/boot/dts/am3517-craneboard.dts |  174 
 +++
  2 files changed, 175 insertions(+)
  create mode 100644 arch/arm/boot/dts/am3517-craneboard.dts
 
 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index fc37bca..ad155fc 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -205,6 +205,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
   am335x-boneblack.dtb \
   am335x-nano.dtb \
   am335x-base0033.dtb \
 + am3517-craneboard.dtb \
   am3517-evm.dtb \
   am3517_mt_ventoux.dtb \
   am43x-epos-evm.dtb \
 diff --git a/arch/arm/boot/dts/am3517-craneboard.dts 
 b/arch/arm/boot/dts/am3517-craneboard.dts
 new file mode 100644
 index 000..2d40b3f
 --- /dev/null
 +++ b/arch/arm/boot/dts/am3517-craneboard.dts
 @@ -0,0 +1,174 @@
 +/*
 + * See craneboard.org for more details
 + *
 + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +/dts-v1/;
 +
 +#include am3517.dtsi
 +
 +/ {
 + model = TI AM3517 CraneBoard (TMDSEVM3517);
 + compatible = ti,am3517-craneboard, ti,am3517, ti,omap3;
 +
 + memory {
 + device_type = memory;
 + reg = 0x8000 0x1000;  /* 256 MB */
 + };
 +
 + vbat: fixedregulator@0 {
 + compatible = regulator-fixed;
 + regulator-name = vbat;
 + regulator-min-microvolt = 500;
 + regulator-max-microvolt = 500;
 + regulator-boot-on;
 + };
 +};
 +
 +davinci_emac {
 + status = okay;
 +};
 +
 +davinci_mdio {
 + status = okay;
 +};
 +
 +i2c1 {
 + clock-frequency = 260;
 +
 + tps: tps@2d {
 + reg = 0x2d;
 + };
 +};
 +
 +i2c2 {
 + clock-frequency = 40;
 + /* goes to expansion connector */
 + status = disabled;
 +};
 +
 +i2c3 {
 + clock-frequency = 40;
 + /* goes to expansion connector */
 + status = disabled;
 +};
 +
 +mmc1 {
 + vmmc-supply = vdd2_reg;
 + bus-width = 8;
 +};
 +
 +mmc2 {
 + /* goes to expansion connector */
 + status = disabled;
 +};
 +
 +mmc3 {
 + /* goes to expansion connector */
 + status = disabled;
 +};
 +
 +#include tps65910.dtsi
 +
 +omap3_pmx_core {
 + tps_pins: pinmux_tps_pins {
 + pinctrl-single,pins = 
 + 0x1b0 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
 sys_nirq.sys_nirq */
 + ;
 + };
 +};
 +
 +tps {
 + pinctrl-names = default;
 + pinctrl-0 = tps_pins;
 +
 + interrupts = 7; /* SYS_NIRQ cascaded to intc */
 + interrupt-parent = intc;
 +
 + ti,en-ck32k-xtal;
 +
 + vcc1-supply = vbat;
 + vcc2-supply = vbat;
 + vcc3-supply = vbat;
 + vcc4-supply = vbat;
 + vcc5-supply = vbat;
 + vcc6-supply = vbat;
 + vcc7-supply = vbat;
 + vccio-supply = vbat;
 +
 + regulators {
 + vrtc_reg: regulator@0 {
 + regulator-always-on;
 + };
 +
 + vio_reg: regulator@1 {
 + regulator-always-on;
 + };
 +
 + /*
 +  * Unused:
 +  * VDIG1=2.7V,300mA max
 +  * VDIG2=1.8V,300mA max
 +  */
 +
 + vpll_reg: regulator@7 {
 + /* VDDS_DPLL_1V8 */
 + regulator-min-microvolt = 180;
 + regulator-max-microvolt = 180;
 + regulator-always-on;
 + };
 +
 + vaux1_reg: regulator@9 {
 + /* VDDS_SRAM_1V8 */
 + regulator-min-microvolt = 180;
 + regulator-max-microvolt = 180;
 + regulator-always-on;
 + };
 +
 + vaux2_reg: regulator@10 {
 + /* VDDA1P8V_USBPHY */
 + regulator-min-microvolt = 180;
 + regulator-max-microvolt = 180;
 + regulator-always-on;
 + };

Re: [GIT PULL] make omap24xx boot in dt mode only, prepare omap3 to drop legacy booting for v3.14

[Kevin Hilman]

Tony Lindgren t...@atomide.com writes:

 * Tony Lindgren t...@atomide.com [131210 12:27]:
 The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:
 
   ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 

 Sorry forgot to push the new tag, the link is:

 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.14/board-removal-safe
  

Pulled into next/boards.

Thanks,

Kevin
--
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: Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver

[Sebastian Reichel]

On Tue, Dec 17, 2013 at 07:58:56PM +0200, Ivajlo Dimitrov wrote:
 On Mon, Dec 16, 2013 at 02:31:53PM +0100, Linus Walleij wrote:
 I am very reluctant in letting device trees specify exports of GPIOs
 to userspace, not so much because it's Linux-specific but for
 the fact that people are doing things in userspace that should not
 be done in userspace.
 
 Last time it was proposed I asked to the specific usecase,
 exactly why userspace needed this handle on a physical
 GPIO line, and why it can't use another userspace interface
 (example: leds, keys etc.)
 There are a couple of lines (cmt_apeslpx, cmt_rst_rq, cmt_en,
 cmt_rst, cmt_bsi), which are handled by ofono to do the correct
 power sequence for the modem. The relevant ofono code is here:
 
 https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c
 
 In MeeGo etc. they have a little board specific init script, which
 exports the gpio lines and setups some symlinks. IMHO at least the
 board specific stuff should be handled by the kernel, thus I added
 this code to the driver. I guess you prefer to move the power
 sequencing completly to the kernel?
 
 Don't forget there is not only ofono, but rtcom-call-ui and all the
 telephony stack in Maemo 5 :). However, power sequencing and control
 is specific not only to the modem model, but to the firmware version
 the modem is running as well (afaik). IMO you can't simply move the
 modem power/reset/sleep control to the kernel and hope for the best,
 I am not sure there is enough documentation (if any) for this to be
 done reliably, esp on n900 with its BB5 modem. The point is that
 those gpios are used not only for the initial power-up, but for
 control of the modem state and reset (if needed) during normal
 usage. The APE reset line is an example of stuff that can't be moved
 to the kernel without providing some interface/feedback to/from the
 userspace IMO - what if she is dialing 112 at the moment the modem
 decides it is too hot and wants a device reset (or whatever reason
 there could be for a modem to request a device reset)? The same goes
 for the APE sleep request line (cmt_apeslpx) - based on what should
 the kernel decide whether to put the modem in sleep?
 
 Sure, exporting gpios to userspace might not be the best way to
 achieve the required functionality, but every way could be argued if
 it is the best. And for sure labeling a modem LED won't make it
 such.

Yes, but as far as I know the kernel design rules are not bended for
nonfree userspace components. Using the nonfree Maemo stuff should
be supported by disabling the CMT driver and exporting the pins from
userspace using some board specific init script (= this is how its
done until now).

I had a look at both ofono's and freesmartphone.org's implementation
for the GPIO handling and both implementations are very similar. I
think it should be possible to move the state machine described in
[0] into the kernel and provide a simple sysfs/uevent interface.

I was thinking of something like /sys/devices/platform/nokia-cmt/state,
which accepts enable, disable and reset as input and outputs the
current state.

[0] 
https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 0/7] usb: dwc3: pm_runtime implementation

[David Cohen]

On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote:
 hi all,
 
 these patches add pm_runtime support for all glue layers.
 
 I plan to add pm_runtime support for dwc3 after these
 patches are merged upstream.
 
 Please test.

At first time I failed to notice you were removing #ifdef's around pm
callback functions. Instead of saying DWC3 will start to have warnings
when CONFIG_PM is not selected, I'd say your patch set is now a
dependence of my RFC :)
https://lkml.org/lkml/2013/12/13/4

Br, David Cohen

 
 Felipe Balbi (7):
   usb: dwc3: keystone: add basic PM support
   usb: dwc3: omap: add basic pm_runtime support
   usb: dwc3: pci: add pm_runtime support
   usb: dwc3: omap: fix pm_runtime usage
   usb: dwc3: omap: fix order of pm_runtime vs child removal
   usb: dwc3: exynos: remove DEV_PM_OPS hackery
   usb: dwc3: exynos: add pm_runtime support
 
  drivers/usb/dwc3/dwc3-exynos.c   | 73 +++---
  drivers/usb/dwc3/dwc3-keystone.c | 97 
 ++--
  drivers/usb/dwc3/dwc3-omap.c | 45 +++
  drivers/usb/dwc3/dwc3-pci.c  | 66 ---
  4 files changed, 239 insertions(+), 42 deletions(-)
 
 -- 
 1.8.4.GIT
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb 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 0/7] usb: dwc3: pm_runtime implementation

[David Cohen]

On Tue, Dec 17, 2013 at 03:31:40PM -0800, David Cohen wrote:
 On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote:
  hi all,
  
  these patches add pm_runtime support for all glue layers.
  
  I plan to add pm_runtime support for dwc3 after these
  patches are merged upstream.
  
  Please test.
 
 At first time I failed to notice you were removing #ifdef's around pm
 callback functions. Instead of saying DWC3 will start to have warnings
 when CONFIG_PM is not selected, I'd say your patch set is now a
 dependence of my RFC :)

I guess I said it in wrong order :P
Your patch set depends on my RFC.

 https://lkml.org/lkml/2013/12/13/4
 
 Br, David Cohen
 
  
  Felipe Balbi (7):
usb: dwc3: keystone: add basic PM support
usb: dwc3: omap: add basic pm_runtime support
usb: dwc3: pci: add pm_runtime support
usb: dwc3: omap: fix pm_runtime usage
usb: dwc3: omap: fix order of pm_runtime vs child removal
usb: dwc3: exynos: remove DEV_PM_OPS hackery
usb: dwc3: exynos: add pm_runtime support
  
   drivers/usb/dwc3/dwc3-exynos.c   | 73 +++---
   drivers/usb/dwc3/dwc3-keystone.c | 97 
  ++--
   drivers/usb/dwc3/dwc3-omap.c | 45 +++
   drivers/usb/dwc3/dwc3-pci.c  | 66 ---
   4 files changed, 239 insertions(+), 42 deletions(-)
  
  -- 
  1.8.4.GIT
  
  --
  To unsubscribe from this list: send the line unsubscribe linux-usb 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-usb 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 00/26] OMAPDSS: DT support (Christmas edition)

[Tony Lindgren]

* Tomi Valkeinen tomi.valkei...@ti.com [131215 23:26]:
 On 2013-12-14 16:09, Tony Lindgren wrote:
 
  Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
  not a fix, just a cleanup.
  
  Hmm OK sorry looks like I removed some non-legacy mux framework code
  by accident. The omap_mux_* parts clearly are dead code for omap4 as
  it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
  using omap_mux_* functions.
  
  Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
  seems to be omap4_tpd12s015_mux_pads(), right?
 
 Yes. I tested the below patch on 4430SDP, both DSI and HDMI works.

OK thanks applying for the -rc cycle.

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: [PATCHv10 10/41] CLK: TI: add support for clockdomain binding

[Mike Turquette]

Quoting Tero Kristo (2013-12-16 00:13:08)
 On 12/15/2013 06:23 AM, Mike Turquette wrote:
  Quoting Tero Kristo (2013-11-26 00:05:51)
  Some OMAP clocks require knowledge about their parent clockdomain for
  book keeping purposes. This patch creates a new DT binding for TI
  clockdomains, which act as a collection of device clocks.
 
  Signed-off-by: Tero Kristo t-kri...@ti.com
  ---
.../devicetree/bindings/clock/ti/clockdomain.txt   |   21 ++
arch/arm/mach-omap2/clock.h|1 -
drivers/clk/ti/Makefile|3 +-
drivers/clk/ti/clockdomain.c   |   70 
  
include/linux/clk/ti.h |3 +
5 files changed, 96 insertions(+), 2 deletions(-)
create mode 100644 
  Documentation/devicetree/bindings/clock/ti/clockdomain.txt
create mode 100644 drivers/clk/ti/clockdomain.c
 
  diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt 
  b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
  new file mode 100644
  index 000..45e6f7c
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
  @@ -0,0 +1,21 @@
  +Binding for Texas Instruments clockdomain.
  +
  +Binding status: Unstable - ABI compatibility may be broken in the future
  +
  +This binding uses the common clock binding[1]. Every clock on
 
  The patch looks fine to me but I think that the binding description
  should capture the fact that you are re-using the common clock binding
  but that this binding definition does not define any new clocks or clock
  controllers in the way that a typical clock binding would.
 
  This code uses the 'clocks' property the same way that any other
  consumer binding definition would, such as an MMC controller or UART.
  Those bindings do not say that they are based on the common clock
  binding AFAIK.
 
 
 Ok, will modify the doc accordingly.

Just to clarify: I think it is great to reference clock-bindings.txt,
but somehow make sure that someone reading this doesn't mistake it for a
clock controller binding or a new clock type binding. This ip sort of
consumes clocks in the usual way as an IO controller.

Regards,
Mike

 
 -Tero
 
  Regards,
  Mike
 
  +TI SoC belongs to one clockdomain, but software only needs this
  +information for specific clocks which require their parent
  +clockdomain to be controlled when the clock is enabled/disabled.
  +
  +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
  +
  +Required properties:
  +- compatible : shall be ti,clockdomain
  +- #clock-cells : from common clock binding; shall be set to 0.
  +- clocks : link phandles of clocks within this domain
  +
  +Examples:
  +   dss_clkdm: dss_clkdm {
  +   compatible = ti,clockdomain;
  +   clocks = dss1_alwon_fck_3430es2, dss_ick_3430es2;
  +   };
  diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
  index bc0f9fc..6bd72b5 100644
  --- a/arch/arm/mach-omap2/clock.h
  +++ b/arch/arm/mach-omap2/clock.h
  @@ -38,7 +38,6 @@ struct omap_clk {
   }
 
struct clockdomain;
  -#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
 
#define DEFINE_STRUCT_CLK(_name, _parent_array_name, _clkops_name) \
   static struct clk _name = { \
  diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
  index 7cba389..67056fb 100644
  --- a/drivers/clk/ti/Makefile
  +++ b/drivers/clk/ti/Makefile
  @@ -1,4 +1,5 @@
ifneq ($(CONFIG_OF),)
obj-y  += clk.o dpll.o autoidle.o 
  divider.o \
  -  fixed-factor.o gate.o 
  composite.o
  +  fixed-factor.o gate.o 
  clockdomain.o \
  +  composite.o
endif
  diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
  new file mode 100644
  index 000..f1e0038
  --- /dev/null
  +++ b/drivers/clk/ti/clockdomain.c
  @@ -0,0 +1,70 @@
  +/*
  + * OMAP clockdomain support
  + *
  + * Copyright (C) 2013 Texas Instruments, Inc.
  + *
  + * Tero Kristo t-kri...@ti.com
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + *
  + * This program is distributed as is WITHOUT ANY WARRANTY of any
  + * kind, whether express or implied; 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-provider.h
  +#include linux/slab.h
  +#include linux/of.h
  +#include linux/of_address.h
  +#include linux/clk/ti.h
  +
  +#undef pr_fmt
  +#define pr_fmt(fmt) %s:  fmt, __func__
  +
  +static void __init of_ti_clockdomain_setup(struct device_node 

Re: [PATCHv10 01/41] clk: add support for platform specific clock I/O wrapper functions

[Paul Walmsley]

On Tue, 17 Dec 2013, Paul Walmsley wrote:

 On Tue, 26 Nov 2013, Tero Kristo wrote:
 
  Current clock wrappers assume simple and direct mapped hardware register
  access. Improve this support by adding functionality for registering
  platform specific clock I/O wrappers, which can be used to support
  various features needed like endianess conversions, indexed regmap support,
  etc. Default I/O wrapper provided also which uses the existing direct
  I/O mapped behavior.
 
 I think it makes more sense to define per-SoC register read and write 
 functions,

Sorry, this should have read per-IP block register read and write 
functions.

 for the same reason that I think it makes more sense to define clock 
 data as part of the IP blocks that contain the clocks' registers.  The 
 register read and write functions should be implemented by the drivers 
 for the IP blocks that the clocks are contained in.  That way the 
 register read and write functions can take whatever steps are necessary 
 to ensure that the IP block registers are accessible before performing 
 the read/write; can implement non-MMIO register accesses if needed; and 
 can operate on register offsets, rather than absolute addresses.
 
 Something like the following draft implementation.  Also needed would be a 
 way for clock providers that rely on the common clock providers (e.g., 
 divider, mux, etc.) to pass in the struct clk_ll_ops pointer.  I guess the 
 simplest way to implement this would be to add another set of registration 
 functions - e.g., clk_register_divider_ipb() or clk_register_divider2() or 
 something similar.  These functions would be similar to 
 clk_register_divider(), but would take a pointer to a struct clk_ll_ops 
 and pass that along to the CCF core.


- 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: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack

[Tomi Valkeinen]

On 2013-12-17 17:30, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [131216 22:47]:
 On 2013-12-16 20:41, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [131216 06:59]:
 As a temporary solution to enable DSS for selected boards when booting
 with DT, a hack was added to board-generic.c in
 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
 DSS for panda  sdp boards).

 We're now adding proper DT support, so the hack can be removed.

 I guess this patch should be merged later on after we have the DT support
 working?

 I'll move this patch also to the end of the series.

 Merged later sounds like you mean this could be merged in a separate
 series. I think this and the other removal can be in this series, they
 just need to be at the end.
 
 Well yeah let's keep those separate still as at least Russell needed
 some more time with the legacy booting. The point we can drop the
 legacy booting for omap3 may still need to wait a bit, maybe even
 until v3.15 to keep things working.

They can't be separate. Once I add DT support for a board, I have to
remove the legacy support for that board. This patch removes legacy
support for the boards that are converted in the series.

If I don't remove the legacy support, both DT and legacy side will be
ran, and both create the DSS devices...

But, it's true that this patch removes the whole file, as all the boards
currently there are converted. But if new boards are added to the DSS
quirks, then I can't remove the file. So I'll change this patch to only
remove the parts for the converted boards, not the whole file.

But but... If I understand right, the plan is to remove all omap3 board
files for the next merge window. I'm not totally familiar with the
quirks system, but how should this be handled:

omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices
are created via DT code. But if the display (i.e. panels) for a
particular omap3 board has not been converted to DT, we should still use
the legacy DSS initialization. But the DSS is already initialized via DT.

I guess I can set the status for all the DSS nodes to disabled in
omap3.dtsi, and that should prevent DT code from creating the DSS
devices. Then, each omap3-board.dts that has been converted to DSS DT,
can override those to enabled.

That way the DT code should not create DSS devices by default, and the
quirks system would probably work fine.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.

[Andreas Naumann]

Am 17.12.2013 18:22, schrieb David Cohen:

On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:

From: Andreas Naumann anaum...@ultratronik.de

This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.

Fix it by not writing the value on runtime resume if it has not been
initialized yet.

Signed-off-by: Andreas Naumann anaum...@ultratronik.de
---
Even though I find the implementation a bit awkward this should fix
the issue without breaking anything else. Hope everyone is happy
with this.

  drivers/usb/musb/omap2430.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 4315d35..fbe2c08 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -48,6 +48,7 @@ struct omap2430_glue {
enum omap_musb_vbus_id_status status;
struct work_struct  omap_musb_mailbox_work;
struct device   *control_otghs;
+   u8  initialized;
  };
  #define glue_to_musb(g)   platform_get_drvdata(g-musb)

@@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
}

musb_writel(musb-mregs, OTG_INTERFSEL, l);
+   glue-initialized = 1;

pr_debug(HS USB OTG: revision 0x%x, sysconfig 0x%02x, 
sysstatus 0x%x, intrfsel 0x%x, simenable  0x%x\n,
@@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device *pdev)
glue-dev= pdev-dev;
glue-musb   = musb;
glue-status = OMAP_MUSB_UNKNOWN;
+   glue-initialized= 0;


You don't need to do this. 'glue' was already allocated with kzalloc().


ok





if (np) {
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
@@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device *dev)

if (musb) {
omap2430_low_level_init(musb);
-   musb_writel(musb-mregs, OTG_INTERFSEL,
+   if(glue-initialized)


Are you sure this is thread safe?
If you're sending this patch it means runtime_resume can be called
before omap2430_must_init(), but how about at the same time?
You defined 'initialized' as u8 type, then read/write operations won't
be atomic in ARM.


You're right, wasnt thinking of that. Shall I use atomic_t and helpers?



Br, David Cohen


+   musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);

usb_phy_set_suspend(musb-xceiv, 0);
--
1.8.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb 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-usb 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