Re: [PATCH v4 3/3] wlcore/wl12xx: spi: add wifi support to cm-t335

[Kalle Valo]

Uri Mashiach  writes:

> Device tree modifications:
> - Pinmux for SPI0 and WiFi GPIOs.
> - SPI0 node with wlcore as a child node.
>
> Cc: Tony Lindgren 
> Signed-off-by: Uri Mashiach 
> ---
> v1 -> v2: Replace interrupts and interrupt-parent with interrupts-extended.
> v2 -> v3: Move the pinctrl-0 = <_pins> to the wlcore node.
> v3 -> v4: replace interrupts-extended with interrupts and interrupt-parent. 
> (revert v2 modification).
>   According to Rob Herring and 
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt,
> interrupts-extended should only be used when a device has multiple 
> interrupt parents.
>
>  arch/arm/boot/dts/am335x-cm-t335.dts | 55 
> 
>  1 file changed, 55 insertions(+)

To what tree should this patch go? My wireless-drivers-next tree doesn't
even have this file.

https://patchwork.kernel.org/patch/7933441/

-- 
Kalle Valo
--
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/3] wlcore/wl12xx: spi: add wifi support to cm-t335

[Uri Mashiach]

Hi Kalle Valo,

On 01/07/2016 11:02 AM, Kalle Valo wrote:

Uri Mashiach  writes:


Device tree modifications:
- Pinmux for SPI0 and WiFi GPIOs.
- SPI0 node with wlcore as a child node.

Cc: Tony Lindgren 
Signed-off-by: Uri Mashiach 
---
v1 -> v2: Replace interrupts and interrupt-parent with interrupts-extended.
v2 -> v3: Move the pinctrl-0 = <_pins> to the wlcore node.
v3 -> v4: replace interrupts-extended with interrupts and interrupt-parent. 
(revert v2 modification).
   According to Rob Herring and 
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt,
  interrupts-extended should only be used when a device has multiple 
interrupt parents.

  arch/arm/boot/dts/am335x-cm-t335.dts | 55 
  1 file changed, 55 insertions(+)


To what tree should this patch go? My wireless-drivers-next tree doesn't
even have this file.


Should be applied into omap-for-v4.x/dt



https://patchwork.kernel.org/patch/7933441/



--
Thanks,
Uri
--
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: Nokia N900: u-SD card in v4.2+

[Pavel Machek]

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.

I enabled CONFIG_REGULATOR_PBIAS and both MMCs now work.

I wonder if we should add some selects, so that users updating from
old kernels don't break their system?

Thanks,

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

[PATCH v12 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

this is v12 of an attempt to make it easier for devices to remain in
runtime PM when the system goes to sleep, mainly to reduce the time
spent resuming devices.

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

With these changes, a uvcvideo device (for example) stays in runtime
suspend when the system goes to sleep and is left in that state when the
system resumes, not delaying it unnecessarily.

Thanks,

Tomeu

Changes in v12:
- Include linux/pm_domain.h in vga_switcheroo.c for dev_pm_domain_set()

Changes in v11:
- Move calls to dev_pm_domain_set() out from >power.lock as that
  isn't needed for dev->pm_domain.

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  device_is_bound()
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()
- Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
- Rename from device_check_pm_callbacks to device_pm_check_callbacks to
  follow with the naming convention of existing API.
- Re-add calling to device_pm_check_callbacks from device registration
  and when updating the PM domain of a device.

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 -
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 21 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 24 
 drivers/base/power/domain.c   |  8 ++--
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 11 ++-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c|  8 +++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 132 insertions(+), 22 deletions(-)

-- 
2.5.0

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

[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

[Tomeu Vizoso]

Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.

This patch also changes all current code that directly sets the
dev.pm_domain pointer.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Ulf Hansson 
---

Changes in v12:
- Include linux/pm_domain.h in vga_switcheroo.c for dev_pm_domain_set()

Changes in v11:
- Move calls to dev_pm_domain_set() out from >power.lock as that
  isn't needed for dev->pm_domain.

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()

Changes in v8:
- Add dev_pm_domain_set() and update code to use it

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 -
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 21 +
 drivers/base/power/domain.c   |  6 --
 drivers/gpu/vga/vga_switcheroo.c  | 11 ++-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 include/linux/pm_domain.h |  3 +++
 10 files changed, 54 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c 
b/arch/arm/mach-omap2/omap_device.c
index 3750ed14f8c5..0437537751bc 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct platform_device 
*pdev)
r->name = dev_name(>dev);
}
 
-   pdev->dev.pm_domain = _device_pm_domain;
+   dev_pm_domain_set(>dev, _device_pm_domain);
 
if (device_active) {
omap_device_enable(pdev);
@@ -180,7 +181,7 @@ odbfd_exit1:
 odbfd_exit:
/* if data/we are at fault.. load up a fail handler */
if (ret)
-   pdev->dev.pm_domain = _device_fail_pm_domain;
+   dev_pm_domain_set(>dev, _device_fail_pm_domain);
 
return ret;
 }
