Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [151021 01:31]:
> On 19/10/15 10:08, Roger Quadros wrote:
> > On 17/10/15 00:25, Tony Lindgren wrote:
> >> * Roger Quadros  [151006 04:13]:
> >>>
> >>> Fine. The updated series is now at
> >>>
> >>> g...@github.com:rogerq/linux.git
> >>>  * [new branch]  for-v4.4/gpmc-v4
> >>
> >> Looks like it produces some build errors, this with RMKs 3430 and 4430
> >> only .configs:
> >>
> >> drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no
> >> member named ‘irqdomain’
> >> drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of
> >> function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration]
> >>
> > 
> > Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver.
> > 
> >> Maybe run randconfig builds on it for overnight?
> > 
> > OK. I'll do that.
> 
> I couldn't run randconfig beyond few iterations as it keeps failing
> everywhere. How do we limit the randconfig options to OMAP only
> platforms?

You can use Felipe's scripts from github.

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: [GIT PULL] two omap fixes for v4.3-rc cycle

[Arnd Bergmann]

On Tuesday 20 October 2015 12:34:01 Tony Lindgren wrote:
> The following changes since commit d8e1f5ed11a39a68da00f05000466c4f6db4456e:
> 
>   Documentation: ARM: List new omap MMC requirements (2015-10-12 16:23:34 
> -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v4.3/fixes-rc6
> 
> for you to fetch changes up to 57df5380853460bc66b59a46273ce113c923d39c:
> 
>   ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init 
> (2015-10-19 08:55:46 -0700)
> 
> 
> Fixes for omaps for v4.3-rc cycle:
> 
> - Fix oops with LPAE and moew than 2GB of memory by enabling
>   ZONE_DMA for LPAE. Probably no need for stable on this one as we
>   only recently ran into this with the mainline kernel
> 
> - Fix imprecise external abort caused by bogus SRAM init. This affects
>   dm814x recently merged, so no need for stable on this one AFAIK

Applied to fixes, thanks!

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 RFC RFT 2/3] clk: clk_put WARNs if user has not disabled clk

[Geert Uytterhoeven]

Hi Mike,

On Wed, Oct 21, 2015 at 5:50 PM, Michael Turquette
 wrote:
> Quoting Russell King - ARM Linux (2015-10-21 03:59:32)
>> On Wed, Oct 21, 2015 at 11:50:07AM +0200, Geert Uytterhoeven wrote:
>> > On Tue, Oct 20, 2015 at 2:40 PM, Michael Turquette
>> >  wrote:
>> > > Why not keep the reference to the struct clk after get'ing it the first
>> > > time?
>> >
>> > And store it where?
>>
>> Not my problem :)
>>
>> Users are supposed to hold on to the reference obtained via clk_get()
>> while they're making use of the clock: in some implementations, this
>> increments the module use count if the clock driver is a module, and
>> may have other effects too.
>>
>> Dropping that while you're still requiring the clock to be enabled is
>> unsafe: if it is provided by a module, then removing and reinserting
>> the module may very well change the enabled state of the clock, it
>> most certainly will disrupt the enable count.
>>
>> It's always been this way, right from the outset, and when I've seen
>> people doing this bollocks, I've always pointed out that it's wrong.
>> Generally, people will fix it once they become aware of it, so it's
>> really that people just don't like reading and conforming to published
>> API requirements.
>>
>> I think the root cause is that people just don't like reading what
>> other people write in terms of documentation, and they prefer to go
>> off and do their own thing, provided it works for them.
>
> Right, so in other words this problem must be solved by the caller of
> clk_get, as it should be. I have never much looked at the pm clk code in
> question, but I gave it a quick look and came up with some example code
> that does not compile, in an effort to be as helpful as possible.
>
> Basically I added a flex array to struct pm_clk_notifier_block, so that
> now there are two flex arrays which is stupid. But I am too lazy to
> replace the nbclk->clks thing with a malloc after walking all of the
> clk_id's to figure out the number of clocks. Or we could just add
> .num_clk to the struct, fix up all 4 users of it and drop the NULL
> sentinel used the .clk_id's... Hmm that would have been better.

Thanks for trying.

