Re: [PATCH V2 05/19] irqchip: crossbar: Change allocation logic by reversing search for free irqs

[Sricharan R]

Hi Jason,

On Thursday 12 June 2014 06:26 PM, Jason Cooper wrote:
 On Thu, Jun 12, 2014 at 05:23:13PM +0530, Sricharan R wrote:
 From: Nishanth Menon n...@ti.com

 Reverse the search algorithm to ensure that address mapping and IRQ
 allocation logics are proper. This can open up new bugs which are
 easily fixable rather than wait till allocation logic approaches
 the limit to find new bugs.
 
 Could you expand on this logic some more?  What class of bugs are you
 hoping to discover more easily?
 

class 1. address space errors - example:
reg = a size_b
ti,max-irqs =  is a wrong parameter

class 2: irq-reserved list - which decides which entries in the
address space is not actually wired in

class 3: wrong list of routable-irqs.

in general allocating from max to min tends to have benefits in
ensuring the different issues that may be present in dts is easily
caught at definition time, rather than at a later point in time.


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

Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning

[Sricharan R]

Hi Jason,

On Thursday 12 June 2014 09:35 PM, Joe Perches wrote:
 On Thu, 2014-06-12 at 11:32 -0400, Jason Cooper wrote:
 
 Hi Jason.
 
 But bugfix backports haven't been much of an issue in
 other subsystems with fairly active whitespace/style
 changes.

 Most of the mvebu fixes we've had that failed to apply were generally
 due to a large whitespace change (dts node shuffling, admittedly not
 checkpatch-related).
 
 So not due to this.
 
   I've also frequently been stymied by code cleanups
 when using git blame to find the commit introducing a regression.
 
 git blame -w can frequently help there.
 
 So, my general rule is: If you're submitting a patch to make checkpatch
 be quiet, re-assess the need.  If you're making changes and you can fix
 some checkpatch items while you're there, then do so.
 
 Decent rule.
 
 There are certainly legitimate checkpatch-only patches, I just don't
 think this is one qualifies.
 
 Of course it's the maintainer's choice (and last I saw,
 that's you) to ignore whatever doesn't fit the appropriate
 vision for the code.
 
 $ ./scripts/get_maintainer.pl -f drivers/irqchip/irq-crossbar.c
 Thomas Gleixner t...@linutronix.de (maintainer:IRQCHIP DRIVERS)
 Jason Cooper ja...@lakedaemon.net (maintainer:IRQCHIP DRIVERS)
 
  Ok, if this is not qualifying as a separate patch then i will merge
  this with other patches in the series which touch them.

Regards,
 Sricharan

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

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Sricharan R]

On Thursday 12 June 2014 07:27 PM, Tony Lindgren wrote:
 * Jason Cooper ja...@lakedaemon.net [140612 05:52]:
 On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
 From: Nishanth Menon n...@ti.com

 When, in the system due to varied reasons, interrupts might be unusable
 due to hardware behavior, but register maps do exist, then those interrupts
 should be skipped while mapping irq to crossbars.

 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Sricharan R r.sricha...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

 Tony, have you applied these somewhere already?
 
 I think some of these I had applied into a branch ready for
 merging but then it was discovered that further changes
 were needed and the branch was dropped.
 
 Sricharan, please remove my Signed-off-by from this series.
 If I end up applying it for merging my scripts will add it
 automatically.
 
 Ok, will remove it.

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

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Sricharan R]

Hi Jason,

On Thursday 12 June 2014 07:37 PM, Jason Cooper wrote:
 On Thu, Jun 12, 2014 at 06:49:17PM +0530, Sricharan R wrote:
 Hi Jason,

 On Thursday 12 June 2014 06:21 PM, Jason Cooper wrote:
 On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
 From: Nishanth Menon n...@ti.com

 When, in the system due to varied reasons, interrupts might be unusable
 due to hardware behavior, but register maps do exist, then those interrupts
 should be skipped while mapping irq to crossbars.

 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Sricharan R r.sricha...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

 Tony, have you applied these somewhere already?

 ---
  drivers/irqchip/irq-crossbar.c |   47 
 
  1 file changed, 43 insertions(+), 4 deletions(-)

 diff --git a/drivers/irqchip/irq-crossbar.c 
 b/drivers/irqchip/irq-crossbar.c
 index 51d4b87..847f6e3 100644
 --- a/drivers/irqchip/irq-crossbar.c
 +++ b/drivers/irqchip/irq-crossbar.c
 @@ -13,11 +13,13 @@
  #include linux/io.h
  #include linux/of_address.h
  #include linux/of_irq.h
 +#include linux/of_device.h
  #include linux/slab.h
  #include linux/irqchip/arm-gic.h
  
  #define IRQ_FREE  -1
  #define IRQ_RESERVED  -2
 +#define IRQ_SKIP  -3
  #define GIC_IRQ_START 32
  
  /*
 @@ -34,6 +36,16 @@ struct crossbar_device {
void (*write) (int, int);
  };
  
 +/**
 + * struct crossbar_data: Platform specific data
 + * @irqs_unused: array of irqs that cannot be used because of hw erratas
 + * @size: size of the irqs_unused array
 + */
 +struct crossbar_data {
 +  const uint *irqs_unused;
 +  const uint size;
 +};
 +
  static struct crossbar_device *cb;
  
  static inline void crossbar_writel(int irq_no, int cb_no)
 @@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops 
 = {
.xlate = crossbar_domain_xlate
  };
  
 -static int __init crossbar_of_init(struct device_node *node)
 +static int __init crossbar_of_init(struct device_node *node,
 + const struct crossbar_data *data)
  {
int i, size, max, reserved = 0, entry;
const __be32 *irqsr;
 +  const int *irqsk = NULL;
  
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
  
 @@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node 
 *node)
reserved += size;
}
  
 +  /* Skip the ones marked as unused */
 +  if (data) {
 +  irqsk = data-irqs_unused;
 +  size = data-size;
 +
 +  for (i = 0; i  size; i++) {
 +  entry = irqsk[i];
 +
 +  if (entry  max) {
 +  pr_err(Invalid skip entry\n);
 +  goto err3;
 +  }
 +  cb-irq_map[entry] = IRQ_SKIP;
 +  }
 +  }
 +
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
  
 @@ -208,18 +238,27 @@ err1:
return -ENOMEM;
  }
  
 +/* irq number 10 cannot be used because of hw bug */
 +int dra_irqs_unused[] = { 10 };
 +struct crossbar_data cb_dra_data = { dra_irqs_unused,
 +   ARRAY_SIZE(dra_irqs_unused) };
 +
  static const struct of_device_id crossbar_match[] __initconst = {
 -  { .compatible = ti,irq-crossbar },
 +  { .compatible = ti,irq-crossbar, .data = cb_dra_data },
{}
  };

 This is a bug in all implementations of this IP?  Or, a specific
 SoC's implementation?  Would this be better expressed in the dts via a
 property?  Can we expect future implementations to be fixed?

 thx,

 Jason.
  Infact this and PATCH#10 should be merged. I will change that.

  So in Socs's (2 so far) that do have a crossbar, some irqs are mapped
  through a crossbar and some are directly wired to the irqchip.
  These 'unused irqs' are those which are directly wired but they still
  have a crossbar register. Their routing cannot be changed. So this
  is not really expected usage of the crossbar hw ip. We initially thought
  having a dts property separately for this, but took this path to avoid
  loading the dts with additional bindings which may not be generic.
 
 How do you plan to handle future SoCs with this IP and possibly
 different hard-wired irqs?
  Yes, that would require adding a new compatible in the above list and dts.
  So if adding a new binding in the dts would be cleaner, then i will change
  it that way.

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

Re: [PATCH] [media] staging: allow omap4iss to be modular

[Laurent Pinchart]

Hi Tony,

On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
 * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 08:32]:
  On Thursday 12 June 2014 08:15:35 Tony Lindgren wrote:
  * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 07:52]:
  On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote:
  These should just use either pinctrl-single.c instead for muxing.
  Or if they are not mux registers, we do have the syscon mapping
  available in omap4.dtsi that pbias-regulator.c is already using.
  
  Laurent, got any better ideas?
  
  The ISS driver needs to write a single register, which contains
  several independent fields. They thus need to be controlled by a
  single driver. Some of them might be considered to be related to
  pinmuxing (although I disagree on that), others are certainly not
  about muxing (there are clock gate bits for instance).
  
  Using the syscon mapping seems like the best option. I'll give it a
  try.
  
  OK if it's not strictly pinctrl related then let's not use
  pinctrl-single,bits for it. You may be able to implement one or more
  framework drivers for it for pinctrl/regulator/clock/transceiver
  whatever that register is doing.
  
  In any case it's best to have that handling in a separate helper driver
  somewhere as it's a separate piece of hardware from the camera module.
  If it does not fit into any existing frameworks then it's best to have
  it in a separate driver with the camera driver.
  
  The register contains the following fields that control the two CSI2 PHYs
  (PHY1 and PHY2).
  
  31CAMERARX_CSI22_LANEENABLE2   PHY2 Lane 2 (CSI22_DX2, CSI22_DY2)
  Enable
  30CAMERARX_CSI22_LANEENABLE1   PHY2 Lane 1 (CSI22_DX1, CSI22_DY1)
  Enable
  29CAMERARX_CSI22_LANEENABLE0   PHY2 Lane 0 (CSI22_DX0, CSI22_DY0)
  Enable
  28CAMERARX_CSI21_LANEENABLE4   PHY1 Lane 4 (CSI21_DX4, CSI21_DY4)
  Enable
  27CAMERARX_CSI21_LANEENABLE3   PHY1 Lane 3 (CSI21_DX3, CSI21_DY3)
  Enable
  26CAMERARX_CSI21_LANEENABLE2   PHY1 Lane 2 (CSI21_DX2, CSI21_DY2)
  Enable
  25CAMERARX_CSI21_LANEENABLE1   PHY1 Lane 1 (CSI21_DX1, CSI21_DY1)
  Enable
  24CAMERARX_CSI21_LANEENABLE0   PHY1 Lane 0 (CSI21_DX0, CSI21_DY0)
  Enable
  21CAMERARX_CSI22_CTRLCLKEN PHY2 Clock Enable
  20:19 CAMERARX_CSI22_CAMMODE   PHY2 Mode (CCP2, CSI1, CSI2)
  18CAMERARX_CSI21_CTRLCLKEN PHY1 Clock Enable
  17:16 CAMERARX_CSI21_CAMMODE   PHY1 Mode (CCP2, CSI1, CSI2)
  
  Bits 18 and 21 could be exposed through CCF. Bits 24 to 31 enable/disable
  the CSI2 lanes, so it could be argued that they could be exposed through
  the pinctrl framework. However, they need to be configured independently,
  possibly at runtime. I'm thus not sure pinctrl would be a good idea. Bits
  17:16 and 20:19 don't fit in existing frameworks.
 
 OK thanks for the info. Sounds like drivers/phy might be the right location
 for it then and then the phy driver can use the syscon regmap.

  Given that this register is specific to the ISS, I think handling it as a
  separate device through a separate driver would only complicate the
  implementation without any real benefit.
 
 Even though it's one register, it shoud still be treated separately from
 the camera driver. The problems with keeping the register access to the
 control module in the camera driver are at least following:
 
 1. They live in separate hardware modules that can be clocked separately

Actually I don't think that's true. The CSI2 PHY is part of the camera device, 
with all its registers but the one above in the camera device register space. 
For some weird reason a couple of bits were pushed to the control module, but 
that doesn't make the CSI2 PHY itself a separate device.

 2. Doing a read-back to flush a posted write in one hardware module most
likely won't flush the write to other and that can lead into hard to
find mysterious bugs

The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ?

 3. If we ever have a common system control module driver, we need to
rewrite all the system control module register tinkering in the drivers

Sure, but that's already the case today, as the OMAP4 ISS driver already 
accesses the control module register directly. I won't make that worse :-)

 So it's best to try to use an existing framework for it. That avoids tons of
 pain later on ;)

I agree, but I don't think the PHY framework would be the right abstraction. 
As explained above the CSI2 PHY is part of the OMAP4 ISS, so modeling its 
single control module register as a PHY would be a hack. 

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Sricharan R]

Hi Jason,

On Thursday 12 June 2014 07:35 PM, Jason Cooper wrote:
 On Thu, Jun 12, 2014 at 06:57:15AM -0700, Tony Lindgren wrote:
 * Jason Cooper ja...@lakedaemon.net [140612 05:52]:
 On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
 From: Nishanth Menon n...@ti.com

 When, in the system due to varied reasons, interrupts might be unusable
 due to hardware behavior, but register maps do exist, then those interrupts
 should be skipped while mapping irq to crossbars.

 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Sricharan R r.sricha...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

 Tony, have you applied these somewhere already?

 I think some of these I had applied into a branch ready for
 merging but then it was discovered that further changes
 were needed and the branch was dropped.
 
 Ok.
 
 Sricharan, please remove my Signed-off-by from this series.
 If I end up applying it for merging my scripts will add it
 automatically.
 
 Do you have other changes outside of irqchip depending on this series?
 If so, I can set up a topic branch for you guys to base off of.
 Otherwise, I'll just apply them to irqchip/core when they're ready.
 
 There are dts changes which are dependent upon this series.

  http://www.spinics.net/lists/linux-omap/msg108116.html

 Also, Sricharan, when you respin this, please clearly identify (in the
 comment section) those patches that need to be flagged for stable.  It
 would be helpful if they were the first patches in the series as well.

Ok, i will point this out clearly.

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

Re: [PATCH 01/36] ARM: OMAP3: hwmod: Fix gpmc memory resource space

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:58]:

Missing description? Probably not an urgent fix or does
this fix something?

Regards,

Tony

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 71ac7d5..f2848a8 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 @@ -3426,7 +3426,7 @@ static struct omap_hwmod_addr_space 
 omap3xxx_counter_32k_addrs[] = {
  static struct omap_hwmod_addr_space omap3xxx_gpmc_addrs[] = {
   {
   .pa_start   = 0x6e00,
 - .pa_end = 0x6e000fff,
 + .pa_end = 0x6e0002d4,
   .flags  = ADDR_TYPE_RT
   },
   { }
 -- 
 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 01/36] ARM: OMAP3: hwmod: Fix gpmc memory resource space

[Roger Quadros]

On 06/13/2014 10:13 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140611 01:58]:
 
 Missing description? Probably not an urgent fix or does
 this fix something?

Doesn't fix anything. It is just for correctness. I'll add the description.

cheers,
-roger

 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 index 71ac7d5..f2848a8 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 @@ -3426,7 +3426,7 @@ static struct omap_hwmod_addr_space 
 omap3xxx_counter_32k_addrs[] = {
  static struct omap_hwmod_addr_space omap3xxx_gpmc_addrs[] = {
  {
  .pa_start   = 0x6e00,
 -.pa_end = 0x6e000fff,
 +.pa_end = 0x6e0002d4,
  .flags  = ADDR_TYPE_RT
  },
  { }
 -- 
 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 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:58]:
 Since the Interrupt Events are used only by the NAND driver,
 there is no point in managing the Interrupt registers
 in the GPMC driver and complicating it with irqchip modeling.
 
 Let's manage the interrupt registers directly in the NAND driver
 and get rid of irqchip model from GPMC driver.
 
 Get rid of IRQ commands and unused commands from gpmc_configure() in
 the GPMC driver.

This seems like a step backward to me. The GPMC interrupt enable
register can do edge detection on the wait pins, how is that
limited to NAND?

Further, let's not start mixing GPMC hardware module register
access with the NAND driver register access. They can be clocked
separately. And bugs in the NAND driver can cause issues in other
GPMC using drivers.

Regards,

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

Re: [PATCH 06/36] mtd: nand: omap: Move gpmc_update_nand_reg to nand driver

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:58]:
 GPMC and NAND drivers share the same register space but never use the
 same registers. As there is no clear address seperation between the
 registers for GPMC and NAND, we can't easily split it up into 2 regions
 i.e. one for GPMC and other for NAND. Instead, we simply remap the entire
 register space in both the drivers. The NAND driver doesn't re-request
 the region as it is already requested by the GPMC driver (parent).

Oh now, let's not do this. It's best to limit GPMC register access
to the GPMC driver. Even if we need to export few NAND specific
functions from the GPMC driver.

Regards,

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

Re: [PATCH 07/36] mtd: nand: omap: Move NAND write protect code from GPMC to NAND driver

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:58]:
 The write protect (WP) pin is only used for NAND devices. So move
 the code into the NAND driver.

Eek, n!

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

Re: [PATCH 10/36] ARM: dts: OMAP2+: Fix NAND device nodes

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:58]:
 Add compatible id, GPMC register resource and interrupt
 resource to NAND controller nodes.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/boot/dts/am335x-evm.dts |  8 ++--
  arch/arm/boot/dts/am335x-igep0033.dtsi   |  8 ++--
  arch/arm/boot/dts/am43x-epos-evm.dts |  8 ++--
  arch/arm/boot/dts/omap3-devkit8000.dts   |  9 +++--
  arch/arm/boot/dts/omap3-evm-37xx.dts | 10 +++---
  arch/arm/boot/dts/omap3-igep0020.dts | 10 +++---
  arch/arm/boot/dts/omap3-igep0030.dts |  8 ++--
  arch/arm/boot/dts/omap3-ldp.dts  | 10 +++---
  arch/arm/boot/dts/omap3-lilly-a83x.dtsi  | 10 +++---
  arch/arm/boot/dts/omap3-lilly-dbb056.dts |  7 ---
  arch/arm/boot/dts/omap3430-sdp.dts   |  8 ++--
  11 files changed, 69 insertions(+), 27 deletions(-)
 
 diff --git a/arch/arm/boot/dts/am335x-evm.dts 
 b/arch/arm/boot/dts/am335x-evm.dts
 index 6028217..fa25f2b 100644
 --- a/arch/arm/boot/dts/am335x-evm.dts
 +++ b/arch/arm/boot/dts/am335x-evm.dts
 @@ -437,9 +437,13 @@
   status = okay;
   pinctrl-names = default;
   pinctrl-0 = nandflash_pins_s0;
 - ranges = 0 0 0x0800 0x1000;   /* CS0: NAND */
 + ranges = 0 0 0x0800 0x1000 /* CS0 space, 16MB */
 +   255 0 0x5000 0x36c;  /* GPMC reg */

And here too let's not let the NAND driver tinker with the GPMC
registers.

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

Re: [PATCH 15/36] ARM: OMAP2+: gpmc: Allow drivers to query GPMC_CLK period

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:59]:
 GPMC_CLK is the external clock output pin that is used for syncronous
 accesses.
 
 Device drivers need to know the fastest possible GPMC_CLK period in order
 to calculate the most optimal device timings. Add the function
 omap_gpmc_get_clk_period() to allow drivers to get the nearset possible
 (equal to or greater than) GPMC_CLK period given the minimum
 clock period supported by the attached device.
 
 This is especially needed by the onenand driver as it calculates
 device timings on the fly for various onenand speed grades.

