Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Pali Rohár]

On Wednesday 06 January 2016 10:55:51 Ivaylo Dimitrov wrote:
> 
> 
> On  6.01.2016 00:49, Tony Lindgren wrote:
> >
> >Suggested fix below, please test and reply with your Tested-by's if
> >it solves the problem so we may still be able to get this into v4.4.
> >
> >Regards,
> >
> >Tony
> >
> >8< ---
> >From: Tony Lindgren 
> >Date: Tue, 5 Jan 2016 12:04:20 -0800
> >Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
> >  corruption
> >
> >Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> >unified the GPMC debug for the SoCs with GPMC. The commit also left
> >out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> >for GPMC to be able to remap GPMC devices out of address 0.
> >
> >Unfortunately on 900, onenand now only partially works with the device
> >tree provided timings. It works enough to get detected but the clock
> >rate supported by the onenand chip gets misdetected. This in turn causes
> >the GPMC timings to be miscalculated and this leads into file system
> >corruption on n900.
> >
> >Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> >write. This is needed also for async timings when we write to onenand
> >with omap2_onenand_set_async_mode(). Without sync write bit set, the
> >async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> >
> >Let's exit with an error if onenand rate is not detected. And let's
> >remove the extra call to omap2_onenand_set_async_mode() as we only
> >need to do this once at the end of omap2_onenand_setup_async().
> >
> >Reported-by: Ivaylo Dimitrov 
> >Signed-off-by: Tony Lindgren 
> >
> >--- a/arch/arm/mach-omap2/gpmc-onenand.c
> >+++ b/arch/arm/mach-omap2/gpmc-onenand.c
> 
> Bellow is gpmc dmesg output with that fix. I also disabled
> CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no obvious
> problems.
> 
> So, seems that fixes the problem, feel free to  add:
> 
> Tested-by: Ivaylo Dimitrov 

Great! Thank you for fixing and testing this problem!

> 
> Jan  6 10:34:15 Nokia-N900 kernel: [1.373229] omap-gpmc 6e00.gpmc:
> GPMC revision 5.0
> Jan  6 10:34:15 Nokia-N900 kernel: [1.379425] GPMC CS0: cs_on  :   0
> ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.387481] GPMC CS0: cs_rd_off  :
> 14 ticks,  84 ns (was  16 ticks)  84 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.395507] GPMC CS0: cs_wr_off  :
> 19 ticks, 114 ns (was  16 ticks) 114 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.403472] GPMC CS0: adv_on  :
> 0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.411407] GPMC CS0: adv_rd_off
> :   3 ticks,  18 ns (was   2 ticks)  18 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.419342] GPMC CS0: adv_wr_off
> :   3 ticks,  18 ns (was   2 ticks)  18 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.427276] GPMC CS0: oe_on  :   5
> ticks,  30 ns (was   2 ticks)  30 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.435211] GPMC CS0: oe_off  :
> 14 ticks,  84 ns (was  16 ticks)  84 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.443115] GPMC CS0: we_on  :   0
> ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.451110] GPMC CS0: we_off  :
> 14 ticks,  84 ns (was  16 ticks)  84 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.459045] GPMC CS0: rd_cycle  :
> 18 ticks, 108 ns (was  19 ticks) 108 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.467041] GPMC CS0: wr_cycle  :
> 17 ticks, 102 ns (was  19 ticks) 102 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.474975] GPMC CS0: access  :
> 13 ticks,  78 ns (was  15 ticks)  78 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.482879] GPMC CS0:
> page_burst_access:   0 ticks,   0 ns (was   2 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.490814] GPMC CS0: bus_turnaround
> :   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.498748] GPMC CS0:
> cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.506683] GPMC CS0: wr_data_mux_bus
> :   5 ticks,  30 ns (was   5 ticks)  30 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.514617] GPMC CS0: wr_access  :
> 13 ticks,  78 ns (was  15 ticks)  78 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.522583] GPMC CS0: wait_monitoring
> :   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.530548] GPMC CS0: clk_activation
> :   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.538543] GPMC CS0 CLK period is 6
> ns (div 1)
> Jan  6 10:34:15 Nokia-N900 kernel: [1.543334] gpmc cs0 after
> gpmc_cs_set_timings:
> Jan  6 10:34:15 Nokia-N900 kernel: [1.548126] cs0 GPMC_CS_CONFIG1:
> 0xd9001200
> Jan  6 10:34:15 Nokia-N900 kernel: [1.552581] cs0 GPMC_CS_CONFIG2:
> 0x00130e00
> 

[PATCH 0/2] DRA72/DRA74: Add 2 lane support

[Kishon Vijay Abraham I]

Add driver modifications in pci-dra7xx to get x2 mode working in
DRA72 and DRA74. Certain modifications is needed in PHY driver also
which will be sent as a separate series.

Certain board modifications has to be done in order to test
x2 mode in dra72-evm.

These patches were created on pci next.

Changes from RFC:
*) .b1co_mode_sel_mask is now set with the correct value.
*) cleanup the patch

Kishon Vijay Abraham I (2):
  pci: host: pci-dra7xx: use "num-lanes" property to find phy count
  pci: host: pci-dra7xx: Enable x2 mode support

 Documentation/devicetree/bindings/pci/ti-pci.txt |8 +-
 drivers/pci/host/pci-dra7xx.c|  104 +++---
 2 files changed, 97 insertions(+), 15 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] phy: ti-pipe3: get tx and rx MEM resource

[Kishon Vijay Abraham I]

get tx and rx MEM resource since this has to be used to configure
for DRA72x to work in X2 mode.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/phy/phy-ti-pipe3.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0a477d2..7d83d2b 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -91,6 +91,8 @@ struct pipe3_dpll_map {
 
 struct ti_pipe3 {
void __iomem*pll_ctrl_base;
+   void __iomem*phy_rx;
+   void __iomem*phy_tx;
struct device   *dev;
struct device   *control_dev;
struct clk  *wkupclk;
@@ -536,6 +538,27 @@ static int ti_pipe3_get_pll_base(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_rx_tx_base(struct ti_pipe3 *phy)
+{
+   struct resource *res;
+   struct device *dev = phy->dev;
+   struct platform_device *pdev = to_platform_device(dev);
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "phy_rx");
+   phy->phy_rx = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(phy->phy_rx))
+   return PTR_ERR(phy->phy_rx);
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "phy_tx");
+   phy->phy_tx = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(phy->phy_tx))
+   return PTR_ERR(phy->phy_tx);
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
@@ -555,6 +578,10 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = ti_pipe3_get_rx_tx_base(phy);
+   if (ret)
+   return ret;
+
ret = ti_pipe3_get_sysctrl(phy);
if (ret)
return ret;
-- 
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 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

On  6.01.2016 00:49, Tony Lindgren wrote:


Suggested fix below, please test and reply with your Tested-by's if
it solves the problem so we may still be able to get this into v4.4.

Regards,

Tony

8< ---
From: Tony Lindgren 
Date: Tue, 5 Jan 2016 12:04:20 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
  corruption

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device
tree provided timings. It works enough to get detected but the clock
rate supported by the onenand chip gets misdetected. This in turn causes
the GPMC timings to be miscalculated and this leads into file system
corruption on n900.

Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
write. This is needed also for async timings when we write to onenand
with omap2_onenand_set_async_mode(). Without sync write bit set, the
async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.

Let's exit with an error if onenand rate is not detected. And let's
remove the extra call to omap2_onenand_set_async_mode() as we only
need to do this once at the end of omap2_onenand_setup_async().

Reported-by: Ivaylo Dimitrov 
Signed-off-by: Tony Lindgren 

--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c


Bellow is gpmc dmesg output with that fix. I also disabled 
CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no 
obvious problems.


So, seems that fixes the problem, feel free to  add:

Tested-by: Ivaylo Dimitrov 


Jan  6 10:34:15 Nokia-N900 kernel: [1.373229] omap-gpmc 
6e00.gpmc: GPMC revision 5.0
Jan  6 10:34:15 Nokia-N900 kernel: [1.379425] GPMC CS0: cs_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.387481] GPMC CS0: cs_rd_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.395507] GPMC CS0: cs_wr_off 
 :  19 ticks, 114 ns (was  16 ticks) 114 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.403472] GPMC CS0: adv_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.411407] GPMC CS0: adv_rd_off 
 :   3 ticks,  18 ns (was   2 ticks)  18 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.419342] GPMC CS0: adv_wr_off 
 :   3 ticks,  18 ns (was   2 ticks)  18 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.427276] GPMC CS0: oe_on 
 :   5 ticks,  30 ns (was   2 ticks)  30 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.435211] GPMC CS0: oe_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.443115] GPMC CS0: we_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.451110] GPMC CS0: we_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.459045] GPMC CS0: rd_cycle 
 :  18 ticks, 108 ns (was  19 ticks) 108 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.467041] GPMC CS0: wr_cycle 
 :  17 ticks, 102 ns (was  19 ticks) 102 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.474975] GPMC CS0: access 
 :  13 ticks,  78 ns (was  15 ticks)  78 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.482879] GPMC CS0: 