> index 25266c6..45e58fe 100644
> --- a/include/linux/pm_clock.h
> +++ b/include/linux/pm_clock.h
> @@ -16,6 +16,7 @@ struct pm_clk_notifier_block {
> struct notifier_block nb;
> struct dev_pm_domain *pm_domain;
> char *con_ids[];
> +   struct clk *clks[];
>  };
>
>  struct clk;

Unfortunately that won't work: while the .con_ids[] array is per-platform,
the .clks[] array should be per-device. I.e. it should be tied to the struct
device, not to the struct pm_clk_notifier_block.

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

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

[Tomeu Vizoso]

Hi,

this is v10 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 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   |  6 --
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 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, 128 insertions(+), 23 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 v10 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 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   |  4 ++--
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 include/linux/pm_domain.h |  3 +++
 10 files changed, 50 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c 
b/arch/arm/mach-omap2/omap_device.c
index 4cb8fd9f741f..204101d11632 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 f51bd0d0bc17..cc6e1abc69b3 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -706,7 +707,7 @@ static int acpi_lpss_platform_notify(struct notifier_block 
*nb,
 
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
-   pdev->dev.pm_domain = _lpss_pm_domain;
+   dev_pm_domain_set(>dev, _lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(>dev.kobj,
  _attr_group);
@@ -714,7 +715,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);
-   pdev->dev.pm_domain = NULL;
+   dev_pm_domain_set(>dev, NULL);
break;
default:
break;
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 4806b7f856c4..8c5955bf9bbf 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"
@@ -1076,7 +1077,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) {
/*
@@ -1128,7 +1129,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, ACPI_STATE_S0, false);
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 652b5a367c1f..e80fda6c03a9 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_PM
@@ -346,7 +347,7 @@ static int pm_clk_notify(struct notifier_block *nb,
if (error)
break;
 
-

Re: [PATCH RFC RFT 2/3] clk: clk_put WARNs if user has not disabled clk

[Michael Turquette]

Quoting Russell King - ARM Linux (2015-10-21 03:59:32)
> On Wed, Oct 21, 2015 at 11:50:07AM +0200, Geert Uytterhoeven wrote:
> > Hi Mike, Russell,
> > 
> > On Tue, Oct 20, 2015 at 2:40 PM, Michael Turquette
> >  wrote:
> > > Why not keep the reference to the struct clk after get'ing it the first
> > > time?
> > 
> > And store it where?
> 
> Not my problem :)
> 
> Users are supposed to hold on to the reference obtained via clk_get()
> while they're making use of the clock: in some implementations, this
> increments the module use count if the clock driver is a module, and
> may have other effects too.
> 
> Dropping that while you're still requiring the clock to be enabled is
> unsafe: if it is provided by a module, then removing and reinserting
> the module may very well change the enabled state of the clock, it
> most certainly will disrupt the enable count.
> 
> It's always been this way, right from the outset, and when I've seen
> people doing this bollocks, I've always pointed out that it's wrong.
> Generally, people will fix it once they become aware of it, so it's
> really that people just don't like reading and conforming to published
> API requirements.
> 
> I think the root cause is that people just don't like reading what
> other people write in terms of documentation, and they prefer to go
> off and do their own thing, provided it works for them.

Right, so in other words this problem must be solved by the caller of
clk_get, as it should be. I have never much looked at the pm clk code in
question, but I gave it a quick look and came up with some example code
that does not compile, in an effort to be as helpful as possible.

Basically I added a flex array to struct pm_clk_notifier_block, so that
now there are two flex arrays which is stupid. But I am too lazy to
replace the nbclk->clks thing with a malloc after walking all of the
clk_id's to figure out the number of clocks. Or we could just add
.num_clk to the struct, fix up all 4 users of it and drop the NULL
sentinel used the .clk_id's... Hmm that would have been better.

Anyways here is the ugly, non-compiling code. I'll take another look at
it in one year if no one else beats me to it.

Regards,
Mike



diff --git a/arch/arm/mach-davinci/pm_domain.c 
b/arch/arm/mach-davinci/pm_domain.c
index 78eac2c..b46e5ce 100644
--- a/arch/arm/mach-davinci/pm_domain.c
+++ b/arch/arm/mach-davinci/pm_domain.c
@@ -24,6 +24,7 @@ static struct dev_pm_domain davinci_pm_domain = {
 static struct pm_clk_notifier_block platform_bus_notifier = {
.pm_domain = _pm_domain,
.con_ids = { "fck", "master", "slave", NULL },
+   .clks = { ERR_PTR(-EAGAIN), ERR_PTR(-EAGAIN), ERR_PTR(-EAGAIN) },
 };
 
 static int __init davinci_pm_runtime_init(void)
diff --git a/arch/arm/mach-keystone/pm_domain.c 
b/arch/arm/mach-keystone/pm_domain.c
index e283939..d21c18b 100644
--- a/arch/arm/mach-keystone/pm_domain.c
+++ b/arch/arm/mach-keystone/pm_domain.c
@@ -27,6 +27,7 @@ static struct dev_pm_domain keystone_pm_domain = {
 
 static struct pm_clk_notifier_block platform_domain_notifier = {
.pm_domain = _pm_domain,
+   .clks = { ERR_PTR(-EAGAIN) },
 };
 
 static const struct of_device_id of_keystone_table[] = {
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index 667c163..5506453 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -31,6 +31,7 @@ static struct dev_pm_domain default_pm_domain = {
 static struct pm_clk_notifier_block platform_bus_notifier = {
.pm_domain = _pm_domain,
.con_ids = { "ick", "fck", NULL, },
+   .clks = { ERR_PTR(-EAGAIN), ERR_PTR(-EAGAIN) },
 };
 
 static int __init omap1_pm_runtime_init(void)
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 652b5a3..26f0dcf 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -407,40 +407,6 @@ int pm_clk_runtime_resume(struct device *dev)
 #else /* !CONFIG_PM */
 
 /**
- * enable_clock - Enable a device clock.
- * @dev: Device whose clock is to be enabled.
- * @con_id: Connection ID of the clock.
- */
-static void enable_clock(struct device *dev, const char *con_id)
-{
-   struct clk *clk;
-
-   clk = clk_get(dev, con_id);
-   if (!IS_ERR(clk)) {
-   clk_prepare_enable(clk);
-   clk_put(clk);
-   dev_info(dev, "Runtime PM disabled, clock forced on.\n");
-   }
-}
-
-/**
- * disable_clock - Disable a device clock.
- * @dev: Device whose clock is to be disabled.
- * @con_id: Connection ID of the clock.
- */
-static void disable_clock(struct device *dev, const char *con_id)
-{
-   struct clk *clk;
-
-   clk = clk_get(dev, con_id);
-   if (!IS_ERR(clk)) {
-   clk_disable_unprepare(clk);
-   clk_put(clk);
-   dev_info(dev, "Runtime PM disabled, clock forced off.\n");
-   }
-}
-
-/**
  * pm_clk_notify - Notify routine for device addition and 

Re: [PATCH] net, can, ti_hecc: add DT support for the ti,hecc controller

[Rob Herring]

On Mon, Oct 19, 2015 at 1:58 AM, Marc Kleine-Budde  wrote:
> On 10/19/2015 08:39 AM, Heiko Schocher wrote:
>> add DT support for the ti hecc controller, used on
>> am3517 SoCs.
>
> A similar patch was posted a few days ago, see
> http://comments.gmane.org/gmane.linux.can/8616 and my comments.

I don't seem to have that in my inbox. Please send DT bindings to the
DT list and maintainers.

Rob

>
> Please coordinate with Anton Glukhov (Cc'ed) and/or pick up his patches
> as they are in better shape.
>
> Marc
>>
>> Signed-off-by: Heiko Schocher 
>> ---
>>
>>  .../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
>>  arch/arm/boot/dts/am3517.dtsi  | 13 +++
>>  drivers/net/can/ti_hecc.c  | 45 
>> +-
>>  3 files changed, 76 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt 
>> b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>> new file mode 100644
>> index 000..09fab59
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>> @@ -0,0 +1,20 @@
>> +* TI HECC CAN *
>> +
>> +Required properties:
>> +  - compatible: Should be "ti,hecc"
>
> We usually put the name of the first SoC this IP core appears in to the
> compatible.
>
>> +  - reg: Should contain CAN controller registers location and length
>> +  - interrupts: Should contain IRQ line for the CAN controller
>
> I'm missing the description of the ti,* properties. I think they are
> required, too. Although the code doesn't enforce it.
>
>> +
>> +Example:
>> +
>> + can0: hecc@5c05 {
>> + compatible = "ti,hecc";
>> + reg = <0x5c05 0x4000>;
>> + interrupts = <24>;
>> + ti,hecc_scc_offset = <0>;
>> + ti,hecc_scc_ram_offset = <0x3000>;
>> + ti,hecc_ram_offset = <0x3000>;
>> + ti,hecc_mbx_offset = <0x2000>;
>> + ti,hecc_int_line = <0>;
>> + ti,hecc_version = <1>;
>
> Versioning in the OF world is done via the compatible. Are the offsets a
> per SoC parameter? I'm not sure if it's better to put
> the offsets into the driver.
>
>> + };
>> diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
>> index 5e3f5e8..47bc429 100644
>> --- a/arch/arm/boot/dts/am3517.dtsi
>> +++ b/arch/arm/boot/dts/am3517.dtsi
>> @@ -25,6 +25,19 @@
>>   interrupt-names = "mc";
>>   };
>>
>> + can0: hecc@5c05 {
>> + compatible = "ti,hecc";
>> + reg = <0x5c05 0x4000>;
>> + interrupts = <24>;
>> + ti,hecc_scc_offset = <0>;
>> + ti,hecc_scc_ram_offset = <0x3000>;
>> + ti,hecc_ram_offset = <0x3000>;
>> + ti,hecc_mbx_offset = <0x2000>;
>> + ti,hecc_int_line = <0>;
>> + ti,hecc_version = <1>;
>> + status = "disabled";
>> + };
>> +
>>   davinci_emac: ethernet@0x5c00 {
>>   compatible = "ti,am3517-emac";
>>   ti,hwmods = "davinci_emac";
>> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
>> index c08e8ea..f1705d5 100644
>> --- a/drivers/net/can/ti_hecc.c
>> +++ b/drivers/net/can/ti_hecc.c
>> @@ -875,16 +875,56 @@ static const struct net_device_ops ti_hecc_netdev_ops 
>> = {
>>   .ndo_change_mtu = can_change_mtu,
>>  };
>>
>> +#if defined(CONFIG_OF)
>> +static const struct of_device_id ti_hecc_can_dt_ids[] = {
>> + {
>> + .compatible = "ti,hecc",
>> + }, {
>> + /* sentinel */
>> + }
>> +};
>> +MODULE_DEVICE_TABLE(of, ti_hecc_can_dt_ids);
>> +#endif
>
> Please remove the ifdef, use __maybe_unused instead.
>
>> +
>> +static const struct ti_hecc_platform_data
>> +*ti_hecc_can_get_driver_data(struct platform_device *pdev)
>> +{
>> + if (pdev->dev.of_node) {
>> + struct ti_hecc_platform_data *data;
>> + struct device_node *np = pdev->dev.of_node;
>> +
>> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return NULL;
>> +
>> + of_property_read_u32(np, "ti,hecc_scc_offset",
>> +  >scc_hecc_offset);
>> + of_property_read_u32(np, "ti,hecc_scc_ram_offset",
>> +  >scc_ram_offset);
>> + of_property_read_u32(np, "ti,hecc_ram_offset",
>> +  >hecc_ram_offset);
>> + of_property_read_u32(np, "ti,hecc_mbx_offset",
>> +  >mbx_offset);
>> + of_property_read_u32(np, "ti,hecc_int_line",
>> +  

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Jassi Brar]

On 22 October 2015 at 05:35, Suman Anna  wrote:

>>   Anyways I am OK too, if you guys want to fix it with a platform
>> specific quirk. Let me know I'll pick this patch.
>
> I haven't gotten a chance to try #1, and I won't be able to look at it
> atleast for another month. I suggest that you go ahead and pick this
> patch up, as a quirk is needed in one form or the other for #2, and #1
> is anyways a bigger change that will affect all our IPC stacks across
> all pairs of MPU - remote processors on different SoCs.
>
Yeah that is the reason I offered to pick this patch as such.
OK I'll take this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

Hi all,

I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:

ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")

With the commit above reverted things work fine with DMA and USB gadgets.

This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.

Anybody got ideas what might be wrong? Some wrong runtime PM usage
under drivers/usb/musb?

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] arm: omap2: board-generic: use omap4_local_timer_init for AM437x

[Tony Lindgren]

* Felipe Balbi  [151020 14:06]:
> AM437x-based boards, can use omap4_local_timer_init()
> just fine. Let's use that instead.

Applying into omap-for-v4.4/soc thanks.

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

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Suman Anna]