Here too this should probably still be done by the gpmc to driver
glue layer, not by the actual driver that shoud be Linux generic.

Regards,

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

Re: [PATCH 14/36] ARM: OMAP2+: gpmc: Allow drivers to reconfigure GPMC settings timings

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:58]:
 Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC
 timings in order to operate with different peripheral clock frequencies.
 Introduce omap_gpmc_retime() to allow them to do that. The driver
 needs to pass the chips select number, GPMC settings and Device timings to
 omap_gpmc_retime().
 
 NOTE: Device tree and board code must still pass the most conservative
 timings to GPMC so that the device can be probed by the respective driver.
 e.g. Onenand must operate in asynchronous mode at bootup. The device driver
 can then request for more optimal timings via omap_gpmc_retime().

Hmm but many of the devices are Linux generic like sms91x and 8250 so it's
not nice to start stuffing omap bus specific data there.

I wonder if we should just keep device specific gpmc-smc91x.c etc
in drivers/memory?

Regards,

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

Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Roger Quadros]

On 06/13/2014 10:18 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140611 01:58]:
 Since the Interrupt Events are used only by the NAND driver,
 there is no point in managing the Interrupt registers
 in the GPMC driver and complicating it with irqchip modeling.

 Let's manage the interrupt registers directly in the NAND driver
 and get rid of irqchip model from GPMC driver.

 Get rid of IRQ commands and unused commands from gpmc_configure() in
 the GPMC driver.
 
 This seems like a step backward to me. The GPMC interrupt enable
 register can do edge detection on the wait pins, how is that
 limited to NAND?

OK. But wait pin edge detection was not yet being used and I couldn't
think of how it would ever be used. Any ideas?

 
 Further, let's not start mixing GPMC hardware module register
 access with the NAND driver register access. They can be clocked
 separately. And bugs in the NAND driver can cause issues in other
 GPMC using drivers.

I understood that NAND controller is integrated into the GPMC module and they 
are clocked
the same. Not sure why the hardware designers would keep the registers so 
closely knit.

FYI. memory/ti-amif.c and mtd/nand/davinci_nand.c share the AMIF register space 
in the
same way. I thought it'd be nice to be consistent across TI drivers.

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

Re: [PATCH 14/36] ARM: OMAP2+: gpmc: Allow drivers to reconfigure GPMC settings timings

[Roger Quadros]

On 06/13/2014 10:25 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140611 01:58]:
 Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC
 timings in order to operate with different peripheral clock frequencies.
 Introduce omap_gpmc_retime() to allow them to do that. The driver
 needs to pass the chips select number, GPMC settings and Device timings to
 omap_gpmc_retime().

 NOTE: Device tree and board code must still pass the most conservative
 timings to GPMC so that the device can be probed by the respective driver.
 e.g. Onenand must operate in asynchronous mode at bootup. The device driver
 can then request for more optimal timings via omap_gpmc_retime().
 
 Hmm but many of the devices are Linux generic like sms91x and 8250 so it's
 not nice to start stuffing omap bus specific data there.

Those drivers should never need to use this function. Hopefully they will work 
with a one time setup where we specify the timings in the DT. This function is 
primarily for use by omap-onenand and tusb6010, which are both OMAP specific.

cheers,
-roger

 
 I wonder if we should just keep device specific gpmc-smc91x.c etc
 in drivers/memory?
 
 Regards,
 
 Tony
 

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

Re: [PATCH 15/36] ARM: OMAP2+: gpmc: Allow drivers to query GPMC_CLK period

[Roger Quadros]

On 06/13/2014 10:26 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140611 01:59]:
 GPMC_CLK is the external clock output pin that is used for syncronous
 accesses.

 Device drivers need to know the fastest possible GPMC_CLK period in order
 to calculate the most optimal device timings. Add the function
 omap_gpmc_get_clk_period() to allow drivers to get the nearset possible
 (equal to or greater than) GPMC_CLK period given the minimum
 clock period supported by the attached device.

 This is especially needed by the onenand driver as it calculates
 device timings on the fly for various onenand speed grades.
 
 Here too this should probably still be done by the gpmc to driver
 glue layer, not by the actual driver that shoud be Linux generic.

Well, this is only needed by the omap-onenand driver to perform the timing 
calculations at run-time.
Other option is to model the GPMC_CLK (external) as a clock and request the 
rate using the clock framework.
But since this and the retime() is only used by 2 OMAP specific drivers, I'm 
not sure if it is worth the effort.

cheers,
-roger

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

Re: [PATCH] [media] staging: allow omap4iss to be modular

[Tony Lindgren]

* Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 23:48]:
 On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
  
  1. They live in separate hardware modules that can be clocked separately
 
 Actually I don't think that's true. The CSI2 PHY is part of the camera 
 device, 
 with all its registers but the one above in the camera device register space. 
 For some weird reason a couple of bits were pushed to the control module, but 
 that doesn't make the CSI2 PHY itself a separate device.

Yes they are separate. Anything in the system control module is
a separate hardware module from the other devices. So in this case
the CSI2 PHY is part of the system control module, not the camera
module.

  2. Doing a read-back to flush a posted write in one hardware module most
 likely won't flush the write to other and that can lead into hard to
 find mysterious bugs
 
 The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ?

Right, but you would have to do readbacks both from the phy register and
camera register to ensure writes get written. It's best to keep the
logic completely separate especially considering that they can be
clocked separately.

  3. If we ever have a common system control module driver, we need to
 rewrite all the system control module register tinkering in the drivers
 
 Sure, but that's already the case today, as the OMAP4 ISS driver already 
 accesses the control module register directly. I won't make that worse :-)

Well it's in staging for a reason :)
 
  So it's best to try to use an existing framework for it. That avoids tons of
  pain later on ;)
 
 I agree, but I don't think the PHY framework would be the right abstraction. 
 As explained above the CSI2 PHY is part of the OMAP4 ISS, so modeling its 
 single control module register as a PHY would be a hack. 

Well that register belongs to the system control module, not the
camera module. It's not like the camera IO space is out of registers
or something! :)

We're already handling similar control module phy cases, see for
example drivers/phy/phy-omap-control.c. Maybe you have most of the
code already there?

Regards,

Tony

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

Re: [PATCH 18/36] ARM: OMAP2+: gpmc-onenand: Move Synchronous setting code to drivers/

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140611 01:59]:
 Move the code that puts the onenand in synchronous mode
 into the appropriate place i.e. drivers/mtd/onenand/omap2.c.
 
 Make use of omap_gpmc_get_clk_period() and omap_gpmc_retime()
 to calculate the necessary timings and configure the GPMC
 parent's timings.

Ideally we would just use the drivers/mtd/onenand/generic.c
and get rid of drivers/mtd/onenand/omap2.c. We still need
the bus glue, which should probably be in drivers/memory?

Regards,

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

Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140613 00:40]:
 On 06/13/2014 10:18 AM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [140611 01:58]:
  Since the Interrupt Events are used only by the NAND driver,
  there is no point in managing the Interrupt registers
  in the GPMC driver and complicating it with irqchip modeling.
 
  Let's manage the interrupt registers directly in the NAND driver
  and get rid of irqchip model from GPMC driver.
 
  Get rid of IRQ commands and unused commands from gpmc_configure() in
  the GPMC driver.
  
  This seems like a step backward to me. The GPMC interrupt enable
  register can do edge detection on the wait pins, how is that
  limited to NAND?
 
 OK. But wait pin edge detection was not yet being used and I couldn't
 think of how it would ever be used. Any ideas?

Maybe to wake-up the system on bus activity or something? 

  Further, let's not start mixing GPMC hardware module register
  access with the NAND driver register access. They can be clocked
  separately. And bugs in the NAND driver can cause issues in other
  GPMC using drivers.
 
 I understood that NAND controller is integrated into the GPMC module and they 
 are clocked
 the same. Not sure why the hardware designers would keep the registers so 
 closely knit.

Yeah. Maybe regmap could provide some abstraction to the the
NAND registers.
 
 FYI. memory/ti-amif.c and mtd/nand/davinci_nand.c share the AMIF register 
 space in the
 same way. I thought it'd be nice to be consistent across TI drivers.

Probably they did not yet learn the problems caused by it :)

Regards,

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

Re: [PATCH 14/36] ARM: OMAP2+: gpmc: Allow drivers to reconfigure GPMC settings timings

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140613 00:46]:
 On 06/13/2014 10:25 AM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [140611 01:58]:
  Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC
  timings in order to operate with different peripheral clock frequencies.
  Introduce omap_gpmc_retime() to allow them to do that. The driver
  needs to pass the chips select number, GPMC settings and Device timings to
  omap_gpmc_retime().
 
  NOTE: Device tree and board code must still pass the most conservative
  timings to GPMC so that the device can be probed by the respective driver.
  e.g. Onenand must operate in asynchronous mode at bootup. The device driver
  can then request for more optimal timings via omap_gpmc_retime().
  
  Hmm but many of the devices are Linux generic like sms91x and 8250 so it's
  not nice to start stuffing omap bus specific data there.
 
 Those drivers should never need to use this function. Hopefully they will 
 work with a one time setup where we specify the timings in the DT. This 
 function is primarily for use by omap-onenand and tusb6010, which are both 
 OMAP specific.

Well those were the only ones so far that had to tolerate with L3
speed changes at some point, so others may need it potentially too.
And we could get rid of the omap specific onenand driver at some
point..

But yeah, I'm fine keeping those recalc functions in the device
drivers if it makes things simpler. Just something to consider in
any case.

Regards,

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

RE: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Gupta, Pekon]

From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140613 00:40]:
 On 06/13/2014 10:18 AM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [140611 01:58]:
  Since the Interrupt Events are used only by the NAND driver,
  there is no point in managing the Interrupt registers
  in the GPMC driver and complicating it with irqchip modeling.
 
  Let's manage the interrupt registers directly in the NAND driver
  and get rid of irqchip model from GPMC driver.
 
  Get rid of IRQ commands and unused commands from gpmc_configure() in
  the GPMC driver.
 
  This seems like a step backward to me. The GPMC interrupt enable
  register can do edge detection on the wait pins, how is that
  limited to NAND?

 OK. But wait pin edge detection was not yet being used and I couldn't
 think of how it would ever be used. Any ideas?

Maybe to wake-up the system on bus activity or something?

Sorry, I wasn't able to review this series.
But just as pointer, GPMC driver was used for interfacing many
non-memory devices like Ethernet (smc91x) and in past GPMC has been
proved to work with camera devices too, but that's wasn't mainlined.
So keeping IRQ and few other things in GPMC driver is helpful.




  Further, let's not start mixing GPMC hardware module register
  access with the NAND driver register access. They can be clocked
  separately. And bugs in the NAND driver can cause issues in other
  GPMC using drivers.

 I understood that NAND controller is integrated into the GPMC module and 
 they are clocked
 the same. Not sure why the hardware designers would keep the registers so 
 closely knit.

Yeah. Maybe regmap could provide some abstraction to the the
NAND registers.

As you mentioned, GPMC has two set of registers:
(a) Chip-select registers (CONFIGx_cs) for device specific parameters
 (like device-width, signal-timings, etc) which are statically programmed
during probe or via DT.
(b) ECC registers which are continuously reconfigured based on
 ECC engine.

*Ideal Scenario*
NAND driver should be considered equivalent to protocol driver,
Therefore ideally it should use only those registers which are
specific to NAND (b).

*Actual Scenario*
But most NAND device today are ONFI compliant and they have
almost all device parameters like device-width, signal-timings
burned on-die in an ONFI page. These values are read back from
NAND device during device_probe() and then re-configured back
Chip-select registers (a).
Hence NAND driver needs access of both (a) and (b), which is why
You need to export complete GPMC register set to NAND driver.
However this is not the case and has been discussed earlier too..

http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html
http://lists.infradead.org/pipermail/linux-mtd/2013-October/049347.html
(Just pointing out my version of history, would be good to read the
entire discussion. But the summary was that we need to re-configure
some GPMC chip-select registers (a) based on probe done in
NAND driver. So we need all GPMC registers exposed to NAND driver).




 FYI. memory/ti-amif.c and mtd/nand/davinci_nand.c share the AMIF register 
 space in the
 same way. I thought it'd be nice to be consistent across TI drivers.

Probably they did not yet learn the problems caused by it :)

I havn't reviewed the ti-amif.c driver completely but I think they too
configure device signal timing statically based on DT. But as per
today this is frowned upon because:

(1) Its difficult for layman user to decipher NAND signal timings
from datasheet and then convert it into controller understandable DT

(2) ONFI parameter page on NAND has these timings specified
on-die itself, and these timings are characterized for best performance
so NAND driver should re-configure these timings after probe.
Refer below mail from 'Rob Herring robherri...@gmail.com'
http://lists.infradead.org/pipermail/linux-mtd/2014-April/053488.html


Considering all these details, please re-review the changes you plan
for GPMC driver.

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

Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Roger Quadros]

On 06/13/2014 11:13 AM, Gupta, Pekon wrote:
 
 From: Tony Lindgren [mailto:t...@atomide.com]
 * Roger Quadros rog...@ti.com [140613 00:40]:
 On 06/13/2014 10:18 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140611 01:58]:
 Since the Interrupt Events are used only by the NAND driver,
 there is no point in managing the Interrupt registers
 in the GPMC driver and complicating it with irqchip modeling.

 Let's manage the interrupt registers directly in the NAND driver
 and get rid of irqchip model from GPMC driver.

 Get rid of IRQ commands and unused commands from gpmc_configure() in
 the GPMC driver.

 This seems like a step backward to me. The GPMC interrupt enable
 register can do edge detection on the wait pins, how is that
 limited to NAND?

 OK. But wait pin edge detection was not yet being used and I couldn't
 think of how it would ever be used. Any ideas?

 Maybe to wake-up the system on bus activity or something?

 Sorry, I wasn't able to review this series.
 But just as pointer, GPMC driver was used for interfacing many
 non-memory devices like Ethernet (smc91x) and in past GPMC has been
 proved to work with camera devices too, but that's wasn't mainlined.
 So keeping IRQ and few other things in GPMC driver is helpful.
 

On further study it seems that the wait pin edge detection is only used in the 
NAND controller use case.
see section 10.1.5.14.2.2 Ready Pin Monitored by Hardware Interrupt

For memory devices, no software wait pin intervention is necessary and doesn't 
even make sense.

So I don't agree on managing the IRQSTATUS and IRQENABLE register in the GPMC 
driver. It is adding unnecessary complexity. I don't mind having a wrapper 
around it though like the other nand registers.

To be frank, I think it is cleaner if the NAND driver directly accesses the 
NAND registers.
I don't see why we should make things complicated just because the hardware 
designers didn't create a clear register split between GPMC and NAND.

Only the GPMC_CONFIG register needs to remain with the GPMC driver.

cheers,
-roger

 
 
 
 Further, let's not start mixing GPMC hardware module register
 access with the NAND driver register access. They can be clocked
 separately. And bugs in the NAND driver can cause issues in other
 GPMC using drivers.

 I understood that NAND controller is integrated into the GPMC module and 
 they are clocked
 the same. Not sure why the hardware designers would keep the registers so 
 closely knit.

 Yeah. Maybe regmap could provide some abstraction to the the
 NAND registers.

 As you mentioned, GPMC has two set of registers:
 (a) Chip-select registers (CONFIGx_cs) for device specific parameters
  (like device-width, signal-timings, etc) which are statically programmed
 during probe or via DT.
 (b) ECC registers which are continuously reconfigured based on
  ECC engine.
 
 *Ideal Scenario*
 NAND driver should be considered equivalent to protocol driver,
 Therefore ideally it should use only those registers which are
 specific to NAND (b).
 
 *Actual Scenario*
 But most NAND device today are ONFI compliant and they have
 almost all device parameters like device-width, signal-timings
 burned on-die in an ONFI page. These values are read back from
 NAND device during device_probe() and then re-configured back
 Chip-select registers (a).
 Hence NAND driver needs access of both (a) and (b), which is why
 You need to export complete GPMC register set to NAND driver.
 However this is not the case and has been discussed earlier too..
 
 http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html
 http://lists.infradead.org/pipermail/linux-mtd/2013-October/049347.html
 (Just pointing out my version of history, would be good to read the
 entire discussion. But the summary was that we need to re-configure
 some GPMC chip-select registers (a) based on probe done in
 NAND driver. So we need all GPMC registers exposed to NAND driver).
 
 
 
 
 FYI. memory/ti-amif.c and mtd/nand/davinci_nand.c share the AMIF register 
 space in the
 same way. I thought it'd be nice to be consistent across TI drivers.

 Probably they did not yet learn the problems caused by it :)

 I havn't reviewed the ti-amif.c driver completely but I think they too
 configure device signal timing statically based on DT. But as per
 today this is frowned upon because:
 
 (1) Its difficult for layman user to decipher NAND signal timings
 from datasheet and then convert it into controller understandable DT
 
 (2) ONFI parameter page on NAND has these timings specified
 on-die itself, and these timings are characterized for best performance
 so NAND driver should re-configure these timings after probe.
 Refer below mail from 'Rob Herring robherri...@gmail.com'
 http://lists.infradead.org/pipermail/linux-mtd/2014-April/053488.html
 
 
 Considering all these details, please re-review the changes you plan
 for GPMC driver.
 
 with regards, pekon
 

--
To unsubscribe from this list: send the line unsubscribe 

Re: [PATCH 18/36] ARM: OMAP2+: gpmc-onenand: Move Synchronous setting code to drivers/

[Roger Quadros]

On 06/13/2014 10:55 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140611 01:59]:
 Move the code that puts the onenand in synchronous mode
 into the appropriate place i.e. drivers/mtd/onenand/omap2.c.

 Make use of omap_gpmc_get_clk_period() and omap_gpmc_retime()
 to calculate the necessary timings and configure the GPMC
 parent's timings.
 
 Ideally we would just use the drivers/mtd/onenand/generic.c
 and get rid of drivers/mtd/onenand/omap2.c. We still need
 the bus glue, which should probably be in drivers/memory?
 

But what about the runtime synchronous timing calculations onenand/omap2.c?
There is also OMAP2 and OMAP3 specific dma handling done there, which should 
probably be done generically using dmaengine.

cheers,
-roger


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

[PATCH 0/2] Couple of fixes to davinci-mcasp driver

[Jyri Sarha]

These changes target to sii9022 HDMI audio support, but are
independent fixes.

Jyri Sarha (2):
  ASoC: davinci-mcasp: Add dependecy to SND_DAVINCI_SOC or SND_OMAP_SOC
  ASoC: davinci-mcasp: Allow best effort in selecting BCLK divider

 sound/soc/davinci/Kconfig |1 +
 sound/soc/davinci/davinci-mcasp.c |   22 +-
 2 files changed, 18 insertions(+), 5 deletions(-)

-- 
1.7.9.5

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