page_burst_access:   0 ticks,   0 ns (was   2 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.490814] GPMC CS0: 
bus_turnaround   :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.498748] GPMC CS0: 
cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.506683] GPMC CS0: 
wr_data_mux_bus  :   5 ticks,  30 ns (was   5 ticks)  30 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.514617] GPMC CS0: wr_access 
 :  13 ticks,  78 ns (was  15 ticks)  78 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.522583] GPMC CS0: 
wait_monitoring  :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.530548] GPMC CS0: 
clk_activation   :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.538543] GPMC CS0 CLK period is 
6 ns (div 1)
Jan  6 10:34:15 Nokia-N900 kernel: [1.543334] gpmc cs0 after 
gpmc_cs_set_timings:
Jan  6 10:34:15 Nokia-N900 kernel: [1.548126] cs0 GPMC_CS_CONFIG1: 
0xd9001200
Jan  6 10:34:15 Nokia-N900 kernel: [1.552581] cs0 GPMC_CS_CONFIG2: 
0x00130e00
Jan  6 10:34:15 Nokia-N900 kernel: [1.558837] cs0 GPMC_CS_CONFIG3: 
0x00030300
Jan  6 10:34:15 Nokia-N900 kernel: [1.563323] cs0 GPMC_CS_CONFIG4: 
0x0e000e05
Jan  6 10:34:15 Nokia-N900 kernel: [1.567901] cs0 GPMC_CS_CONFIG5: 
0x000d1112
Jan  6 10:34:15 Nokia-N900 kernel: [1.572357] cs0 

[PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

[Kishon Vijay Abraham I]

Perform syscon configurations to get x2 mode to working in DRA74x and
DRA72x. Also add a new compatible string to dfferentiate
DRA72x and DRA74x, since b1c0 mask is different for both these platforms.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
 drivers/pci/host/pci-dra7xx.c|   81 +-
 2 files changed, 86 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e2516..0b10e84 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,7 +1,9 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
+ - compatible: "ti,dra7-pcie" is deprecated
+  Should be "ti,dra746-pcie" for DRA74x
+  Should be "ti,dra726-pcie" for DRA72x
  - reg : Two register ranges as listed in the reg-names property
  - reg-names : The first entry must be "ti-conf" for the TI specific registers
   The second entry must be "rc-dbics" for the designware pcie
@@ -14,6 +16,10 @@ PCIe Designware Controller
   where  is the instance number of the pcie from the HW spec.
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
+ - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
module and the
+   register offset to specify 1 lane or 2 lane.
+ - syscon-lane-sel : phandle/offset pair. Phandle to the system control module 
and the
+   register offset to specify lane selection.
  - #address-cells,
#size-cells,
#interrupt-cells,
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 05bbeee..dac216f 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -22,9 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include 
 
@@ -67,14 +69,22 @@
 #defineLINK_UP BIT(16)
 #defineDRA7XX_CPU_TO_BUS_ADDR  0x0FFF
 
+#define PCIE_1LANE_2LANE_SELECTION BIT(13)
+#define PCIE_B1C0_MODE_SEL BIT(2)
+
 struct dra7xx_pcie {
void __iomem*base;
+   u32 *b1c0_mask;
struct phy  **phy;
int lanes;
struct device   *dev;
struct pcie_portpp;
 };
 
+struct dra7xx_pcie_data {
+   u32 b1co_mode_sel_mask;
+};
+
 #define to_dra7xx_pcie(x)  container_of((x), struct dra7xx_pcie, pp)
 
 static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
@@ -358,6 +368,57 @@ static int dra7xx_pcie_reset(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id of_dra7xx_pcie_match[];
+
+static int dra7xx_pcie_configure_two_lane(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct regmap *pcie_syscon;
+   unsigned int pcie_reg;
+   struct dra7xx_pcie_data *data;
+   const struct of_device_id *match;
+
+   match = of_match_device(of_dra7xx_pcie_match, dev);
+   if (!match)
+   return -EINVAL;
+
+   data = (struct dra7xx_pcie_data *)match->data;
+   if (!data) {
+   dev_err(dev, "no b1c0 mask data\n");
+   return -EINVAL;
+   }
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-conf");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-conf\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-conf", 1, _reg)) {
+   dev_err(dev, "couldn't get lane configuration reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, PCIE_1LANE_2LANE_SELECTION,
+  PCIE_1LANE_2LANE_SELECTION);
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-sel");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-sel\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-sel", 1, _reg)) {
+   dev_err(dev, "couldn't get lane selection reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, data->b1co_mode_sel_mask,
+  PCIE_B1C0_MODE_SEL);
+
+   return 0;
+}
+
 static int __init dra7xx_pcie_probe(struct platform_device *pdev)
 {
u32 reg;
@@ -428,6 +489,12 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
}
}
 