@@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev)
 {
pr_debug("omap_device: %s: registering\n", pdev->name);
 
-   pdev->dev.pm_domain = _device_pm_domain;
+   dev_pm_domain_set(>dev, _device_pm_domain);
return platform_device_add(pdev);
 }
 
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 047281a6ae11..c570b1d9f094 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -875,13 +876,14 @@ static int acpi_lpss_platform_notify(struct 
notifier_block *nb,
 
switch (action) {
case BUS_NOTIFY_BIND_DRIVER:
-   pdev->dev.pm_domain = _lpss_pm_domain;
+   dev_pm_domain_set(>dev, _lpss_pm_domain);
break;
case BUS_NOTIFY_DRIVER_NOT_BOUND:
case BUS_NOTIFY_UNBOUND_DRIVER:
pdev->dev.pm_domain = NULL;
break;
case BUS_NOTIFY_ADD_DEVICE:
+   dev_pm_domain_set(>dev, _lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(>dev.kobj,
  _attr_group);
@@ -889,6 +891,7 @@ static int acpi_lpss_platform_notify(struct notifier_block 
*nb,
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->flags & LPSS_LTR)
sysfs_remove_group(>dev.kobj, _attr_group);
+   dev_pm_domain_set(>dev, NULL);
break;
default:
break;
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 08a02cdc737c..cd2c3d6d40e0 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "internal.h"
@@ -1059,7 +1060,7 @@ static void acpi_dev_pm_detach(struct device *dev, bool 
power_off)
struct acpi_device *adev = ACPI_COMPANION(dev);
 
if (adev && dev->pm_domain == _general_pm_domain) {
-   dev->pm_domain = NULL;
+   dev_pm_domain_set(dev, NULL);
acpi_remove_pm_notifier(adev);
if (power_off) {
/*
@@ -,7 +1112,7 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on)
return -EBUSY;
 
acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
-   dev->pm_domain = _general_pm_domain;
+   dev_pm_domain_set(dev, _general_pm_domain);
if (power_on) {
acpi_dev_pm_full_power(adev);
acpi_device_wakeup(adev, 

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

Re: Nokia N900: Broken lirc ir-rx51 driver

[Pali Rohár]

On Saturday 02 January 2016 09:06:57 Tony Lindgren wrote:
> Hi,
> 
> * Pali Rohár  [160102 06:46]:
> > --- a/drivers/media/rc/ir-rx51.c
> > +++ b/drivers/media/rc/ir-rx51.c
> > @@ -25,9 +25,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> > -#include 
> > -#include 
> > +#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h"
> 
> Well we don't want to export the dmtimer functions to drivers..But
> we now have the PWM driver that can be already used for most of the
> ir-rx51.c.

Ok. Is PWM driver included in mainline kernel?

> >  #include 
> >  #include 
> > @@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 
> > *lirc_rx51)
> > }
> >  
> > clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer);
> > -   lirc_rx51->fclk_khz = clk_fclk->rate / 1000;
> > +   lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000;
> >  
> > return 0;
> >  
> > 
> > So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51
> > module for Nokia N900. Do you know how to fix this driver for upstream
> > kernel? It would be great to have driver working and not to have it in
> > this dead state...
> 
> Yup please take a look at thread "[PATCH 0/3] pwm: omap: Add PWM support
> using dual-mode timers". Chances are we still need to set up the dmtimer
> code to provide also irqchip functions. That way ir-rx51.c can just do
> request_irq on the selected dmtimer for interrupts.

No I see that patch from that thread uses dmtimer.h from plat-omap. So
it is really OK?

> > Also platform data for this driver are only in legacy board code.
> > Support in DTS is missing, so driver (after fixing above problem) cannot
> > be used on DT booted kernel.
> 
> Yeah those parts should be already doable with the PWM timer code AFAIK.
> 
> Regards,
> 
> Tony
> 
> 

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

Re: Nokia N900: Adjust MPU OPP values

[Pali Rohár]

On Saturday 02 January 2016 14:38:36 Nishanth Menon wrote:
> On 01/02/2016 11:16 AM, Tony Lindgren wrote:
> > * Pali Rohár  [160102 06:31]:
> >> Hello,
> >>
> >> MPU OPP table table (omap36xx_vddcore_volt_data) defined in
> >> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
> >> dirty patch in linux-n900 tree for it, see:
> >>
> >> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c
> >>
> >> Now when doing transition to device tree, is there any way how correct
> >> MPU OOP table for Nokia N900 could be defined in DT file?
> > 
> > Hmm I'd assume we can just define this in the dts.. Nishanth, got
> > any comments on this one?
> > 
> 
> We already have definitions in dtb for omap3 OPPs. I think we should
> start using device tree as default. the oppxx_data.c is sticking around
> waiting for legacy boot to go away, then those files should be deleted.
> 

Freemangordon, maybe... would it be possible to add (now stable and
tested by lot of users) OPP table from Maemo kernel-power to DTS?

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

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

[Pali Rohár]

On Monday 04 January 2016 20:13:56 Tony Lindgren wrote:
> * Ivaylo Dimitrov  [160104 10:59]:
> > Hi,
> > 
> > On  4.01.2016 19:40, Tony Lindgren wrote:
> > >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> >  >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> >  >dmesg output?
> > 
> > Here it is, including the pre-gpmc log, keep in mind this is with restored
> > HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg output
> > from the syslog. Don't know if it is helpful :). Also, this device has
> > Numonyx onenand (HW rev. 2204), unlike most of the others which have Samsung
> > onenand (HW rev. 2101 etc), no idea if it is relevant.
> 
> Thanks. I got the problem reproduced here too.
> 
> [1.915557] gpmc cs0 after gpmc_cs_set_timings:
> [1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201
> 
> Looks like in the failing case the clock rates are not properly
> calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
> GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
> best way to fix this.
> 
> Regards,
> 
> Tony

Hm... Maybe this problem is in U-Boot too?

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

Re: [PATCH v5 0/5] Add memory mapped read support for ti-qspi

[Mark Brown]

On Tue, Jan 05, 2016 at 10:50:42AM +0530, Vignesh R wrote:
> Hi Brian,
> 
> On 12/11/2015 09:39 AM, Vignesh R wrote:
> > Changes since v4:
> > Use syscon to access system control module register in ti-qspi driver.
> > 
> 
> Gentle ping...
> Are you ok with MTD side changes of this patch series?

Please don't send content free pings and please allow a reasonable time
for review (we've just had the Christmas vacation...).


signature.asc
Description: PGP signature

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

[H. Nikolaus Schaller]

Hi,

Am 06.01.2016 um 00:40 schrieb Nishanth Menon :

> 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?

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>;

> 
>> +ti,backup-battery-chargeable;
>> +ti,backup-battery-charge-high-current;
>> +};
>> +
>>  palmas_pmic {
>>  compatible = "ti,palmas-pmic";
>>  interrupt-parent = <>;
>> 
> 
> 
> -- 
> Regards,
> Nishanth Menon


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 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár  [160105 00:50]:
> On Monday 04 January 2016 20:13:56 Tony Lindgren wrote:
> > * Ivaylo Dimitrov  [160104 10:59]:
> > > Hi,
> > > 
> > > On  4.01.2016 19:40, Tony Lindgren wrote:
> > > >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> > >  >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> > >  >dmesg output?
> > > 
> > > Here it is, including the pre-gpmc log, keep in mind this is with restored
> > > HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg 
> > > output
> > > from the syslog. Don't know if it is helpful :). Also, this device has
> > > Numonyx onenand (HW rev. 2204), unlike most of the others which have 
> > > Samsung
> > > onenand (HW rev. 2101 etc), no idea if it is relevant.
> > 
> > Thanks. I got the problem reproduced here too.
> > 
> > [1.915557] gpmc cs0 after gpmc_cs_set_timings:
> > [1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201
> > 
> > Looks like in the failing case the clock rates are not properly
> > calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
> > GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
> > best way to fix this.
> > 
> > Regards,
> > 
> > Tony
> 
> Hm... Maybe this problem is in U-Boot too?

Yeah maybe. Looks like we need sync write bit set also for async
timings for omap2_onenand_set_async_mode() to work to detect the
onenand rate for sync mode :)

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
@@ -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/5] arm: devtree: Set system_rev from DT "/revision"

[Arnd Bergmann]

On Tuesday 05 January 2016 12:37:50 Pali Rohár wrote:
> On Monday 28 December 2015 23:27:17 Arnd Bergmann wrote:
> > On Monday 28 December 2015 13:01:22 Frank Rowand wrote:
> > > 
> > > Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
> > > property.
> > > 
> > > If the use of /revision is limited to being a location to hold an ATAG
> > > value to pass to the global variable system_rev, then it would make
> > > sense to just copy directly from the ATAG value into system_rev in the
> > > same board file where you are copying the ATAGs.
> > 
> > Agreed. That would be simpler, and avoid a situation where someone relies
> > on the /revision property in DT to be set from the atags compat code
> > (preventing an upgrade to a newer bootloader), or on the system_rev variable
> > to be the same across multiple boot loaders, in the absence of other
> > kernel code setting it.
> 
> So, set system_rev only for Nokia N900? At same place where is called
> save_atags()?
> 
> 

Yes.

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

Re: [PATCH] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver

[Pali Rohár]

On Thursday 31 December 2015 09:38:45 Eduardo Valentin wrote:
> > +
> > +   bandgap {
> > +   reg = <0x48002524 0x4>;
> > +   compatible = "ti,omap36xx-bandgap";
> 
> Can you please already add on both cases
> 
> #thermal-sensor-cells = <0>;
> ?
> 
> This way we can already use them to define thermal zones. Of course,
> that alone won't add the thermal zones. A separated patch would be
> needed to add the thermal zone for OMAP3.

Are you going to add thermal zone defines? If yes, then it would make
sense to add that #thermal line together with thermal zone defines...

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

Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

[Pali Rohár]

On Monday 28 December 2015 23:27:17 Arnd Bergmann wrote:
> On Monday 28 December 2015 13:01:22 Frank Rowand wrote:
> > 
> > Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
> > property.
> > 
> > If the use of /revision is limited to being a location to hold an ATAG
> > value to pass to the global variable system_rev, then it would make
> > sense to just copy directly from the ATAG value into system_rev in the
> > same board file where you are copying the ATAGs.
> 
> Agreed. That would be simpler, and avoid a situation where someone relies
> on the /revision property in DT to be set from the atags compat code
> (preventing an upgrade to a newer bootloader), or on the system_rev variable
> to be the same across multiple boot loaders, in the absence of other
> kernel code setting it.

So, set system_rev only for Nokia N900? At same place where is called
save_atags()?

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

[PATCH 3/3] ARM: dts: twl6030: add gpadc

[H. Nikolaus Schaller]

tested on Pandaboard ES.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 55eb35f..98e444d 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -99,4 +99,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+   adc {
+   compatible = "ti,twl6030-gpadc";
+   interrupts = <3>;
+   #io-channel-cells = <1>;
+   };
 };
-- 
2.5.1

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

[PATCH 0/3] Enable twl603x-GPADC for some OMAP4/OMAP5 boards and Palmas-RTC for OMAP5

[H. Nikolaus Schaller]

This patch series adds DT nodes for:

twl6030-gpadc for omap4 based boards (Pandaboard ES)
twl6037-gpadc for omap5 based boards (OMAP5 EVM)
twl6037-rtc for omap5 based boards (OMAP5 EVM)


H. Nikolaus Schaller (3):
  ARM: dts: omap5-board-common: enable rtc and charging of backup
battery
  ARM: dts: omap5-board-common: enable iio gpadc for Palmas
  ARM: dts: twl6030: add gpadc

 arch/arm/boot/dts/omap5-board-common.dtsi | 18 ++
 arch/arm/boot/dts/twl6030.dtsi|  6 ++
 2 files changed, 24 insertions(+)

-- 
2.5.1

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

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

[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?

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: Nokia N900: Broken lirc ir-rx51 driver

[Tony Lindgren]

* Pali Rohár  [160105 02:19]:
> On Saturday 02 January 2016 09:06:57 Tony Lindgren wrote:
> >
> > Yup please take a look at thread "[PATCH 0/3] pwm: omap: Add PWM support
> > using dual-mode timers". Chances are we still need to set up the dmtimer
> > code to provide also irqchip functions. That way ir-rx51.c can just do
> > request_irq on the selected dmtimer for interrupts.
> 
> No I see that patch from that thread uses dmtimer.h from plat-omap. So
> it is really OK?

It's using the header to populate the platform data in mach-omap2 so
that's fine. But we do not want to directly expose the dmtimer functions
to device drivers as they are not Linux generic at this point.

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 v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

[dbasehore .]

On Tue, Jan 5, 2016 at 4:48 AM, Rafael J. Wysocki  wrote:
> On Monday, January 04, 2016 06:27:18 PM Derek Basehore wrote:
>> On Mon, Nov 02, 2015 at 02:50:40AM +0100, Rafael J. Wysocki wrote:
>> >
>> > I've queued up this series for the second half of the v4.4 merge window.
>> >
>> > Thanks,
>> > Rafael
>> >
>> >
>> > ___
>> > linux-arm-kernel mailing list
>> > linux-arm-ker...@lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>> What's the status of this patch series? I haven't seen the patches
>> posted for v4.4, plus there's the issue that Dan found that needs to be
>> addressed.
>>
>> Is there a new revision of the patch series being worked on?
>
> Tomeu is not working on one AFAICS, but I may just revive his series.
>
> Do you have a pointer to the Dan's report?
>
> Thanks,
> Rafael
>

It was a reply to the second patch in the series. Here's a link to it
https://lkml.org/lkml/2015/11/10/107
--
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/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?

> + ti,backup-battery-chargeable;
> + ti,backup-battery-charge-high-current;
> + };
> +
>   palmas_pmic {
>   compatible = "ti,palmas-pmic";
>   interrupt-parent = <>;
> 


-- 
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 v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Rafael J. Wysocki]

On Monday, January 04, 2016 06:27:18 PM Derek Basehore wrote:
> On Mon, Nov 02, 2015 at 02:50:40AM +0100, Rafael J. Wysocki wrote:
> > 
> > I've queued up this series for the second half of the v4.4 merge window.
> > 
> > Thanks,
> > Rafael
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> What's the status of this patch series? I haven't seen the patches
> posted for v4.4, plus there's the issue that Dan found that needs to be
> addressed.
> 
> Is there a new revision of the patch series being worked on?

Tomeu is not working on one AFAICS, but I may just revive his series.

Do you have a pointer to the Dan's report?

Thanks,
Rafael

--
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] ARM: dts: omap5-board-common: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

tested on OMP5432 EVM

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap5-board-common.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
b/arch/arm/boot/dts/omap5-board-common.dtsi
index 30c0d3b..56429ce 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -366,6 +366,16 @@
ti,backup-battery-charge-high-current;
};
 
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   #io-channel-cells = <1>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+
palmas_pmic {
compatible = "ti,palmas-pmic";
interrupt-parent = <>;
-- 
2.5.1

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

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

[H. Nikolaus Schaller]

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>;
+   ti,backup-battery-chargeable;
+   ti,backup-battery-charge-high-current;
+   };
+
palmas_pmic {
compatible = "ti,palmas-pmic";
interrupt-parent = <>;
-- 
2.5.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: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tero Kristo]

On 01/04/2016 06:37 PM, Tony Lindgren wrote:

* Russell King - ARM Linux  [160104 06:43]:

On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:

On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:

FWIW, there are small loops with just a cpu_relax() in various clock drivers
under drivers/clk/shmobile/.


Just did a quick profiling round, and the clk_enable/disable delay loops
take anything from 0...1500ns, most typically consuming some 400-600ns. So,
based on this, dropping the udelay and adding cpu_relax instead looks like a
good change. I just verified that changing the udelay to cpu_relax works
fine also, I just need to change the bail-out period to be something sane.


Was that profiling done with lockdep/lock debugging enabled or disabled?


omap2plus_defconfig, so lockdep was enabled. The profiling was done 
around the while {} block though, which should not have any locks within 
it (except for the SCM clocks, which may explain some of the higher 
latency numbers seen.)



And also the thing to check from the hw folks is what all do these clkctrl
bits really control. If they group together the OCP clock and an extra
functional clock for some devices the delays could be larger.


Does it matter really? The latencies are only imposed to the device in 
question, and lets face it, the same latencies are there already with 
the hwmod implementation. This series moves the implementation under 
clock driver with as less modifications as possible to avoid any problems.



In general, I think we need to get rid of pm_runtime_irq_safe usage to
allow clocks to sleep properly. The other option is to allow toggling
pm_runtime_irq_safe but that probably gets super messy.


That is something not to be done with this set though.

-Tero
--
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  4.01.2016 19:40, Tony Lindgren wrote:

On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

> >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> >dmesg output?


Here it is, including the pre-gpmc log, keep in mind this is with 
restored HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get 
dmesg output from the syslog. Don't know if it is helpful :). Also, this 
device has Numonyx onenand (HW rev. 2204), unlike most of the others 
which have Samsung onenand (HW rev. 2101 etc), no idea if it is relevant.


Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Booting Linux on 
physical CPU 0x0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Initializing cgroup 
subsys cpu
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Linux version 
4.4.0-rc7+ (ivo@ivo-H81M-S2PV) (gcc version 4.7.2 20120701 (prerelease) 
(Linaro GCC 4.7-2012.07) ) #4 PREEMPT Mon Jan 4 20:30:31 EET 2016
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: ARMv7 Processor 
[411fc083] revision 3 (ARMv7), cr=10c5387d
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: PIPT / VIPT 
nonaliasing data cache, VIPT nonaliasing instruction cache

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Machine model: Nokia N900
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory policy: Data 
cache writeback
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] On node 0 totalpages: 
65280
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] free_area_init_node: 
node 0, pgdat c06776f8, node_mem_map cfcf9000
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 512 
pages used for memmap
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 0 pages 
reserved
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 65280 
pages, LIFO batch:15
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: All CPU(s) 
started in SVC mode.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] OMAP3430/3530 ES3.1 
(l2cache iva sgx neon isp )
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: s0 r0 
d32768 u32768 alloc=1*32768

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: [0] 0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Built 1 zonelists in 
Zone order, mobility grouping on.  Total pages: 64768
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Kernel command line: 
init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs 
rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log console=tty0 
console=ttyO2 omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] PID hash table 
entries: 1024 (order: 0, 4096 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Dentry cache hash 
table entries: 32768 (order: 5, 131072 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Inode-cache hash table 
entries: 16384 (order: 4, 65536 bytes)
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: com.nokia.phone.SIM: 
csd-libsimpb::configure: args=<(null)>
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: Succesfully loaded 
plugin 
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory: 
251588K/261120K available (4487K kernel code, 232K rwdata, 1624K rodata, 
244K init, 256K bss, 9532K reserved, 0K cma-reserved, 0K highmem)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Virtual kernel memory 
layout:
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vector  : 
0x - 0x1000   (   4 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] fixmap  : 
0xffc0 - 0xfff0   (3072 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vmalloc : 
0xd080 - 0xff80   ( 752 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] lowmem  : 
0xc000 - 0xd000   ( 256 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pkmap   : 
0xbfe0 - 0xc000   (   2 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] modules : 
0xbf00 - 0xbfe0   (  14 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .text : 
0xc0008000 - 0xc0600044   (6113 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .init : 
0xc0601000 - 0xc063e000   ( 244 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .data : 
0xc063e000 - 0xc0678240   ( 233 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00].bss : 
0xc0678240 - 0xc06b8628   ( 257 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] SLUB: HWalign=64, 
Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Preemptible 
hierarchical RCU implementation.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] ^IBuild-time 
adjustment of leaf fanout to 32.

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] NR_IRQS:16 nr_irqs:16 16
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] IRQ: Found an INTC at 
0xfa20 (revision 4.0) with 96 interrupts
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Clocking rate 
(Crystal/Core/MPU): 19.2/332/500 MHz
Jan  4 20:42:50 Nokia-N900 

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Geert Uytterhoeven]

Hi Tero,

On Mon, Jan 4, 2016 at 8:36 AM, Tero Kristo  wrote:
> On 01/01/2016 07:48 AM, Michael Turquette wrote:
>> Quoting Tero Kristo (2015-12-18 05:58:58)
>>> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
>>> +{
>>> +   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
>>> +   u32 val;
>>> +   int timeout = 0;
>>> +   int ret;
>>> +
>>> +   if (!clk->enable_bit)
>>> +   return 0;
>>> +
>>> +   if (clk->clkdm) {
>>> +   ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm,
>>> hw->clk);
>>> +   if (ret) {
>>> +   WARN(1,
>>> +"%s: could not enable %s's clockdomain %s:
>>> %d\n",
>>> +__func__, clk_hw_get_name(hw),
>>> +clk->clkdm_name, ret);
>>> +   return ret;
>>> +   }
>>> +   }
>>> +
>>> +   val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
>>> +
>>> +   val &= ~OMAP4_MODULEMODE_MASK;
>>> +   val |= clk->enable_bit;
>>> +
>>> +   ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
>>> +
>>> +   /* Wait until module is enabled */
>>> +   while (!_omap4_is_ready(val)) {
>>> +   udelay(1);
>>
>> This should really be a .prepare callback if you plan to keep the delays
>> in there.
>
> If this is changed to a .prepare, then all OMAP power management is
> effectively ruined as all clocks are going to be enabled all the time. hwmod
> core doesn't support .prepare/.enable at the moment that well, and changing
> that is going to be a big burden (educated guess, haven't checked this
> yet)... The call chain that comes here is:
>
> device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.
>
> The delay within this function should usually be pretty short, just to wait
> that the module comes up from idle.

Does it take multiple µs? Perhaps even one µs is much longer than needed?

> I recall the discussions regarding the udelays within clk_enable/disable
> calls, but what is the preferred approach then? Typically clk_enable/disable
> just becomes a NOP if it is not allowed to wait for hardware to complete
> transitioning before exiting the function.

FWIW, there are small loops with just a cpu_relax() in various clock drivers
under drivers/clk/shmobile/.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: omapfb: Add early framebuffer memory allocator

[Tomi Valkeinen]

Hi,

On 01/01/16 14:01, Pali Rohár wrote:
> Hi Tomi! Can you review this patch? It is waiting here for two years!
> 
> On Thursday 26 December 2013 00:12:39 Ivaylo Dimitrov wrote:
>> From: Ivaylo Dimitrov 
>>
>> On memory limited devices, CMA fails easily when asked to allocate
>> big chunks of memory like framebuffer memory needed for video
>> playback.
>>
>> Add boot parameter "omapfb_memsize" which allocates memory to be used
>> as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator
>> when trying to allocate memory for the framebuffers

We probably need exactly the same for omapdrm, as omapfb is on the way
to being deprecated. And sounds to me that we probably need similar for
other devices which try to do large allocations (camera? video decoders?).

So I really think this should be somehow be a general option for any device.

I also wonder if CMA can be improved to not need anything like this? If
you just increase the CMA area, won't that increase the chances CMA will
work?

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling

[Sekhar Nori]

Hi Thomas,

On Tuesday 15 December 2015 08:58 PM, Tony Lindgren wrote:
> * Sekhar Nori  [151215 06:26]:
>> Under some conditions, irq sorting procedure used
>> by INTC can go wrong resulting in a spurious irq
>> getting reported.
>>
>> If this condition is not handled, it results in
>> endless stream of:
>>
>> unexpected IRQ trap at vector 00
>>
>> messages from ack_bad_irq()
>>
>> Handle the spurious interrupt condition in omap-intc
>> driver to prevent this.
>>
>> Measurements using kernel function profiler on AM335x
>> EVM running at 720MHz show that after this patch
>> omap_intc_handle_irq() takes about 37.4us against
>> 34us before this patch.
>>
>> Signed-off-by: Sekhar Nori 
> 
> Looks good to me, probably should get tagged Cc stable when
> committing:
> 
> Acked-by: Tony Lindgren 

Can you please apply this if it looks good?

Thanks,
Sekhar
--
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: Nokia N900 - audio TPA6130A2 problems

[Pali Rohár]

On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote:
> On 08/03/2015 09:48 PM, Jarkko Nikula wrote:
> > It is well possible that some regression got introduced to
> > TPA6130A2 I2C communication over the years without nobody than you
> > now notices. We used to do QA back in Meego N900 days but that was
> > pre 3.x kernels.
> 
> No major changes has been done to the tpa driver during the past
> years... I wanted to do some updates, like moving it to regmap, but
> as you said, n900 is the only user (and n9) and I do not feel
> comfortable to hack on a device where I do not have serial
> console... And I'm using the n900 time to time also.
> 
> >> So maybe something similar? Kernel expects that some PM or
> >> regulator parts are initialized, but they are only sometimes?
> >> Just speculation...
> > 
> > I'm thinking the same. I could figure SCL could be stuck low if TPA
> > or some other chip connected to the same I2C bus is without power
> > and is pulling I2C signals down.
> 
> What would happen with the SCL stuck on i2c.2 bus if you remove the
> tpa driver from the kernel? If you remove the other drivers for the
> devices on i2c.2?

Hi Peter and Jarkko! Do you have some code samples for testing? Or 
something else which I can test? This problem is still reproducible on 
more N900 devices and I would like to see it fixed.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Michael Turquette]

Quoting Tero Kristo (2016-01-04 11:15:36)
> On 01/04/2016 06:37 PM, Tony Lindgren wrote:
> > * Russell King - ARM Linux  [160104 06:43]:
> >> On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:
> >>> On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:
>  FWIW, there are small loops with just a cpu_relax() in various clock 
>  drivers
>  under drivers/clk/shmobile/.
> >>>
> >>> Just did a quick profiling round, and the clk_enable/disable delay loops
> >>> take anything from 0...1500ns, most typically consuming some 400-600ns. 
> >>> So,
> >>> based on this, dropping the udelay and adding cpu_relax instead looks 
> >>> like a
> >>> good change. I just verified that changing the udelay to cpu_relax works
> >>> fine also, I just need to change the bail-out period to be something sane.
> >>
> >> Was that profiling done with lockdep/lock debugging enabled or disabled?
> 
> omap2plus_defconfig, so lockdep was enabled. The profiling was done 
> around the while {} block though, which should not have any locks within 
> it (except for the SCM clocks, which may explain some of the higher 
> latency numbers seen.)
> 
> > And also the thing to check from the hw folks is what all do these clkctrl
> > bits really control. If they group together the OCP clock and an extra
> > functional clock for some devices the delays could be larger.
> 
> Does it matter really? The latencies are only imposed to the device in 
> question, and lets face it, the same latencies are there already with 
> the hwmod implementation. This series moves the implementation under 
> clock driver with as less modifications as possible to avoid any problems.

So long as we can all convince ourselves that the flaw is not a flaw
then I'm OK with it. No bugs were ever introduced that way ;-)

But in fairness, we've had these delays in the .enable callbacks for a
while, so this patch does not introduce the regression. Furthermore it
does clean up some code that needs more work, and I don't want to delay
that.

I won't NACK the patch due to the delays, but it would be nice to
revisit it some day.

Regards,
Mike

> 
> > In general, I think we need to get rid of pm_runtime_irq_safe usage to
> > allow clocks to sleep properly. The other option is to allow toggling
> > pm_runtime_irq_safe but that probably gets super messy.
> 
> That is something not to be done with this set though.
> 
> -Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Derek Basehore]

On Mon, Nov 02, 2015 at 02:50:40AM +0100, Rafael J. Wysocki wrote:
> 
> I've queued up this series for the second half of the v4.4 merge window.
> 
> Thanks,
> Rafael
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

What's the status of this patch series? I haven't seen the patches
posted for v4.4, plus there's the issue that Dan found that needs to be
addressed.

Is there a new revision of the patch series being worked on?
--
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  [160104 10:59]:
> Hi,
> 
> On  4.01.2016 19:40, Tony Lindgren wrote:
> >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
>  >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
>  >dmesg output?
> 
> Here it is, including the pre-gpmc log, keep in mind this is with restored
> HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg output
> from the syslog. Don't know if it is helpful :). Also, this device has
> Numonyx onenand (HW rev. 2204), unlike most of the others which have Samsung
> onenand (HW rev. 2101 etc), no idea if it is relevant.

Thanks. I got the problem reproduced here too.

[1.915557] gpmc cs0 after gpmc_cs_set_timings:
[1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201

Looks like in the failing case the clock rates are not properly
calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
best way to fix this.

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: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Michael Turquette]

Quoting Tero Kristo (2016-01-03 23:36:05)
> On 01/01/2016 07:48 AM, Michael Turquette wrote:
> > Hi Tero,
> >
> > Quoting Tero Kristo (2015-12-18 05:58:58)
> >> Previously, hwmod core has been used for controlling the hwmod level
> >> clocks. This has certain drawbacks, like being unable to share the
> >> clocks for multiple users, missing usecounting and generally being
> >> totally incompatible with common clock framework.
> >>
> >> Add support for new clock type under the TI clock driver, which will
> >> be used to convert all the existing hwmdo clocks to. This helps to
> >> get rid of the clock related hwmod data from kernel and instead
> >> parsing this from DT.
> >
> > I'm really happy to see this series. Looks pretty good to me.
> >
> >> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
> >> +{
> >> +   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
> >> +   u32 val;
> >> +   int timeout = 0;
> >> +   int ret;
> >> +
> >> +   if (!clk->enable_bit)
> >> +   return 0;
> >> +
> >> +   if (clk->clkdm) {
> >> +   ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw->clk);
> >> +   if (ret) {
> >> +   WARN(1,
> >> +"%s: could not enable %s's clockdomain %s: 
> >> %d\n",
> >> +__func__, clk_hw_get_name(hw),
> >> +clk->clkdm_name, ret);
> >> +   return ret;
> >> +   }
> >> +   }
> >> +
> >> +   val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
> >> +
> >> +   val &= ~OMAP4_MODULEMODE_MASK;
> >> +   val |= clk->enable_bit;
> >> +
> >> +   ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
> >> +
> >> +   /* Wait until module is enabled */
> >> +   while (!_omap4_is_ready(val)) {
> >> +   udelay(1);
> >
> > This should really be a .prepare callback if you plan to keep the delays
> > in there.
> 
> If this is changed to a .prepare, then all OMAP power management is 
> effectively ruined as all clocks are going to be enabled all the time. 

Let's not ruin system PM.

> hwmod core doesn't support .prepare/.enable at the moment that well, and 
> changing that is going to be a big burden (educated guess, haven't 
> checked this yet)... The call chain that comes here is:
> 
> device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.

Right, and for calls to pm_runtime_get/put from process context it
should result in a call to clk_prepare_enable/clk_disable_unprepare. I
guess that change is hugely invasive from your statements above?

> 
> The delay within this function should usually be pretty short, just to 
> wait that the module comes up from idle.
> 
> I recall the discussions regarding the udelays within clk_enable/disable 
> calls, but what is the preferred approach then?

There are many cases where a clk only provides .{un}prepare ops and does
NOT provide any .{en,dis}able ops.

> Typically 
> clk_enable/disable just becomes a NOP

Yes, it becomes a NOP (though it is critical that drivers with knowledge
of this do not try to skip the step of calling clk_enable).

> if it is not allowed to wait for 
> hardware to complete transitioning before exiting the function.

The clk.h api clearly states that clk_prepare must be called and
complete before calling clk_enable. So if a clk only provides a .prepare
with delays but no .enable, and a consumer driver complies with that api
rule then we're guaranteed to have a toggling line when clk_enable
returns.

Regards,
Mike

> 
> -Tero
> 
> >
> > Regards,
> > Mike
> >
> 
--
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: omapfb: Add early framebuffer memory allocator

[Ivaylo Dimitrov]

Hi Tomi,

On  4.01.2016 13:37, Tomi Valkeinen wrote:


We probably need exactly the same for omapdrm, as omapfb is on the way
to being deprecated. And sounds to me that we probably need similar for
other devices which try to do large allocations (camera? video decoders?).



Re omapdrm - I guess it wouldn't be hard for omapdrm to use the same 
preallocated memory, when/if it is needed. Though I know nothing about 
omapdrm, so can't really tell.


If not mistaken, camera driver uses sg lists. DSP needs such a memory, 
but anyway it(driver) was removed from mainline, with no signs/hope to 
be returned anytime soon.



So I really think this should be somehow be a general option for any device.



Then maybe add the relevant people in CC, so we to start some kind of 
discussion. But until such a general option exists, I think it makes 
sense to apply the $subject patch, we can easily fix it to use whatever 
general purpose API might the discussion come up with. As it is now, 
omapfb simply cannot be used to play any video with sane resolution 
(without preallocated memory that is), unless this is the only thing the 
device does. And even then it is not assured.



I also wonder if CMA can be improved to not need anything like this? If
you just increase the CMA area, won't that increase the chances CMA will
work?



The short answer is no, at least not with the CMA code currently 
upstream. A kind of a long answer could be found on 
http://marc.info/?l=linux-mm=141571797202006=2


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: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tero Kristo]

On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:

Hi Tero,

On Mon, Jan 4, 2016 at 8:36 AM, Tero Kristo  wrote:

On 01/01/2016 07:48 AM, Michael Turquette wrote:

Quoting Tero Kristo (2015-12-18 05:58:58)

+static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
+{
+   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+   u32 val;
+   int timeout = 0;
+   int ret;
+
+   if (!clk->enable_bit)
+   return 0;
+
+   if (clk->clkdm) {
+   ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm,
hw->clk);
+   if (ret) {
+   WARN(1,
+"%s: could not enable %s's clockdomain %s:
%d\n",
+__func__, clk_hw_get_name(hw),
+clk->clkdm_name, ret);
+   return ret;
+   }
+   }
+
+   val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
+
+   val &= ~OMAP4_MODULEMODE_MASK;
+   val |= clk->enable_bit;
+
+   ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
+
+   /* Wait until module is enabled */
+   while (!_omap4_is_ready(val)) {
+   udelay(1);


This should really be a .prepare callback if you plan to keep the delays
in there.


If this is changed to a .prepare, then all OMAP power management is
effectively ruined as all clocks are going to be enabled all the time. hwmod
core doesn't support .prepare/.enable at the moment that well, and changing
that is going to be a big burden (educated guess, haven't checked this
yet)... The call chain that comes here is:

device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.

The delay within this function should usually be pretty short, just to wait
that the module comes up from idle.


Does it take multiple µs? Perhaps even one µs is much longer than needed?


I recall the discussions regarding the udelays within clk_enable/disable
calls, but what is the preferred approach then? Typically clk_enable/disable
just becomes a NOP if it is not allowed to wait for hardware to complete
transitioning before exiting the function.


FWIW, there are small loops with just a cpu_relax() in various clock drivers
under drivers/clk/shmobile/.


Just did a quick profiling round, and the clk_enable/disable delay loops 
take anything from 0...1500ns, most typically consuming some 400-600ns. 
So, based on this, dropping the udelay and adding cpu_relax instead 
looks like a good change. I just verified that changing the udelay to 
cpu_relax works fine also, I just need to change the bail-out period to 
be something sane.


-Tero





Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds



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

Re: [PATCH v5 0/5] Add memory mapped read support for ti-qspi

[Vignesh R]

Hi Brian,

On 12/11/2015 09:39 AM, Vignesh R wrote:
> Changes since v4:
> Use syscon to access system control module register in ti-qspi driver.
> 

Gentle ping...
Are you ok with MTD side changes of this patch series?

> Changes since v3:
> Rework to introduce spi_flash_read_message struct.
> Support different opcode/addr/data formats as per Brian's suggestion
> here: https://lkml.org/lkml/2015/11/11/454
> 
> Changes since v2:
> Remove mmap_lock_mutex.
> Optimize enable/disable of mmap mode.
> 
> Changes since v1:
> Introduce API in SPI core that MTD flash driver can call for mmap read
> instead of directly calling spi-master driver callback. This API makes
> sure that SPI core msg queue is locked during mmap transfers.
> v1: https://lkml.org/lkml/2015/9/4/103
> 
> 
> Cover letter:
> 
> This patch series adds support for memory mapped read port of ti-qspi.
> ti-qspi has a special memory mapped port through which SPI flash
> memories can be accessed directly via SoC specific memory region.
> 
> First patch adds a method to pass flash specific information like read
> opcode, dummy bytes etc and to request mmap read. Second patch
> implements mmap read method in ti-qspi driver. Patch 3 adapts m25p80 to
> use mmap read method before trying normal SPI transfer. Patch 4 and 5
> add memory map region DT entries for DRA7xx and AM43xx SoCs.
> 
> This patch series is based on the discussions here:
> http://www.spinics.net/lists/linux-spi/msg04796.html
> 
> Tested on DRA74 EVM and AM437x-SK.
> Read performance increases from ~100kB/s to ~2.5MB/s.
> 
> Vignesh R (5):
>   spi: introduce accelerated read support for spi flash devices
>   spi: spi-ti-qspi: add mmap mode read support
>   mtd: devices: m25p80: add support for mmap read request
>   ARM: dts: DRA7: add entry for qspi mmap region
>   ARM: dts: AM4372: add entry for qspi mmap region
> 
>  Documentation/devicetree/bindings/spi/ti_qspi.txt |  22 +++-
>  arch/arm/boot/dts/am4372.dtsi |   4 +-
>  arch/arm/boot/dts/dra7.dtsi   |   6 +-
>  drivers/mtd/devices/m25p80.c  |  20 
>  drivers/spi/spi-ti-qspi.c | 139 
> +-
>  drivers/spi/spi.c |  45 +++
>  include/linux/spi/spi.h   |  41 +++
>  7 files changed, 243 insertions(+), 34 deletions(-)
> 

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

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Russell King - ARM Linux]

On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:
> On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:
> >FWIW, there are small loops with just a cpu_relax() in various clock drivers
> >under drivers/clk/shmobile/.
> 
> Just did a quick profiling round, and the clk_enable/disable delay loops
> take anything from 0...1500ns, most typically consuming some 400-600ns. So,
> based on this, dropping the udelay and adding cpu_relax instead looks like a
> good change. I just verified that changing the udelay to cpu_relax works
> fine also, I just need to change the bail-out period to be something sane.

Was that profiling done with lockdep/lock debugging enabled or disabled?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tony Lindgren]

* Russell King - ARM Linux  [160104 06:43]:
> On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:
> > On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:
> > >FWIW, there are small loops with just a cpu_relax() in various clock 
> > >drivers
> > >under drivers/clk/shmobile/.
> > 
> > Just did a quick profiling round, and the clk_enable/disable delay loops
> > take anything from 0...1500ns, most typically consuming some 400-600ns. So,
> > based on this, dropping the udelay and adding cpu_relax instead looks like a
> > good change. I just verified that changing the udelay to cpu_relax works
> > fine also, I just need to change the bail-out period to be something sane.
> 
> Was that profiling done with lockdep/lock debugging enabled or disabled?

And also the thing to check from the hw folks is what all do these clkctrl
bits really control. If they group together the OCP clock and an extra
functional clock for some devices the delays could be larger.

In general, I think we need to get rid of pm_runtime_irq_safe usage to
allow clocks to sleep properly. The other option is to allow toggling
pm_runtime_irq_safe but that probably gets super messy.

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

[Tony Lindgren]

* Pali Rohár  [160104 09:35]:
> On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> > Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> > dmesg output?
> 
> Hi Tony. We do not have serial console for N900 and so when kernel is 
> not fully bootable to userspace we cannot provide dmesg for you :-(

OK

> Maybe something with simple initramfs could work, but really if you have 
> serial console for N900 it should be for you lot of easier to get it.

Yeah OK will take a look ASAP. Is this happening with both legacy
booting and dts based booting?

For testing, CONFIG_INITRAMFS_SOURCE etc allow building initramfs
that's appended to the kernel.

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

[Pali Rohár]

On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> dmesg output?

Hi Tony. We do not have serial console for N900 and so when kernel is 
not fully bootable to userspace we cannot provide dmesg for you :-(

Maybe something with simple initramfs could work, but really if you have 
serial console for N900 it should be for you lot of easier to get it.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: Nokia N900: twl4030-power different data in DTS and board code

[Tony Lindgren]

* Pali Rohár  [160102 13:39]:
> On Saturday 02 January 2016 18:14:31 Tony Lindgren wrote:
> 
> > The n900 specific code was based on something before the TI generic
> > values were available I think. And the last time I looked at it I
> > came to the conclusion the n900 specific code is no better.
> 
> Hm... if generic values are better, why old values are still there (in 
> board n900 code)?

We never had PM working in a generic way for the legacy booting but
relied on board specific configuration instead for the ones that did
work. Probably not worth changing the board-*.c file configuration
unless you want to test that the new generic settings work.

> > Or did I miss something? Are you seeing some issues with PM with dts
> > based code?
> 
> I'm just asking why we have different code for DST and board...

OK. Yeah no reason beyond somebody taking the time to verify that the
generic settings work on n900 in legacy booting mode :)

> > We can certainly add it to twl4030-power if it provides something
> > that the "ti,twl4030-power-idle-osc-off" does not.
> 
> But do we need 'compatible = "ti,twl4030-power-n900"' specification in 
> omap3-n900.dts file at all?

Well that generally done to allow adding support for the board specific
configuration if needed with a fallback to the generic configuration.
That's used quite a bit, for example boards typically set the compatible
to the specific board but still end up booting with a generic one
sucha as "ti,omap3".

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

[Tony Lindgren]

* Ivaylo Dimitrov  [160101 03:29]:
> Hi Tony,
> 
> On 21.05.2015 00:21, Tony Lindgren wrote:
> >We support decoding the bootloader values if DEBUG is defined.
> >But we also need to change the struct omap_hwmod flags to have
> >HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
> >boot. Otherwise just the default timings will be displayed
> >instead of the bootloader configured timings.
> >
> >This also allows us to clean up the various GPMC related
> >hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
> >and HWMOD_INIT_NO_IDLE is not needed.
> >
> >Cc: Brian Hutchinson 
> >Cc: Paul Walmsley 
> >Cc: Roger Quadros 
> >Signed-off-by: Tony Lindgren 
> >---
> >  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
> >  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
> >  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
> >  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
> >  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
> >  drivers/memory/Kconfig  |  8 
> >  drivers/memory/omap-gpmc.c  |  6 +++---
> >  9 files changed, 29 insertions(+), 35 deletions(-)
> >
> 
> 1. Happy new year :)

Same to you :)

> 2. It was a while I tested upstream on N900 but I had some spare time during
> the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To my
> surprise, after that try, Maemo 5 rootfs, which is located on onenand became
> irreversibly corrupted. I bisected the tree to the $subject commit and after
> restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod flags, the problem was
> solved. It seems that GPMC is either incorrectly or incompletely setup by
> the kernel, leading to failed onenand reads/writes and whatnot.
> Unfortunately, what I have here is a release device, so I am unable to
> capture any logs through the serial port. BTW keep in mind that rootfs
> corruption happens as soon as a boot is attempted, even after a freshly
> flashed rootfs.

Oh crap, sorry to hear that :(

Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related dmesg
output? The dmesg timings with CONFIG_OMAP_GPMC_DEBUG enabled should be
compared against omap3-n900.dts gpmc timings. And if you don't see the whole
dmesg after booting, you may need to also increase CONFIG_LOG_BUF_SHIFT.
Meanwhile, I'll try to also produce it here.

Chances are we have bad or incomplete timings in the n900 :(

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: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tero Kristo]

On 01/01/2016 07:48 AM, Michael Turquette wrote:

Hi Tero,

Quoting Tero Kristo (2015-12-18 05:58:58)

Previously, hwmod core has been used for controlling the hwmod level
clocks. This has certain drawbacks, like being unable to share the
clocks for multiple users, missing usecounting and generally being
totally incompatible with common clock framework.

Add support for new clock type under the TI clock driver, which will
be used to convert all the existing hwmdo clocks to. This helps to
get rid of the clock related hwmod data from kernel and instead
parsing this from DT.


I'm really happy to see this series. Looks pretty good to me.


+static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
+{
+   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+   u32 val;
+   int timeout = 0;
+   int ret;
+
+   if (!clk->enable_bit)
+   return 0;
+
+   if (clk->clkdm) {
+   ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw->clk);
+   if (ret) {
+   WARN(1,
+"%s: could not enable %s's clockdomain %s: %d\n",
+__func__, clk_hw_get_name(hw),
+clk->clkdm_name, ret);
+   return ret;
+   }
+   }
+
+   val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
+
+   val &= ~OMAP4_MODULEMODE_MASK;
+   val |= clk->enable_bit;
+
+   ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
+
+   /* Wait until module is enabled */
+   while (!_omap4_is_ready(val)) {
+   udelay(1);


This should really be a .prepare callback if you plan to keep the delays
in there.


If this is changed to a .prepare, then all OMAP power management is 
effectively ruined as all clocks are going to be enabled all the time. 
hwmod core doesn't support .prepare/.enable at the moment that well, and 
changing that is going to be a big burden (educated guess, haven't 
checked this yet)... The call chain that comes here is:


device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.

The delay within this function should usually be pretty short, just to 
wait that the module comes up from idle.


I recall the discussions regarding the udelays within clk_enable/disable 
calls, but what is the preferred approach then? Typically 
clk_enable/disable just becomes a NOP if it is not allowed to wait for 
hardware to complete transitioning before exiting the function.


-Tero



Regards,
Mike



--
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 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Le jeudi 31 décembre 2015 à 22:14 +, Mark Brown a écrit :
> On Thu, Dec 31, 2015 at 10:59:06PM +0100, Paul Kocialkowski wrote:
> 
> > I understand, thanks for pointing this out. Well, for my use case, there
> > is no use in disabling the chip at any point as it powers the external
> > mmc.
> 
> Presumably someone might decide not to use the MMC in some case (perhaps
> only mounting it when explicitly needed in order to save power for
> example, or the MMC subsystem might figure out a way to power down an
> idle MMC block device).

Makes sense, I'll keep that in mind.

> > Would you agree to have the enable pin handled directly (and by that, I
> > mean enabled once, when requested, as I first suggested in the patchset)
> > in the driver then?
> 
> That's probably fine, or do it via runtime PM (the framework is fairly
> simple to use, I'll probably go add support in the core for it in the
> next day or two as this seems like a sensible use case).  I can't
> remember if this device is a MFD or not and I'm just on my way out the
> door.

Runtime PM seems like a good fit (though I hadn't heard about it before:
you can guess I'm fairly new to kernel development), please let me know
whether you end up implementing it so I can try to handle the GPIO this
way.

Thanks!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



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

Nokia N900: twl4030-power different data in DTS and board code

[Pali Rohár]

Hello,

now I'm looking at differences between legacy board code and DTS file
for Nokia N900 and I see some inconsistency for twl4030-power driver.

In board code are defined more twl4030 power scripts which override
defaults defined in twl4030-power code. See:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51-peripherals.c#n790

Next in DTS file is defined just "compatible" keyword, but no custom
scripts, see:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts#n416

And the last in DTS file is defined line:

compatible = "ti,twl4030-power-n900" 

which is not in twl4030-power driver itself, see:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/twl4030-power.c#n851

So all this stuff looks like some errors when board code was ported to
DTS. Tony, can you look at this at all?

-- 
Pali Rohár
pali.ro...@gmail.com


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

Nokia N900: Adjust MPU OPP values

[Pali Rohár]

Hello,

MPU OPP table table (omap36xx_vddcore_volt_data) defined in
opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
dirty patch in linux-n900 tree for it, see:

https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c

Now when doing transition to device tree, is there any way how correct
MPU OOP table for Nokia N900 could be defined in DT file?

-- 
Pali Rohár
pali.ro...@gmail.com


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

Nokia N900: Broken lirc ir-rx51 driver

[Pali Rohár]

Hello,

due to this commit (ARM: OMAP2+: Disable code that currently does not
work with multiplaform)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/media/rc/Kconfig?id=a62a6e98c370ccca37d353a5f763b532411a4c14

lirc driver for Nokia N900 (ir-rx51) cannot be enabled via make
menuconfig. It is because Nokia N900 support cannot be compiled without
ARCH_MULTIPLATFORM, but Nokia N900 lirc driver (IR_RX51) cannot be
compiled when ARCH_MULTIPLATFORM is enabled.

Because ir-rx51 driver is just for Nokia N900 it is nonsense to have
such condition because nobody can use ir-rx51 driver... It is even not
possible to enable compilation for it...

Here is simple patch which enable compilation for Nokia N900 and fix
compile errors:

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index b6e1311..f70d4c7 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -335,7 +335,7 @@ config IR_TTUSBIR
 
 config IR_RX51
tristate "Nokia N900 IR transmitter diode"
-   depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC && 
!ARCH_MULTIPLATFORM
+   depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC
---help---
   Say Y or M here if you want to enable support for the IR
   transmitter diode built in the Nokia N900 (RX51) device.
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index b1e19a2..be29bd0 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -25,9 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
-#include 
+#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h"
 
 #include 
 #include 
@@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 *lirc_rx51)
}
 
clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer);
-   lirc_rx51->fclk_khz = clk_fclk->rate / 1000;
+   lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000;
 
return 0;
 

So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51
module for Nokia N900. Do you know how to fix this driver for upstream
kernel? It would be great to have driver working and not to have it in
this dead state...

Also platform data for this driver are only in legacy board code.
Support in DTS is missing, so driver (after fixing above problem) cannot
be used on DT booted kernel.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Nokia N900: Proper C-states

[Pali Rohár]

Hello,

due to this Daniel Lezcano commit (ARM: OMAP3: cpuidle - remove rx51
cpuidle parameters table)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc

we need patch cpuidle34xx.c code to fix commit for Nokia N900. See:

https://github.com/pali/linux-n900/commit/e147fd4b678f1f3d7a5235287910960bd41e04dc

As Nokia N900 code is converting from legacy board code to DST, I would
like to know how to patch correctly omap3_idle_driver in DTS with
correct values measured for Nokia N900. Thanks!

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: Nokia N900: Adjust MPU OPP values

[Tony Lindgren]

* Pali Rohár  [160102 06:31]:
> Hello,
> 
> MPU OPP table table (omap36xx_vddcore_volt_data) defined in
> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
> dirty patch in linux-n900 tree for it, see:
> 
> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c
> 
> Now when doing transition to device tree, is there any way how correct
> MPU OOP table for Nokia N900 could be defined in DT file?

Hmm I'd assume we can just define this in the dts.. Nishanth, got
any comments on this one?

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: Nokia N900: Broken lirc ir-rx51 driver

[Tony Lindgren]

Hi,

* Pali Rohár  [160102 06:46]:
> --- a/drivers/media/rc/ir-rx51.c
> +++ b/drivers/media/rc/ir-rx51.c
> @@ -25,9 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -#include 
> -#include 
> +#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h"

Well we don't want to export the dmtimer functions to drivers..But
we now have the PWM driver that can be already used for most of the
ir-rx51.c.

>  #include 
>  #include 
> @@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 
> *lirc_rx51)
>   }
>  
>   clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer);
> - lirc_rx51->fclk_khz = clk_fclk->rate / 1000;
> + lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000;
>  
>   return 0;
>  
> 
> So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51
> module for Nokia N900. Do you know how to fix this driver for upstream
> kernel? It would be great to have driver working and not to have it in
> this dead state...