[PATCH 1/2] ASoC: davinci-mcasp: Add dependecy to SND_DAVINCI_SOC or SND_OMAP_SOC

[Jyri Sarha]

Fixes build with SND_DAVINCI_SOC or SND_OMAP_SOC alone and adds build
dependecy to SND_DAVINCI_SOC or SND_OMAP_SOC.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 sound/soc/davinci/Kconfig |1 +
 sound/soc/davinci/davinci-mcasp.c |8 
 2 files changed, 9 insertions(+)

diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 50a0987..fdbb16f 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -6,6 +6,7 @@ config SND_DAVINCI_SOC_I2S
tristate
 
 config SND_DAVINCI_SOC_MCASP
+   depends on SND_DAVINCI_SOC || SND_OMAP_SOC
tristate
 
 config SND_DAVINCI_SOC_VCIF
diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index 9afb146..0ee4986 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1223,14 +1223,22 @@ static int davinci_mcasp_probe(struct platform_device 
*pdev)
goto err;
 
switch (mcasp-version) {
+#if IS_BUILTIN(CONFIG_SND_DAVINCI_SOC) || \
+   (IS_MODULE(CONFIG_SND_DAVINCI_SOC_MCASP)  \
+IS_MODULE(CONFIG_SND_DAVINCI_SOC))
case MCASP_VERSION_1:
case MCASP_VERSION_2:
case MCASP_VERSION_3:
ret = davinci_soc_platform_register(pdev-dev);
break;
+#endif
+#if IS_BUILTIN(CONFIG_SND_OMAP_SOC) || \
+   (IS_MODULE(CONFIG_SND_DAVINCI_SOC_MCASP)  \
+IS_MODULE(CONFIG_SND_OMAP_SOC))
case MCASP_VERSION_4:
ret = omap_pcm_platform_register(pdev-dev);
break;
+#endif
default:
dev_err(pdev-dev, Invalid McASP version: %d\n,
mcasp-version);
-- 
1.7.9.5

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

[PATCH 2/2] ASoC: davinci-mcasp: Allow best effort in selecting BCLK divider

[Jyri Sarha]

Do not fail if the exact BLCK rate can not be produced, just print a
warning. Check that sysclk frequency is set before implicitly setting
the BCLK divider.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 sound/soc/davinci/davinci-mcasp.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index 0ee4986..e26a89d 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -676,14 +676,18 @@ static int davinci_mcasp_hw_params(struct 
snd_pcm_substream *substream,
int ret;
 
/* If mcasp is BCLK master we need to set BCLK divider */
-   if (mcasp-bclk_master) {
+   if (mcasp-bclk_master  mcasp-sysclk_freq) {
unsigned int bclk_freq = snd_soc_params_to_bclk(params);
+   unsigned int div = mcasp-sysclk_freq / bclk_freq;
if (mcasp-sysclk_freq % bclk_freq != 0) {
-   dev_err(mcasp-dev, Can't produce required BCLK\n);
-   return -EINVAL;
+   if (((mcasp-sysclk_freq / div) - bclk_freq) 
+   (bclk_freq - (mcasp-sysclk_freq / (div+1
+   div++;
+   dev_warn(mcasp-dev,
+Inaccurate BCLK: %u Hz / %u != %u Hz\n,
+mcasp-sysclk_freq, div, bclk_freq);
}
-   davinci_mcasp_set_clkdiv(
-   cpu_dai, 1, mcasp-sysclk_freq / bclk_freq);
+   davinci_mcasp_set_clkdiv(cpu_dai, 1, div);
}
 
ret = mcasp_common_hw_param(mcasp, substream-stream,
-- 
1.7.9.5

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

[PATCH 1/3] ASoC: simple-card: Make u32 DT parameter handling 64-bit proof

[Jyri Sarha]

Passing unsigned int pointers as u32 ponters may be dangerous on 64-bit
system.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 sound/soc/generic/simple-card.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 03a7fdc..159e517f 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -116,6 +116,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
 {
struct device_node *node;
struct clk *clk;
+   u32 val;
int ret;
 
/*
@@ -151,10 +152,8 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
}
 
dai-sysclk = clk_get_rate(clk);
-   } else if (of_property_read_bool(np, system-clock-frequency)) {
-   of_property_read_u32(np,
-system-clock-frequency,
-dai-sysclk);
+   } else if (!of_property_read_u32(np, system-clock-frequency, val)) {
+   dai-sysclk = val;
} else {
clk = of_clk_get(node, 0);
if (!IS_ERR(clk))
@@ -303,6 +302,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
 {
struct snd_soc_dai_link *dai_link = priv-snd_card.dai_link;
struct simple_dai_props *dai_props = priv-dai_props;
+   u32 val;
int ret;
 
/* parsing the card name from DT */
@@ -325,8 +325,9 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
}
 
/* Factor to mclk, used in hw_params() */
-   of_property_read_u32(node, simple-audio-card,mclk-fs,
-priv-mclk_fs);
+   ret = of_property_read_u32(node, simple-audio-card,mclk-fs, val);
+   if (ret == 0)
+   priv-mclk_fs = val;
 
dev_dbg(dev, New simple-card: %s\n, priv-snd_card.name ?
priv-snd_card.name : );
-- 
1.7.9.5

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

[PATCH 3/3] ASoC: simple-card: Add system-clock-id DT parameter to dai nodes

[Jyri Sarha]

Select clk_id parameters for set_sysclk calls in the card init phase.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 .../devicetree/bindings/sound/simple-card.txt  |2 ++
 include/sound/simple_card.h|1 +
 sound/soc/generic/simple-card.c|6 +-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt 
b/Documentation/devicetree/bindings/sound/simple-card.txt
index 8460744..8877130 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -72,6 +72,8 @@ Optional CPU/CODEC subnodes properties:
  clock node (= common clock), or 
system-clock-frequency
  (if system doens't support common 
clock)
 - system-clock-direction   : in or out, default in
+- system-clock-id  : u32, clk_id parameter for set_sysclk,
+ default 0
 
 Example 1 - single DAI link:
 
diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
index 6d74fef..f3c7a30 100644
--- a/include/sound/simple_card.h
+++ b/include/sound/simple_card.h
@@ -19,6 +19,7 @@ struct asoc_simple_dai {
unsigned int fmt;
unsigned int sysclk;
int sysclk_dir;
+   int sysclk_id;
int slots;
int slot_width;
 };
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 8dd7957..f840d9c 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -64,7 +64,7 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
*dai,
}
 
if (set-sysclk) {
-   ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk,
+   ret = snd_soc_dai_set_sysclk(dai, set-sysclk_id, set-sysclk,
 set-sysclk_dir);
if (ret  ret != -ENOTSUPP) {
dev_err(dai-dev, simple-card: set_sysclk error\n);
@@ -150,6 +150,10 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return -EINVAL;
}
 
+   ret = of_property_read_u32(np, system-clock-id, val);
+   if (ret == 0)
+   dai-sysclk_id = val;
+
/*
 * dai-sysclk come from
 *  clocks = xxx (if system has common clock)
-- 
1.7.9.5

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

[PATCH 0/3] More simple-card dai node clock parameters

[Jyri Sarha]

These changes target to sii9022 HDMI audio support, but are
independent fixes and additions.

To cover more cases with simple-card it should be possible to select
all parameters for set_sysclk() callback. The default behavior is not
changed by these patches.

Jyri Sarha (3):
  ASoC: simple-card: Make u32 DT parameter handling 64-bit proof
  ASoC: simple-card: Add system-clock-direction DT parameter to dai
nodes
  ASoC: simple-card: Add system-clock-id DT parameter to dai nodes

 .../devicetree/bindings/sound/simple-card.txt  |3 ++
 include/sound/simple_card.h|2 ++
 sound/soc/generic/simple-card.c|   31 +++-
 3 files changed, 29 insertions(+), 7 deletions(-)

-- 
1.7.9.5

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

[PATCH 2/3] ASoC: simple-card: Add system-clock-direction DT parameter to dai nodes

[Jyri Sarha]

Select dir parameters for set_sysclk calls in the card init phase.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 .../devicetree/bindings/sound/simple-card.txt  |1 +
 include/sound/simple_card.h|1 +
 sound/soc/generic/simple-card.c|   14 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt 
b/Documentation/devicetree/bindings/sound/simple-card.txt
index c2e9841..8460744 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -71,6 +71,7 @@ Optional CPU/CODEC subnodes properties:
  it can be specified via clocks if 
system has
  clock node (= common clock), or 
system-clock-frequency
  (if system doens't support common 
clock)
+- system-clock-direction   : in or out, default in
 
 Example 1 - single DAI link:
 
diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
index 9b0ac77..6d74fef 100644
--- a/include/sound/simple_card.h
+++ b/include/sound/simple_card.h
@@ -18,6 +18,7 @@ struct asoc_simple_dai {
const char *name;
unsigned int fmt;
unsigned int sysclk;
+   int sysclk_dir;
int slots;
int slot_width;
 };
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 159e517f..8dd7957 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -64,7 +64,8 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
*dai,
}
 
if (set-sysclk) {
-   ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk, 0);
+   ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk,
+set-sysclk_dir);
if (ret  ret != -ENOTSUPP) {
dev_err(dai-dev, simple-card: set_sysclk error\n);
goto err;
@@ -116,6 +117,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
 {
struct device_node *node;
struct clk *clk;
+   const char *str;
u32 val;
int ret;
 
@@ -138,6 +140,16 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
if (ret)
return ret;
 
+   ret = of_property_read_string(np, system-clock-direction, str);
+   if (ret == 0) {
+   if (!strcmp(str, out))
+   dai-sysclk_dir = SND_SOC_CLOCK_OUT;
+   else if (!strcmp(str, in))
+   dai-sysclk_dir = SND_SOC_CLOCK_IN;
+   else
+   return -EINVAL;
+   }
+
/*
 * dai-sysclk come from
 *  clocks = xxx (if system has common clock)
-- 
1.7.9.5

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

Re: [PATCH] [media] staging: allow omap4iss to be modular

[Laurent Pinchart]

Hi Tony,

On Friday 13 June 2014 00:53:25 Tony Lindgren wrote:
 * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 23:48]:
  On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
   1. They live in separate hardware modules that can be clocked separately
  
  Actually I don't think that's true. The CSI2 PHY is part of the camera
  device, with all its registers but the one above in the camera device
  register space. For some weird reason a couple of bits were pushed to the
  control module, but that doesn't make the CSI2 PHY itself a separate
  device.
 
 Yes they are separate. Anything in the system control module is
 a separate hardware module from the other devices. So in this case
 the CSI2 PHY is part of the system control module, not the camera
 module.

Section 8.2.3 (ISS CSI2 PHY) of the OMAP4460 TRM (revision AA) documents the 
CSI2 PHY is being part of the ISS, with three PHY registers in the ISS 
register space (not counting the PHY interrupt and status bits in several 
other ISS registers) and one register in the system control module register 
space. It's far from clear which power domain(s) is (are) involved.

   2. Doing a read-back to flush a posted write in one hardware module most
  likely won't flush the write to other and that can lead into hard to
  find mysterious bugs
  
  The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ?
 
 Right, but you would have to do readbacks both from the phy register and
 camera register to ensure writes get written. It's best to keep the
 logic completely separate especially considering that they can be
 clocked separately.
 
   3. If we ever have a common system control module driver, we need to
  rewrite all the system control module register tinkering in the
  drivers
  
  Sure, but that's already the case today, as the OMAP4 ISS driver already
  accesses the control module register directly. I won't make that worse :-)
 
 Well it's in staging for a reason :)
 
   So it's best to try to use an existing framework for it. That avoids
   tons of pain later on ;)
  
  I agree, but I don't think the PHY framework would be the right
  abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS, so
  modeling its single control module register as a PHY would be a hack.
 
 Well that register belongs to the system control module, not the
 camera module. It's not like the camera IO space is out of registers
 or something! :)

The PHY has 3 registers in the ISS I/O space and one register in the control 
module I/O space. I have no idea why they've split it that way. The clock 
enable bits are especially interested, the source clock (CAM_PHY_CTRL_FCLK) 
comes from the ISS as documented in section 8.1.1 (ISS Integration), is 
gated by the control module (the gated clock is called CTRLCLK) and then goes 
back to the ISS CSI2 PHY (it's mentioned in the CSI2 PHY REGISTER1 
documentation).

 We're already handling similar control module phy cases, see for
 example drivers/phy/phy-omap-control.c. Maybe you have most of the
 code already there?

I'm afraid not. For PHYs that are in the system control module that solution 
is perfectly fine, but the CSI2 PHY isn't (or at least not all of it).

I would be fine with writing a separate PHY driver if the PHY was completely 
separate. As the documentation doesn't make it clear which part of the 
hardware belongs to which module, matching the software implementation with an 
unknown hardware implementation would be pretty difficult :-)

If you have a couple of minutes to spare and can look at the CSI2 PHY 
documentation in the TRM, you might be more successful than me figuring out 
how the hardware is implemented.

-- 
Regards,

Laurent Pinchart

--
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] OMAP: add deprecation message for legacy omap DMA API

[Russell King]

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/arm/plat-omap/dma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index b5608b1f9fbd..1c98659bbf89 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -698,6 +698,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
unsigned long flags;
struct omap_dma_lch *chan;
 
+   WARN(strcmp(dev_name, DMA engine), Using deprecated platform DMA API 
- please update to DMA engine);
+
spin_lock_irqsave(dma_chan_lock, flags);
for (ch = 0; ch  dma_chan_count; ch++) {
if (free_ch == -1  dma_chan[ch].dev_id == -1) {
-- 
1.8.3.1

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

Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140613 01:24]:
 On 06/13/2014 11:13 AM, Gupta, Pekon wrote:
  From: Tony Lindgren [mailto:t...@atomide.com]
  * Roger Quadros rog...@ti.com [140613 00:40]:
  On 06/13/2014 10:18 AM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [140611 01:58]:
 
  OK. But wait pin edge detection was not yet being used and I couldn't
  think of how it would ever be used. Any ideas?
 
  Maybe to wake-up the system on bus activity or something?
 
  Sorry, I wasn't able to review this series.
  But just as pointer, GPMC driver was used for interfacing many
  non-memory devices like Ethernet (smc91x) and in past GPMC has been
  proved to work with camera devices too, but that's wasn't mainlined.
  So keeping IRQ and few other things in GPMC driver is helpful.
  
 
 On further study it seems that the wait pin edge detection is only used in 
 the NAND controller use case.
 see section 10.1.5.14.2.2 Ready Pin Monitored by Hardware Interrupt

It seems they can be used for anything slow like NOR and NAND.
 
 For memory devices, no software wait pin intervention is necessary and 
 doesn't even make sense.

Still seems that it's use can be generic though, not limited
to NAND.
 
 So I don't agree on managing the IRQSTATUS and IRQENABLE register in the GPMC 
 driver. It is adding unnecessary complexity. I don't mind having a wrapper 
 around it though like the other nand registers.

But all the consumer driver should need to do is request_irq()
on it? That's pretty much the most common interface we have
for drivers :)
 
 To be frank, I think it is cleaner if the NAND driver directly accesses the 
 NAND registers.
 I don't see why we should make things complicated just because the hardware 
 designers didn't create a clear register split between GPMC and NAND.

Because they are in separate hardware modules :)

Who knows why it was set up this way. Maybe the plan was to have
the common features in GPMC that then can be used by various MTD
devices.
 
 Only the GPMC_CONFIG register needs to remain with the GPMC driver.

And managing clocks and runtime PM in general. In any case, let's
not let drivers tinker with the GPMC registers directly though.
Some kind of abstraction via existing frameworks or with regmap
is needed.

Regards,

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

Re: [PATCH V2 16/19] irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping

[Sricharan R]

Hi Jason,

On Thursday 12 June 2014 07:24 PM, Jason Cooper wrote:
 On Thu, Jun 12, 2014 at 05:23:24PM +0530, Sricharan R wrote:
 From: Nishanth Menon n...@ti.com

 Currently we attempt to map any crossbar value to an IRQ, however,
 this is not correct from hardware perspective. There is a max crossbar
 event number upto which hardware supports. So describe the same in
 device tree using 'ti,max-crossbar-sources' property and use it to
 validate requests.

 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  .../devicetree/bindings/arm/omap/crossbar.txt  |2 ++
  drivers/irqchip/irq-crossbar.c |   21 
 ++--
  2 files changed, 21 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt 
 b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
 index fb88585..6d2e2f5 100644
 --- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
 @@ -10,6 +10,7 @@ Required properties:
  - compatible : Should be ti,irq-crossbar
  - reg: Base address and the size of the crossbar registers.
  - ti,max-irqs: Total number of irqs available at the interrupt controller.
 +- ti,max-crossbar-sources: Maximum number of crossbar sources that can be 
 routed.
  - ti,reg-size: Size of a individual register in bytes. Every individual
  register is assumed to be of same size. Valid sizes are 1, 2, 4.
  - ti,irqs-reserved: List of the reserved irq lines that are not muxed using
 @@ -22,6 +23,7 @@ Examples:
  compatible = ti,irq-crossbar;
  reg = 0x4a002a48 0x130;
  ti,max-irqs = 160;
 +ti,max-crossbar-sources = 400;
  ti,reg-size = 2;
  ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
  };
 diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
 index 2a73a66..cf69c4d 100644
 --- a/drivers/irqchip/irq-crossbar.c
 +++ b/drivers/irqchip/irq-crossbar.c
 @@ -26,6 +26,7 @@
  /**
   * struct crossbar_device - crossbar device descriptio
   * @int_max: maximum number of supported interrupts
 + * @max_crossbar_sources: Maximum number of crossbar sources
   * @irq_map: array of interrupts to crossbar number mapping
   * @crossbar_base: crossbar base address
   * @register_offsets: offsets for each irq number
 @@ -33,6 +34,7 @@
   */
  struct crossbar_device {
  uint int_max;
 +uint max_crossbar_sources;
  uint *irq_map;
  void __iomem *crossbar_base;
  int *register_offsets;
 @@ -126,12 +128,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
   unsigned int *out_type)
  {
  int ret;
 +int req_num = intspec[1];
  
 -ret = get_prev_map_irq(intspec[1]);
 +if (req_num = cb-max_crossbar_sources) {
 +pr_err(%s: requested crossbar number %d  max %d\n,
 +   __func__, req_num, cb-max_crossbar_sources);
 +return -EINVAL;
 +}
 +
 +ret = get_prev_map_irq(req_num);
  if (ret = 0)
  goto found;
  
 -ret = allocate_free_irq(intspec[1]);
 +ret = allocate_free_irq(req_num);
  
  if (ret  0)
  return ret;
 @@ -164,6 +173,14 @@ static int __init crossbar_of_init(struct device_node 
 *node,
  if (!cb-crossbar_base)
  goto err_cb;
  
 +of_property_read_u32(node, ti,max-crossbar-sources,
 + cb-max_crossbar_sources);
 +if (!cb-max_crossbar_sources) {
 +pr_err(missing 'ti,max-crossbar-sources' property\n);
 +ret = -EINVAL;
 +goto err_base;
 +}
 
 This completely breaks all boards using old dtbs.  Please set
 max_crossbar_sources to a sane value (400) when the property is missing.
 
 +
  of_property_read_u32(node, ti,max-irqs, max);
  if (!max) {
  pr_err(missing 'ti,max-irqs' property\n);
 
 I know this is context, but you may want to look at this property as
 well and set it to a sane value instead of erroring out.
 
 crossbar dts node itself is not there in any dts yet. So this is not applicable
 for any old boards. Any future dts with crossbar node should have this property
 defined.

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

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Sricharan R]

On Friday 13 June 2014 12:26 PM, Sricharan R wrote:
 Hi Jason,
 
 On Thursday 12 June 2014 07:35 PM, Jason Cooper wrote:
 On Thu, Jun 12, 2014 at 06:57:15AM -0700, Tony Lindgren wrote:
 * Jason Cooper ja...@lakedaemon.net [140612 05:52]:
 On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
 From: Nishanth Menon n...@ti.com

 When, in the system due to varied reasons, interrupts might be unusable
 due to hardware behavior, but register maps do exist, then those 
 interrupts
 should be skipped while mapping irq to crossbars.

 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Sricharan R r.sricha...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

 Tony, have you applied these somewhere already?

 I think some of these I had applied into a branch ready for
 merging but then it was discovered that further changes
 were needed and the branch was dropped.

 Ok.

 Sricharan, please remove my Signed-off-by from this series.
 If I end up applying it for merging my scripts will add it
 automatically.

 Do you have other changes outside of irqchip depending on this series?
 If so, I can set up a topic branch for you guys to base off of.
 Otherwise, I'll just apply them to irqchip/core when they're ready.

  There are dts changes which are dependent upon this series.
 
   http://www.spinics.net/lists/linux-omap/msg108116.html
 
 Also, Sricharan, when you respin this, please clearly identify (in the
 comment section) those patches that need to be flagged for stable.  It
 would be helpful if they were the first patches in the series as well.
 
 Ok, i will point this out clearly.
 Infact since the dts node is not present in the older kernel (even now),
 the driver itself is not used. So i feel there is nothing to be flagged
  for stable as such.

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

Re: [PATCH] [media] staging: allow omap4iss to be modular

[Tony Lindgren]

* Laurent Pinchart laurent.pinch...@ideasonboard.com [140613 03:30]:
 Hi Tony,
 
 On Friday 13 June 2014 00:53:25 Tony Lindgren wrote:
  * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 23:48]:
   On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
1. They live in separate hardware modules that can be clocked separately
   
   Actually I don't think that's true. The CSI2 PHY is part of the camera
   device, with all its registers but the one above in the camera device
   register space. For some weird reason a couple of bits were pushed to the
   control module, but that doesn't make the CSI2 PHY itself a separate
   device.
  
  Yes they are separate. Anything in the system control module is
  a separate hardware module from the other devices. So in this case
  the CSI2 PHY is part of the system control module, not the camera
  module.
 
 Section 8.2.3 (ISS CSI2 PHY) of the OMAP4460 TRM (revision AA) documents 
 the 
 CSI2 PHY is being part of the ISS, with three PHY registers in the ISS 
 register space (not counting the PHY interrupt and status bits in several 
 other ISS registers) and one register in the system control module register 
 space. It's far from clear which power domain(s) is (are) involved.

OK I see. The register in the system control module just contains some
pin and clock related resources for the phy.
 
2. Doing a read-back to flush a posted write in one hardware module most
   likely won't flush the write to other and that can lead into hard to
   find mysterious bugs
   
   The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ?
  
  Right, but you would have to do readbacks both from the phy register and
  camera register to ensure writes get written. It's best to keep the
  logic completely separate especially considering that they can be
  clocked separately.
  
3. If we ever have a common system control module driver, we need to
   rewrite all the system control module register tinkering in the
   drivers
   
   Sure, but that's already the case today, as the OMAP4 ISS driver already
   accesses the control module register directly. I won't make that worse :-)
  
  Well it's in staging for a reason :)
  
So it's best to try to use an existing framework for it. That avoids
tons of pain later on ;)
   
   I agree, but I don't think the PHY framework would be the right
   abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS, so
   modeling its single control module register as a PHY would be a hack.
  
  Well that register belongs to the system control module, not the
  camera module. It's not like the camera IO space is out of registers
  or something! :)
 
 The PHY has 3 registers in the ISS I/O space and one register in the control 
 module I/O space. I have no idea why they've split it that way. The clock 
 enable bits are especially interested, the source clock (CAM_PHY_CTRL_FCLK) 
 comes from the ISS as documented in section 8.1.1 (ISS Integration), is 
 gated by the control module (the gated clock is called CTRLCLK) and then goes 
 back to the ISS CSI2 PHY (it's mentioned in the CSI2 PHY REGISTER1 
 documentation).
 
  We're already handling similar control module phy cases, see for
  example drivers/phy/phy-omap-control.c. Maybe you have most of the
  code already there?
 
 I'm afraid not. For PHYs that are in the system control module that solution 
 is perfectly fine, but the CSI2 PHY isn't (or at least not all of it).
 
 I would be fine with writing a separate PHY driver if the PHY was completely 
 separate. As the documentation doesn't make it clear which part of the 
 hardware belongs to which module, matching the software implementation with 
 an 
 unknown hardware implementation would be pretty difficult :-)

Yeah it seems the phy driver would still have to use the pin resources
in the system control module.
 
 If you have a couple of minutes to spare and can look at the CSI2 PHY 
 documentation in the TRM, you might be more successful than me figuring out 
 how the hardware is implemented.

Took a look and it seems the phy is split into two parts. So probably
using the syscon mapping for the register in scm are is a good start.
At least then there's some protection from drivers tinkering directly
with the system control modules.

Maybe s ee what drivers/regulator/pbias-regulator.c is doing with
syscon to see if that works? Moving that to some phy driver later on
should be trivial if needed :)

Regards,

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

Re: usb: musb: omap: Add device tree support for omap musb glue

[Kishon Vijay Abraham I]

Hi,

On Wednesday 11 June 2014 12:32 AM, Dan Carpenter wrote:
 Hello Kishon Vijay Abraham I,
 
 The patch 00a0b1d58af873d8: usb: musb: omap: Add device tree support
 for omap musb glue, from Sep 11 2012, leads to the following static
 checker warning:
 
   drivers/usb/musb/omap2430.c:569 omap2430_probe()
   warn: does endianness matter for 'config-num_eps'?
 
 drivers/usb/musb/omap2430.c
565  
566  of_property_read_u32(np, mode, (u32 *)pdata-mode);
567  of_property_read_u32(np, interface-type,
568  (u32 
 *)data-interface_type);
569  of_property_read_u32(np, num-eps, (u32 
 *)config-num_eps);
 
 ^^^
 
 This is not endian safe, but more importantly -num_eps is a u8 so when
 we write 32 bits to it, we are corrupting -dma_channels,
 -dyn_fifo_size, and -vendor_ctrl.  On little endian, it's going to be
 setting them to zero so it might not cause and immediate problem.
 
 The way to do this is to use a 32 bit temporary variable and then save
 the value to -num_eps afterward.  Create a small function to do this in
 a nice way.

Sure. Will do it.

Thanks
Kishon
 
 All the casts here are a bit scary.
 
570  of_property_read_u32(np, ram-bits, (u32 
 *)config-ram_bits);
571  of_property_read_u32(np, power, (u32 
 *)pdata-power);
 
 regards,
 dan carpenter
 
--
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] OMAP: add deprecation message for legacy omap DMA API

[Tony Lindgren]

* Russell King rmk+ker...@arm.linux.org.uk [140613 03:36]:
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

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

 ---
  arch/arm/plat-omap/dma.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
 index b5608b1f9fbd..1c98659bbf89 100644
 --- a/arch/arm/plat-omap/dma.c
 +++ b/arch/arm/plat-omap/dma.c
 @@ -698,6 +698,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
   unsigned long flags;
   struct omap_dma_lch *chan;
  
 + WARN(strcmp(dev_name, DMA engine), Using deprecated platform DMA API 
 - please update to DMA engine);
 +
   spin_lock_irqsave(dma_chan_lock, flags);
   for (ch = 0; ch  dma_chan_count; ch++) {
   if (free_ch == -1  dma_chan[ch].dev_id == -1) {
 -- 
 1.8.3.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Roger Quadros]

On 06/13/2014 01:46 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140613 01:24]:
 On 06/13/2014 11:13 AM, Gupta, Pekon wrote:
 From: Tony Lindgren [mailto:t...@atomide.com]
 * Roger Quadros rog...@ti.com [140613 00:40]:
 On 06/13/2014 10:18 AM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140611 01:58]:

 OK. But wait pin edge detection was not yet being used and I couldn't
 think of how it would ever be used. Any ideas?

 Maybe to wake-up the system on bus activity or something?

 Sorry, I wasn't able to review this series.
 But just as pointer, GPMC driver was used for interfacing many
 non-memory devices like Ethernet (smc91x) and in past GPMC has been
 proved to work with camera devices too, but that's wasn't mainlined.
 So keeping IRQ and few other things in GPMC driver is helpful.


 On further study it seems that the wait pin edge detection is only used in 
 the NAND controller use case.
 see section 10.1.5.14.2.2 Ready Pin Monitored by Hardware Interrupt
 
 It seems they can be used for anything slow like NOR and NAND.

But NOR driver never requests for any IRQ.

We should not confuse this wait pin edge interrupt with NOR bus cycle WAIT pin 
mechanism.
That is configured using GPMC_CONFIG1 register via WAITPINSELECT and 
WAITREAD/WRITEMONITORING bits.
That wait pin handling is done completely in hardware and doesn't need any 
software intervention.
Imagine using it for interrupt for every bus cycle wait. It will be dead slow 
and unusable.

The WAIT edge interrupt mechanism is exclusively for NAND use case to notify 
the status of READY pin after a block/page operation.

  
 For memory devices, no software wait pin intervention is necessary and 
 doesn't even make sense.
 
 Still seems that it's use can be generic though, not limited
 to NAND.
  
 So I don't agree on managing the IRQSTATUS and IRQENABLE register in the 
 GPMC driver. It is adding unnecessary complexity. I don't mind having a 
 wrapper around it though like the other nand registers.
 
 But all the consumer driver should need to do is request_irq()
 on it? That's pretty much the most common interface we have
 for drivers :)

the client driver side is easy, but it adds unnecessary complication to model 
it as IRQ chip and assign a line for each event. Since it is going to be used 
exclusively by NAND we should avoid IRQ chip modeling.

  
 To be frank, I think it is cleaner if the NAND driver directly accesses the 
 NAND registers.
 I don't see why we should make things complicated just because the hardware 
 designers didn't create a clear register split between GPMC and NAND.
 
 Because they are in separate hardware modules :)
 
 Who knows why it was set up this way. Maybe the plan was to have
 the common features in GPMC that then can be used by various MTD
 devices.
  
 Only the GPMC_CONFIG register needs to remain with the GPMC driver.
 
 And managing clocks and runtime PM in general. In any case, let's
 not let drivers tinker with the GPMC registers directly though.
 Some kind of abstraction via existing frameworks or with regmap
 is needed.

OK. I agree about using some kind of abstraction instead of direct access.

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

Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140613 04:43]:
 On 06/13/2014 01:46 PM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [140613 01:24]:
  On 06/13/2014 11:13 AM, Gupta, Pekon wrote:
  From: Tony Lindgren [mailto:t...@atomide.com]
  * Roger Quadros rog...@ti.com [140613 00:40]:
  On 06/13/2014 10:18 AM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [140611 01:58]:
 
  OK. But wait pin edge detection was not yet being used and I couldn't
  think of how it would ever be used. Any ideas?
 
  Maybe to wake-up the system on bus activity or something?
 
  Sorry, I wasn't able to review this series.
  But just as pointer, GPMC driver was used for interfacing many
  non-memory devices like Ethernet (smc91x) and in past GPMC has been
  proved to work with camera devices too, but that's wasn't mainlined.
  So keeping IRQ and few other things in GPMC driver is helpful.
 
 
  On further study it seems that the wait pin edge detection is only used in 
  the NAND controller use case.
  see section 10.1.5.14.2.2 Ready Pin Monitored by Hardware Interrupt
  
  It seems they can be used for anything slow like NOR and NAND.
 
 But NOR driver never requests for any IRQ.
 
 We should not confuse this wait pin edge interrupt with NOR bus cycle WAIT 
 pin mechanism.
 That is configured using GPMC_CONFIG1 register via WAITPINSELECT and 
 WAITREAD/WRITEMONITORING bits.
 That wait pin handling is done completely in hardware and doesn't need any 
 software intervention.
 Imagine using it for interrupt for every bus cycle wait. It will be dead slow 
 and unusable.
 
 The WAIT edge interrupt mechanism is exclusively for NAND use case to notify 
 the status of READY pin after a block/page operation.

OK thanks for clarifying it. 
 
  For memory devices, no software wait pin intervention is necessary and 
  doesn't even make sense.
  
  Still seems that it's use can be generic though, not limited
  to NAND.
   
  So I don't agree on managing the IRQSTATUS and IRQENABLE register in the 
  GPMC driver. It is adding unnecessary complexity. I don't mind having a 
  wrapper around it though like the other nand registers.
  
  But all the consumer driver should need to do is request_irq()
  on it? That's pretty much the most common interface we have
  for drivers :)
 
 the client driver side is easy, but it adds unnecessary complication to model 
 it as IRQ chip and assign a line for each event. Since it is going to be used 
 exclusively by NAND we should avoid IRQ chip modeling.