+   if (lanes == 2) {
+   ret = 

[PATCH 1/2] pci: host: pci-dra7xx: use "num-lanes" property to find phy count

[Kishon Vijay Abraham I]

use "num-lanes" property to find phy count instead of the number
phy-names property.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/pci/host/pci-dra7xx.c |   23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 5963adc..05bbeee 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -70,7 +70,7 @@
 struct dra7xx_pcie {
void __iomem*base;
struct phy  **phy;
-   int phy_count;
+   int lanes;
struct device   *dev;
struct pcie_portpp;
 };
@@ -364,7 +364,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
int ret;
int irq;
int i;
-   int phy_count;
+   u32 lanes;
struct phy **phy;
void __iomem *base;
struct resource *res;
@@ -402,17 +402,16 @@ static int __init dra7xx_pcie_probe(struct 
platform_device *pdev)
if (!base)
return -ENOMEM;
 
-   phy_count = of_property_count_strings(np, "phy-names");
-   if (phy_count < 0) {
-   dev_err(dev, "unable to find the strings\n");
-   return phy_count;
+   if (of_property_read_u32(np, "num-lanes", )) {
+   dev_err(dev, "Failed to parse the number of lanes\n");
+   return -EINVAL;
}
 
-   phy = devm_kzalloc(dev, sizeof(*phy) * phy_count, GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy) * lanes, GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   for (i = 0; i < phy_count; i++) {
+   for (i = 0; i < lanes; i++) {
snprintf(name, sizeof(name), "pcie-phy%d", i);
phy[i] = devm_phy_get(dev, name);
if (IS_ERR(phy[i]))
@@ -432,7 +431,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
dra7xx->base = base;
dra7xx->phy = phy;
dra7xx->dev = dev;
-   dra7xx->phy_count = phy_count;
+   dra7xx->lanes = lanes;
 
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
@@ -489,7 +488,7 @@ static int __exit dra7xx_pcie_remove(struct platform_device 
*pdev)
struct dra7xx_pcie *dra7xx = platform_get_drvdata(pdev);
struct pcie_port *pp = >pp;
struct device *dev = >dev;
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
if (pp->irq_domain)
irq_domain_remove(pp->irq_domain);
@@ -535,7 +534,7 @@ static int dra7xx_pcie_resume(struct device *dev)
 static int dra7xx_pcie_suspend_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
while (count--) {
phy_power_off(dra7xx->phy[count]);
@@ -548,7 +547,7 @@ static int dra7xx_pcie_suspend_noirq(struct device *dev)
 static int dra7xx_pcie_resume_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int phy_count = dra7xx->phy_count;
+   int phy_count = dra7xx->lanes;
int ret;
int i;
 
-- 
1.7.9.5

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

[PATCH 0/2] dra72: add support for PCIE 2 lane mode

[Kishon Vijay Abraham I]

dra72 reuse the USB PHY for the PCIe 2n lane. So in order for PCIe x2 mode
to work in dra72, certain special configuration has to be made in
USB PHY. This patch series adds those configurations.

In order to enable PCIe x2 mode in DRA72, USB should be disabled.

Certain board modifications has to be done in order to test
x2 mode in dra72-evm.

Patch series is rebased on top of linux-phy next

Kishon Vijay Abraham I (2):
  phy: ti-pipe3: get tx and rx MEM resource
  phy: ti-pipe3: configure usb3 phy to be used as pcie phy

 Documentation/devicetree/bindings/phy/ti-phy.txt |2 +
 drivers/phy/phy-ti-pipe3.c   |   57 +-
 2 files changed, 58 insertions(+), 1 deletion(-)

-- 
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] phy: ti-pipe3: configure usb3 phy to be used as pcie phy

[Kishon Vijay Abraham I]

DRA72 uses USB3 PHY for the 2nd lane of PCIE. The configuration
required to make USB3 PHY used for the 2nd lane of PCIe is done
here.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
 drivers/phy/phy-ti-pipe3.c   |   30 +-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index a3b3945..6a7de94 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -91,6 +91,8 @@ Optional properties:
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
  - syscon-pcs : phandle/offset pair. Phandle to the system control module and 
the
register offset to write the PCS delay value.
+ - "ti,configure-as-pcie" : property to indicate if the PHY should be
+   configured as PCIE PHY.
 
 Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 7d83d2b..793185e 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -56,6 +56,12 @@
 
 #define SATA_PLL_SOFT_RESETBIT(18)
 
+#define PHY_RX_ANA_PRGRAMMABILITY_REG  0xC
+#define MEM_EN_PLLBYP  BIT(7)
+
+#define PHY_TX_TEST_CONFIG 0x2C
+#define MEM_ENTESTCLK  BIT(31)
+
 #define PIPE3_PHY_PWRCTL_CLK_CMD_MASK  0x003FC000
 #define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
 
@@ -68,6 +74,10 @@
 #define PCIE_PCS_MASK  0xFF
 #define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
 
+#define PIPE3_PHY_DISABLE_SYNC_POWER   BIT(4)
+
+#define CONFIGURE_AS_PCIE  BIT(0)
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -90,6 +100,7 @@ struct pipe3_dpll_map {
 };
 
 struct ti_pipe3 {
+   u32 flags;
void __iomem*pll_ctrl_base;
void __iomem*phy_rx;
void __iomem*phy_tx;
@@ -270,6 +281,19 @@ static int ti_pipe3_init(struct phy *x)
int ret = 0;
 
ti_pipe3_enable_clocks(phy);
+
+   if (phy->flags & CONFIGURE_AS_PCIE) {
+   val = ti_pipe3_readl(phy->phy_rx,
+PHY_RX_ANA_PRGRAMMABILITY_REG);
+   val |= MEM_EN_PLLBYP;
+   ti_pipe3_writel(phy->phy_rx, PHY_RX_ANA_PRGRAMMABILITY_REG,
+   val);
+   val = ti_pipe3_readl(phy->phy_tx, PHY_TX_TEST_CONFIG);
+   val |= MEM_ENTESTCLK;
+   ti_pipe3_writel(phy->phy_tx, PHY_TX_TEST_CONFIG, val);
+   return 0;
+   }
+
/*
 * Set pcie_pcs register to 0x96 for proper functioning of phy
 * as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
@@ -318,7 +342,8 @@ static int ti_pipe3_exit(struct phy *x)
return 0;
 
/* PCIe doesn't have internal DPLL */
-   if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
+   if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie") &&
+   !(phy->flags & CONFIGURE_AS_PCIE)) {
/* Put DPLL in IDLE mode */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
val |= PLL_IDLE;
@@ -590,6 +615,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   if (of_property_read_bool(node, "ti,configure-as-pcie"))
+   phy->flags |= CONFIGURE_AS_PCIE;
+
platform_set_drvdata(pdev, phy);
pm_runtime_enable(dev);
 
-- 
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 2/2] pci: host: pci-dra7xx: Enable x2 mode support

[Rob Herring]

On Wed, Jan 06, 2016 at 04:19:53PM +0530, Kishon Vijay Abraham I wrote:
> Perform syscon configurations to get x2 mode to working in DRA74x and
> DRA72x. Also add a new compatible string to dfferentiate
> DRA72x and DRA74x, since b1c0 mask is different for both these platforms.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
>  drivers/pci/host/pci-dra7xx.c|   81 
> +-
>  2 files changed, 86 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
> b/Documentation/devicetree/bindings/pci/ti-pci.txt
> index 60e2516..0b10e84 100644
> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> @@ -1,7 +1,9 @@
>  TI PCI Controllers
>  
>  PCIe Designware Controller
> - - compatible: Should be "ti,dra7-pcie""
> + - compatible: "ti,dra7-pcie" is deprecated
> +Should be "ti,dra746-pcie" for DRA74x
> +Should be "ti,dra726-pcie" for DRA72x
>   - reg : Two register ranges as listed in the reg-names property
>   - reg-names : The first entry must be "ti-conf" for the TI specific 
> registers
>  The second entry must be "rc-dbics" for the designware pcie
> @@ -14,6 +16,10 @@ PCIe Designware Controller
>  where  is the instance number of the pcie from the HW spec.
>   - interrupts : Two interrupt entries must be specified. The first one is for
>   main interrupt line and the second for MSI interrupt line.
> + - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
> module and the
> +   register offset to specify 1 lane or 2 lane.
> + - syscon-lane-sel : phandle/offset pair. Phandle to the system control 
> module and the
> +   register offset to specify lane selection.

These should have a ti prefix.

>   - #address-cells,
> #size-cells,
> #interrupt-cells,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] phy: ti-pipe3: configure usb3 phy to be used as pcie phy

[Rob Herring]

On Wed, Jan 06, 2016 at 04:29:08PM +0530, Kishon Vijay Abraham I wrote:
> DRA72 uses USB3 PHY for the 2nd lane of PCIE. The configuration
> required to make USB3 PHY used for the 2nd lane of PCIe is done
> here.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
>  drivers/phy/phy-ti-pipe3.c   |   30 
> +-
>  2 files changed, 31 insertions(+), 1 deletion(-)

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

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
> 
> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>> Hi,
>>
>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon :
>>
>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
 +rtc {
 +compatible = "ti,palmas-rtc";
 +interrupt-parent = <>;
 +interrupts = <8 IRQ_TYPE_NONE>;
>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>> it had none, there'd be no interrupt, right?
>> Well, it just translates IRQ_TYPE_NONE through
>>
>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>
>> to
>>
>> interrupts = <8 0>;
>>
>> which is given as an example in
>>
>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>
>> Since I don't know anything about the rtc driver beyond the bindings
>> documentation I assume it is correct...
>> I have added Laxman Dewangan because he introduced this interrupts =
>> <8 0>;
>>
> 
> As this is for palmas interrupt controller, it does not use the second
> field for interrupt from RTC.
> So there is no really any polarity. It can be set to 0.
> 
> The second argument will be used for GPIOs mainly. However, support need
> to be added on GPIO driver for rising/falling configuration.


Device tree represents the hardware - not to reflect how the driver
works. if the driver is wrong, fix it. the interrupt polarity needs to
be described in DT. based on palmas like designs, you should probably
use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
the SoC as it reaches Secondary interrupt handlers(SIH) registers.

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

Re: OMAP4430 power management support

[Nishanth Menon]

On 01/06/2016 08:22 AM, Frank Jenner wrote:
> Hello,
> 
> I am working on trying to enable power management features on a
> product that was based on the OMAP4430 SoC and the mainline 3.14
> kernel. In particular, I am interested in enabling Smart Reflex/AVS
> and frequency scaling (via cpufreq) functionality.


AVS class1.5 is supposed to be the official AVS class to be supported on
OMAP3630, OMAP4, OMAP5 SoCs. unfortunately, we dont have that supported
in upstream yet - let alone with cpufreq.

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

OMAP4430 power management support

[Frank Jenner]

Hello,

I am working on trying to enable power management features on a
product that was based on the OMAP4430 SoC and the mainline 3.14
kernel. In particular, I am interested in enabling Smart Reflex/AVS
and frequency scaling (via cpufreq) functionality.

I have attempted to use the following kernel configuration additions:

CONFIG_CPU_FREQ
CONFIG_POWER_AVS_OMAP
CONFIG_ARM_OMAP2PLUS_CPUFREQ or CONFIG_GENERIC_CPUFREQ_CPU0
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE
CONFIG_CPU_FREQ_GOV_COMMON
CONFIG_CPU_FREQ_GOV_CONSERVATIVE
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_CPU_FREQ_GOV_PERFORMANCE
CONFIG_CPU_FREQ_GOV_POWERSAVE
CONFIG_CPU_FREQ_GOV_USERSPACE
CONFIG_CPU_FREQ_STAT
CONFIG_POWER_AVS_OMAP_CLASS3

However, I don't get the expected sysfs nodes for cpufreq, and
omapconf (via "omapconf show sr") reports "All Smart-Reflex Modules
disabled." During kernel boot, I also see the following output which
might or might not be related to the problem:

ARM PMU: not yet supported on OMAP4430 due to missing CTI driver
OMAP4 PM: u-boot >= v2012.07 is required for full PM support
sr_init: No PMIC hook to init smartreflex
sr_init: platform driver register failed for SR

In addition, if I attempt to use CONFIG_GENERIC_CPUFREQ_CPU0 instead
of CONFIG_ARM_OMAP2PLUS_CPUFREQ, I also get the following output:

cpufreq_cpu0: failed to get cpu0 regulator: -19
cpufreq_cpu0: failed to get cpu0 clock: -2
cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2

I have also tried out the latest in the linux-3.14.y branch of the
ti-linux-kernel fork [1], thinking that OMAP power management might be
better supported there, but similarly did not see any indication of
cpufreq or Smart Reflex functioning.

My question, then, is whether power management is expected to work for
OMAP4430 under Linux 3.14, or whether there might be issues on my end?
Perhaps I am missing something in the device tree, or maybe my
bootloader isn't setting up something the kernel expects (I'm using a
pretty minimal custom bootloader).

If OMAP4 power management is not supported in the mainline or TI 3.14
kernels, is there another/later kernel that has this support? I was
hoping to stick with 3.14 because I don't want regressions in the
project due to major kernel updates, but I would be willing to see
what happens with a newer kernel if it supports power management. I
had been looking at a few older threads ([2], [3], [4]) that deal with
this, but it was unclear whether/when such support was upstreamed.

Thank you.

[1] https://git.ti.com/ti-linux-kernel/ti-linux-kernel/commits/linux-3.14.y
[2] http://www.spinics.net/lists/linux-omap/msg102038.html
[3] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/212472.html
[4] https://bugzilla.kernel.org/show_bug.cgi?id=58541
___
Frank Jenner
--
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] clk: move the common clock's to_clk_*(_hw) macros to clk-provider.h

[Geliang Tang]

to_clk_*(_hw) macros have been repeatedly defined in many places.
This patch moves all the to_clk_*(_hw) definations in the common
clock framework to public header clk-provider.h, and drop the local
definations.

Signed-off-by: Geliang Tang 
---
 drivers/clk/clk-composite.c  |  2 --
 drivers/clk/clk-divider.c|  2 --
 drivers/clk/clk-fixed-factor.c   |  2 --
 drivers/clk/clk-fixed-rate.c |  2 --
 drivers/clk/clk-fractional-divider.c |  2 --
 drivers/clk/clk-gate.c   |  2 --
 drivers/clk/clk-gpio.c   |  2 --
 drivers/clk/clk-multiplier.c |  2 --
 drivers/clk/clk-mux.c|  2 --
 drivers/clk/imx/clk-busy.c   |  4 ++--
 drivers/clk/imx/clk-fixup-div.c  |  5 ++---
 drivers/clk/imx/clk-fixup-mux.c  |  2 --
 drivers/clk/imx/clk-gate-exclusive.c |  2 +-
 drivers/clk/mediatek/clk-gate.c  |  8 
 drivers/clk/mediatek/clk-gate.h  |  2 +-
 drivers/clk/mvebu/common.c   |  2 --
 drivers/clk/mvebu/kirkwood.c |  2 --
 drivers/clk/mxs/clk-div.c|  2 +-
 drivers/clk/nxp/clk-lpc18xx-ccu.c|  2 --
 drivers/clk/st/clkgen-mux.c  |  9 -
 drivers/clk/ti/composite.c   |  2 --
 drivers/clk/ti/divider.c |  2 --
 drivers/clk/ti/gate.c|  2 --
 drivers/clk/ti/mux.c |  2 --
 include/linux/clk-provider.h | 18 ++
 25 files changed, 33 insertions(+), 51 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 4735de0..1f903e1f8 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -19,8 +19,6 @@
 #include 
 #include 
 
-#define to_clk_composite(_hw) container_of(_hw, struct clk_composite, hw)
-
 static u8 clk_composite_get_parent(struct clk_hw *hw)
 {
struct clk_composite *composite = to_clk_composite(hw);
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ded3ff4..c8bea2b 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -28,8 +28,6 @@
  * parent - fixed parent.  No clk_set_parent support
  */
 
-#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
-
 #define div_mask(width)((1 << (width)) - 1)
 
 static unsigned int _get_table_maxdiv(const struct clk_div_table *table,
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 83de57a..f0ddf37 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -23,8 +23,6 @@
  * parent - fixed parent.  No clk_set_parent support
  */
 
-#define to_clk_fixed_factor(_hw) container_of(_hw, struct clk_fixed_factor, hw)
-
 static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
 {
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index f85ec8d..e156beb 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -26,8 +26,6 @@
  * parent - fixed parent.  No clk_set_parent support
  */
 
-#define to_clk_fixed_rate(_hw) container_of(_hw, struct clk_fixed_rate, hw)
-
 static unsigned long clk_fixed_rate_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
 {
diff --git a/drivers/clk/clk-fractional-divider.c 
b/drivers/clk/clk-fractional-divider.c
index 5c4955e..1abcd76 100644
--- a/drivers/clk/clk-fractional-divider.c
+++ b/drivers/clk/clk-fractional-divider.c
@@ -16,8 +16,6 @@
 #include 
 #include 
 
-#define to_clk_fd(_hw) container_of(_hw, struct clk_fractional_divider, hw)
-
 static unsigned long clk_fd_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
 {
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index de0b322..d0d8ec8 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -26,8 +26,6 @@
  * parent - fixed parent.  No clk_set_parent support
  */
 
-#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
-
 /*
  * It works on following logic:
  *
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 19fed65..cbbea29 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -31,8 +31,6 @@
  * parent - fixed parent.  No clk_set_parent support
  */
 
-#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
-
 static int clk_gpio_gate_enable(struct clk_hw *hw)
 {
struct clk_gpio *clk = to_clk_gpio(hw);
diff --git a/drivers/clk/clk-multiplier.c b/drivers/clk/clk-multiplier.c
index fe78065..9e449c7 100644
--- a/drivers/clk/clk-multiplier.c
+++ b/drivers/clk/clk-multiplier.c
@@ -14,8 +14,6 @@
 #include 
 #include 
 
-#define to_clk_multiplier(_hw) container_of(_hw, struct clk_multiplier, hw)
-
 static unsigned long __get_mult(struct clk_multiplier *mult,
unsigned long rate,
unsigned long parent_rate)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 5ed03c8..252188f 

Re: OMAP4430 power management support

[Adam Ford]

I dont' know if it helps, but I struggeled with this too.

With my DM3730 (OMAP 3630), I had to enable Device Drivers->Adaptive
Voltage Scaling Class Support which enables CONFIG_POWER_AVS, a
requirement for POWER_AVS_OMAP.

Once I did that, I was able to get AVS Class 3 working on my DM3730
using th3 4.2+ kernel.  I haven't tried it with 3.14, but I would
expect it to be something similar.

adam

On Wed, Jan 6, 2016 at 9:08 AM, Nishanth Menon  wrote:
> On 01/06/2016 09:05 AM, Frank Jenner wrote:
>> On Wed, Jan 6, 2016 at 9:26 AM, Nishanth Menon  wrote:
>>> On 01/06/2016 08:22 AM, Frank Jenner wrote:
 Hello,

 I am working on trying to enable power management features on a
 product that was based on the OMAP4430 SoC and the mainline 3.14
 kernel. In particular, I am interested in enabling Smart Reflex/AVS
 and frequency scaling (via cpufreq) functionality.
>>>
>>>
>>> AVS class1.5 is supposed to be the official AVS class to be supported on
>>> OMAP3630, OMAP4, OMAP5 SoCs. unfortunately, we dont have that supported
>>> in upstream yet - let alone with cpufreq.
>>>
>>> --
>>> Regards,
>>> Nishanth Menon
>>
>> Sorry my original post might have been TL;DR, but is there a public
>> fork/branch that does have the support?
>
>
> There should be TI vendor kernels on 3.0 or 3.4 kernel that should have
> full entitlement of the SoC if you need that.. but I doubt there has
> been work on OMAP4 on more recent kernels to my knowledge. All work on
> OMAP4/3 is mostly community driven and in upstream.
>
> https://plus.google.com/+NishanthMenon/posts/gvyZQcNieoq
> kind of gives an overview of where we need to go. all contributions are
> welcome.
>
> --
> Regards,
> Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: OMAP4430 power management support

[Frank Jenner]

On Wed, Jan 6, 2016 at 9:26 AM, Nishanth Menon  wrote:
> On 01/06/2016 08:22 AM, Frank Jenner wrote:
>> Hello,
>>
>> I am working on trying to enable power management features on a
>> product that was based on the OMAP4430 SoC and the mainline 3.14
>> kernel. In particular, I am interested in enabling Smart Reflex/AVS
>> and frequency scaling (via cpufreq) functionality.
>
>
> AVS class1.5 is supposed to be the official AVS class to be supported on
> OMAP3630, OMAP4, OMAP5 SoCs. unfortunately, we dont have that supported
> in upstream yet - let alone with cpufreq.
>
> --
> Regards,
> Nishanth Menon

Sorry my original post might have been TL;DR, but is there a public
fork/branch that does have the support?
--
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: OMAP4430 power management support

[Nishanth Menon]

On 01/06/2016 09:05 AM, Frank Jenner wrote:
> On Wed, Jan 6, 2016 at 9:26 AM, Nishanth Menon  wrote:
>> On 01/06/2016 08:22 AM, Frank Jenner wrote:
>>> Hello,
>>>
>>> I am working on trying to enable power management features on a
>>> product that was based on the OMAP4430 SoC and the mainline 3.14
>>> kernel. In particular, I am interested in enabling Smart Reflex/AVS
>>> and frequency scaling (via cpufreq) functionality.
>>
>>
>> AVS class1.5 is supposed to be the official AVS class to be supported on
>> OMAP3630, OMAP4, OMAP5 SoCs. unfortunately, we dont have that supported
>> in upstream yet - let alone with cpufreq.
>>
>> --
>> Regards,
>> Nishanth Menon
> 
> Sorry my original post might have been TL;DR, but is there a public
> fork/branch that does have the support?


There should be TI vendor kernels on 3.0 or 3.4 kernel that should have
full entitlement of the SoC if you need that.. but I doubt there has
been work on OMAP4 on more recent kernels to my knowledge. All work on
OMAP4/3 is mostly community driven and in upstream.

https://plus.google.com/+NishanthMenon/posts/gvyZQcNieoq
kind of gives an overview of where we need to go. all contributions are
welcome.

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Sebastian Reichel]

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> unified the GPMC debug for the SoCs with GPMC. The commit also left
> out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> for GPMC to be able to remap GPMC devices out of address 0.
> 
> Unfortunately on 900, onenand now only partially works with the device

You may want to change 900 to n900 (maybe even Nokia N900) before
actually committing this.

> tree provided timings. It works enough to get detected but the clock
> rate supported by the onenand chip gets misdetected. This in turn causes
> the GPMC timings to be miscalculated and this leads into file system
> corruption on n900.
> 
> Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> write. This is needed also for async timings when we write to onenand
> with omap2_onenand_set_async_mode(). Without sync write bit set, the
> async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> 
> Let's exit with an error if onenand rate is not detected. And let's
> remove the extra call to omap2_onenand_set_async_mode() as we only
> need to do this once at the end of omap2_onenand_setup_async().
> 
> Reported-by: Ivaylo Dimitrov 
> Signed-off-by: Tony Lindgren 

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

On  6.01.2016 19:47, Tony Lindgren wrote:

* Sebastian Reichel  [160106 09:41]:

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device


You may want to change 900 to n900 (maybe even Nokia N900) before
actually committing this.


Thanks will do.

Tony




Unfortunately, it seems there is more to be fixed. It booted several 
times to the userspace, but after a couple of shutdowns, rootfs became 
corrupted again. I flashed, installed linux 4.4, but the same happened 
after the first shutdown with 4.4:


<5>[8.159179] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
<3>[8.184631] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node 
type (255 but expected 9)
<3>[8.197937] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node 
at LEB 1934:6936, LEB mapping status 0

<3:[8.216522] Not a node, first 24 bytes:
<3>[8.220520] : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff  

<4>[8.247772] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.0-rc7+ #4
<4>[8.258911] Hardware name: Nokia RX-51 board
<4>[8.268096] [] (unwind_backtrace) from Y] 
(show_stack+0x10/0x14)
<4>[8.281097] [] (show_stack) from [] 
(ubifs_read_node+0x29c/0x2d4)
<4>[8.294097] [] (ubifs_read_node) from [] 
(dbg_old_index_check_init+0x60/0x9c)
<4>[8.308258] [] (dbg_old_index_check_init) from 
[] (ubifs_mount+0xd90/0x15f0)
<4>[8.322357] [] (ubifs_mount) from [] 
(mount_fs+0x70/0x148)
<4>[8.334747] [] (mount_fs) from [] 
(vfs_kern_mount+0x4c/0x110)
<4>[8.347412] [] (vfs_kern_mount) from [] 
(do_mount+0xadc/0xc34)
<4>[8.360168] [] (do_mount) from [] 
(SyS_mount+0x70/0x9c)
<4>[8.372253] [] (SyS_mount) from [] 
(mount_block_root+0xf0/0x28c)
<4>[8.385162] [] (mount_block_root) from [] 
(prepare_namespace+0x88/0x1bc)
<4>[8.398834] [] (prepare_namespace) from [] 
(kernel_init_freeable+0x178/0x1c4)
<4>[8.412963] [] (kernel_init_freeabme) from [] 
(kernel_init+0x8/0xe4)
<4>[8.426300] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x3c)


P.S.
(Pali, sorry for not having time to read the kernel docs re e-mail 
clients :) )

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Sebastian Reichel  [160106 09:41]:
> Hi,
> 
> On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > unified the GPMC debug for the SoCs with GPMC. The commit also left
> > out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> > for GPMC to be able to remap GPMC devices out of address 0.
> > 
> > Unfortunately on 900, onenand now only partially works with the device
> 
> You may want to change 900 to n900 (maybe even Nokia N900) before
> actually committing this.

Thanks will do.

Tony


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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov  [160106 10:01]:
> 
> Unfortunately, it seems there is more to be fixed. It booted several times
> to the userspace, but after a couple of shutdowns, rootfs became corrupted
> again. I flashed, installed linux 4.4, but the same happened after the first
> shutdown with 4.4:

Hmm. Care to verify that your onenand really gets detected at 83 MHz like
your earlier logs show? Below is a patch that should show it.

Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG
enabled? Or does that also produce corruption after few reboots?

Regards,

Tony

8< --
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 0;
}
 
+   pr_info("onenand rate detected: %i\n", freq);
+
return freq;
 }
 
--
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

OMAP3630-ISP and MT9P031 Device Tree Help

[Adam Ford]

I am trying to setup the device tree to enable a parallel camera
interface as found on the LPD Dev Kit.

The instructions I am using for the basis are:
https://alaganraj.wordpress.com/2015/08/08/beagleboard-xm-camera-li-5m03-mt9p031-support-with-device-tree/

It I get the same results when I compile it into the kernel or as a
module, but the errors are the same.

When I modprobe it, I get:

# modprobe omap3-isp
 omap3isp 480bc000.isp: parsing endpoint
/ocp/isp@480bc000/ports/port@0/endpoint, interface 0
 omap3isp 480bc000.isp: Revision 15.0 found
iommu: Adding device 480bc000.isp to group 0
 omap-iommu 480bd400.mmu: 480bd400.mmu: version 1.1
omap3isp 480bc000.isp: hist: using DMA channel dma0chan6
 omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
CCP2 was not initialized!
omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
CSI2a was not initialized!
omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
CCDC was not initialized!
omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
preview was not initialized!
 omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
resizer was not initialized!
omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
AEWB was not initialized!
omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
AF was not initialized!
omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP
histogram was not initialized!
#

 I then modprobe the mt9p031 driver, and it won't initialize, but it
is detected.

# modprobe mt9p031
[  127.390808] 1-0048 supply vdd not found, using dummy regulator
[  127.398101] 1-0048 supply vaa not found, using dummy regulator
[  127.404907] omap3isp 480bc000.isp: isp_xclk_set_rate: cam_xclka set
to 2160 Hz (div 8)
[  127.432861] mt9p031 1-0048: MT9P031 detected at address 0x48
[  127.438873] omap3isp 480bc000.isp: Entity type for entity mt9p031
1-0048 was not initialized!
#

I can post my device tree if necessary, but it's basically like what's
in the link above.  Does anyone have any ideas on what I am doing
wrong?

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

Hi,

On  6.01.2016 20:26, Tony Lindgren wrote:



Hmm. Care to verify that your onenand really gets detected at 83 MHz like
your earlier logs show? Below is a patch that should show it.


before the corruption appeared, I looked a couple of times in syslog and 
the freq there was 83MHz. Including after I disabled CONFIG_OMAP_GPMC_DEBUG.




Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG
enabled? Or does that also produce corruption after few reboots?


CONFIG_OMAP_GPMC_DEBUG is disabled, shall I enable it?


--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 0;
}

+   pr_info("onenand rate detected: %i\n", freq);
+
return freq;
  }



Where am I supposed to get the output from ^^^ if rootfs become 
corrupted? The problem appears after poweroff/restart when it is already 
too late to get the syslog.


BTW, did you compare all the GPMC registers with and without 
HWMOD_INIT_NO_RESET?


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

Re: OMAP4430 power management support

[Nishanth Menon]

On 01/06/2016 10:02 AM, Adam Ford wrote:
> I dont' know if it helps, but I struggeled with this too.
> 
> With my DM3730 (OMAP 3630), I had to enable Device Drivers->Adaptive
> Voltage Scaling Class Support which enables CONFIG_POWER_AVS, a
> requirement for POWER_AVS_OMAP.
> 
> Once I did that, I was able to get AVS Class 3 working on my DM3730
> using th3 4.2+ kernel.  I haven't tried it with 3.14, but I would


Arggh... using AVS class3 with DM3730 will create all kinds of issues
later on as the device gets old. Wish we had managed to get AVS 1.5
basic functionality upstream :(.


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

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Rob Herring]

On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon  wrote:
> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>
>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>>> Hi,
>>>
>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon :
>>>
 On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> +rtc {
> +compatible = "ti,palmas-rtc";
> +interrupt-parent = <>;
> +interrupts = <8 IRQ_TYPE_NONE>;
 IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
 it had none, there'd be no interrupt, right?
>>> Well, it just translates IRQ_TYPE_NONE through
>>>
>>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>>
>>> to
>>>
>>> interrupts = <8 0>;
>>>
>>> which is given as an example in
>>>
>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>>
>>> Since I don't know anything about the rtc driver beyond the bindings
>>> documentation I assume it is correct...
>>> I have added Laxman Dewangan because he introduced this interrupts =
>>> <8 0>;
>>>
>>
>> As this is for palmas interrupt controller, it does not use the second
>> field for interrupt from RTC.
>> So there is no really any polarity. It can be set to 0.
>>
>> The second argument will be used for GPIOs mainly. However, support need
>> to be added on GPIO driver for rising/falling configuration.
>
>
> Device tree represents the hardware - not to reflect how the driver
> works. if the driver is wrong, fix it. the interrupt polarity needs to
> be described in DT. based on palmas like designs, you should probably
> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
> the SoC as it reaches Secondary interrupt handlers(SIH) registers.

If the trigger type is not programmable, then not setting the trigger
type in the DT is fine. Internal connections are often not documented.

Rob
--
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: OMAP4430 power management support

[Adam Ford]

Any chance you can define what you mean by 'issues' and 'old'?

Logic PD (my daytime employer) uses AVS 3 in their custom Linux
distribution.  If that's going to be a problem, I would like to notify
some people there.

adam

On Wed, Jan 6, 2016 at 1:12 PM, Nishanth Menon  wrote:
> On 01/06/2016 10:02 AM, Adam Ford wrote:
>> I dont' know if it helps, but I struggeled with this too.
>>
>> With my DM3730 (OMAP 3630), I had to enable Device Drivers->Adaptive
>> Voltage Scaling Class Support which enables CONFIG_POWER_AVS, a
>> requirement for POWER_AVS_OMAP.
>>
>> Once I did that, I was able to get AVS Class 3 working on my DM3730
>> using th3 4.2+ kernel.  I haven't tried it with 3.14, but I would
>
>
> Arggh... using AVS class3 with DM3730 will create all kinds of issues
> later on as the device gets old. Wish we had managed to get AVS 1.5
> basic functionality upstream :(.
>
>
> --
> Regards,
> Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár  [160106 01:06]:
> On Wednesday 06 January 2016 10:55:51 Ivaylo Dimitrov wrote:
> > On  6.01.2016 00:49, Tony Lindgren wrote:
> > >
> > >Suggested fix below, please test and reply with your Tested-by's if
> > >it solves the problem so we may still be able to get this into v4.4.
> > >
> > >8< ---
> > >From: Tony Lindgren 
> > >Date: Tue, 5 Jan 2016 12:04:20 -0800
> > >Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid 
> > >filesystem
> > >  corruption
> > >
> > >Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > >unified the GPMC debug for the SoCs with GPMC. The commit also left
> > >out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> > >for GPMC to be able to remap GPMC devices out of address 0.
> > >
> > >Unfortunately on 900, onenand now only partially works with the device
> > >tree provided timings. It works enough to get detected but the clock
> > >rate supported by the onenand chip gets misdetected. This in turn causes
> > >the GPMC timings to be miscalculated and this leads into file system
> > >corruption on n900.
> > >
> > >Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> > >write. This is needed also for async timings when we write to onenand
> > >with omap2_onenand_set_async_mode(). Without sync write bit set, the
> > >async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> > >
> > >Let's exit with an error if onenand rate is not detected. And let's
> > >remove the extra call to omap2_onenand_set_async_mode() as we only
> > >need to do this once at the end of omap2_onenand_setup_async().
> > >
> > >Reported-by: Ivaylo Dimitrov 
> > >Signed-off-by: Tony Lindgren 
> > >
> > >--- a/arch/arm/mach-omap2/gpmc-onenand.c
> > >+++ b/arch/arm/mach-omap2/gpmc-onenand.c
> > 
> > Bellow is gpmc dmesg output with that fix. I also disabled
> > CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no obvious
> > problems.
> > 
> > So, seems that fixes the problem, feel free to  add:
> > 
> > Tested-by: Ivaylo Dimitrov 
> 
> Great! Thank you for fixing and testing this problem!

Good to hear it fixes the issue. I'll wait to hear from Aaro before
committing.

Regards,

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

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* H. Nikolaus Schaller  [160106 08:48]:
> Hi Tony,
> 
> Am 06.01.2016 um 17:41 schrieb Tony Lindgren :
> 
> > Hi,
> > 
> > * H. Nikolaus Schaller  [160106 00:12]:
> >> Am 06.01.2016 um 02:00 schrieb Tony Lindgren :
> >>> 
> >>> Also I'm not seeing just zeroes coming from RTC after typing hwclock
> >>> on omap5-uevm. It's working on x15 though.
> >>> 
> >>> Nikolaus, is hwclock command working for you on omap5-uevm?
> >> 
> >> Well, yes and no. It appears it *was* working when tested last time
> >> (we sometimes have months of delay for submitting patches upstream).
> >> 
> >> I have found an SD image with 4.3-rc6 with this patch in the dtb and
> >> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
> >> 10 seconds (I guess some timeout).
> >> 
> >> I have checked the dtb and in both cases it is interrupts = <8 0>;
> >> 
> >> xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
> >> 000:  0008  
> >> 
> >> So I think something has changed in the rtc driver or somewhere else.
> > 
> > I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
> > RTC, and I still don't have hwclock working with RTC.
> > 
> > It seems you have some additional patches there that make it work?
> 
> Hm. Not that I am aware of. We just did add the rtc nodes but did not
> touch palmas drivers (except adding the gpadc of this patch series).

OK

> > I guess it could also be a bootloader change if it's a different
> > SD image that works for you.
> 
> Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from
> source. I will try to find out if it makes a difference.

OK. It could be also some .config change with something built-in?

Regards,

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

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

Hi,

* H. Nikolaus Schaller  [160106 00:12]:
> Am 06.01.2016 um 02:00 schrieb Tony Lindgren :
> > 
> > Also I'm not seeing just zeroes coming from RTC after typing hwclock
> > on omap5-uevm. It's working on x15 though.
> > 
> > Nikolaus, is hwclock command working for you on omap5-uevm?
> 
> Well, yes and no. It appears it *was* working when tested last time
> (we sometimes have months of delay for submitting patches upstream).
> 
> I have found an SD image with 4.3-rc6 with this patch in the dtb and
> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
> 10 seconds (I guess some timeout).
> 
> I have checked the dtb and in both cases it is interrupts = <8 0>;
> 
> xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
> 000:  0008  
> 
> So I think something has changed in the rtc driver or somewhere else.

I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
RTC, and I still don't have hwclock working with RTC.

It seems you have some additional patches there that make it work?

I guess it could also be a bootloader change if it's a different
SD image that works for you.

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Aaro Koskinen]

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> From: Tony Lindgren 
> Date: Tue, 5 Jan 2016 12:04:20 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
>  corruption
> 
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> unified the GPMC debug for the SoCs with GPMC. The commit also left
> out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> for GPMC to be able to remap GPMC devices out of address 0.
> 
> Unfortunately on 900, onenand now only partially works with the device
> tree provided timings. It works enough to get detected but the clock
> rate supported by the onenand chip gets misdetected. This in turn causes
> the GPMC timings to be miscalculated and this leads into file system
> corruption on n900.
> 
> Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> write. This is needed also for async timings when we write to onenand
> with omap2_onenand_set_async_mode(). Without sync write bit set, the
> async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> 
> Let's exit with an error if onenand rate is not detected. And let's
> remove the extra call to omap2_onenand_set_async_mode() as we only
> need to do this once at the end of omap2_onenand_setup_async().
> 
> Reported-by: Ivaylo Dimitrov 
> Signed-off-by: Tony Lindgren 

This fixes also the detection issue on N950. Also tested the patch
with N810.

Tested-by: Aaro Koskinen 

A.

> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -149,8 +149,8 @@ static int omap2_onenand_get_freq(struct 
> omap_onenand_platform_data *cfg,
>   freq = 104;
>   break;
>   default:
> - freq = 54;
> - break;
> + pr_err("onenand rate not detected, bad GPMC async timings?\n");
> + freq = 0;
>   }
>  
>   return freq;
> @@ -271,6 +271,11 @@ static int omap2_onenand_setup_async(void __iomem 
> *onenand_base)
>   struct gpmc_timings t;
>   int ret;
>  
> + /*
> +  * Note that we need to keep sync_write set for the call to
> +  * omap2_onenand_set_async_mode() to work to detect the onenand
> +  * supported clock rate for the sync timings.
> +  */
>   if (gpmc_onenand_data->of_node) {
>   gpmc_read_settings_dt(gpmc_onenand_data->of_node,
> _async);
> @@ -281,12 +286,9 @@ static int omap2_onenand_setup_async(void __iomem 
> *onenand_base)
>   else
>   gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
>   onenand_async.sync_read = false;
> - onenand_async.sync_write = false;
>   }
>   }
>  
> - omap2_onenand_set_async_mode(onenand_base);
> -
>   omap2_onenand_calc_async_timings();
>  
>   ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, _async);
> @@ -310,6 +312,8 @@ static int omap2_onenand_setup_sync(void __iomem 
> *onenand_base, int *freq_ptr)
>   if (!freq) {
>   /* Very first call freq is not known */
>   freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
> + if (!freq)
> + return -ENODEV;
>   set_onenand_cfg(onenand_base);
>   }
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 17:41 schrieb Tony Lindgren :