Hi Jassi,

On 10/20/2015 11:44 PM, Jassi Brar wrote:
> On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach  wrote:
>> The mailbox framework controls the transmission queue and requires
>> either its controller implementations or clients to run the state
>> machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
>> interrupt as the equivalent of a Tx-done interrupt to run this Tx
>> queue state-machine.
>>
>> The WkupM3 processor on AM33xx and AM43xx SoCs is used to offload
>> certain PM tasks, like doing the necessary operations for Device
>> PM suspend/resume or for entering lower c-states during cpuidle.
>>
>> The CPUIdle on AM33xx requires the messages to be sent without
>> having to trigger the Tx-ready interrupts, as the interrupt
>> would immediately terminate the CPUIdle operation. Support for
>> this has been added by introducing a DT quirk, "ti,mbox-send-noirq"
>> and using it to modify the normal OMAP mailbox controller behavior
>> on the sub-mailboxes used to communicate with the WkupM3 remote
>> processor. This also requires the wkup_m3_ipc driver to adjust
>> its mailbox usage logic to run the Tx state machine.
>>
> Probably Suman already updated you on what was discussed about this
> patch at Connect-SFO. My suggestion was to drive TX poll-based (I
> know, I know...) because the "interrupt-driven" is just an impression,
> it is not really. You get the interrupt as soon as you enable it
> because it is the "FIFO not-full" interrupt which is always because
> there is always space left after writing to the fifo. The cons are
> that it buffers messages hidden from the client while abusing the irq.
> If you guys could break away from the "interrupt-driven" illusion and
> use polling which it actually is, everything falls into place and you
> avoid the "ti,mbox-send-noirq" quirk.