OK up to you if there are no other users for it. 
 
  To be frank, I think it is cleaner if the NAND driver directly accesses 
  the NAND registers.
  I don't see why we should make things complicated just because the 
  hardware designers didn't create a clear register split between GPMC and 
  NAND.
  
  Because they are in separate hardware modules :)
  
  Who knows why it was set up this way. Maybe the plan was to have
  the common features in GPMC that then can be used by various MTD
  devices.
   
  Only the GPMC_CONFIG register needs to remain with the GPMC driver.
  
  And managing clocks and runtime PM in general. In any case, let's
  not let drivers tinker with the GPMC registers directly though.
  Some kind of abstraction via existing frameworks or with regmap
  is needed.
 
 OK. I agree about using some kind of abstraction instead of direct access.

Yes and like we chatted on irc, adding a syscon mapping for for
the NAND specific registers might do the trick here.

Regards,

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

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Jason Cooper]

On Fri, Jun 13, 2014 at 12:26:10PM +0530, Sricharan R wrote:
 On Thursday 12 June 2014 07:35 PM, Jason Cooper wrote:
...
  Do you have other changes outside of irqchip depending on this series?
  If so, I can set up a topic branch for you guys to base off of.
  Otherwise, I'll just apply them to irqchip/core when they're ready.
  
  There are dts changes which are dependent upon this series.
 
   http://www.spinics.net/lists/linux-omap/msg108116.html

In general, dts changes shouldn't depend on code changes or vice-versa.
If they do, that's an indicator that we're breaking compatibility with
older dtbs.

Looking at the dra7.dtsi changes, we're redefining the interrupt
property, which can't be good. :(

Perhaps a better solution would be to add a property, say 'ti,cross-irq'
that is the exact same format as 'interrupts', but is used by the
crossbar driver?

I'm not convinced of this yet, I suspect we may not actually have a
dependency between the dtsi changes and the code changes.  We would have
the ugly if you have the crossbar node, 'interrupts' means X, if not it
means Y in the binding docs.  But the absence of the node prevents the
crossbar driver from re-interpreting the interrupts property.

Have you tried booting all the different scenarios?  eg:

  old dtb, new driver
  new dtb, old driver
  old dtb, old driver
  new dtb, new driver

thx,

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

Re: [PATCH V2 05/19] irqchip: crossbar: Change allocation logic by reversing search for free irqs

[Jason Cooper]

On Fri, Jun 13, 2014 at 11:39:39AM +0530, Sricharan R wrote:
 Hi Jason,
 
 On Thursday 12 June 2014 06:26 PM, Jason Cooper wrote:
  On Thu, Jun 12, 2014 at 05:23:13PM +0530, Sricharan R wrote:
  From: Nishanth Menon n...@ti.com
 
  Reverse the search algorithm to ensure that address mapping and IRQ
  allocation logics are proper. This can open up new bugs which are
  easily fixable rather than wait till allocation logic approaches
  the limit to find new bugs.
  
  Could you expand on this logic some more?  What class of bugs are you
  hoping to discover more easily?
  
 
 class 1. address space errors - example:
 reg = a size_b
 ti,max-irqs =  is a wrong parameter
 
 class 2: irq-reserved list - which decides which entries in the
 address space is not actually wired in
 
 class 3: wrong list of routable-irqs.
 
 in general allocating from max to min tends to have benefits in
 ensuring the different issues that may be present in dts is easily
 caught at definition time, rather than at a later point in time.

Perfect, thanks for clarifying.  Please add this to the commit log when
you respin.

thx,

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

Re: [PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning

[Jason Cooper]

On Fri, Jun 13, 2014 at 12:00:31PM +0530, Sricharan R wrote:
   Ok, if this is not qualifying as a separate patch then i will merge
   this with other patches in the series which touch them.

A good general rule of thumb is to just run checkpatch on the patches,
not the source files.  This way, we prevent new warnings from being
introduced, and we can cleanup stuff in the immediate vicinity to code
we are already changing.

thx,

Jason.
--
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] [media] staging: allow omap4iss to be modular

[Laurent Pinchart]

Hi Tony,

On Friday 13 June 2014 04:10:12 Tony Lindgren wrote:
 * Laurent Pinchart laurent.pinch...@ideasonboard.com [140613 03:30]:
  On Friday 13 June 2014 00:53:25 Tony Lindgren wrote:
   * Laurent Pinchart laurent.pinch...@ideasonboard.com [140612 23:48]:
On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
 1. They live in separate hardware modules that can be clocked
 separately

Actually I don't think that's true. The CSI2 PHY is part of the camera
device, with all its registers but the one above in the camera device
register space. For some weird reason a couple of bits were pushed to
the control module, but that doesn't make the CSI2 PHY itself a
separate device.
   
   Yes they are separate. Anything in the system control module is
   a separate hardware module from the other devices. So in this case
   the CSI2 PHY is part of the system control module, not the camera
   module.
  
  Section 8.2.3 (ISS CSI2 PHY) of the OMAP4460 TRM (revision AA) documents
  the CSI2 PHY is being part of the ISS, with three PHY registers in the
  ISS register space (not counting the PHY interrupt and status bits in
  several other ISS registers) and one register in the system control
  module register space. It's far from clear which power domain(s) is (are)
  involved.

 OK I see. The register in the system control module just contains some
 pin and clock related resources for the phy.