> Hi,
> 
> * H. Nikolaus Schaller  [160106 00:12]:
>> Am 06.01.2016 um 02:00 schrieb Tony Lindgren :
>>> 
>>> Also I'm not seeing just zeroes coming from RTC after typing hwclock
>>> on omap5-uevm. It's working on x15 though.
>>> 
>>> Nikolaus, is hwclock command working for you on omap5-uevm?
>> 
>> Well, yes and no. It appears it *was* working when tested last time
>> (we sometimes have months of delay for submitting patches upstream).
>> 
>> I have found an SD image with 4.3-rc6 with this patch in the dtb and
>> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
>> 10 seconds (I guess some timeout).
>> 
>> I have checked the dtb and in both cases it is interrupts = <8 0>;
>> 
>> xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
>> 000:  0008  
>> 
>> So I think something has changed in the rtc driver or somewhere else.
> 
> I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
> RTC, and I still don't have hwclock working with RTC.
> 
> It seems you have some additional patches there that make it work?

Hm. Not that I am aware of. We just did add the rtc nodes but did not
touch palmas drivers (except adding the gpadc of this patch series).

> 
> I guess it could also be a bootloader change if it's a different
> SD image that works for you.

Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from
source. I will try to find out if it makes a difference.

BR,
Nikolaus

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

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 02:00 schrieb Tony Lindgren :