Looking at this closely, even with that approach, we would still need a
quirk to deal with the weird behavior of our wakeup m3. Essentially we
have two independent things:
1. Tx state machine (currently interrupt driven) for ticking the mailbox
core tx state machine.
2. A quirk that we need for dealing with Wakeup M3 behavior, MPU needs
to take out the message on behalf of WkupM3 processor after transmission
and clearing the IP-level interrupt intended for WkupM3. This will be
irrespective of the Tx state machine choice, and this needs to be
different only on the specific mbox channel used to talk with WkupM3
processor.

Previously, we were doing #2 in the OMAP mailbox regular interrupt
handler (handles both Rx and Tx interrupts) as part of the Rx interrupt
handler with the rx mbox variables reflecting those of the WkupM3
processor. But when we remove the interrupt processing, we now actually
need to add code to deal with this.

>   Anyways I am OK too, if you guys want to fix it with a platform
> specific quirk. Let me know I'll pick this patch.

I haven't gotten a chance to try #1, and I won't be able to look at it
atleast for another month. I suggest that you go ahead and pick this
patch up, as a quirk is needed in one form or the other for #2, and #1
is anyways a bigger change that will affect all our IPC stacks across
all pairs of MPU - remote processors on different SoCs.

regards
Suman

--
To unsubscribe from this list: send the line "unsubscribe 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 15/19] ARM: dts: omap: replace legacy *,wakeup property with wakeup-source