Yup please take a look at thread "[PATCH 0/3] pwm: omap: Add PWM support
using dual-mode timers". Chances are we still need to set up the dmtimer
code to provide also irqchip functions. That way ir-rx51.c can just do
request_irq on the selected dmtimer for interrupts.

> Also platform data for this driver are only in legacy board code.
> Support in DTS is missing, so driver (after fixing above problem) cannot
> be used on DT booted kernel.

Yeah those parts should be already doable with the PWM timer code AFAIK.

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/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Pali Rohár]

On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote:
> > > On Monday 28 December 2015 15:28:48 Pali Rohár wrote:
> > > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> > > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > > > > > * Arnd Bergmann  [150515 14:26]:
> > > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > > > > > If setting up the generic binding is expected to take a
> > > > > > > > while, you can naturally pass it in pdata while waiting
> > > > > > > > for the generic binding to get merged.
> > > > > > > 
> > > > > > > Yes, good idea. So the n900 machine can use auxdata to
> > > > > > > pass this for the time being, while the binding and
> > > > > > > generic implementation is being worked out.
> > > > > > 
> > > > > > Ok, so what is needed to finish this patch series?
> > > > > 
> > > > > I don't know where we are at this point. Has either the
> > > > > auxdata approach or the generic binding been worked on at
> > > > > all?
> > > > 
> > > > What are auxdata data?
> > > 
> > > I mean you can add the platform data to the omap_auxdata_lookup[]
> > > table for this board.
> > 
> > But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]?
> 
> Yes.
> 
>   Arnd