And the configuration of the PHY mode (CCP2, CSI1 or CSI2). It really seems 
like random bits :-)

 2. Doing a read-back to flush a posted write in one hardware module
most likely won't flush the write to other and that can lead into
hard to find mysterious bugs

The OMAP4 ISS driver can just read back the CAMERA_RX register, can't
it ?
   
   Right, but you would have to do readbacks both from the phy register and
   camera register to ensure writes get written. It's best to keep the
   logic completely separate especially considering that they can be
   clocked separately.
   
 3. If we ever have a common system control module driver, we need to
rewrite all the system control module register tinkering in the
drivers

Sure, but that's already the case today, as the OMAP4 ISS driver
already accesses the control module register directly. I won't make
that worse :-)
   
   Well it's in staging for a reason :)
   
 So it's best to try to use an existing framework for it. That avoids
 tons of pain later on ;)

I agree, but I don't think the PHY framework would be the right
abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS,
so modeling its single control module register as a PHY would be a
hack.
   
   Well that register belongs to the system control module, not the
   camera module. It's not like the camera IO space is out of registers
   or something! :)
  
  The PHY has 3 registers in the ISS I/O space and one register in the
  control module I/O space. I have no idea why they've split it that way.
  The clock enable bits are especially interested, the source clock
  (CAM_PHY_CTRL_FCLK) comes from the ISS as documented in section 8.1.1
  (ISS Integration), is gated by the control module (the gated clock is
  called CTRLCLK) and then goes back to the ISS CSI2 PHY (it's mentioned in
  the CSI2 PHY REGISTER1 documentation).
  
   We're already handling similar control module phy cases, see for
   example drivers/phy/phy-omap-control.c. Maybe you have most of the
   code already there?
  
  I'm afraid not. For PHYs that are in the system control module that
  solution is perfectly fine, but the CSI2 PHY isn't (or at least not all
  of it).
  
  I would be fine with writing a separate PHY driver if the PHY was
  completely separate. As the documentation doesn't make it clear which
  part of the hardware belongs to which module, matching the software
  implementation with an unknown hardware implementation would be pretty
  difficult :-)
 
 Yeah it seems the phy driver would still have to use the pin resources
 in the system control module.
 
  If you have a couple of minutes to spare and can look at the CSI2 PHY
  documentation in the TRM, you might be more successful than me figuring
  out how the hardware is implemented.
 
 Took a look and it seems the phy is split into two parts. So probably
 using the syscon mapping for the register in scm are is a good start.
 At least then there's some protection from drivers tinkering directly
 with the system control modules.

That's my plan.

 Maybe s   ee what drivers/regulator/pbias-regulator.c is doing with
 syscon to see if that works? Moving that to some phy driver later on
 should be trivial if needed :)

I'll have a look, but I'm not sure whether the same approach will be possible.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to 

Re: [PATCH V2 16/19] irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping

[Jason Cooper]

On Fri, Jun 13, 2014 at 04:24:52PM +0530, Sricharan R wrote:
 On Thursday 12 June 2014 07:24 PM, Jason Cooper wrote:
  On Thu, Jun 12, 2014 at 05:23:24PM +0530, Sricharan R wrote:
...
  +  of_property_read_u32(node, ti,max-crossbar-sources,
  +   cb-max_crossbar_sources);
  +  if (!cb-max_crossbar_sources) {
  +  pr_err(missing 'ti,max-crossbar-sources' property\n);
  +  ret = -EINVAL;
  +  goto err_base;
  +  }
  
  This completely breaks all boards using old dtbs.  Please set
  max_crossbar_sources to a sane value (400) when the property is missing.
  
  +
 of_property_read_u32(node, ti,max-irqs, max);
 if (!max) {
 pr_err(missing 'ti,max-irqs' property\n);
  
  I know this is context, but you may want to look at this property as
  well and set it to a sane value instead of erroring out.
  
  crossbar dts node itself is not there in any dts yet. So this is not 
 applicable
  for any old boards. Any future dts with crossbar node should have this 
 property
  defined.

Now that I see the dra7.dtsi changes, I fully agree.

thx,

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

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Jason Cooper]

On Fri, Jun 13, 2014 at 12:07:49PM +0530, Sricharan R wrote:
 Hi Jason,
 
 On Thursday 12 June 2014 07:37 PM, Jason Cooper wrote:
  On Thu, Jun 12, 2014 at 06:49:17PM +0530, Sricharan R wrote:
  Hi Jason,
 
  On Thursday 12 June 2014 06:21 PM, Jason Cooper wrote:
  On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
  From: Nishanth Menon n...@ti.com
 
  When, in the system due to varied reasons, interrupts might be unusable
  due to hardware behavior, but register maps do exist, then those 
  interrupts
  should be skipped while mapping irq to crossbars.
 
  Signed-off-by: Nishanth Menon n...@ti.com
  Signed-off-by: Sricharan R r.sricha...@ti.com
  Signed-off-by: Tony Lindgren t...@atomide.com
 
  Tony, have you applied these somewhere already?
 
  ---
   drivers/irqchip/irq-crossbar.c |   47 
  
   1 file changed, 43 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/irqchip/irq-crossbar.c 
  b/drivers/irqchip/irq-crossbar.c
  index 51d4b87..847f6e3 100644
  --- a/drivers/irqchip/irq-crossbar.c
  +++ b/drivers/irqchip/irq-crossbar.c
  @@ -13,11 +13,13 @@
   #include linux/io.h
   #include linux/of_address.h
   #include linux/of_irq.h
  +#include linux/of_device.h
   #include linux/slab.h
   #include linux/irqchip/arm-gic.h
   
   #define IRQ_FREE-1
   #define IRQ_RESERVED-2
  +#define IRQ_SKIP-3
   #define GIC_IRQ_START   32
   
   /*
  @@ -34,6 +36,16 @@ struct crossbar_device {
   void (*write) (int, int);
   };
   
  +/**
  + * struct crossbar_data: Platform specific data
  + * @irqs_unused: array of irqs that cannot be used because of hw erratas
  + * @size: size of the irqs_unused array
  + */
  +struct crossbar_data {
  +const uint *irqs_unused;
  +const uint size;
  +};
  +
   static struct crossbar_device *cb;
   
   static inline void crossbar_writel(int irq_no, int cb_no)
  @@ -119,10 +131,12 @@ const struct irq_domain_ops 
  routable_irq_domain_ops = {
   .xlate = crossbar_domain_xlate
   };
   
  -static int __init crossbar_of_init(struct device_node *node)
  +static int __init crossbar_of_init(struct device_node *node,
  +   const struct crossbar_data *data)
   {
   int i, size, max, reserved = 0, entry;
   const __be32 *irqsr;
  +const int *irqsk = NULL;
   
   cb = kzalloc(sizeof(*cb), GFP_KERNEL);
   
  @@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct 
  device_node *node)
   reserved += size;
   }
   
  +/* Skip the ones marked as unused */
  +if (data) {
  +irqsk = data-irqs_unused;
  +size = data-size;
  +
  +for (i = 0; i  size; i++) {
  +entry = irqsk[i];
  +
  +if (entry  max) {
  +pr_err(Invalid skip entry\n);
  +goto err3;
  +}
  +cb-irq_map[entry] = IRQ_SKIP;
  +}
  +}
  +
   register_routable_domain_ops(routable_irq_domain_ops);
   return 0;
   
  @@ -208,18 +238,27 @@ err1:
   return -ENOMEM;
   }
   
  +/* irq number 10 cannot be used because of hw bug */
  +int dra_irqs_unused[] = { 10 };
  +struct crossbar_data cb_dra_data = { dra_irqs_unused,
  + ARRAY_SIZE(dra_irqs_unused) };
  +
   static const struct of_device_id crossbar_match[] __initconst = {
  -{ .compatible = ti,irq-crossbar },
  +{ .compatible = ti,irq-crossbar, .data = cb_dra_data },
   {}
   };
 
  This is a bug in all implementations of this IP?  Or, a specific
  SoC's implementation?  Would this be better expressed in the dts via a
  property?  Can we expect future implementations to be fixed?
 
  thx,
 
  Jason.
   Infact this and PATCH#10 should be merged. I will change that.
 
   So in Socs's (2 so far) that do have a crossbar, some irqs are mapped
   through a crossbar and some are directly wired to the irqchip.
   These 'unused irqs' are those which are directly wired but they still
   have a crossbar register. Their routing cannot be changed. So this
   is not really expected usage of the crossbar hw ip. We initially thought
   having a dts property separately for this, but took this path to avoid
   loading the dts with additional bindings which may not be generic.
  
  How do you plan to handle future SoCs with this IP and possibly
  different hard-wired irqs?
   Yes, that would require adding a new compatible in the above list and dts.
   So if adding a new binding in the dts would be cleaner, then i will change
   it that way.

Yes, unless the DT maintainers have shot the idea down, I'd prefer to
see a separate property.  With the method you currently have, we'll have
to change the compatible when the IP _hasn't_ changed, just because the
SoC was wired differently.

We 

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Santosh Shilimkar]

On Friday 13 June 2014 09:10 AM, Jason Cooper wrote:
 On Fri, Jun 13, 2014 at 12:26:10PM +0530, Sricharan R wrote:
 On Thursday 12 June 2014 07:35 PM, Jason Cooper wrote:
 ...
 Do you have other changes outside of irqchip depending on this series?
 If so, I can set up a topic branch for you guys to base off of.
 Otherwise, I'll just apply them to irqchip/core when they're ready.

  There are dts changes which are dependent upon this series.

   http://www.spinics.net/lists/linux-omap/msg108116.html
 
 In general, dts changes shouldn't depend on code changes or vice-versa.
 If they do, that's an indicator that we're breaking compatibility with
 older dtbs.

Thats true. The case with cross-bar though is the feature wasn't
completly supported so far before this series. Perhaps the the initial
bindings should have been marked unstable. 
 
 Looking at the dra7.dtsi changes, we're redefining the interrupt
 property, which can't be good. :(

 Perhaps a better solution would be to add a property, say 'ti,cross-irq'
 that is the exact same format as 'interrupts', but is used by the
 crossbar driver?

We have gone over those earlier and it was agreed to re-use interrupt
properties and for special cases, define a cross-bar property to describe
it.
 
 I'm not convinced of this yet, I suspect we may not actually have a
 dependency between the dtsi changes and the code changes.  We would have
 the ugly if you have the crossbar node, 'interrupts' means X, if not it
 means Y in the binding docs.  But the absence of the node prevents the
 crossbar driver from re-interpreting the interrupts property.
 
In ideal cross-bar hardware you don't need the assumption if you have the
crossbar node, 'interrupts' means X, if not it means Y

It is purely because the cross-bar irq router hardware has few nasty
bugs which needs those special handling. And thats the reason, the
property was added.

 Have you tried booting all the different scenarios?  eg:
 
   old dtb, new driver
   new dtb, old driver
   old dtb, old driver
   new dtb, new driver
 
Old driver wasn't complete as mentioned and hence the above
combinations becomes bit irrelevant.

Regards,
Santosh


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

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Jason Cooper]

On Fri, Jun 13, 2014 at 09:35:20AM -0400, Santosh Shilimkar wrote:
 On Friday 13 June 2014 09:10 AM, Jason Cooper wrote:
...
  Have you tried booting all the different scenarios?  eg:
  
old dtb, new driver
new dtb, old driver
old dtb, old driver
new dtb, new driver
  
 Old driver wasn't complete as mentioned and hence the above
 combinations becomes bit irrelevant.

Ahh, great!  In that case, I think we should be good without the
dependency between the code changes and the dtsi changes.

thx,

Jason.
--
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/5] Handle non-secure L2C initialization on Exynos4

[Tomasz Figa]

Hi Daniel,

I have attached, three patches which make the kernel boot fine with L2
cache enabled on ODROID-U3. Could you test them on your setup to verify
that they indeed fix the issue?

Best regards,
Tomasz

On 12.06.2014 15:38, Daniel Drake wrote:
 Hi Tomasz,
 
 Thanks for working on this!
 
 I have just tried this, against Linus master
 64b2d1fbbfda07765dae3f601862796a61b2c451.
 Added patch ARM: dts: Initial ODROID U2 support and booted on
 ODROID-U2. I believe this board has the security enabled.
 
 Unfortunately, it hangs during early boot. With earlyprintk the last
 messages seen are:
 
 L2C: platform modifies aux control register: 0x0207 - 0x3e470001
 L2C: platform provided aux values permit register corruption.
 L2C: DT/platform modifies aux control register: 0x0207 - 0x3e470001
 L2C-310 enabling early BRESP for Cortex-A9
 L2C-310: enabling full line of zeros but not enabled in Cortex-A9
 L2C-310 ID prefetch enabled, offset 1 lines
 L2C-310 dynamic clock gating enabled, standby mode enabled
 L2C-310 cache controller enabled, 16 ways, 1024 kB
 L2C-310: CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001
 
 I then tried to go back to the earlier patch ARM: EXYNOS: Add secure
 firmware support for l2x0 init (attached, needed a rebase) but that
 one also now hangs at:
 
 L2C: platform modifies aux control register: 0x0207 - 0x3e470001
 
 It did work on 3.14 though. Looking at the changelogs, many changes
 have been made to l2x0 recently. Can you confirm that you have tested
 your patches against a kernel with all of Russell King's recent
 changes?
 
 Thanks
 Daniel
 
From b574212db2c1c226212c74b475acceb7fa507c27 Mon Sep 17 00:00:00 2001
From: Tomasz Figa t.f...@samsung.com
Date: Fri, 13 Jun 2014 16:40:29 +0200
Subject: [PATCH 1/3] ARM: EXYNOS: Invalidate L2 cache with SMC command before
 enabling