[Sudeep Holla]

Though the keyboard and other driver will continue to support the legacy
"gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup
source, "wakeup-source" is the new standard binding.

This patch replaces all the legacy wakeup properties with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.

Cc: "Benoît Cousson" 
Cc: Tony Lindgren 
Cc: linux-omap@vger.kernel.org
Signed-off-by: Sudeep Holla 
---
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts  |  8 ++---
 arch/arm/boot/dts/omap3-beagle-xm.dts  |  2 +-
 arch/arm/boot/dts/omap3-beagle.dts |  2 +-
 arch/arm/boot/dts/omap3-cm-t3x.dtsi|  2 +-
 arch/arm/boot/dts/omap3-devkit8000-common.dtsi |  2 +-
 arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi |  2 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |  2 +-
 arch/arm/boot/dts/omap3-ldp.dts| 18 ++--
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|  2 +-
 arch/arm/boot/dts/omap3-n900.dts   | 10 +++
 arch/arm/boot/dts/omap3-overo-alto35-common.dtsi   |  2 +-
 .../boot/dts/omap3-overo-chestnut43-common.dtsi|  4 +--
 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi|  2 +-
 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi|  2 +-
 arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi |  4 +--
 arch/arm/boot/dts/omap3-overo-palo35-common.dtsi   |  4 +--
 arch/arm/boot/dts/omap3-overo-palo43-common.dtsi   |  4 +--
 arch/arm/boot/dts/omap3-pandora-common.dtsi| 34 +++---
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|  2 +-
 arch/arm/boot/dts/omap4-duovero-parlor.dts |  2 +-
 arch/arm/boot/dts/omap4-var-om44customboard.dtsi   |  2 +-
 arch/arm/boot/dts/omap5-cm-t54.dts |  2 +-
 22 files changed, 57 insertions(+), 57 deletions(-)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index 91146c318798..caeb3b076042 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -23,28 +23,28 @@