Hm... looks like it is not possible. omap_hsmmc driver ignores any 
supplied platform data if there are device tree data. So array 
omap_auxdata_lookup[] does not help.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: Nokia N900: twl4030-power different data in DTS and board code

[Tony Lindgren]

* Pali Rohár  [160102 06:14]:
> Hello,
> 
> now I'm looking at differences between legacy board code and DTS file
> for Nokia N900 and I see some inconsistency for twl4030-power driver.
> 
> In board code are defined more twl4030 power scripts which override
> defaults defined in twl4030-power code. See:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51-peripherals.c#n790
> 
> Next in DTS file is defined just "compatible" keyword, but no custom
> scripts, see:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts#n416
> 
> And the last in DTS file is defined line:
> 
> compatible = "ti,twl4030-power-n900" 
> 
> which is not in twl4030-power driver itself, see:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/twl4030-power.c#n851
> 
> So all this stuff looks like some errors when board code was ported to
> DTS. Tony, can you look at this at all?

AFAIK it should work fine with the generic "ti,twl4030-power-idle-osc-off".
This means reboot works and regulators are cut off during off mode.

The n900 specific code was based on something before the TI generic values
were available I think. And the last time I looked at it I came to the
conclusion the n900 specific code is no better.

Or did I miss something? Are you seeing some issues with PM with dts based
code?