> * Nishanth Menon  [160105 15:40]:
>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>> tested on OMP5432 EVM
>>> 
>>> Signed-off-by: H. Nikolaus Schaller 
>>> ---
>>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 
>>> 1 file changed, 8 insertions(+)
>>> 
>>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
>>> b/arch/arm/boot/dts/omap5-board-common.dtsi
>>> index 5cf76a1..30c0d3b 100644
>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>>> @@ -358,6 +358,14 @@
>>> #clock-cells = <0>;
>>> };
>>> 
>>> +   rtc {
>>> +   compatible = "ti,palmas-rtc";
>>> +   interrupt-parent = <>;
>>> +   interrupts = <8 IRQ_TYPE_NONE>;
>> 
>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>> it had none, there'd be no interrupt, right?
> 
> Also I'm not seeing just zeroes coming from RTC after typing hwclock
> on omap5-uevm. It's working on x15 though.
> 
> Nikolaus, is hwclock command working for you on omap5-uevm?

Well, yes and no. It appears it *was* working when tested last time
(we sometimes have months of delay for submitting patches upstream).

I have found an SD image with 4.3-rc6 with this patch in the dtb and
there it works. With 4.4-rc8 it does not work. hwclock command hangs for
10 seconds (I guess some timeout).

I have checked the dtb and in both cases it is interrupts = <8 0>;

xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
000:  0008  

So I think something has changed in the rtc driver or somewhere else.

BR,
Nikolaus

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

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Laxman Dewangan]