Signed-off-by: Tomasz Figa t.f...@samsung.com
---
 arch/arm/mach-exynos/firmware.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index d8544537..a688757 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -110,6 +110,8 @@ static void exynos_l2_write_sec(unsigned long val, void __iomem *base,
 {
 	switch (reg) {
 	case L2X0_CTRL:
+		if (val  L2X0_CTRL_EN)
+			exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
 		exynos_smc(SMC_CMD_L2X0CTRL, val, 0, 0);
 		break;
 
-- 
1.9.3

From 0803df887262849ab8ef905f15fdbe2b34598dde Mon Sep 17 00:00:00 2001
From: Tomasz Figa t.f...@samsung.com
Date: Fri, 13 Jun 2014 16:48:47 +0200
Subject: [PATCH 2/3] ARM: mm: l2x0: Add support for overriding prefetch
 settings

Signed-off-by: Tomasz Figa t.f...@samsung.com
---
 Documentation/devicetree/bindings/arm/l2cc.txt | 10 ++
 arch/arm/mm/cache-l2x0.c   | 46 ++
 2 files changed, 56 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index b513cb8..8096fcd 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -44,6 +44,16 @@ Optional properties:
 - cache-id-part: cache id part number to be used if it is not present
   on hardware
 - wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+  non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+  if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+  if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
+  disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+  0-7, 15, 23, and 31.
 
 Example:
 
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index c25cc13..de39865 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1018,9 +1018,12 @@ static const struct l2c_init_data of_l2c220_data __initconst = {
 static void __init l2c310_of_parse(const struct device_node *np,
 	u32 *aux_val, u32 *aux_mask)
 {
+	bool set_prefetch = false;
 	u32 data[3] = { 0, 0, 0 };
 	u32 tag[3] = { 0, 0, 0 };
 	u32 filter[2] = { 0, 0 };
+	u32 prefetch;
+	u32 val;
 
 	of_property_read_u32_array(np, arm,tag-latency, tag, ARRAY_SIZE(tag));
 	if (tag[0]  tag[1]  tag[2])
@@ -1047,6 +1050,49 @@ static void __init l2c310_of_parse(const struct device_node *np,
 		writel_relaxed((filter[0]  ~(SZ_1M - 1)) | L310_ADDR_FILTER_EN,
 			   l2x0_base + L310_ADDR_FILTER_START);
 	}
+
+	prefetch = readl_relaxed(l2x0_base + L310_PREFETCH_CTRL);
+
+	if (!of_property_read_u32(np, arm,double-linefill, val)) {
+		if (val)
+			prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL;
+		else
+			prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL;
+		set_prefetch = true;
+	}
+
+	if (!of_property_read_u32(np, arm,double-linefill-incr, val)) {
+		if (val)
+			

Re: [PATCH V2 00/19] irqchip: crossbar: driver fixes

[Jason Cooper]

On Thu, Jun 12, 2014 at 05:23:08PM +0530, Sricharan R wrote:
 This series does some cleanups, fixes for handling two interrupts
 getting mapped twice to same crossbar and provides support for
 hardwired IRQ and crossbar definitions.
 
 On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10,
 131, 132, 133 are direct wired to hardware blocks bypassing
 crossbar. This quirky implementation is *NOT* supposed to be the
 expectation of crossbar hardware usage. This series adds support
 to represent such hard-wired irqs through DT and avoid generic
 allocation/programming of crossbar in the driver.
 
 This way of supporting hard-wired irqs was a result of
 the below discussions.
 http://www.spinics.net/lists/arm-kernel/msg329946.html
 
 Based on 3.15 mainline.
 
 All the patches are available here
  g...@github.com:Sricharanti/sricharan.git crossbar_updates
 
 The fixes series[1] earlier posted is merged in to this.
 [1] http://www.spinics.net/lists/arm-kernel/msg328273.html
 
 [V2] Merged the above series and rebased on 3.15 mainline
 
 Nishanth Menon (16):
   irqchip: crossbar: dont use '0' to mark reserved interrupts
   irqchip: crossbar: check for premapped crossbar before allocating
   irqchip: crossbar: Skip some irqs from getting mapped to crossbar
   irqchip: crossbar: Initialise the crossbar with a safe value
   irqchip: crossbar: Change allocation logic by reversing search for
 free irqs
   irqchip: crossbar: remove IS_ERR_VALUE check
   irqchip: crossbar: fix sparse warnings
   irqchip: crossbar: fix checkpatch warning
   irqchip: crossbar: fix kerneldoc warning
   irqchip: crossbar: fix memory leak incase of invalid entry
   irqchip: crossbar: return proper error value
   irqchip: crossbar: change the goto naming
   irqchip: crossbar: introduce ti,max-crossbar-sources to identify
 valid crossbar mapping
   irqchip: crossbar: introduce centralized check for crossbar write
   Documentation: dt: OMAP: crossbar: add description for interrupt
 consumer
   irqchip: crossbar allow for quirky hardware with direct hardwiring of
 GIC
 
 Rajendra Nayak (1):
   irqchip: crossbar: DRA7: Fix unused crossbar list
 
 Sricharan R (2):
   irqchip: crossbar: set cb pointer to null in case of error
   irqchip: crossbar: Add kerneldoc for crossbar_domain_unmap callback

Also, I just noticed this when I decided to look at the history of this
driver: Please format the subject lines like so:

  irqchip: crossbar: Set cb pointer ...
 ^
 |
 \-- note the capitalization

thx,

Jason.
--
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 02/14] ARM: omap2: fix am43xx dependency on l2x0 cache

[Arnd Bergmann]

Commit d941f86fad41b (ARM: l2c: AM43x: add L2 cache support) enabled
the L2 cache support for the am43xx SoC, but caused a build regression
when the driver for that cache controller is disabled:

arch/arm/mach-omap2/built-in.o: In function `am43xx_init_early':
:(.init.text+0xb20): undefined reference to `omap_l2_cache_init'

This did not happen for OMAP4, which has the same call, but enables
the l2x0 driver unconditionally. We could do the same thing for
am43xx, but it seems better to allow turning it off and make the
code work in either case.

This adds an inline wrapper for omap_l2_cache_init for the disabled
case, and removes the 'select' from OMAP4 so it becomes a user
visible option.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-omap@vger.kernel.org
Cc: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/omap2plus_defconfig | 1 +
 arch/arm/mach-omap2/Kconfig  | 1 -
 arch/arm/mach-omap2/common.h | 7 +++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 59066cf..536a137 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -32,6 +32,7 @@ CONFIG_SOC_OMAP5=y
 CONFIG_SOC_AM33XX=y
 CONFIG_SOC_AM43XX=y
 CONFIG_SOC_DRA7XX=y
+CONFIG_CACHE_L2X0=y
 CONFIG_ARM_THUMBEE=y
 CONFIG_ARM_ERRATA_411920=y
 CONFIG_SMP=y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0ba4826..2085b3d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -28,7 +28,6 @@ config ARCH_OMAP4
select ARM_CPU_SUSPEND if PM
select ARM_ERRATA_720789
select ARM_GIC
-   select CACHE_L2X0
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select OMAP_INTERCONNECT
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index ff02973..a373d50 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -91,7 +91,14 @@ extern void omap3_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
 extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
+#ifdef CONFIG_CACHE_L2X0
 int omap_l2_cache_init(void);
+#else
+static inline int omap_l2_cache_init(void)
+{
+   return 0;
+}
+#endif
 extern void omap5_realtime_timer_init(void);
 
 void omap2420_init_early(void);
-- 
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 00/14] arm-soc fixes for 3.16 review

[Arnd Bergmann]

Hi Everyone,

here are the fixes I've picked up so far as the last pull request
for the merge window. I'm sure there will be a lot more in the
future, but let us know if I missed something or if any of the
patches (in particular mine, some of which I have not posted
before) are not ok.

Arnd Bergmann (6):
  ARM: mvebu: fix randconfig builds for pmsu driver
  ARM: omap2: fix am43xx dependency on l2x0 cache
  ARM: keystone requires ARM_PATCH_PHYS_VIRT
  bus/arm-cci: add dependency on OF  CPU_V7
  remoteproc: da8xx: don't select CMA on no-MMU
  ARM: samsung: make SAMSUNG_DMADEV optional

Dan Carpenter (1):
  misc: vexpress: fix error handling vexpress_syscfg_regmap_init()

Jason Cooper (1):
  ARM: mvebu: DT: fix OpenBlocks AX3-4 RAM size

Linus Walleij (1):
  ARM: integrator: fix section mismatch problem

Olof Johansson (1):
  ARM: exynos: move sysram info to exynos.c

Rob Herring (2):
  ARM: exynos: cleanup kconfig option display
  ARM: use menuconfig for sub-arch menus

Sachin Kamat (1):
  ARM: EXYNOS: Fix compilation warning

Stephen Boyd (1):
  ARM: Remove ARCH_HAS_CPUFREQ config option

 arch/arm/Kconfig | 20 +--
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  2 +-
 arch/arm/configs/omap2plus_defconfig |  1 +
 arch/arm/mach-bcm/Kconfig|  7 +++---
 arch/arm/mach-berlin/Kconfig |  6 +
 arch/arm/mach-cns3xxx/Kconfig|  7 +++---
 arch/arm/mach-davinci/Kconfig|  1 -
 arch/arm/mach-exynos/Kconfig |  7 +-
 arch/arm/mach-exynos/common.h|  1 +
 arch/arm/mach-exynos/exynos.c| 31 +++-
 arch/arm/mach-exynos/platsmp.c   | 26 ++--
 arch/arm/mach-highbank/Kconfig   |  1 -
 arch/arm/mach-imx/Kconfig| 10 +++-
 arch/arm/mach-integrator/Kconfig |  2 +-
 arch/arm/mach-integrator/impd1.c | 12 -
 arch/arm/mach-keystone/Kconfig   |  1 +
 arch/arm/mach-moxart/Kconfig |  2 +-
 arch/arm/mach-mvebu/Kconfig  |  8 ++
 arch/arm/mach-mvebu/pmsu.c   |  9 ++-
 arch/arm/mach-nomadik/Kconfig|  4 +--
 arch/arm/mach-omap2/Kconfig  | 11 +
 arch/arm/mach-omap2/common.h |  7 ++
 arch/arm/mach-prima2/Kconfig |  6 ++---
 arch/arm/mach-qcom/Kconfig   |  6 +
 arch/arm/mach-s3c24xx/Kconfig|  2 +-
 arch/arm/mach-s3c64xx/Kconfig|  4 +--
 arch/arm/mach-s5p64x0/Kconfig|  6 +++--
 arch/arm/mach-s5pc100/Kconfig|  3 ++-
 arch/arm/mach-s5pv210/Kconfig|  3 ++-
 arch/arm/mach-shmobile/Kconfig   |  6 ++---
 arch/arm/mach-spear/Kconfig  |  1 -
 arch/arm/mach-tegra/Kconfig  |  8 +++---
 arch/arm/mach-u300/Kconfig   |  6 +
 arch/arm/mach-ux500/Kconfig  |  7 +-
 arch/arm/mach-vexpress/Kconfig   |  8 +++---
 arch/arm/mach-vt8500/Kconfig |  1 -
 arch/arm/mach-zynq/Kconfig   |  1 -
 arch/arm/plat-samsung/Kconfig| 28 ++---
 drivers/bus/Kconfig  |  2 +-
 drivers/misc/vexpress-syscfg.c   | 12 ++---
 drivers/remoteproc/Kconfig   |  2 +-
 41 files changed, 127 insertions(+), 161 deletions(-)

-- 
1.8.3.2

Cc: and...@lunn.ch
Cc: a...@arndb.de
Cc: ben-li...@fluff.org
Cc: dan.carpen...@oracle.com
Cc: daniel.lezc...@linaro.org
Cc: gregory.clem...@free-electrons.com
Cc: ja...@lakedaemon.net
Cc: khil...@linaro.org
Cc: kgene@samsung.com
Cc: linus.wall...@linaro.org
Cc: lorenzo.pieral...@arm.com
Cc: o...@wizery.com
Cc: o...@lixom.net
Cc: pawel.m...@arm.com
Cc: r...@kernel.org
Cc: rt...@ti.com
Cc: li...@arm.linux.org.uk
Cc: sachin.ka...@linaro.org
Cc: santosh.shilim...@ti.com
Cc: sebastian.hesselba...@gmail.com
Cc: shawn@linaro.org
Cc: sb...@codeaurora.org
Cc: t.f...@samsung.com
Cc: t...@atomide.com
Cc: tushar.beh...@linaro.org
Cc: viresh.ku...@linaro.org
Cc:  linux-omap@vger.kernel.org
Cc:  linux-samsung-...@vger.kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 00/19] irqchip: crossbar: driver fixes

[Joe Perches]

On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
 Please format the subject lines like so:
 
   irqchip: crossbar: Set cb pointer ...
  ^
  |
  \-- note the capitalization

I suggest you don't make this a rule and focus
on more important stuff instead.

Nobody is going to write tools that parse the
changelogs by git log --format=%s for case
sensitivity.

As is, it's about half/half.

$ git log --format=%s --no-merges drivers/irqchip/ | \
  grep ^irqchip: | cut -f3- -d:

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

[PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

Add support for TI's AM437x StarterKit Evaluation
Module.

Cc: Josh Elliot jelli...@ti.com
Cc: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---

Thanks to Josh and Darren for helping out with Audio and Display parts of this
DTS.

 .../devicetree/bindings/arm/omap/omap.txt  |   3 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/am437x-sk-evm.dts| 539 +
 3 files changed, 543 insertions(+)
 create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index d22b216..0edc903 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -129,6 +129,9 @@ Boards:
 - AM437x GP EVM
   compatible = ti,am437x-gp-evm, ti,am4372, ti,am43
 
+- AM437x SK EVM: AM437x StarterKit Evaluation Module
+  compatible = ti,am437x-sk-evm, ti,am4372, ti,am43
+
 - DRA742 EVM:  Software Development Board for DRA742
   compatible = ti,dra7-evm, ti,dra742, ti,dra74, ti,dra7
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0f1e8be..749cdc8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-var-dvk-om44.dtb \
omap4-var-stk-om44.dtb
 dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
+   am437x-sk-evm.dtb \
am437x-gp-evm.dtb
 dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
b/arch/arm/boot/dts/am437x-sk-evm.dts
new file mode 100644
index 000..51ffab1
--- /dev/null
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -0,0 +1,539 @@
+/*
+ * Copyright (C) 2014 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.
+ */
+
+/* AM437x SK EVM */
+
+/dts-v1/;
+
+#include am4372.dtsi
+#include dt-bindings/pinctrl/am43xx.h
+#include dt-bindings/pwm/pwm.h
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/input/input.h
+
+/ {
+   model = TI AM437x SK EVM;
+   compatible = ti,am437x-sk-evm,ti,am4372,ti,am43;
+
+   aliases {
+   display0 = lcd0;
+   };
+
+   vmmcsd_fixed: fixedregulator-sd {
+   compatible = regulator-fixed;
+   regulator-name = vmmcsd_fixed;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   enable-active-high;
+   };
+
+   v33_fixed: fixedregulator-v33 {
+   compatible = regulator-fixed;
+   regulator-name = v33_fixed;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   enable-active-high;
+   };
+
+   v18_fixed: fixedregulator-v18 {
+   compatible = regulator-fixed;
+   regulator-name = v18_fixed;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   enable-active-high;
+   };
+
+   backlight {
+   compatible = pwm-backlight;
+   pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
+   brightness-levels = 0 51 53 56 62 75 101 152 255;
+   default-brightness-level = 8;
+   };
+
+   sound {
+   compatible = ti,da830-evm-audio;
+   ti,model = AM437x-SK-EVM;
+   ti,audio-codec = tlv320aic3106;
+   ti,mcasp-controller = mcasp1;
+   ti,codec-clock-rate = 2400;
+   ti,audio-routing =
+   Headphone Jack,   HPLOUT,
+   Headphone Jack,   HPROUT;
+   };
+
+   matrix_keypad: matrix_keypad@0 {
+   compatible = gpio-matrix-keypad;
+
+   debounce-delay-ms = 5;
+   col-scan-delay-us = 1500;
+
+   row-gpios = gpio5 5 GPIO_ACTIVE_HIGH  /* Bank5, pin5 
*/
+   gpio5 6 GPIO_ACTIVE_HIGH; /* Bank5, pin6 
*/
+
+   col-gpios = gpio5 13 GPIO_ACTIVE_HIGH /* Bank5, pin13 
*/
+   gpio5 4 GPIO_ACTIVE_HIGH; /* Bank5, pin4 
*/
+
+   linux,keymap = 
+   MATRIX_KEY(0, 0, KEY_DOWN)
+   MATRIX_KEY(0, 1, KEY_RIGHT)
+   MATRIX_KEY(1, 0, KEY_LEFT)
+   MATRIX_KEY(1, 1, KEY_UP)
+   ;
+   };
+
+   leds {
+   compatible = gpio-leds;
+
+   led@0 {
+   label = am437x-sk:red:heartbeat;
+   gpios = gpio5 0 GPIO_ACTIVE_HIGH;/* Bank 5, 

[RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

From: Sathya Prakash M R sath...@ti.com

Add DSS hwmod data for AM43xx.

Cc: Andrew Morton a...@linux-foundation.org
Acked-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---

Note that this patch was originally send on May 9th [1], changes were requested
and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
maintainer again and go no response.

Without this patch, we cannot get display working on any AM437x devices.

[1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2
[2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2
[3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2

 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++
 arch/arm/mach-omap2/prcm43xx.h |  1 +
 2 files changed, 99 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c2cc80..d2a7b6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
 #include omap_hwmod.h
 #include omap_hwmod_33xx_43xx_common_data.h
 #include prcm43xx.h
+#include omap_hwmod_common_data.h
+
 
 /* IP blocks */
 static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
 };
 
+/* Display sub system - DSS */
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+   .manager_count  = 1,
+   .has_framedonetv_irq= 0
+};
+
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
+   .name   = dispc,
+   .sysc   = am43xx_dispc_sysc,
+};
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+   .name   = dss_core,
+   .class  = omap2_dss_hwmod_class,
+   .clkdm_name = dss_clkdm,
+   .main_clk   = disp_clk,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* display controller -dispc*/
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+   .name   = dss_dispc,
+   .class  = am43xx_dispc_hwmod_class,
+   .clkdm_name = dss_clkdm,
+   .main_clk   = disp_clk,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+   },
+   },
+   .dev_attr   = am43xx_dss_dispc_dev_attr,
+};
+
+/*RFBI*/
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+   .name   = dss_rfbi,
+   .class  = omap2_rfbi_hwmod_class,
+   .clkdm_name = dss_clkdm,
+   .main_clk   = disp_clk,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+   },
+   },
+};
+
 /* Interfaces */
 static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -654,6 +720,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+   .master = am43xx_dss_core_hwmod,
+   .slave  = am33xx_l3_main_hwmod,
+   .clk= l3_gclk,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+   .master = am33xx_l4_ls_hwmod,
+   .slave  = am43xx_dss_core_hwmod,
+   .clk= l4ls_gclk,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+   .master = am33xx_l4_ls_hwmod,
+   .slave  = am43xx_dss_dispc_hwmod,
+   .clk= l4ls_gclk,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+   .master = am33xx_l4_ls_hwmod,
+   .slave  = am43xx_dss_rfbi_hwmod,
+   .clk= l4ls_gclk,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -748,6 +842,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
__initdata = {
am43xx_l4_ls__ocp2scp1,
am43xx_l3_s__usbotgss0,
am43xx_l3_s__usbotgss1,
+   am43xx_dss__l3_main,

[PATCH 0/2] Add support for am437x StarterKit

[Felipe Balbi]

Hi,

The following two patches (one of which is a resend from a patch which has been
pending since May 19th!) enable AM437x StarterKit to boot in mainline.

Patches have been tested on top of 27a4e439fe5cd92b70137ae237c7aa6888c07b5a
(next-20140610). With these we even have X with I3 running on this board, with
audio, touchscreen, networking, blinky leds and others.

Felipe Balbi (1):
  arm: dts: add support for AM437x StarterKit

Sathya Prakash M R (1):
  ARM: AM43xx: hwmod: add DSS hwmod data

 .../devicetree/bindings/arm/omap/omap.txt  |   3 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/am437x-sk-evm.dts| 539 +
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c |  98 
 arch/arm/mach-omap2/prcm43xx.h |   1 +
 5 files changed, 642 insertions(+)
 create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts

-- 
2.0.0.rc1

--
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] Add support for am437x StarterKit

[Felipe Balbi]

Fixing Benoit's address

On Fri, Jun 13, 2014 at 11:15:45AM -0500, Felipe Balbi wrote:
 Hi,
 
 The following two patches (one of which is a resend from a patch which has 
 been
 pending since May 19th!) enable AM437x StarterKit to boot in mainline.
 
 Patches have been tested on top of 27a4e439fe5cd92b70137ae237c7aa6888c07b5a
 (next-20140610). With these we even have X with I3 running on this board, with
 audio, touchscreen, networking, blinky leds and others.
 
 Felipe Balbi (1):
   arm: dts: add support for AM437x StarterKit
 
 Sathya Prakash M R (1):
   ARM: AM43xx: hwmod: add DSS hwmod data
 
  .../devicetree/bindings/arm/omap/omap.txt  |   3 +
  arch/arm/boot/dts/Makefile |   1 +
  arch/arm/boot/dts/am437x-sk-evm.dts| 539 
 +
  arch/arm/mach-omap2/omap_hwmod_43xx_data.c |  98 
  arch/arm/mach-omap2/prcm43xx.h |   1 +
  5 files changed, 642 insertions(+)
  create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
 
 -- 
 2.0.0.rc1
 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
 Add support for TI's AM437x StarterKit Evaluation
 Module.
 
 Cc: Josh Elliot jelli...@ti.com
 Cc: Darren Etheridge detheri...@ti.com
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 Thanks to Josh and Darren for helping out with Audio and Display parts of this
 DTS.
 
  .../devicetree/bindings/arm/omap/omap.txt  |   3 +
  arch/arm/boot/dts/Makefile |   1 +
  arch/arm/boot/dts/am437x-sk-evm.dts| 539 
 +
  3 files changed, 543 insertions(+)
  create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
 
 diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
 b/Documentation/devicetree/bindings/arm/omap/omap.txt
 index d22b216..0edc903 100644
 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
 @@ -129,6 +129,9 @@ Boards:
  - AM437x GP EVM
compatible = ti,am437x-gp-evm, ti,am4372, ti,am43
  
 +- AM437x SK EVM: AM437x StarterKit Evaluation Module
 +  compatible = ti,am437x-sk-evm, ti,am4372, ti,am43
 +
  - DRA742 EVM:  Software Development Board for DRA742