We can certainly add it to twl4030-power if it provides something that
the "ti,twl4030-power-idle-osc-off" does not.

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/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Saturday 02 January 2016 16:22:03 Pali Rohár wrote:
> On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> > On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > > > 
> > > > I mean you can add the platform data to the omap_auxdata_lookup[]
> > > > table for this board.
> > > 
> > > But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]?
> > 
> Hm... looks like it is not possible. omap_hsmmc driver ignores any 
> supplied platform data if there are device tree data. So array 
> omap_auxdata_lookup[] does not help.

Obviously you need to the driver to work with that setting. Maybe
something as simple as

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e06b1881b6a1..4fa35fc84b8b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2006,7 +2006,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
void __iomem *base;
 
match = of_match_device(of_match_ptr(omap_mmc_of_match), >dev);
-   if (match) {
+   if (!pdata && match) {
pdata = of_get_hsmmc_pdata(>dev);
 
if (IS_ERR(pdata))


Arnd
--
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: Nokia N900: Adjust MPU OPP values

[Nishanth Menon]

On 01/02/2016 11:16 AM, Tony Lindgren wrote:
> * Pali Rohár  [160102 06:31]:
>> Hello,
>>
>> MPU OPP table table (omap36xx_vddcore_volt_data) defined in
>> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
>> dirty patch in linux-n900 tree for it, see:
>>
>> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c
>>
>> Now when doing transition to device tree, is there any way how correct
>> MPU OOP table for Nokia N900 could be defined in DT file?
> 
> Hmm I'd assume we can just define this in the dts.. Nishanth, got
> any comments on this one?
> 

We already have definitions in dtb for omap3 OPPs. I think we should
start using device tree as default. the oppxx_data.c is sticking around
waiting for legacy boot to go away, then those files should be deleted.


-- 
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: Nokia N900: Proper C-states

[Daniel Lezcano]

On 01/02/2016 03:26 PM, Pali Rohár wrote:

Hello,

due to this Daniel Lezcano commit (ARM: OMAP3: cpuidle - remove rx51
cpuidle parameters table)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc

we need patch cpuidle34xx.c code to fix commit for Nokia N900. See:

https://github.com/pali/linux-n900/commit/e147fd4b678f1f3d7a5235287910960bd41e04dc

As Nokia N900 code is converting from legacy board code to DST, I would
like to know how to patch correctly omap3_idle_driver in DTS with
correct values measured for Nokia N900. Thanks!


Hi Pali,

the conversion to the DT based arm cpuidle driver could be a bit complex 
with one issue (index 0 != cpu_do_idle()) and one performance regression 
(cpu_pm_enter/exit will be called in retention mode, even if this is not 
needed).


It will result in a PM code only on one side and on the other side, the 
generic cpuidle-arm.c driver will be used instead with the DT 
definition. It is worth to the conversion because the result will be 
nice IMO.


Added Lorenzo who is initially author of the arm generic driver. We 
already discussed in the past about those two issues above and I think 
this is something we should improve.




--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Pali Rohár]

On Saturday 02 January 2016 23:57:47 Arnd Bergmann wrote:
> On Saturday 02 January 2016 16:22:03 Pali Rohár wrote:
> > On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> > > On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > > > > I mean you can add the platform data to the
> > > > > omap_auxdata_lookup[] table for this board.
> > > > 
> > > > But can I mix data from omap3-n900.dts and
> > > > omap_auxdata_lookup[]?
> > 
> > Hm... looks like it is not possible. omap_hsmmc driver ignores any
> > supplied platform data if there are device tree data. So array
> > omap_auxdata_lookup[] does not help.
> 
> Obviously you need to the driver to work with that setting. Maybe
> something as simple as
> 
> diff --git a/drivers/mmc/host/omap_hsmmc.c
> b/drivers/mmc/host/omap_hsmmc.c index e06b1881b6a1..4fa35fc84b8b
> 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2006,7 +2006,7 @@ static int omap_hsmmc_probe(struct
> platform_device *pdev) void __iomem *base;
> 
>   match = of_match_device(of_match_ptr(omap_mmc_of_match),
> >dev); -if (match) {
> + if (!pdata && match) {
>   pdata = of_get_hsmmc_pdata(>dev);
> 
>   if (IS_ERR(pdata))
> 
> 
>   Arnd

But in this case I must copy mmc definition from omap3-n900.dts file 
back to board code to omap_auxdata_lookup[]. And mmc definitions in 
omap3-n900.dts will be ignored. This is step back.

Mixing mmc definitions from DTS file together with omap_auxdata_lookup[] 
just will not work.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Sunday 03 January 2016 00:03:54 Pali Rohár wrote:
> On Saturday 02 January 2016 23:57:47 Arnd Bergmann wrote:
> > On Saturday 02 January 2016 16:22:03 Pali Rohár wrote:
> > > On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> > > > On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > > > > > I mean you can add the platform data to the
> > > > > > omap_auxdata_lookup[] table for this board.
> > > > > 
> > > > > But can I mix data from omap3-n900.dts and
> > > > > omap_auxdata_lookup[]?
> > > 
> > > Hm... looks like it is not possible. omap_hsmmc driver ignores any
> > > supplied platform data if there are device tree data. So array
> > > omap_auxdata_lookup[] does not help.
> > 
> > Obviously you need to the driver to work with that setting. Maybe
> > something as simple as
> > 
> > diff --git a/drivers/mmc/host/omap_hsmmc.c
> > b/drivers/mmc/host/omap_hsmmc.c index e06b1881b6a1..4fa35fc84b8b
> > 100644
> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -2006,7 +2006,7 @@ static int omap_hsmmc_probe(struct
> > platform_device *pdev) void __iomem *base;
> > 
> >   match = of_match_device(of_match_ptr(omap_mmc_of_match),
> > >dev); -if (match) {
> > + if (!pdata && match) {
> >   pdata = of_get_hsmmc_pdata(>dev);
> > 
> >   if (IS_ERR(pdata))
> > 
> 
> But in this case I must copy mmc definition from omap3-n900.dts file 
> back to board code to omap_auxdata_lookup[]. And mmc definitions in 
> omap3-n900.dts will be ignored. This is step back.
> 
> Mixing mmc definitions from DTS file together with omap_auxdata_lookup[] 
> just will not work.

As I said earlier, if you prefer to avoid the auxdata hack, you are
also welcome to work on support for named slots in the MMC core code,
it will just be more work and will take time to get consensus on.

Arnd
--
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: Nokia N900: twl4030-power different data in DTS and board code

[Pali Rohár]

On Saturday 02 January 2016 18:14:31 Tony Lindgren wrote:
> * Pali Rohár  [160102 06:14]:
> > Hello,
> > 
> > now I'm looking at differences between legacy board code and DTS
> > file for Nokia N900 and I see some inconsistency for twl4030-power
> > driver.
> > 
> > In board code are defined more twl4030 power scripts which override
> > defaults defined in twl4030-power code. See:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre
> > e/arch/arm/mach-omap2/board-rx51-peripherals.c#n790
> > 
> > Next in DTS file is defined just "compatible" keyword, but no
> > custom scripts, see:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre
> > e/arch/arm/boot/dts/omap3-n900.dts#n416
> > 
> > And the last in DTS file is defined line:
> > 
> > compatible = "ti,twl4030-power-n900"
> > 
> > which is not in twl4030-power driver itself, see:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre
> > e/drivers/mfd/twl4030-power.c#n851
> > 
> > So all this stuff looks like some errors when board code was ported
> > to DTS. Tony, can you look at this at all?
> 
> AFAIK it should work fine with the generic
> "ti,twl4030-power-idle-osc-off". This means reboot works and
> regulators are cut off during off mode.

Ok.

> The n900 specific code was based on something before the TI generic
> values were available I think. And the last time I looked at it I
> came to the conclusion the n900 specific code is no better.

Hm... if generic values are better, why old values are still there (in 
board n900 code)?

> Or did I miss something? Are you seeing some issues with PM with dts
> based code?

I'm just asking why we have different code for DST and board...

> We can certainly add it to twl4030-power if it provides something
> that the "ti,twl4030-power-idle-osc-off" does not.

But do we need 'compatible = "ti,twl4030-power-n900"' specification in 
omap3-n900.dts file at all?

-- 
Pali Rohár
pali.ro...@gmail.com


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

Re: bbb kexec bug: Unhandled fault external abort on non-linefetch (0x1028) at 0xfa1ac140

[Dave Young]

Hi, Grygorii

Thanks fot your reply.

On 12/28/15 at 02:15pm, Grygorii Strashko wrote:
> On 12/28/2015 09:18 AM, Dave Young wrote:
> > On 12/27/15 at 03:38pm, Dave Young wrote:
> >> Here is what I get when I test kdump on Beagle bone black:
> >>
> >> Added a printk line at the begin of function omap_gpio_rmw:
> >> printk("## %lx, %x, %x\n", base, reg, mask);
> >>
> >> Any hints how to fix it? I tried call the machine_kexec_mask_interrupts
> >> at runtime kernel also panics so it may not limit to kdump case.
> >>
> >> [   66.340168] ## fa1ac000, 140, 1
> >> [   66.344456] Unhandled fault: external abort on non-linefetch (0x1028) 
> >> at 0xfa1ac140
> >> [   66.352142] pgd = dd9f
> 
> [...]
> 
> >> [   66.727278] [] (omap_set_gpio_triggering) from [] 
> >> (omap_gpio_mask_irq+0x29/0x34)
> 
> Usually such back-trace means that you are trying to access HW
> which is disabled (powered off) already. Or this HW IP has never been enabled.

It is possible, but how to detect such disabled gpio in this for_each_irq_desc
loop? I tried below, it works for me but I'm not sure if it is a right fix.

---
 arch/arm/kernel/machine_kexec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux.orig/arch/arm/kernel/machine_kexec.c
+++ linux/arch/arm/kernel/machine_kexec.c
@@ -106,7 +106,7 @@ static void machine_kexec_mask_interrupt
if (chip->irq_eoi && irqd_irq_inprogress(>irq_data))
chip->irq_eoi(>irq_data);
 
-   if (chip->irq_mask)
+   if ((chip->irq_mask) && !irqd_irq_masked(>irq_data))
chip->irq_mask(>irq_data);
 
if (chip->irq_disable && !irqd_irq_disabled(>irq_data))

> 
> >> [   66.736457] [] (omap_gpio_mask_irq) from [] 
> >> (machine_crash_shutdown+0xb9/0x104)
> >> [   66.745551] [] (machine_crash_shutdown) from [] 
> >> (crash_kexec+0x35/0x68)
> >> [   66.753942] [] (crash_kexec) from [] 
> >> (die+0x1b9/0x390)
> >> [   66.760859] [] (die) from [] 
> >> (__do_kernel_fault.part.0+0x4f/0x1cc)
> >> [   66.768824] [] (__do_kernel_fault.part.0) from [] 
> >> (do_page_fault+0x155/0x29c)
> >> [   66.40] [] (do_page_fault) from [] 
> >> (do_DataAbort+0x2f/0x88)
> >> [   66.785432] [] (do_DataAbort) from [] 
> >> (__dabt_svc+0x3b/0x80)
> >> [   66.792858] Exception stack(0xddc39e58 to 0xddc39ea0)
> >> [   66.797929] 9e40:   
> >> 0063 df93647c
> >> [   66.806144] 9e60: 1f26a000  0001 0063 0007 c0702e3c 
> >>  ddc38000
> >> [   66.814359] 9e80:  7f70d614 0030 ddc39ea8 c021e54b c021e54c 
> >> 600e0033 
> >> [   66.822575] [] (__dabt_svc) from [] 
> >> (sysrq_handle_crash+0x18/0x1c)
> >> [   66.830530] [] (sysrq_handle_crash) from [] 
> >> (__handle_sysrq+0x79/0x10c)
> >> [   66.838919] [] (__handle_sysrq) from [] 
> >> (write_sysrq_trigger+0x45/0x50)
> >> [   66.847310] [] (write_sysrq_trigger) from [] 
> >> (proc_reg_write+0x43/0x68)
> >> [   66.855700] [] (proc_reg_write) from [] 
> >> (__vfs_write+0xf/0x8c)
> >> [   66.863304] [] (__vfs_write) from [] 
> >> (vfs_write+0x5f/0x128)
> >> [   66.870646] [] (vfs_write) from [] 
> >> (SyS_write+0x2b/0x68)
> >> [   66.877729] [] (SyS_write) from [] 
> >> (ret_fast_syscall+0x1/0x4c)
> >> [   66.885332] Code: 443c 4643 f6a9 f9a1 (6823) 0732
> >> [   66.890145] ---[ end trace 5a39094ece4dc200 ]---
> >> [   66.894782] Kernel panic - not syncing: Fatal exception
> >> [   66.900033] ---[ end Kernel panic - not syncing: Fatal exception
> >>
> 
> 
> -- 
> regards,
> -grygorii

Thanks
Dave
--
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 Tony,

On 21.05.2015 00:21, Tony Lindgren wrote:

We support decoding the bootloader values if DEBUG is defined.
But we also need to change the struct omap_hwmod flags to have
HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
boot. Otherwise just the default timings will be displayed
instead of the bootloader configured timings.

This also allows us to clean up the various GPMC related
hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
and HWMOD_INIT_NO_IDLE is not needed.

Cc: Brian Hutchinson 
Cc: Paul Walmsley 
Cc: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
  drivers/memory/Kconfig  |  8 
  drivers/memory/omap-gpmc.c  |  6 +++---
  9 files changed, 29 insertions(+), 35 deletions(-)



1. Happy new year :)

2. It was a while I tested upstream on N900 but I had some spare time 
during the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To 
my surprise, after that try, Maemo 5 rootfs, which is located on onenand 
became irreversibly corrupted. I bisected the tree to the $subject 
commit and after restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod 
flags, the problem was solved. It seems that GPMC is either incorrectly 
or incompletely setup by the kernel, leading to failed onenand 
reads/writes and whatnot. Unfortunately, what I have here is a release 
device, so I am unable to capture any logs through the serial port. BTW 
keep in mind that rootfs corruption happens as soon as a boot is 
attempted, even after a freshly flashed rootfs.


Please advice on how to proceed.

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: [PATCH 2/2] OMAP: RX51: save ATAGS data in the early boot stage

[Ivaylo Dimitrov]

Hi,

On 24.12.2015 20:56, Tony Lindgren wrote:


Maybe update the description to say "This fixes a regression with
device tree based booting compared to legacy booting for n900 to
make the n900 legacy user space to also work with device tree based
booting".



OK, will do.


It would be nice to get these two in as fixes after -rc1 assuming
people have no objections to it. So please upload this one also
into Russell's patch system after no more comments:



Seems there are no more comments (and objections) so I will *try* to 
upload the patches in Russell's patch system. Will pester you to do it 
for me if I fail to do so :)



Acked-by: Tony Lindgren 



Thanks,
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