On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:

Hi,

Am 06.01.2016 um 00:40 schrieb Nishanth Menon :


On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:

+   rtc {
+   compatible = "ti,palmas-rtc";
+   interrupt-parent = <>;
+   interrupts = <8 IRQ_TYPE_NONE>;

IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
it had none, there'd be no interrupt, right?

Well, it just translates IRQ_TYPE_NONE through

Linux/include/dt-bindings/interrupt-controller/irq.h

to

interrupts = <8 0>;

which is given as an example in

Documentation//devicetree/bindings/rtc/rtc-palmas.txt

Since I don't know anything about the rtc driver beyond the bindings 
documentation I assume it is correct...
I have added Laxman Dewangan because he introduced this interrupts = <8 0>;



As this is for palmas interrupt controller, it does not use the second 
field for interrupt from RTC.

So there is no really any polarity. It can be set to 0.

The second argument will be used for GPIOs mainly. However, support need 
to be added on GPIO driver for rising/falling configuration.





--
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] PCI: hosts: mark pcie/pci (msi) irq cascade handler as IRQF_NO_THREAD

[Bjorn Helgaas]

Hi Grygorii,

On Thu, Dec 10, 2015 at 09:18:20PM +0200, Grygorii Strashko wrote:
> On -RT and if kernel is booting with "threadirqs" cmd line parameter
> pcie/pci (msi) irq cascade handlers (like dra7xx_pcie_msi_irq_handler())
> will be forced threaded and, as result, will generate warnings like:
> 
> WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 
> handle_irq_event_percpu+0x14c/0x174()
> irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
> Backtrace:
>  (warn_slowpath_common) from [] (warn_slowpath_fmt+0x38/0x40)
>  (warn_slowpath_fmt) from [] (handle_irq_event_percpu+0x14c/0x174)
>  (handle_irq_event_percpu) from [] (handle_irq_event+0x84/0xb8)
>  (handle_irq_event) from [] (handle_simple_irq+0x90/0x118)
>  (handle_simple_irq) from [] (generic_handle_irq+0x30/0x44)
>  (generic_handle_irq) from [] 
> (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
>  (dra7xx_pcie_msi_irq_handler) from [] 
> (irq_forced_thread_fn+0x28/0x5c)
>  (irq_forced_thread_fn) from [] (irq_thread+0x128/0x204)
> 
> This happens because all of them invoke generic_handle_irq() from the
> requsted handler. generic_handle_irq grabs raw_locks and this needs to
> run in raw-irq context.
> 
> This issue was originally reproduced on TI dra7-evem, but, as was
> identified during dicussion [1], other PCI(e) hosts can also suffer
> from this issue. So let's fix all them at once and mark pcie/pci (msi)
> irq cascade handlers IRQF_NO_THREAD explicitly.
> 
> [1] https://lkml.org/lkml/2015/11/20/356
> 
> Cc: Kishon Vijay Abraham I 
> Cc: Bjorn Helgaas 
> Cc: Jingoo Han 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Richard Zhu 
> Cc: Lucas Stach 
> Cc: Thierry Reding 
> Cc: Stephen Warren 
> Cc: Alexandre Courbot 
> Cc: Simon Horman 
> Cc: Pratyush Anand 
> Cc: Michal Simek 
> Cc: "Sören Brinkmann" 
> Cc: Sebastian Andrzej Siewior 
> Signed-off-by: Grygorii Strashko 
> ---
> Changes in v3:
>  - change applied to all affected pci(e) host drivers in drivers/pci/hosts.
>After some invsetigation I've decided to not touch arch code - it is not 
> easy
>to identify all places which need to be fixed. 
>if it's still required - i can send separate patches for 
>arch/mips/pci/msi-octeon.c and arch/sparc/kernel/pci_msi.c.
> Links
> v2: https://lkml.org/lkml/2015/11/20/356
> v1: https://lkml.org/lkml/2015/11/5/593
> ref: https://lkml.org/lkml/2015/11/3/660
> 
>  drivers/pci/host/pci-dra7xx.c | 13 -
>  drivers/pci/host/pci-exynos.c |  3 ++-
>  drivers/pci/host/pci-imx6.c   |  3 ++-
>  drivers/pci/host/pci-tegra.c  |  2 +-
>  drivers/pci/host/pcie-rcar.c  |  6 --
>  drivers/pci/host/pcie-spear13xx.c |  3 ++-
>  drivers/pci/host/pcie-xilinx.c|  3 ++-
>  7 files changed, 25 insertions(+), 8 deletions(-)

I applied this to pci/host for v4.5, thanks.  I added a stable tag.
I haven't seen any acks from the host driver guys, but I will still add
them if I see any in the next few days.

Bjorn

> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 8c36880..0415192 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct 
> dra7xx_pcie *dra7xx,
>   return -EINVAL;
>   }
>  
> + /*
> +  * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
> +  * On -RT and if kernel is booting with "threadirqs" cmd line parameter
> +  * the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
> +  * in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
> +  * which, in turn, will be resolved to handle_simple_irq() call.
> +  * The handle_simple_irq() expected to be called with IRQ disabled, as
> +  * result kernle will display warning:
> +  * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
> +  */
>   ret = devm_request_irq(>dev, pp->irq,
> -dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
> +dra7xx_pcie_msi_irq_handler,
> +IRQF_SHARED | IRQF_NO_THREAD,
>  "dra7-pcie-msi", pp);
>   if (ret) {
>   dev_err(>dev, "failed to request irq\n");
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index 01095e1..d997d22 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -522,7 +522,8 @@ static int __init exynos_add_pcie_port(struct pcie_port 
> *pp,
>  
>   ret = devm_request_irq(>dev, pp->msi_irq,
>   exynos_pcie_msi_irq_handler,

Re: Nokia N900: u-SD card in v4.2+

[Kishon Vijay Abraham I]

Hi,

On Thursday 07 January 2016 02:16 AM, Pavel Machek wrote:
> Hi!
> 
> In v4.1, both internal MMC and u-SD cards work ok.
> 
> In v4.2, only the internal MMC is detected. In v4.3, not even internal
> MMC works. In v4.4, only the internal MMC is detected.
> 
> Does it work for you? Any patches?

I don't have Nokia N900 to check this, but can you share your config and kernel
logs? Check if CONFIG_REGULATOR_PBIAS is present in your config.
CONFIG_REGULATOR_PBIAS is now mandatory for all omap3+ SoCs to work.

Thanks
Kishon

> 
> (I do have hack in the dts to disable back cover detection...)
> 
>   Pavel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

[Kishon Vijay Abraham I]

Hi,

On Wednesday 06 January 2016 07:43 PM, Rob Herring wrote:
> On Wed, Jan 06, 2016 at 04:19:53PM +0530, Kishon Vijay Abraham I wrote:
>> Perform syscon configurations to get x2 mode to working in DRA74x and
>> DRA72x. Also add a new compatible string to dfferentiate
>> DRA72x and DRA74x, since b1c0 mask is different for both these platforms.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
>>  drivers/pci/host/pci-dra7xx.c|   81 
>> +-
>>  2 files changed, 86 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
>> b/Documentation/devicetree/bindings/pci/ti-pci.txt
>> index 60e2516..0b10e84 100644
>> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
>> @@ -1,7 +1,9 @@
>>  TI PCI Controllers
>>  
>>  PCIe Designware Controller
>> - - compatible: Should be "ti,dra7-pcie""
>> + - compatible: "ti,dra7-pcie" is deprecated
>> +   Should be "ti,dra746-pcie" for DRA74x
>> +   Should be "ti,dra726-pcie" for DRA72x
>>   - reg : Two register ranges as listed in the reg-names property
>>   - reg-names : The first entry must be "ti-conf" for the TI specific 
>> registers
>> The second entry must be "rc-dbics" for the designware pcie
>> @@ -14,6 +16,10 @@ PCIe Designware Controller
>> where  is the instance number of the pcie from the HW spec.
>>   - interrupts : Two interrupt entries must be specified. The first one is 
>> for
>>  main interrupt line and the second for MSI interrupt line.
>> + - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
>> module and the
>> +   register offset to specify 1 lane or 2 lane.
>> + - syscon-lane-sel : phandle/offset pair. Phandle to the system control 
>> module and the
>> +   register offset to specify lane selection.
> 
> These should have a ti prefix.

Okay. Will fix that and post a new version.

Thanks
Kishon
> 
>>   - #address-cells,
>> #size-cells,
>> #interrupt-cells,
--
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: OMAP4430 power management support

[Nishanth Menon]

On 01/06/2016 01:44 PM, Adam Ford wrote:
> Any chance you can define what you mean by 'issues' and 'old'?
> 

AVS class recommendation is AVS Class 1.5 for DM3730. If one does not
follow the recommendation, then the result will be that some devices may
not function OR fail in some unpredictable manner after a duration of
time (aka device gets old).

> Logic PD (my daytime employer) uses AVS 3 in their custom Linux
> distribution.  If that's going to be a problem, I would like to notify
> some people there.

Logic PD probably should talk with TI on the topic.

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

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/06/2016 01:34 PM, Rob Herring wrote:
> On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon  wrote:
>> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>>
>>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
 Hi,

 Am 06.01.2016 um 00:40 schrieb Nishanth Menon :

> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>> +rtc {
>> +compatible = "ti,palmas-rtc";
>> +interrupt-parent = <>;
>> +interrupts = <8 IRQ_TYPE_NONE>;
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?
 Well, it just translates IRQ_TYPE_NONE through

 Linux/include/dt-bindings/interrupt-controller/irq.h

 to

 interrupts = <8 0>;

 which is given as an example in

 Documentation//devicetree/bindings/rtc/rtc-palmas.txt

 Since I don't know anything about the rtc driver beyond the bindings
 documentation I assume it is correct...
 I have added Laxman Dewangan because he introduced this interrupts =
 <8 0>;

>>>
>>> As this is for palmas interrupt controller, it does not use the second
>>> field for interrupt from RTC.
>>> So there is no really any polarity. It can be set to 0.
>>>
>>> The second argument will be used for GPIOs mainly. However, support need
>>> to be added on GPIO driver for rising/falling configuration.
>>
>>
>> Device tree represents the hardware - not to reflect how the driver
>> works. if the driver is wrong, fix it. the interrupt polarity needs to
>> be described in DT. based on palmas like designs, you should probably
>> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
>> the SoC as it reaches Secondary interrupt handlers(SIH) registers.
> 
> If the trigger type is not programmable, then not setting the trigger
> type in the DT is fine. Internal connections are often not documented.
> 

Weird, that is not what I got feedback when I send
https://patchwork.ozlabs.org/patch/381125/

If this is the new norm, I retract my objection.


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

Nokia N900: u-SD card in v4.2+

[Pavel Machek]

Hi!

In v4.1, both internal MMC and u-SD cards work ok.

In v4.2, only the internal MMC is detected. In v4.3, not even internal
MMC works. In v4.4, only the internal MMC is detected.

Does it work for you? Any patches?

(I do have hack in the dts to disable back cover detection...)

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