label = "sysboot2";
gpios = < 2 GPIO_ACTIVE_LOW>; /* gpio2 */
linux,code = ;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
sysboot5 {
label = "sysboot5";
gpios = < 7 GPIO_ACTIVE_LOW>; /* gpio7 */
linux,code = ;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
gpio1 {
label = "gpio1";
gpios = < 21 GPIO_ACTIVE_LOW>;/* gpio181 */
linux,code = ;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
gpio2 {
label = "gpio2";
gpios = < 18 GPIO_ACTIVE_LOW>;/* gpio178 */
linux,code = ;
-   gpio-key,wakeup;
+   wakeup-source;
};
};
 
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 7c4dca122a91..f0e2cf3c9e89 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,7 +69,7 @@
label = "user";
gpios = < 4 GPIO_ACTIVE_HIGH>;
linux,code = <0x114>;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 67659a0ed13e..de5138e61ddc 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -80,7 +80,7 @@
label = "user";
gpios = < 7 GPIO_ACTIVE_HIGH>;
linux,code = <0x114>;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
};
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi 
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 4d091ca43e25..5ec6491d7933 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -238,7 +238,7 @@
ti,debounce-tol = /bits/ 16 <10>;
ti,debounce-rep = /bits/ 16 <1>;
 
-   linux,wakeup;
+   wakeup-source;
};
 };
 
diff --git a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi 
b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
index 9ca2865a83d6..86850bb311eb 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
+++ b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
@@ -64,7 +64,7 @@

Re: [PATCH RFC RFT 2/3] clk: clk_put WARNs if user has not disabled clk

[Geert Uytterhoeven]

Hi Mike, Russell,

On Tue, Oct 20, 2015 at 2:40 PM, Michael Turquette
 wrote:
> Quoting Geert Uytterhoeven (2015-09-30 08:38:46)
>> On Fri, Aug 7, 2015 at 9:09 PM, Michael Turquette
>>  wrote:
>> > From the clk_put kerneldoc in include/linux/clk.h:
>> >
>> > """
>> > Note: drivers must ensure that all clk_enable calls made on this clock
>> > source are balanced by clk_disable calls prior to calling this function.
>> > """
>> >
>> > The common clock framework implementation of the clk.h api has per-user
>> > reference counts for calls to clk_prepare and clk_disable. As such it
>> > can enforce the requirement to properly call clk_disable and
>> > clk_unprepare before calling clk_put.
>> >
>> > Because this requirement is probably violated in many places, this patch
>> > starts with a simple warning. Once offending code has been fixed this
>> > check could additionally release the reference counts automatically.
>> >
>> > Signed-off-by: Michael Turquette 
>> > ---
>> >  drivers/clk/clk.c | 8 
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> > index 72feee9..6ec0f77 100644
>> > --- a/drivers/clk/clk.c
>> > +++ b/drivers/clk/clk.c
>> > @@ -2764,6 +2764,14 @@ void __clk_put(struct clk *clk)
>> > clk->max_rate < clk->core->req_rate)
>> > clk_core_set_rate_nolock(clk->core, clk->core->req_rate);
>> >
>> > +   /*
>> > +* before calling clk_put, all calls to clk_prepare and clk_enable 
>> > from
>> > +* a given user must be balanced with calls to clk_disable and
>> > +* clk_unprepare by that same user
>> > +*/
>> > +   WARN_ON(clk->prepare_count);
>> > +   WARN_ON(clk->enable_count);
>>
>> These two WARN_ON()s are triggered a lot when using a legacy clock domain,
>> and CONFIG_PM=n. Indeed, without Runtime PM, the idea is that the module 
>> clocks
>> get enabled unconditionally, which violates the assumptions above.
>>
>> Cfr. the CONFIG_PM=n version of pm_clk_notify() in
>> drivers/base/power/clock_ops.c, which calls enable_clock():
>>
>> /**
>>  * enable_clock - Enable a device clock.
>>  * @dev: Device whose clock is to be enabled.
>>  * @con_id: Connection ID of the clock.
>>  */
>> static void enable_clock(struct device *dev, const char *con_id)
>> {
>> struct clk *clk;
>>
>> clk = clk_get(dev, con_id);
>> if (!IS_ERR(clk)) {
>> clk_prepare_enable(clk);
>> clk_put(clk);
>
> This is a violation of the clkdev api as defined in include/linux/clk.h:
>
> /**
>  * clk_put|-- "free" the clock source
>  * @clk: clock source
>  *
>  * Note: drivers must ensure that all clk_enable calls made on this
>  * clock source are balanced by clk_disable calls prior to calling
>  * this function.

I know.

> So the WARN is doing its job and letting us know about incorrect use of
> the API.
>
>> dev_info(dev, "Runtime PM disabled, clock forced on.\n");
>> }
>> }
>>
>> I think this affects shmobile, keystone, davinci, omap1, and legacy sh.
>
> Why not keep the reference to the struct clk after get'ing it the first
> time?

And store it where?

dev_pm_get_subsys_data() also depends on CONFIG_PM=y.

Note that there can be multiple clocks.

>> Sorry for not noticing before, we usually build with CONFIG_PM=y.
>> One more reason for making CONFIG_PM=y mandatory on SoCs with clock domains?

On ARM/shmobile, we only use it for the CONFIG_PM=n case, cfr.
drivers/sh/pm_runtime.c. In the CONFIG_PM=y case, we use DT and genpd.

For keystone, davinci, omap1, and legacy sh it's different, though.

With the advent of hardware Power and Clock Domains, keeping support for
CONFIG_PM=n alive is getting harder and harder...

> I don't know about that, but it seems like a reason to fix the clkdev
> usage in the clock domain code.

This is the legacy clock domain code. The way forward is genpd ;-)

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

[PATCH 09/19] ARM: dts: am335x: replace gpio-key,wakeup with wakeup-source property

[Sudeep Holla]

Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.

Cc: "Benoît Cousson" 
Cc: Tony Lindgren 
Cc: linux-omap@vger.kernel.org
Signed-off-by: Sudeep Holla 
---
 arch/arm/boot/dts/am335x-evm.dts| 4 ++--
 arch/arm/boot/dts/am335x-evmsk.dts  | 2 +-
 arch/arm/boot/dts/am335x-pepper.dts | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 1942a5c8132d..a6e398a213ec 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -83,14 +83,14 @@
label = "volume-up";
linux,code = <115>;
gpios = < 2 GPIO_ACTIVE_LOW>;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
switch@10 {
label = "volume-down";
linux,code = <114>;
gpios = < 3 GPIO_ACTIVE_LOW>;
-   gpio-key,wakeup;
+   wakeup-source;
};
};
 
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index 315bb02c9920..6b57baaa2bb0 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -123,7 +123,7 @@
label = "button2";
linux,code = <0x102>;
gpios = < 30 GPIO_ACTIVE_HIGH>;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
switch@4 {
diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index 7106114c7464..5107dbb07a7d 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -627,21 +627,21 @@
label = "home";
linux,code = ;
gpios = < 22 GPIO_ACTIVE_LOW>;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
button@1 {
label = "menu";
linux,code = ;
gpios = < 23 GPIO_ACTIVE_LOW>;
-   gpio-key,wakeup;
+   wakeup-source;
};
 
buttons@2 {
label = "power";
linux,code = ;
gpios = < 7 GPIO_ACTIVE_LOW>;
-   gpio-key,wakeup;
+   wakeup-source;
};
 };
 
-- 
1.9.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 RFC RFT 2/3] clk: clk_put WARNs if user has not disabled clk

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 11:50:07AM +0200, Geert Uytterhoeven wrote:
> Hi Mike, Russell,
> 
> On Tue, Oct 20, 2015 at 2:40 PM, Michael Turquette
>  wrote:
> > Why not keep the reference to the struct clk after get'ing it the first
> > time?
> 
> And store it where?

Not my problem :)

Users are supposed to hold on to the reference obtained via clk_get()
while they're making use of the clock: in some implementations, this
increments the module use count if the clock driver is a module, and
may have other effects too.

Dropping that while you're still requiring the clock to be enabled is
unsafe: if it is provided by a module, then removing and reinserting
the module may very well change the enabled state of the clock, it
most certainly will disrupt the enable count.

It's always been this way, right from the outset, and when I've seen
people doing this bollocks, I've always pointed out that it's wrong.
Generally, people will fix it once they become aware of it, so it's
really that people just don't like reading and conforming to published
API requirements.

I think the root cause is that people just don't like reading what
other people write in terms of documentation, and they prefer to go
off and do their own thing, provided it works for them.

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

[PATCH] ARM: dts: Set VAUX1 and VAUX4 to 3.0V and 1.8V respectively for LogicPD Torpedo DM3730 devkit

[Adam Ford]

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index 892ff1d..2ac1488 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -73,6 +73,16 @@
};
 };
 
+ {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+};
+
+ {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+};
+
  {
status = "okay";
 };
-- 
1.9.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] ARM: dts: Change I2C2 and I2C3 to 400KHz for LogicPD Torpedo DM3730 devkit

[Adam Ford]

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 9777ff4..c8091ff 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -104,6 +104,14 @@
};
 };
 
+ {
+   clock-frequency = <40>;
+};
+
+ {
+   clock-frequency = <40>;
+};
+
 /*
  * Only found on the wireless SOM. For the SOM without wireless, the pins for
  * MMC3 can be routed with jumpers to the second MMC slot on the devkit and
-- 
1.9.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 2/2] ARM: dts: omap3: keep ssi ports by default

[Roger Quadros]

On 19/10/15 19:01, Tony Lindgren wrote:
> * Roger Quadros  [151014 03:48]:
>> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
>> getting the following noise on the console for boards that don't
>> use the SSI ports.
>>
>> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
>>
>> As omap3-n900 uses one SSI port, mark it enabled there.
> 
> This is the wrong way around.. The SSI ports are there on all omap3 SoCs,
> we do want to have the struct device created for them. It's best to have
> the driver probe and then idle SSI and bail out. Marking something with
> status = "disabled" should be only used if you really want to avoid kernel
> touching the device at all, for example, if something is managed from
> the start by a copropcessor.

Agreed. Please ignore this patch.

cheers,
-roger

> 
> 
>> Signed-off-by: Roger Quadros 
>> ---
>>  arch/arm/boot/dts/omap3-n900.dts | 1 +
>>  arch/arm/boot/dts/omap3.dtsi | 2 ++
>>  2 files changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-n900.dts 
>> b/arch/arm/boot/dts/omap3-n900.dts
>> index 5f5e0f3..bdb72fb 100644
>> --- a/arch/arm/boot/dts/omap3-n900.dts
>> +++ b/arch/arm/boot/dts/omap3-n900.dts
>> @@ -949,6 +949,7 @@
>>  };
>>  
>>  _port1 {
>> +status = "ok";
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_pins>;
>>  
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 8a2b253..25b0b37 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -815,6 +815,7 @@
>>  interrupt-parent = <>;
>>  interrupts = <67>,
>>   <68>;
>> +status = "disabled";
>>  };
>>  
>>  ssi_port2: ssi-port@4805b000 {
>> @@ -828,6 +829,7 @@
>>  interrupt-parent = <>;
>>  interrupts = <69>,
>>   <70>;
>> +status = "disabled";
>>  };
>>  };
>>  };
>> -- 
>> 2.1.4
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 19/10/15 10:08, Roger Quadros wrote:
> On 17/10/15 00:25, Tony Lindgren wrote:
>> * Roger Quadros  [151006 04:13]:
>>>
>>> Fine. The updated series is now at
>>>
>>> g...@github.com:rogerq/linux.git
>>>  * [new branch]  for-v4.4/gpmc-v4
>>
>> Looks like it produces some build errors, this with RMKs 3430 and 4430
>> only .configs:
>>
>> drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no
>> member named ‘irqdomain’
>> drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of
>> function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration]
>>
> 
> Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver.
> 
>> Maybe run randconfig builds on it for overnight?
> 
> OK. I'll do that.

I couldn't run randconfig beyond few iterations as it keeps failing
everywhere. How do we limit the randconfig options to OMAP only
platforms?

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