compatible = ti,dra7-evm, ti,dra742, ti,dra74, ti,dra7
  
 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 0f1e8be..749cdc8 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
   omap4-var-dvk-om44.dtb \
   omap4-var-stk-om44.dtb
  dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
 + am437x-sk-evm.dtb \
   am437x-gp-evm.dtb
  dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
   omap5-sbc-t54.dtb \
 diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
 b/arch/arm/boot/dts/am437x-sk-evm.dts
 new file mode 100644
 index 000..51ffab1
 --- /dev/null
 +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
 @@ -0,0 +1,539 @@
 +/*
 + * Copyright (C) 2014 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.
 + */
 +
 +/* AM437x SK EVM */
 +
 +/dts-v1/;
 +
 +#include am4372.dtsi
 +#include dt-bindings/pinctrl/am43xx.h
 +#include dt-bindings/pwm/pwm.h
 +#include dt-bindings/gpio/gpio.h
 +#include dt-bindings/input/input.h
 +
 +/ {
 + model = TI AM437x SK EVM;
 + compatible = ti,am437x-sk-evm,ti,am4372,ti,am43;
 +
 + aliases {
 + display0 = lcd0;
 + };
 +
 + vmmcsd_fixed: fixedregulator-sd {
 + compatible = regulator-fixed;
 + regulator-name = vmmcsd_fixed;
 + regulator-min-microvolt = 330;
 + regulator-max-microvolt = 330;
 + enable-active-high;
 + };
 +
 + v33_fixed: fixedregulator-v33 {
 + compatible = regulator-fixed;
 + regulator-name = v33_fixed;
 + regulator-min-microvolt = 330;
 + regulator-max-microvolt = 330;
 + enable-active-high;
 + };
 +
 + v18_fixed: fixedregulator-v18 {
 + compatible = regulator-fixed;
 + regulator-name = v18_fixed;
 + regulator-min-microvolt = 180;
 + regulator-max-microvolt = 180;
 + enable-active-high;
 + };
 +
 + backlight {
 + compatible = pwm-backlight;
 + pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
 + brightness-levels = 0 51 53 56 62 75 101 152 255;
 + default-brightness-level = 8;
 + };
 +
 + sound {
 + compatible = ti,da830-evm-audio;
 + ti,model = AM437x-SK-EVM;
 + ti,audio-codec = tlv320aic3106;
 + ti,mcasp-controller = mcasp1;
 + ti,codec-clock-rate = 2400;
 + ti,audio-routing =
 + Headphone Jack,   HPLOUT,
 + Headphone Jack,   HPROUT;
 + };
 +
 + matrix_keypad: matrix_keypad@0 {
 + compatible = gpio-matrix-keypad;
 +
 + debounce-delay-ms = 5;
 + col-scan-delay-us = 1500;
 +
 + row-gpios = gpio5 5 GPIO_ACTIVE_HIGH  /* Bank5, pin5 
 */
 + gpio5 6 GPIO_ACTIVE_HIGH; /* Bank5, pin6 
 */
 +
 + col-gpios = gpio5 13 GPIO_ACTIVE_HIGH /* Bank5, pin13 
 */
 + gpio5 4 GPIO_ACTIVE_HIGH; /* Bank5, pin4 
 */
 +
 + linux,keymap = 
 + MATRIX_KEY(0, 0, KEY_DOWN)
 + MATRIX_KEY(0, 1, KEY_RIGHT)
 + MATRIX_KEY(1, 0, KEY_LEFT)
 + MATRIX_KEY(1, 1, KEY_UP)
 + ;
 + };
 +
 + leds {
 + compatible = gpio-leds;
 +
 + led@0 {
 + label = 

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote:
 From: Sathya Prakash M R sath...@ti.com
 
 Add DSS hwmod data for AM43xx.
 
 Cc: Andrew Morton a...@linux-foundation.org
 Acked-by: Rajendra Nayak rna...@ti.com
 Signed-off-by: Sathya Prakash M R sath...@ti.com
 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 Note that this patch was originally send on May 9th [1], changes were 
 requested
 and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
 maintainer again and go no response.
 
 Without this patch, we cannot get display working on any AM437x devices.
 
 [1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2
 [2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2
 [3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2
 
  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 
 ++
  arch/arm/mach-omap2/prcm43xx.h |  1 +
  2 files changed, 99 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 index 5c2cc80..d2a7b6d 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
 @@ -19,6 +19,8 @@
  #include omap_hwmod.h
  #include omap_hwmod_33xx_43xx_common_data.h
  #include prcm43xx.h
 +#include omap_hwmod_common_data.h
 +
  
  /* IP blocks */
  static struct omap_hwmod am43xx_l4_hs_hwmod = {
 @@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
   },
  };
  
 +/* Display sub system - DSS */
 +
 +struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
 + .manager_count  = 1,
 + .has_framedonetv_irq= 0
 +};
 +
 +
 +static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
 + .rev_offs   = 0x,
 + .sysc_offs  = 0x0010,
 + .syss_offs  = 0x0014,
 + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
 + .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
 + .sysc_fields= omap_hwmod_sysc_type1,
 +};
 +
 +static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
 + .name   = dispc,
 + .sysc   = am43xx_dispc_sysc,
 +};
 +
 +static struct omap_hwmod am43xx_dss_core_hwmod = {
 + .name   = dss_core,
 + .class  = omap2_dss_hwmod_class,
 + .clkdm_name = dss_clkdm,
 + .main_clk   = disp_clk,
 + .prcm = {
 + .omap4 = {
 + .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
 + .modulemode   = MODULEMODE_SWCTRL,
 + },
 + },
 +};
 +
 +/* display controller -dispc*/
 +
 +static struct omap_hwmod am43xx_dss_dispc_hwmod = {
 + .name   = dss_dispc,
 + .class  = am43xx_dispc_hwmod_class,
 + .clkdm_name = dss_clkdm,
 + .main_clk   = disp_clk,
 + .prcm = {
 + .omap4 = {
 + .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
 + },
 + },
 + .dev_attr   = am43xx_dss_dispc_dev_attr,
 +};
 +
 +/*RFBI*/
 +
 +static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
 + .name   = dss_rfbi,
 + .class  = omap2_rfbi_hwmod_class,
 + .clkdm_name = dss_clkdm,
 + .main_clk   = disp_clk,
 + .prcm = {
 + .omap4 = {
 + .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
 + },
 + },
 +};
 +
  /* Interfaces */
  static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
   .master = am33xx_l3_main_hwmod,
 @@ -654,6 +720,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
   .user   = OCP_USER_MPU | OCP_USER_SDMA,
  };
  
 +static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
 + .master = am43xx_dss_core_hwmod,
 + .slave  = am33xx_l3_main_hwmod,
 + .clk= l3_gclk,
 + .user   = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
 + .master = am33xx_l4_ls_hwmod,
 + .slave  = am43xx_dss_core_hwmod,
 + .clk= l4ls_gclk,
 + .user   = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
 + .master = am33xx_l4_ls_hwmod,
 + .slave  = am43xx_dss_dispc_hwmod,
 + .clk= l4ls_gclk,
 + .user   = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
 + .master = am33xx_l4_ls_hwmod,
 + .slave  = am43xx_dss_rfbi_hwmod,
 + .clk= l4ls_gclk,
 + .user   = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
  static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
   am33xx_l4_wkup__synctimer,
   am43xx_l4_ls__timer8,
 @@ -748,6 +842,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
 __initdata = {
   am43xx_l4_ls__ocp2scp1,
  

Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

Hi,

adding devicetree and some others

On Fri, Jun 13, 2014 at 11:23:34AM -0500, Felipe Balbi wrote:
 On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
  Add support for TI's AM437x StarterKit Evaluation
  Module.
  
  Cc: Josh Elliot jelli...@ti.com
  Cc: Darren Etheridge detheri...@ti.com
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
  
  Thanks to Josh and Darren for helping out with Audio and Display parts of 
  this
  DTS.
  
   .../devicetree/bindings/arm/omap/omap.txt  |   3 +
   arch/arm/boot/dts/Makefile |   1 +
   arch/arm/boot/dts/am437x-sk-evm.dts| 539 
  +
   3 files changed, 543 insertions(+)
   create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
  
  diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
  b/Documentation/devicetree/bindings/arm/omap/omap.txt
  index d22b216..0edc903 100644
  --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
  +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
  @@ -129,6 +129,9 @@ Boards:
   - AM437x GP EVM
 compatible = ti,am437x-gp-evm, ti,am4372, ti,am43
   
  +- AM437x SK EVM: AM437x StarterKit Evaluation Module
  +  compatible = ti,am437x-sk-evm, ti,am4372, ti,am43
  +
   - DRA742 EVM:  Software Development Board for DRA742
 compatible = ti,dra7-evm, ti,dra742, ti,dra74, ti,dra7
   
  diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
  index 0f1e8be..749cdc8 100644
  --- a/arch/arm/boot/dts/Makefile
  +++ b/arch/arm/boot/dts/Makefile
  @@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
  omap4-var-dvk-om44.dtb \
  omap4-var-stk-om44.dtb
   dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
  +   am437x-sk-evm.dtb \
  am437x-gp-evm.dtb
   dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
  omap5-sbc-t54.dtb \
  diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
  b/arch/arm/boot/dts/am437x-sk-evm.dts
  new file mode 100644
  index 000..51ffab1
  --- /dev/null
  +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
  @@ -0,0 +1,539 @@
  +/*
  + * Copyright (C) 2014 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.
  + */
  +
  +/* AM437x SK EVM */
  +
  +/dts-v1/;
  +
  +#include am4372.dtsi
  +#include dt-bindings/pinctrl/am43xx.h
  +#include dt-bindings/pwm/pwm.h
  +#include dt-bindings/gpio/gpio.h
  +#include dt-bindings/input/input.h
  +
  +/ {
  +   model = TI AM437x SK EVM;
  +   compatible = ti,am437x-sk-evm,ti,am4372,ti,am43;
  +
  +   aliases {
  +   display0 = lcd0;
  +   };
  +
  +   vmmcsd_fixed: fixedregulator-sd {
  +   compatible = regulator-fixed;
  +   regulator-name = vmmcsd_fixed;
  +   regulator-min-microvolt = 330;
  +   regulator-max-microvolt = 330;
  +   enable-active-high;
  +   };
  +
  +   v33_fixed: fixedregulator-v33 {
  +   compatible = regulator-fixed;
  +   regulator-name = v33_fixed;
  +   regulator-min-microvolt = 330;
  +   regulator-max-microvolt = 330;
  +   enable-active-high;
  +   };
  +
  +   v18_fixed: fixedregulator-v18 {
  +   compatible = regulator-fixed;
  +   regulator-name = v18_fixed;
  +   regulator-min-microvolt = 180;
  +   regulator-max-microvolt = 180;
  +   enable-active-high;
  +   };
  +
  +   backlight {
  +   compatible = pwm-backlight;
  +   pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
  +   brightness-levels = 0 51 53 56 62 75 101 152 255;
  +   default-brightness-level = 8;
  +   };
  +
  +   sound {
  +   compatible = ti,da830-evm-audio;
  +   ti,model = AM437x-SK-EVM;
  +   ti,audio-codec = tlv320aic3106;
  +   ti,mcasp-controller = mcasp1;
  +   ti,codec-clock-rate = 2400;
  +   ti,audio-routing =
  +   Headphone Jack,   HPLOUT,
  +   Headphone Jack,   HPROUT;
  +   };
  +
  +   matrix_keypad: matrix_keypad@0 {
  +   compatible = gpio-matrix-keypad;
  +
  +   debounce-delay-ms = 5;
  +   col-scan-delay-us = 1500;
  +
  +   row-gpios = gpio5 5 GPIO_ACTIVE_HIGH  /* Bank5, pin5 
  */
  +   gpio5 6 GPIO_ACTIVE_HIGH; /* Bank5, pin6 
  */
  +
  +   col-gpios = gpio5 13 GPIO_ACTIVE_HIGH /* Bank5, pin13 
  */
  +   gpio5 4 GPIO_ACTIVE_HIGH; /* Bank5, pin4 
  */
  +
  +   linux,keymap = 
  +   MATRIX_KEY(0, 0, KEY_DOWN)
  +   MATRIX_KEY(0, 1, KEY_RIGHT)
  +   MATRIX_KEY(1, 0, KEY_LEFT)
  +   MATRIX_KEY(1, 1, KEY_UP)
  +   ;
  +   };
  +
  

Re: [PATCH V2 00/19] irqchip: crossbar: driver fixes

[Jason Cooper]

On Fri, Jun 13, 2014 at 09:14:34AM -0700, Joe Perches wrote:
 On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
  Please format the subject lines like so:
  
irqchip: crossbar: Set cb pointer ...
   ^
   |
   \-- note the capitalization
 
 I suggest you don't make this a rule and focus
 on more important stuff instead.

It's not my rule.  ;-)

 Nobody is going to write tools that parse the
 changelogs by git log --format=%s for case
 sensitivity.
 
 As is, it's about half/half.
 
 $ git log --format=%s --no-merges drivers/irqchip/ | \
   grep ^irqchip: | cut -f3- -d:

Yeah, we haven't been perfect in the past, and a lot of stuff was merged
without going though tglx's tree.  That's why I was asked to help out.

Either I'm fixing up the subject line as I apply the patch, or, I kindly
ask the submitter to fix it up during a re-spin.

thx,

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

Re: [PATCH V2 00/19] irqchip: crossbar: driver fixes

[Joe Perches]

On Fri, 2014-06-13 at 12:37 -0400, Jason Cooper wrote:
 On Fri, Jun 13, 2014 at 09:14:34AM -0700, Joe Perches wrote:
  On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
   Please format the subject lines like so:
   
 irqchip: crossbar: Set cb pointer ...
^
|
\-- note the capitalization
  
  I suggest you don't make this a rule and focus
  on more important stuff instead.
 
 It's not my rule.  ;-)

Who's rule is it then?

Documentation/SubmittingPatches simply says:

The canonical patch subject line is:

Subject: [PATCH 001/123] subsystem: summary phrase

It doesn't say anything about capitalization.

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

Re: [PATCH V2 00/19] irqchip: crossbar: driver fixes

[Jason Cooper]

On Fri, Jun 13, 2014 at 09:48:24AM -0700, Joe Perches wrote:
 On Fri, 2014-06-13 at 12:37 -0400, Jason Cooper wrote:
  On Fri, Jun 13, 2014 at 09:14:34AM -0700, Joe Perches wrote:
   On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
Please format the subject lines like so:

  irqchip: crossbar: Set cb pointer ...
 ^
 |
 \-- note the capitalization
   
   I suggest you don't make this a rule and focus
   on more important stuff instead.
  
  It's not my rule.  ;-)
 
 Who's rule is it then?

Thomas'

thx,

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

Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods

[Paul Walmsley]

Hi Roger,

On Wed, 23 Apr 2014, Roger Quadros wrote:

 From: Nikhil Devshatwar nikhil...@ti.com
 
 Add hwmods for ocp2scp3 and sata modules.
 
 [Roger Q] Clean up.

Sorry for the delay on this.  Have been corresponding with TI to figure 
out what to do about these DRA7xx/AM43xx patches, since I don't have 
boards or public documentation for these devices, so it's impossible for 
me to meaningfully review the patches.  Looks like boards and/or public 
docs won't be coming any time soon.

So for my part, here's what I'll need to merge any hwmod patches that 
involve AM437x or DRA7xx:

1. A Reviewed-by: from one of the following folks (which should come from 
a different person than who is submitting the patches):

Roger Quadros
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren

2. A Tested-by: from one of the following folks (who can be the same as 
the person who is the same as the person who is submitting the patches):

Nishanth Menon
Rajendra Nayak
Kevin Hilman 
Tony Lindgren

Once these are in place, I'd be happy to queue it for 3.16.


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

Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss

[Paul Walmsley]

Hi Roger,

On Mon, 5 May 2014, Roger Quadros wrote:

 Add the sysconfig class bits for the Super Speed USB
 controllers
 
 CC: Paul Walmsley p...@pwsan.com
 Signed-off-by: Roger Quadros rog...@ti.com

As with the previous DRA7 hwmod patch, I'd like to get a Reviewed-by: and 
a Tested-by: before merging this one.


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

Re: [PATCH] ARM: DRA7: hwmod: add entry for RTCSS

[Paul Walmsley]

Hi Sekhar,

On Fri, 9 May 2014, Sekhar Nori wrote:

 From: Lokesh Vutla lokeshvu...@ti.com
 
 RTCSS on DRA7 provides a precise real-time clock.
 Add hwmod entry for this IP.
 
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 Signed-off-by: Sekhar Nori nsek...@ti.com

Sorry for the delay on this patch.  Have been corresponding with TI to 
figure out what to do about DRA7xx/AM43xx patches.  I don't have boards or 
public documentation for these devices, so it's impossible for me to 
meaningfully review the patches.  Looks like boards and/or public docs 
won't be coming any time soon.

So for my part, here's what I'll need to merge any hwmod patches that
involve AM437x or DRA7xx:

1. A Reviewed-by: from one of the following folks (which should come from
a different person than who is submitting the patches):

Roger Quadros
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren

2. A Tested-by: from one of the following folks (who can be the same as 
the person who is the same as the person who is submitting the patches):

Nishanth Menon
Rajendra Nayak
Kevin Hilman 
Tony Lindgren


Once these are in place, I'd be happy to queue it for 3.16.



- 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: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Paul Walmsley]

Hi Felipe, Tomi,

On Fri, 13 Jun 2014, Felipe Balbi wrote:

 On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote:
  From: Sathya Prakash M R sath...@ti.com
  
  Add DSS hwmod data for AM43xx.
  
  Cc: Andrew Morton a...@linux-foundation.org
  Acked-by: Rajendra Nayak rna...@ti.com
  Signed-off-by: Sathya Prakash M R sath...@ti.com
  Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
  
  Note that this patch was originally send on May 9th [1], changes were 
  requested
  and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
  maintainer again and go no response.
  
  Without this patch, we cannot get display working on any AM437x devices.
  
  [1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2
  [2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2
  [3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2
  
   arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 
  ++
   arch/arm/mach-omap2/prcm43xx.h |  1 +
   2 files changed, 99 insertions(+)

Sorry for the delay on this.  Have been corresponding with TI management 
to figure out what to do about patches for AM43xx.  I don't have boards or 
public documentation for these devices, so it's impossible for me to 
meaningfully review the patches.  Looks like boards and/or public docs 
won't be coming any time soon.

So for my part, here's what I'll need to merge any hwmod or PRCM patches 
that involve AM437x:

1. A Reviewed-by: from one of the following folks (which should come from
a different person than who is submitting the patches):

Roger Quadros
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren

2. A Tested-by: from one of the following folks (who can be the same as 
the person who is the same as the person who is submitting the patches):

Nishanth Menon
Rajendra Nayak
Kevin Hilman 
Tony Lindgren


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

Re: [PATCH] ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX

[Paul Walmsley]

On Mon, 9 Jun 2014, Dave Gerlach wrote:

 am43xx reset register layout is more similar to am33xx than omap4 so
 use the am33xx functions for hwmod hardreset soc_ops rather than the
 currently used omap4 functions. Without this, assert_hardreset and
 deassert_hardreset will not work on am43xx.
 
 Signed-off-by: Dave Gerlach d-gerl...@ti.com

Makes sense to me; queued for v3.16-rc.


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

Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag

[Paul Walmsley]

On Wed, 4 Jun 2014, Tomi Valkeinen wrote:

 On 03/06/14 22:35, Paul Walmsley wrote:
 
  What's really needed is better control over rounding in the clock code.  
 
 Well, if you ask me, what's really needed _now_ is to fix the bug that
 makes am3xxx (and am4xxx when it's merged) display not to work. I don't
 need a fix that solves all the clock set_rate/round issues once and for
 all, I just want to get the display working.

Yep, I understand; it's not a great situation.

  Both the driver API should be improved; and, to the extent that clock 
  sources share the same underlying code implementation, probably some clock 
  source configuration data enhancement is needed (DT or whatever).
  
  Furthermore, clk_set_rate() should never silently round a requested rate - 
  it should just return an error if it can't satisfy the requested rate 
  precisely.  Silently rounding a rate is racy, and, if we care about 
  drivers behaving consistently across different integration environments, 
  prone to behavior that the driver may not expect.
  
  Frankly, a DT ti,round-rate property is risible.  I certainly understand 
  why you don't like it and I don't know why that specific property was 
  proposed.  The issue has never been whether clk_round_rate() should round 
 
 I created the property for the v2 because (if I recall right) you were
 worried that fixing the rounding bug unconditionally could break some
 drivers, and suggested that it should be used only for DSS.

Here's the summary from my perspective: I don't want to merge a patch that 
results in a behavior change for all PLLs just to fix one user of one 
single PLL.  That's why I haven't merged your v1 patches.

So that's why I asked you for patches that limit the impact of the change 
to the PLL that you're trying to change.  You (graciously) respun those 
patches, but with a DT flag that doesn't really make sense, and those 
patches were NACK'ed by others.  So that's why the v2 patches haven't gone 
anywhere.

  But all this won't happen in -rc8; this is 3.16 material..
  
  
  We can always see how it goes and fix it up afterwards when everything 
  explodes.
  
  No thanks... that's what leads to these kinds of messes :-( 
 
 I don't understand how this fix would lead to a mess.
 
 1. AM3xxx/AM4xxx display is broken
 2. The PLL round function is broken, it doesn't round
 3. The fix to omap2_dpll_round_rate has been in TI's kernel for a long
 time, no problems observed
 4. We've ran test runs with linux-next + the fix, no problems observed

Whatever we do to the (common, not DSS-specific) clock code to fix this 
issue, it has to make sense independently of your specific DSS needs.  
This is why I asked you for a DSS-specific change, since it would 
effectively avoid this basic principle.  

Right now, in my view, it does not make sense to have a PLL clk_set_rate() 
function that unconditionally rounds to the closest rate for all users.  
As I've written before, callers could end up with a clock rate that is 
different than what's needed for a synchronous I/O user that expects an 
exact rate.  I am concerned about both rounding to a lower rate and 
rounding to a higher rate in this case, although the higher rate is 
marginally more of a concern to me since the resulting rate may be higher 
than the device is characterized for at a given voltage.

Furthermore, as a general interface principle, allowing clk_set_rate() to 
silently round rates could lead to unexpected behavior, since the set of 
rates that clk_set_rate() can round to may change between the call to 
clk_round_rate() and the call to clk_set_rate().

So again I think that the right way to deal with this is to:

1. avoid silently rounding rates in clk_set_rate() and to return an error 
if calling clk_set_rate() would result in a rate other than the one 
desired; and to

2. modify clk_round_rate() such that it returns the closest 
lowest-or-equal rate match to the target rate requested.


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

Re: [PATCH V2 00/19] irqchip: crossbar: driver fixes

[Thomas Gleixner]

On Fri, 13 Jun 2014, Jason Cooper wrote:
 On Fri, Jun 13, 2014 at 09:48:24AM -0700, Joe Perches wrote:
  On Fri, 2014-06-13 at 12:37 -0400, Jason Cooper wrote:
   On Fri, Jun 13, 2014 at 09:14:34AM -0700, Joe Perches wrote:
On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
 Please format the subject lines like so:
 
   irqchip: crossbar: Set cb pointer ...
  ^
  |
  \-- note the capitalization

I suggest you don't make this a rule and focus
on more important stuff instead.

Says the one, who pesters people about typos in changelogs

WTF? Jason is doing a great job in reviewing and he knows what to
concentrate on.

   It's not my rule.  ;-)
  
  Who's rule is it then?
 
 Thomas'

Sentences start with an upper case letter. Our brain is trained on
that rule when parsing a line.

So for people who actually review patches by reading them instead of
running a spell checker, consistent formatting more important than
avoiding the random typo, which our brain just blends out in most of
the cases. Unfortunately also when the typo is in actual code :(

Thanks,

tglx






   

   






--
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/14] arm-soc fixes for 3.16 review

[Jason Cooper]

On Fri, Jun 13, 2014 at 06:01:02PM +0200, Arnd Bergmann wrote:
 here are the fixes I've picked up so far as the last pull request
 for the merge window. I'm sure there will be a lot more in the
 future, but let us know if I missed something 

Please see my pull request that I replied to today.  It has two dts
fixes for NAND ECC handling.

thx,

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

Re: [PATCH V2 00/19] irqchip: crossbar: driver fixes

[Joe Perches]

On Fri, 2014-06-13 at 22:38 +0200, Thomas Gleixner wrote:
 On Fri, 13 Jun 2014, Jason Cooper wrote:
  On Fri, Jun 13, 2014 at 09:48:24AM -0700, Joe Perches wrote:
   On Fri, 2014-06-13 at 12:37 -0400, Jason Cooper wrote:
On Fri, Jun 13, 2014 at 09:14:34AM -0700, Joe Perches wrote:
 On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
  Please format the subject lines like so:
  
irqchip: crossbar: Set cb pointer ...
   ^
   |
   \-- note the capitalization
 
 I suggest you don't make this a rule and focus
 on more important stuff instead.

[elided the bit that describes what a patch subject looks like]

Documentation/SubmittingPatches simply says:

The canonical patch subject line is:

Subject: [PATCH 001/123] subsystem: summary phrase

It doesn't say anything about capitalization.

 Sentences start with an upper case letter. Our brain is trained on
 that rule when parsing a line.

shrug  I don't think patch subjects are sentences.
The docs call them phrases.

 So for people who actually review patches by reading them instead of
 running a spell checker, consistent formatting more important than
 avoiding the random typo, which our brain just blends out in most of
 the cases. Unfortunately also when the typo is in actual code :(

That part about the code is truth.

Anyway, how you spend your time is certainly up to you.
Do what makes you happy.

But if you want this specific form for your patches,
please just document it somewhere in the kernel tree.

I think that relatively commit log subjects are generally
easy to parse as-is and don't need more strictures.

I think it akin to british/american spelling uses and
I and i.  I just don't care which people use.

I did propose a mechanism to nudge people when proposed
patch subjects don't fit some specific maintainer's idea
of proper.

https://lkml.org/lkml/2010/11/16/245

cheers, Joe




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

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

Hi,

On Fri, Jun 13, 2014 at 07:11:58PM +, Paul Walmsley wrote:
   From: Sathya Prakash M R sath...@ti.com
   
   Add DSS hwmod data for AM43xx.
   
   Cc: Andrew Morton a...@linux-foundation.org
   Acked-by: Rajendra Nayak rna...@ti.com
   Signed-off-by: Sathya Prakash M R sath...@ti.com
   Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
   Signed-off-by: Felipe Balbi ba...@ti.com
   ---
   
   Note that this patch was originally send on May 9th [1], changes were 
   requested
   and a new version was sent on May 19th [2], then on May 27th [3] Tomi 
   pinged
   maintainer again and go no response.
   
   Without this patch, we cannot get display working on any AM437x devices.
   
   [1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2
   [2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2
   [3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2
   
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 
   ++
arch/arm/mach-omap2/prcm43xx.h |  1 +
2 files changed, 99 insertions(+)
 
 Sorry for the delay on this.  Have been corresponding with TI management 
 to figure out what to do about patches for AM43xx.  I don't have boards or 
 public documentation for these devices, so it's impossible for me to 
 meaningfully review the patches.  Looks like boards and/or public docs 
 won't be coming any time soon.
 
 So for my part, here's what I'll need to merge any hwmod or PRCM patches 
 that involve AM437x:
 
 1. A Reviewed-by: from one of the following folks (which should come from
 a different person than who is submitting the patches):
 
 Roger Quadros
 Nishanth Menon
 Rajendra Nayak
 Kevin Hilman
 Tony Lindgren
 
 2. A Tested-by: from one of the following folks (who can be the same as 
 the person who is the same as the person who is submitting the patches):
 
 Nishanth Menon
 Rajendra Nayak
 Kevin Hilman 
 Tony Lindgren

What you're saying here is that it's pointless for anybody else in TI to
review and/or test patches because you will only accept such tags from
this list of 4 ~ 5 people. It doesn't take a brain surgeon to note how
this won't scale and, if you continue to ignore patches during the
entire development cycle and only reply after it's too late for $this
merge window, it won't help much.

Quite frankly, it's very upsetting to see an affirmation that all the
work that I (personally) and many others do is seen as pointless from
your side *unless* it gets the blessing from the few folks listed above.

This just makes it ever more difficult for anything, which is clearly
*BROKEN* to be fixed upstream and will just contribute to people
vanishing from mainline development.

The very fact that you will only accept patches blessed by the gang-of-4
goes against the very foundations of open source development. Just
because you don't have access to documentation - and granted, that
_does_ make things a lot more difficult - does not mean you have to
consider an entire company as a non-trust worthy organization. Specially
when there are so many here who have been doing mainline development for
quite some time.

Anyway, whatever... I just hope that if we go through *another* merge
window without $subject being merged, someone takes the patch because
this already has a ridiculous amount of bureaucratic bariers to patches
which are, to put it very bluntly, *CORRECT*.

ps: $subject in particular, has been tested by 3 different people.
Actually 4, if you consider Darren Etheridge who used $subject to help
me get display working on AM437x SK.

pps: Darren, can you reply with your (according to Paul) pointless
Tested-by ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] input: touchscreen: ti_am335x_tsc: warn about incorrect spelling

[Felipe Balbi]

Hi,

Here's another patch which has been pending for months.

On Mon, Nov 18, 2013 at 09:29:01AM -0600, Felipe Balbi wrote:
 In the hopes that people run new kernels on
 their devices, let's add a warning message
 asking users to have their DTS file fixed.
 
 The goal is that by Linux 4.0 we will be
 able to remove support for the bogus version
 of our touchscreen's DTS.
 
 Suggested-by: Mark Rutland mark.rutl...@arm.com
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 Here you go, I've added your Suggested-by Mark,
 if you wish I can remove or change to something
 else.
 
 cheers
 
  drivers/input/touchscreen/ti_am335x_tsc.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
 b/drivers/input/touchscreen/ti_am335x_tsc.c
 index b61df9d..91302cd 100644
 --- a/drivers/input/touchscreen/ti_am335x_tsc.c
 +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
 @@ -354,9 +354,12 @@ static int titsc_parse_dt(struct platform_device *pdev,
*/
   err = of_property_read_u32(node, ti,coordinate-readouts,
   ts_dev-coordinate_readouts);
 - if (err  0)
 + if (err  0) {
 + dev_warn(pdev-dev, please use 'ti,coordinate-readouts' 
 instead\n);
   err = of_property_read_u32(node, ti,coordiante-readouts,
   ts_dev-coordinate_readouts);
 + }
 +
   if (err  0)
   return err;
  
 -- 
 1.8.4.GIT
 

-- 
balbi


signature.asc
Description: Digital signature

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Paul Walmsley]

Hi

On Fri, 13 Jun 2014, Felipe Balbi wrote:

 On Fri, Jun 13, 2014 at 07:11:58PM +, Paul Walmsley wrote:
From: Sathya Prakash M R sath...@ti.com

Add DSS hwmod data for AM43xx.

Cc: Andrew Morton a...@linux-foundation.org
Acked-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---

Note that this patch was originally send on May 9th [1], changes were 
requested
and a new version was sent on May 19th [2], then on May 27th [3] Tomi 
pinged
maintainer again and go no response.

Without this patch, we cannot get display working on any AM437x devices.

[1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2
[2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2
[3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2

 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 
++
 arch/arm/mach-omap2/prcm43xx.h |  1 +
 2 files changed, 99 insertions(+)
  
  Sorry for the delay on this.  Have been corresponding with TI management 
  to figure out what to do about patches for AM43xx.  I don't have boards or 
  public documentation for these devices, so it's impossible for me to 
  meaningfully review the patches.  Looks like boards and/or public docs 
  won't be coming any time soon.
  
  So for my part, here's what I'll need to merge any hwmod or PRCM patches 
  that involve AM437x:
  
  1. A Reviewed-by: from one of the following folks (which should come from
  a different person than who is submitting the patches):
  
  Roger Quadros
  Nishanth Menon
  Rajendra Nayak
  Kevin Hilman
  Tony Lindgren
  
  2. A Tested-by: from one of the following folks (who can be the same as 
  the person who is the same as the person who is submitting the patches):
  
  Nishanth Menon
  Rajendra Nayak
  Kevin Hilman 
  Tony Lindgren
 
 What you're saying here is that it's pointless for anybody else in TI to
 review and/or test patches because you will only accept such tags from
 this list of 4 ~ 5 people.

That might be how you interpreted the E-mail.  But that's not what was 
written.

For the record, I'm pleased to accept Reviewed-by:s and Tested-by:s from 
anyone.  But, like most maintainers, there are some folks who I think do a 
better job of reviewing and testing hwmod and PRCM patches than others.

The people listed above are a first cut at that list.  I'm certainly happy 
to consider adding others, but the reviewers need:

1. to have experience with those parts of the kernel;

2. to have access to the canonical documentation for AM43xx to review 
against; and

3. to have some kind of track record doing in-depth reviews of patches for 
that subsystem, or writing clean code for that subsystem.


Similarly, for testers, the folks listed above are people who:

1. could actually have AM43xx boards; and

2. who have a history of testing patches against mainline kernels in 
public forums, rather than testing against vendor kernels; and

3. who I think would be mortally embarrassed if a patch was broken 
that they had a Tested-by: for.

(N.B. In the case of anything involving DSS, such as this patch, I'd be 
happy to accept Tested-by:s from Archit or Tomi.)

If you have other people that you think I'm missing from the above two 
lists, who meet those requirements, please suggest some names!

 Quite frankly, it's very upsetting to see an affirmation that all the
 work that I (personally) and many others do is seen as pointless from
 your side *unless* it gets the blessing from the few folks listed above.

I'd be curious to know how many of the people listed in the Signed-off-by: 
for these patches have double-checked the data against the TRM (or 
whatever documentation is canonical for this chip).  And have thought 
through whether the data actually makes sense with regards to the SoC 
integration.  I consider those to be the prerequisites for reviewing hwmod 
device data patches.  That's what I generally do myself, and that's what I 
expect from trusted reviewers.

 This just makes it ever more difficult for anything, which is clearly
 *BROKEN* to be fixed upstream and will just contribute to people
 vanishing from mainline development.

Sounds like you might be mixing mailing list threads.  

The description for these patches states:

Add DSS hwmod data for AM43xx

Unless I'm missing something, these patches add a feature.  They are not 
fixing something that is broken.

 The very fact that you will only accept patches blessed by the gang-of-4
 goes against the very foundations of open source development. Just
 because you don't have access to documentation - and granted, that
 _does_ make things a lot more difficult - does not mean you have to
 consider an entire company as a non-trust worthy organization. Specially
 when there are so many here 

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

[Felipe Balbi]

Hi,

On Sat, Jun 14, 2014 at 02:57:32AM +, Paul Walmsley wrote:
 From: Sathya Prakash M R sath...@ti.com
 
 Add DSS hwmod data for AM43xx.
 
 Cc: Andrew Morton a...@linux-foundation.org
 Acked-by: Rajendra Nayak rna...@ti.com
 Signed-off-by: Sathya Prakash M R sath...@ti.com
 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 Note that this patch was originally send on May 9th [1], changes were 
 requested
 and a new version was sent on May 19th [2], then on May 27th [3] Tomi 
 pinged
 maintainer again and go no response.
 
 Without this patch, we cannot get display working on any AM437x 
 devices.
 
 [1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2
 [2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2
 [3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2
 
  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 
 ++
  arch/arm/mach-omap2/prcm43xx.h |  1 +
  2 files changed, 99 insertions(+)
   
   Sorry for the delay on this.  Have been corresponding with TI management 
   to figure out what to do about patches for AM43xx.  I don't have boards 
   or 
   public documentation for these devices, so it's impossible for me to 
   meaningfully review the patches.  Looks like boards and/or public docs 
   won't be coming any time soon.
   
   So for my part, here's what I'll need to merge any hwmod or PRCM patches 
   that involve AM437x:
   
   1. A Reviewed-by: from one of the following folks (which should come from
   a different person than who is submitting the patches):
   
   Roger Quadros
   Nishanth Menon
   Rajendra Nayak
   Kevin Hilman
   Tony Lindgren
   
   2. A Tested-by: from one of the following folks (who can be the same as 
   the person who is the same as the person who is submitting the patches):
   
   Nishanth Menon
   Rajendra Nayak
   Kevin Hilman 
   Tony Lindgren
  
  What you're saying here is that it's pointless for anybody else in TI to
  review and/or test patches because you will only accept such tags from
  this list of 4 ~ 5 people.
 
 That might be how you interpreted the E-mail.  But that's not what was 
 written.

of course it was. Read what you wrote:

here's what I'll need to *merge* any hwmod or PRCM patches that involve
AM437x.

That basically puts down the requirements to getting any patches
accepted and those requirements are the blessings of a handful.

 For the record, I'm pleased to accept Reviewed-by:s and Tested-by:s from 
 anyone.  But, like most maintainers, there are some folks who I think do a 
 better job of reviewing and testing hwmod and PRCM patches than others.
 
 The people listed above are a first cut at that list.  I'm certainly
 happy to consider adding others, but the reviewers need:
 
 1. to have experience with those parts of the kernel;
 
 2. to have access to the canonical documentation for AM43xx to review
 against; and

anybody in ti.com have access to those.

 3. to have some kind of track record doing in-depth reviews of patches
 for that subsystem, or writing clean code for that subsystem.
 
 
 Similarly, for testers, the folks listed above are people who:
 
 1. could actually have AM43xx boards; and

well, quite a few have rather easy access to multiple (3, to be exact)
different am437x platforms.

 2. who have a history of testing patches against mainline kernels in 
 public forums, rather than testing against vendor kernels; and

$subject and patch two have both been tested on top of linux next from
june 10th. Is that bleeding edge enough for you ? Moreover, *only* these
two patches were applied on top of Stephen's linux-next.

 3. who I think would be mortally embarrassed if a patch was broken 
 that they had a Tested-by: for.

right, and when those guys try to get bugs fixed, we spend half a year
discussing pointless might-happen-when-the-sun-dies problems with other
drivers even when... h what the heck, you'll just say I'm mixing
threads again...

The point is that it has been this back and forth for quite a while now,
in countless occasions we have missed merge windows because this or that
maintainer just stops responding and *nobody* else has balls to pick the
patch up.

Weeks later social network posts start to arise blaming TI for not
sending patches upstream.

 (N.B. In the case of anything involving DSS, such as this patch, I'd be 
 happy to accept Tested-by:s from Archit or Tomi.)
 
 If you have other people that you think I'm missing from the above two 
 lists, who meet those requirements, please suggest some names!

the point is about not having a list. Sure, you need to know some folks
who you can trust, but sometimes, when it's clear that the patch doesn't
break anything, follows standard code practices, have passed through
more than one hand and soaked in the mailing list for months, it's time