date:20151019

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

2015-10-19 Thread Heiko Schocher

add DT support for the ti hecc controller, used on
am3517 SoCs.

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"
+  - reg: Should contain CAN controller registers location and length
+  - interrupts: Should contain IRQ line for the CAN controller
+
+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>;
+   };
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
+
+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",
+>int_line);
+   of_property_read_u32(np, "ti,hecc_version",
+>version);
+   return data;
+   }
+   return (const struct ti_hecc_platform_data *)
+   dev_get_platdata(>dev);
+}
+
 static int ti_hecc_probe(struct platform_device *pdev)
 {
struct net_device *ndev = (struct net_device *)0;
struct ti_hecc_priv *priv;
-   struct ti_hecc_platform_data *pdata;
+   const struct ti_hecc_platform_data *pdata;
struct resource *mem, *irq;
void __iomem *addr;
int err = -ENODEV;
 
-   pdata = dev_get_platdata(>dev);
+   pdata = ti_hecc_can_get_driver_data(pdev);
if (!pdata) {
dev_err(>dev, "No platform data\n");
goto probe_exit;
@@ -1040,6 +1080,7 @@ static int ti_hecc_resume(struct platform_device *pdev)
 static struct platform_driver ti_hecc_driver = {
.driver = {
.name= DRV_NAME,
+   .of_match_table = of_match_ptr(ti_hecc_can_dt_ids),
},
.probe = ti_hecc_probe,
.remove = ti_hecc_remove,

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

2015-10-19 Thread Marc Kleine-Budde

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.

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",
> +  >int_line);
> + of_property_read_u32(np, "ti,hecc_version",
> +  >version);

I'm missing error handling here.

> + return data;
> + }
> + return (const struct ti_hecc_platform_data *)
> + dev_get_platdata(>dev);

Is this cast needed?

> +}
> +
>

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

2015-10-19 Thread Heiko Schocher


Hello Marc,

Am 19.10.2015 um 08:58 schrieb Marc Kleine-Budde:

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.


Uh, sorry! Seems I missed them ...


Please coordinate with Anton Glukhov (Cc'ed) and/or pick up his patches
as they are in better shape.


Yes, I try the patchset from Anton ... thanks for pointing to them.

@Anton: Do you have a newer version, which contains the comments
from Marc?

bye,
Heiko


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.


Ok, so "ti,am335xx-hecc" would be OK?
@Anton: you used "am35x" ... it should be "am35xx"


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


Ok.


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


I am unsure here too..


+   };
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",
+>int_line);
+

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

2015-10-19 Thread Marc Kleine-Budde

On 10/19/2015 09:27 AM, Heiko Schocher wrote:
>>>   .../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.
> 
> Ok, so "ti,am335xx-hecc" would be OK?
> @Anton: you used "am35x" ... it should be "am35xx"

The "xx" is not okay. Give precisely the first SoC Version this IP core
was implemented in.

> 
>>> +  - 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.
> 
> Ok.
> 
>>> +
>>> +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.
> 
> I am unsure here too..

The devicetree people will hopefully help here.

regards,
Marc
-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

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

2015-10-19 Thread Roger Quadros

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.

> 
> Other than that your series seems to behave for me now, so feel
> free to add:
> 
> Acked-by: Tony Lindgren 

Thanks for the tests :)

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

Re: [PATCH v3 2/3] iio:adc:palmas: add DT support

2015-10-19 Thread H. Nikolaus Schaller

Am 19.10.2015 um 13:57 schrieb Lars-Peter Clausen :

> On 10/16/2015 02:53 PM, H. Nikolaus Schaller wrote:
> [...]
>> +Optional sub-nodes:
>> +ti,channel0-current-microamp: Channel 0 current in uA.
>> +Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
>> +ti,channel3-current-microamp: Channel 3 current in uA.
>> +Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
>> +ti,enable-extended-delay: Enable extended delay.
> 
> Those three above sound more like configuration policy, rather than hardware
> description. What influence which values should be chosen?

e.g. the nominal value of the NTC that can be connected if the Palmas
is hooked up in a standard way.

If a board has no NTC and uses channel0 for a different purpose one
should choose 0uA.

If it is let's say 10kOhm it should probably be 20uA to give a nominal voltage
reading of 200mV.

100kOhm will give 2V which is at the limit of the ADC input range and
therefore it would be better to choose 15uA or 5uA.

I think choosing extended delay depends on the noisiness of the input
signal but I am not a specialist for this feature.

So I would say the board hardware mandates some specific value.

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

bug in omap3_rom_rng_idle()

2015-10-19 Thread Sebastian Reichel

Hi,

During N900 boot I get the trace found below. The problem can be
seen in omap3_rom_rng_idle(), which is called by a kernel timer
(=softirq). In that function you call clk_disable_unprepare(), which
must not be called from atomic context, since clk_unprepare() may
sleep.

[1.885131] [ cut here ]
[1.890075] WARNING: CPU: 0 PID: 6 at kernel/locking/mutex.c:868 
mutex_trylock+0x1fc/0x21c()
[1.899169] DEBUG_LOCKS_WARN_ON(in_interrupt())
[1.903808] Modules linked in:
[1.907287] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: GW   
4.3.0-rc6-00012-g689422d8e6d2-dirty #630
[1.917999] Hardware name: Nokia RX-51 board
[1.922576] Workqueue: deferwq deferred_probe_work_func
[1.928192] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[1.936462] [] (show_stack) from [] 
(dump_stack+0x84/0x9c)
[1.944183] [] (dump_stack) from [] 
(warn_slowpath_common+0x78/0xb4)
[1.952758] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[1.962036] [] (warn_slowpath_fmt) from [] 
(mutex_trylock+0x1fc/0x21c)
[1.970855] [] (mutex_trylock) from [] 
(clk_prepare_lock+0xc/0xec)
[1.979309] [] (clk_prepare_lock) from [] 
(clk_unprepare+0x1c/0x2c)
[1.987854] [] (clk_unprepare) from [] 
(omap3_rom_rng_idle+0x38/0x5c)
[1.996582] [] (omap3_rom_rng_idle) from [] 
(call_timer_fn+0x8c/0x194)
[2.005371] [] (call_timer_fn) from [] 
(run_timer_softirq+0x1d8/0x2c8)
[2.014190] [] (run_timer_softirq) from [] 
(__do_softirq+0xcc/0x34c)
[2.022766] [] (__do_softirq) from [] 
(irq_exit+0xbc/0x130)
[2.030578] [] (irq_exit) from [] 
(__handle_domain_irq+0x6c/0xe0)
[2.038940] [] (__handle_domain_irq) from [] 
(__irq_svc+0x58/0x78)
[2.047363] [] (__irq_svc) from [] 
(_raw_spin_unlock_irqrestore+0x34/0x44)
[2.056549] [] (_raw_spin_unlock_irqrestore) from [] 
(onenand_release_device+0x48/0x54)
[2.066925] [] (onenand_release_device) from [] 
(onenand_bbt_read_oob+0x17c/0x1dc)
[2.076843] [] (onenand_bbt_read_oob) from [] 
(onenand_scan_bbt+0x104/0x24c)
[2.086212] [] (onenand_scan_bbt) from [] 
(onenand_scan+0x4f4/0xe40)
[2.094818] [] (onenand_scan) from [] 
(omap2_onenand_probe+0x250/0x49c)
[2.103729] [] (omap2_onenand_probe) from [] 
(platform_drv_probe+0x44/0xac)
[2.112945] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1f4/0x2f0)
[2.122406] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x64/0x98)
[2.131500] [] (bus_for_each_drv) from [] 
(__device_attach+0xb0/0x118)
[2.140289] [] (__device_attach) from [] 
(bus_probe_device+0x88/0x90)
[2.149017] [] (bus_probe_device) from [] 
(device_add+0x348/0x568)
[2.157470] [] (device_add) from [] 
(platform_device_add+0xf8/0x214)
[2.166076] [] (platform_device_add) from [] 
(gpmc_onenand_init+0x80/0x10c)
[2.175384] [] (gpmc_onenand_init) from [] 
(gpmc_probe+0x3ac/0x7e8)
[2.183898] [] (gpmc_probe) from [] 
(platform_drv_probe+0x44/0xac)
[2.192291] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1f4/0x2f0)
[2.201751] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x64/0x98)
[2.210815] [] (bus_for_each_drv) from [] 
(__device_attach+0xb0/0x118)
[2.219635] [] (__device_attach) from [] 
(bus_probe_device+0x88/0x90)
[2.228363] [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x60/0x90)
[2.237884] [] (deferred_probe_work_func) from [] 
(process_one_work+0x1a4/0x558)
[2.247619] [] (process_one_work) from [] 
(worker_thread+0x3c/0x514)
[2.256256] [] (worker_thread) from [] 
(kthread+0xd4/0xf0)
[2.263946] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)
[2.271606] ---[ end trace 814b02d2fa769522 ]---

-- Sebastian


signature.asc
Description: PGP signature

Re: [RFC PATCH 1/3] arm: plat-omap: dmtimer: Add clock source from DT

2015-10-19 Thread Neil Armstrong

Hi,

On 10/16/2015 05:40 PM, Felipe Balbi wrote:
>> +static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer)
>> +{
>> +int ret;
>> +struct clk *parent;
>> +
>> +if (unlikely(!timer))
>> +return -EINVAL;
> 
> IMO, let this crash. If this happens we have bigger problems.
> 
>> +if (IS_ERR(timer->fclk))
>> +return -EINVAL;
> 
> We bail out if we can't get fclk, this check is unnecessary.

Sure, I will remove the checks.
This was also breaking OMAP1, fclk must be checked against NULL here to detect 
OMAP1 and return -ENODEV;

> 
>> +parent = clk_get(>pdev->dev, NULL);
> 
> why NULL ? You could use something more descriptive, but no strong
> feelings.


Actually, I just wanted the "default" clock for this device, NULL will select 
the first OF clock found.
If we specify a name, we should also specify it in the DT as clock-names, is it 
desired ?
If you feel I should name it somehow... I don't want it to conflict all the 
HWMOD clk namings actually.

> 
>> +if (IS_ERR(parent))
>> +return -ENODEV;
>> +
>> +ret = clk_set_parent(timer->fclk, parent);
>> +if (ret < 0)
>> +pr_err("%s: failed to set parent\n", __func__);
>> +
>> +clk_put(parent);
>> +
>> +return ret;
>> +}
>> +
>>  static int omap_dm_timer_prepare(struct omap_dm_timer *timer)
>>  {
>> -int rc;
>> +int rc, ret;
> 
> doesn't seem like you need this extra 'ret' variable. Just use 'rc'.
> 
>> @@ -166,7 +190,11 @@ static int omap_dm_timer_prepare(struct omap_dm_timer 
>> *timer)
>>  __omap_dm_timer_enable_posted(timer);
>>  omap_dm_timer_disable(timer);
>>
>> -return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
>> +ret = omap_dm_timer_of_set_source(timer);
>> +if (ret < 0 && ret == -ENODEV)
> 
> this < 0 check is pointless if you're going to check for equality to -ENODEV

Sure, I was certainly tired, this was a so stupid mistake...

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

Re: [PATCH v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-19 Thread Lucas Stach

Am Donnerstag, den 15.10.2015, 16:32 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > Install a non-faulting handler just before unmasking imprecise aborts
> > and switch back to the regular one after unmasking is done.
> > 
> > This catches any pending imprecise abort that the firmware/bootloader
> > may have left behind that would normally crash the kernel at that point.
> > As there are apparently a lot of bootlaoders out there that do such a
> > thing it makes sense to handle it in the common startup code.
> > 
> > Signed-off-by: Lucas Stach 
> 
> Much better.  Please feel free to add it to the patch system, thanks.
> 
> I think, given that the original seems to be breaking platforms, this
> patch needs to go into -rc kernels, right?
> 
Okay, this is in the patch system as patch 8447/1 now.

As Russell hasn't said whether he would like to pick up the platform
patches I've omitted them for now and would ask the platform maintainers
to pick them up themselves for kernel 4.4.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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 2/3] iio:adc:palmas: add DT support

2015-10-19 Thread Lars-Peter Clausen

On 10/16/2015 02:53 PM, H. Nikolaus Schaller wrote:
[...]
> +Optional sub-nodes:
> +ti,channel0-current-microamp: Channel 0 current in uA.
> + Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
> +ti,channel3-current-microamp: Channel 3 current in uA.
> + Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
> +ti,enable-extended-delay: Enable extended delay.

Those three above sound more like configuration policy, rather than hardware
description. What influence which values should be chosen?


--
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] irqchip: omap-intc: fix spurious irq handling

2015-10-19 Thread Sekhar Nori

Under some conditions, irq sorting procedure used by INTC can go wrong
resulting in a spurious irq getting reported.

This condition is flagged by INTC by setting "Spurious IRQ Flag" in SIR
register to 0x1ff. Section 6.2.5 of AM335x TRM revised Jun 2014
describes this.

Using IRQ number 0 for checking this condition is wrong. 0 is a valid
INTC IRQ. For example, on AM335x, it is the emulation interrupt.

Fix handing of spurious interrupt condition in omap-intc driver by
correct detection of spurious interrupt condition.

Since spurious IRQ condition can happen under genuine conditions (see
the section of AM335x TRM for details) and is recoverable, we do not
need a warning splat for users to report. It can however result in
reduced performance so we add a ratelimited debug print to aid
developers.

Signed-off-by: Sekhar Nori 
---
 drivers/irqchip/irq-omap-intc.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 8587d0f8d8c0..739725515fab 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* Define these here for now until we drop all board-files */
 #define OMAP24XX_IC_BASE   0x480fe000
@@ -47,6 +49,7 @@
 #define INTC_ILR0  0x0100
 
 #define ACTIVEIRQ_MASK 0x7f/* omap2/3 active interrupt bits */
+#define SPURIOUSIRQ_MASK   (0x1ff << 7)
 #define INTCPS_NR_ILR_REGS 128
 #define INTCPS_NR_MIR_REGS 4
 
@@ -333,8 +336,23 @@ omap_intc_handle_irq(struct pt_regs *regs)
u32 irqnr;
 
irqnr = intc_readl(INTC_SIR);
+
+   /*
+* A spurious IRQ can result if interrupt that triggered the
+* sorting is no longer active during the sorting (10 INTC
+* functional clock cycles after interrupt assertion). Or a
+* change in interrupt mask affected the result during sorting
+* time. There is no special handling required except ignoring
+* the SIR register value just read and retrying.
+* See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
+*/
+   if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
+   pr_debug_ratelimited("%s: spurious irq!\n", __func__);
+   omap_ack_irq(NULL);
+   return;
+   }
+
irqnr &= ACTIVEIRQ_MASK;
-   WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
handle_domain_irq(domain, irqnr, regs);
 }
 
-- 
2.4.4.408.g16da57c

--
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] irqchip: omap-intc: fix spurious irq handling

2015-10-19 Thread Thomas Gleixner

On Mon, 19 Oct 2015, Sekhar Nori wrote:
> + /*
> +  * A spurious IRQ can result if interrupt that triggered the
> +  * sorting is no longer active during the sorting (10 INTC
> +  * functional clock cycles after interrupt assertion). Or a
> +  * change in interrupt mask affected the result during sorting
> +  * time. There is no special handling required except ignoring
> +  * the SIR register value just read and retrying.
> +  * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
> +  */
> + if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
> + pr_debug_ratelimited("%s: spurious irq!\n", __func__);

I'd prefer that this is a pr_once() and the spurious interrupt counter
is incremented. That's far more useful as it gives you real
information about the frequency of the issue.

Thanks,

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

Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

2015-10-19 Thread Lokesh Vutla



On Saturday 17 October 2015 12:53 AM, Tony Lindgren wrote:
> * Lokesh Vutla  [151015 08:21]:

[..snip..]

>>>
> 
> 8< --From c37732f6cea23d15fa357cf698833c03ce05 Mon 
> Sep 17 00:00:00 2001
> Date: Fri, 16 Oct 2015 12:16:21 -0700
> Subject: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory
> 
> On boards with more than 2GB of RAM booting goes wrong with things not
> working and we're getting lots of l3 warnings:
> 
> WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
> l3_interrupt_handler+0x260/0x384()
> 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle):
> Data Access in User mode during Functional access
> ...
> [] (scsi_add_host_with_dma) from []
> (ata_scsi_add_hosts+0x5c/0x18c)
> [] (ata_scsi_add_hosts) from []
> (ata_host_register+0x150/0x2cc)
> [] (ata_host_register) from []
> (ata_host_activate+0xd4/0x124)
> [] (ata_host_activate) from []
> (ahci_host_activate+0x5c/0x194)
> [] (ahci_host_activate) from []
> (ahci_platform_init_host+0x1f0/0x3f0)
> [] (ahci_platform_init_host) from []
> (ahci_probe+0x70/0x98)
> [] (ahci_probe) from []
> (platform_drv_probe+0x54/0xb4)
> 
> Let's fix the issue by enabling ZONE_DMA for LPAE. Note that we need to
> limit dma_zone_size to 2GB as the rest of the RAM is beyond the 4GB limit.
> 
> Let's also fix things for dra7 as done in similar patches in the TI tree
> by Lokesh Vutla .

Looks good to me.
Reviewed-by: Lokesh Vutla 

Since there is a big hole with in the memory space, we might also need
to enable SPARSEMEM ?

Thanks and regards,
Lokesh

> 
> Signed-off-by: Tony Lindgren 
> 
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -49,6 +49,7 @@ config SOC_OMAP5
>   select OMAP_INTERCONNECT
>   select OMAP_INTERCONNECT_BARRIER
>   select PM_OPP if PM
> + select ZONE_DMA if ARM_LPAE
>  
>  config SOC_AM33XX
>   bool "TI AM33XX"
> @@ -78,6 +79,7 @@ config SOC_DRA7XX
>   select OMAP_INTERCONNECT
>   select OMAP_INTERCONNECT_BARRIER
>   select PM_OPP if PM
> + select ZONE_DMA if ARM_LPAE
>  
>  config ARCH_OMAP2PLUS
>   bool
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -243,6 +243,9 @@ static const char *const omap5_boards_compat[] 
> __initconst = {
>  };
>  
>  DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
> +#if defined(CONFIG_ZONE_DMA) && defined(CONFIG_ARM_LPAE)
> + .dma_zone_size  = SZ_2G,
> +#endif
>   .reserve= omap_reserve,
>   .smp= smp_ops(omap4_smp_ops),
>   .map_io = omap5_map_io,
> @@ -288,6 +291,9 @@ static const char *const dra74x_boards_compat[] 
> __initconst = {
>  };
>  
>  DT_MACHINE_START(DRA74X_DT, "Generic DRA74X (Flattened Device Tree)")
> +#if defined(CONFIG_ZONE_DMA) && defined(CONFIG_ARM_LPAE)
> + .dma_zone_size  = SZ_2G,
> +#endif
>   .reserve= omap_reserve,
>   .smp= smp_ops(omap4_smp_ops),
>   .map_io = dra7xx_map_io,
> @@ -308,6 +314,9 @@ static const char *const dra72x_boards_compat[] 
> __initconst = {
>  };
>  
>  DT_MACHINE_START(DRA72X_DT, "Generic DRA72X (Flattened Device Tree)")
> +#if defined(CONFIG_ZONE_DMA) && defined(CONFIG_ARM_LPAE)
> + .dma_zone_size  = SZ_2G,
> +#endif
>   .reserve= omap_reserve,
>   .map_io = dra7xx_map_io,
>   .init_early = dra7xx_init_early,
> 
--
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 3/3] ARM: dts: Add basic support for isee igepv5

2015-10-19 Thread Tony Lindgren

* Pau Pajuel  [151019 06:40]:
> Hi Tony,
> 2015-10-16 16:57 GMT+02:00 Tony Lindgren :
> > >
> > > So far I've tested that basic things work, such as serial, USB
> > > Ethernet, HDMI and WLAN.

Also mSATA works too BTW.

> I am testing your patch without succes. Which u-boot version are you using?

I'm using the isee git tree u-boot with the following enabled in the
omap5_igep0050.h:

#define IGEPv5_MEMORY_4G
#define CONFIG_SUPPORT_RAW_INITRD
#define CONFIG_ENV_IS_IN_FAT
#define FAT_ENV_INTERFACE   "mmc"
#define FAT_ENV_DEVICE  1
#define FAT_ENV_PART1
#define FAT_ENV_FILE"uboot.env"
#define CONFIG_FAT_WRITE

The CONFIG_SUPPORT_RAW_INITRD is needed to support raw initramfs instead of
using mkimage on it for bootz command. I don't think these changes should
affect booting though.

> Do you apply config changes into omap2plus_defconfig

Looks like I only enabled CONFIG_USB_NET_SMSC75XX.

> Here is my setup and log: http://pastebin.com/j51ugRvK

My guess is that you need to play with initrd_high etc, try doing something
like this in u-boot:

setenv fdtaddr 80a0
setenv loadaddr 80c0
setenv rdaddr 8140
setenv fdt_high 8c00
setenv initrd_high 

And see if that helps?

BTW, we really need to use initramfs based booting on these for NFS to
avoid having to compile all the USB into the kernel. Well at least for
the mainline omap2plus_defconfig.

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] irqchip: omap-intc: fix spurious irq handling

2015-10-19 Thread Tony Lindgren

Hi,

* Sekhar Nori  [151019 02:51]:
> Under some conditions, irq sorting procedure used by INTC can go wrong
> resulting in a spurious irq getting reported.
> 
> This condition is flagged by INTC by setting "Spurious IRQ Flag" in SIR
> register to 0x1ff. Section 6.2.5 of AM335x TRM revised Jun 2014
> describes this.

OK so we have this finally documented, that's great. It's been bugging
me for years now :) What we used to have for omap3 was 6ccc4c0dedf8
("ARM: OMAP3: Warn about spurious interrupts"). I alsways thought it's
some undocumented omap3 weirdness but obviously not if you're seeing it
on am335x too.

> Using IRQ number 0 for checking this condition is wrong. 0 is a valid
> INTC IRQ. For example, on AM335x, it is the emulation interrupt.
> 
> Fix handing of spurious interrupt condition in omap-intc driver by
> correct detection of spurious interrupt condition.
> 
> Since spurious IRQ condition can happen under genuine conditions (see
> the section of AM335x TRM for details) and is recoverable, we do not
> need a warning splat for users to report. It can however result in
> reduced performance so we add a ratelimited debug print to aid
> developers.

Do you know what really is causing the spurious interrupts in your
case?

In all the cases I've seen, the spurious interrupts were caused by
a missing flush of posted write acking the IRQ at the device driver.
for the _previously triggered_ INTC interrupt.

If you have a reproducable case, I suggest you test that by printing
out the previous interrupt to check if that makes sense. And then see
if adding the missing read back to that interrupt handler fixes the
issue.

And if my assumption is correct, you can then update your patch and
actually warn about the real culprit irq number :)

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

[RFC PATCH v2 1/3] arm: plat-omap: dmtimer: Add clock source from DT

2015-10-19 Thread Neil Armstrong

Add a function which sets the timer source from the clocks
binding on dm_timer_prepare call.

In case the clocks property is not valid, it falls back to
the set_source() with 32_KHZ clock as default.

Suggested-by: Tony Lindgren 
Signed-off-by: Neil Armstrong 
---
 arch/arm/plat-omap/dmtimer.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 8ca94d3..7c7f260 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -137,6 +137,31 @@ static int omap_dm_timer_reset(struct omap_dm_timer *timer)
return 0;
 }

+static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer)
+{
+   int ret;
+   struct clk *parent;
+
+   /*
+* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
+* do not call clk_get() for these devices.
+*/
+   if (!timer->fclk)
+   return -ENODEV;
+
+   parent = clk_get(>pdev->dev, NULL);
+   if (IS_ERR(parent))
+   return -ENODEV;
+
+   ret = clk_set_parent(timer->fclk, parent);
+   if (ret < 0)
+   pr_err("%s: failed to set parent\n", __func__);
+
+   clk_put(parent);
+
+   return ret;
+}
+
 static int omap_dm_timer_prepare(struct omap_dm_timer *timer)
 {
int rc;
@@ -166,7 +191,11 @@ static int omap_dm_timer_prepare(struct omap_dm_timer 
*timer)
__omap_dm_timer_enable_posted(timer);
omap_dm_timer_disable(timer);

-   return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+   rc = omap_dm_timer_of_set_source(timer);
+   if (rc == -ENODEV)
+   return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+
+   return rc;
 }

 static inline u32 omap_dm_timer_reserved_systimer(int id)
-- 
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

[RFC PATCH v2 3/3] arm: plat-omap: Add PWM dmtimer platform data quirks

2015-10-19 Thread Neil Armstrong

In order to set the currently platform dependent dmtimer
functions pointers as platform data for the pwm-omap-dmtimer
platform driver, add it to plat-omap auxdata_lookup table.

Suggested-by: Tony Lindgren 
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-omap2/pdata-quirks.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ea56397..647dec5 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
@@ -453,6 +455,24 @@ void omap_auxdata_legacy_init(struct device *dev)
dev->platform_data = _gpio_auxdata;
 }

+/* Dual mode timer PWM callbacks platdata */
+#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
+struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
+   .request_by_node = omap_dm_timer_request_by_node,
+   .free = omap_dm_timer_free,
+   .enable = omap_dm_timer_enable,
+   .disable = omap_dm_timer_disable,
+   .get_fclk = omap_dm_timer_get_fclk,
+   .start = omap_dm_timer_start,
+   .stop = omap_dm_timer_stop,
+   .set_load = omap_dm_timer_set_load,
+   .set_match = omap_dm_timer_set_match,
+   .set_pwm = omap_dm_timer_set_pwm,
+   .set_prescaler = omap_dm_timer_set_prescaler,
+   .write_counter = omap_dm_timer_write_counter,
+};
+#endif
+
 /*
  * Few boards still need auxdata populated before we populate
  * the dev entries in of_platform_populate().
@@ -506,6 +526,9 @@ static struct of_dev_auxdata omap_auxdata_lookup[] 
__initdata = {
OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d0, "44d0.wkup_m3",
   _m3_data),
 #endif
+#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
+   OF_DEV_AUXDATA("ti,omap-dmtimer-pwm", 0, NULL, _dmtimer_pdata),
+#endif
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
   _iommu_pdata),
-- 
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

[RFC PATCH v2 0/3] pwm: omap: Add PWM support using dual-mode timers

2015-10-19 Thread Neil Armstrong

This patch is based on an earlier patch by NeilBrown which is based on
a older patch from Grant Erickson which provided PWM devices using
the 'legacy' interface.

The pwm driver was renamed to not be confused with the OMAP4 PWM dedicated
hardware and was cleaned with the review from Thierry Reding.

The first patch introduces a way to select to dmtimer clock source via a
clocks binding and a dedicated function wit the legacy fallback.

In order to prepare for the future form of the dmtimer (clksource or whatever),
and less rely on specific bindings the first patch introduces the PWM driver
with all the dmtimer calls into a platform data structure.

The structure is then filled in plat-omap and added as auxdata for the
ti,pwm-dmtimer-omap compatible nodes.

Suggested-by: Tony Lindgren 

v2: fix dmtimer of clock handling, fix binding doc example

Neil Armstrong (3):
  arm: plat-omap: dmtimer: Add clock source from DT
  pwm: Add PWM driver for OMAP using dual-mode timers
  arm: plat-omap: Add PWM dmtimer platform data quirks

 .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt   |  18 ++
 arch/arm/mach-omap2/pdata-quirks.c |  23 ++
 arch/arm/plat-omap/dmtimer.c   |  31 +-
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-omap-dmtimer.c | 322 +
 include/linux/platform_data/pwm_omap_dmtimer.h |  69 +
 7 files changed, 472 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
 create mode 100644 drivers/pwm/pwm-omap-dmtimer.c
 create mode 100644 include/linux/platform_data/pwm_omap_dmtimer.h

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

[RFC PATCH v2 2/3] pwm: Add PWM driver for OMAP using dual-mode timers

2015-10-19 Thread Neil Armstrong

Adds support for using a OMAP dual-mode timer with PWM capability
as a Linux PWM device. The driver controls the timer by using the
dmtimer API.

Add a platform_data structure for each pwm-omap-dmtimer nodes containing
the dmtimers functions in order to get driver not rely on platform
specific functions.

Cc: Grant Erickson 
Cc: NeilBrown 
Cc: Joachim Eastwood 
Suggested-by: Tony Lindgren 
Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt   |  18 ++
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-omap-dmtimer.c | 322 +
 include/linux/platform_data/pwm_omap_dmtimer.h |  69 +
 5 files changed, 419 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
 create mode 100644 drivers/pwm/pwm-omap-dmtimer.c
 create mode 100644 include/linux/platform_data/pwm_omap_dmtimer.h

diff --git a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt 
b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
new file mode 100644
index 000..5befb53
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
@@ -0,0 +1,18 @@
+* OMAP PWM for dual-mode timers
+
+Required properties:
+- compatible: Shall contain "ti,omap-dmtimer-pwm".
+- ti,timers: phandle to PWM capable OMAP timer. See arm/omap/timer.txt for info
+  about these timers.
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+  the cells format.
+
+Optional properties:
+- ti,prescaler: Should be a value between 0 and 7, see the timers datasheet
+
+Example:
+   pwm9: dmtimer-pwm@9 {
+   compatible = "ti,omap-dmtimer-pwm";
+   ti,timers = <>;
+   #pwm-cells = <3>;
+   };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 062630a..2da60f8 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -240,6 +240,15 @@ config PWM_MXS
  To compile this driver as a module, choose M here: the module
  will be called pwm-mxs.

+config PWM_OMAP_DMTIMER
+   tristate "OMAP Dual-Mode Timer PWM support"
+   depends on OF && ARCH_OMAP && OMAP_DM_TIMER
+   help
+ Generic PWM framework driver for OMAP Dual-Mode Timer PWM output
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap-dmtimer
+
 config PWM_PCA9685
tristate "NXP PCA9685 PWM driver"
depends on OF && I2C
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a0e00c0..af14774 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PWM_LPSS)+= pwm-lpss.o
 obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
 obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o
 obj-$(CONFIG_PWM_MXS)  += pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
 obj-$(CONFIG_PWM_PCA9685)  += pwm-pca9685.o
 obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
 obj-$(CONFIG_PWM_PXA)  += pwm-pxa.o
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
new file mode 100644
index 000..c1a4967
--- /dev/null
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -0,0 +1,322 @@
+/*
+ *Copyright (c) 2015 Neil Armstrong 
+ *Copyright (c) 2014 Joachim Eastwood 
+ *Copyright (c) 2012 NeilBrown 
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson 
+ *
+ *Also based on pwm-samsung.c
+ *
+ *This program is free software; you can redistribute it and/or
+ *modify it under the terms of the GNU General Public License
+ *version 2 as published by the Free Software Foundation.
+ *
+ *Description:
+ *  This file is the core OMAP support for the generic, Linux
+ *  PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DM_TIMER_LOAD_MIN  0xFFFE
+
+struct pwm_omap_dmtimer_chip {
+   struct pwm_chip chip;
+   struct mutexmutex;
+   pwm_omap_dmtimer*dm_timer;
+   struct pwm_omap_dmtimer_pdata   *pdata;
+   struct platform_device  *dm_timer_pdev;
+};
+
+#define to_pwm_omap_dmtimer_chip(chip) container_of(chip,\
+   struct pwm_omap_dmtimer_chip, chip)
+
+static int pwm_omap_dmtimer_calc_value(unsigned long clk_rate, int ns)
+{
+   u64 c;
+
+   c = (u64)clk_rate * ns;
+   do_div(c, NSEC_PER_SEC);
+
+   return DM_TIMER_LOAD_MIN - c;
+}
+
+static void pwm_omap_dmtimer_start(struct pwm_omap_dmtimer_chip *omap)
+{

[PATCH 1/3] ARM: dts: omap3-igep0020: Use IOPAD pinmux macro

2015-10-19 Thread Javier Martinez Canillas

Use the OMAP3 pinmux IOPAD macro to define the physical address instead
of the offset from the padconf address. It makes the DTS easier to read
since matches the addresses listed in the Technical Reference Manual.

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/omap3-igep0020-common.dtsi | 58 ++--
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020-common.dtsi 
b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
index 5ad688c57a00..17bf58fb9520 100644
--- a/arch/arm/boot/dts/omap3-igep0020-common.dtsi
+++ b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
@@ -111,40 +111,40 @@
 
tfp410_pins: pinmux_tfp410_pins {
pinctrl-single,pins = <
-   0x196 (PIN_OUTPUT | MUX_MODE4)   /* hdq_sio.gpio_170 */
+   OMAP3_CORE1_IOPAD(0x21c6, PIN_OUTPUT | MUX_MODE4)   /* 
hdq_sio.gpio_170 */
>;
};
 
dss_dpi_pins: pinmux_dss_dpi_pins {
pinctrl-single,pins = <
-   0x0a4 (PIN_OUTPUT | MUX_MODE0)   /* dss_pclk.dss_pclk */
-   0x0a6 (PIN_OUTPUT | MUX_MODE0)   /* dss_hsync.dss_hsync 
*/
-   0x0a8 (PIN_OUTPUT | MUX_MODE0)   /* dss_vsync.dss_vsync 
*/
-   0x0aa (PIN_OUTPUT | MUX_MODE0)   /* 
dss_acbias.dss_acbias */
-   0x0ac (PIN_OUTPUT | MUX_MODE0)   /* dss_data0.dss_data0 
*/
-   0x0ae (PIN_OUTPUT | MUX_MODE0)   /* dss_data1.dss_data1 
*/
-   0x0b0 (PIN_OUTPUT | MUX_MODE0)   /* dss_data2.dss_data2 
*/
-   0x0b2 (PIN_OUTPUT | MUX_MODE0)   /* dss_data3.dss_data3 
*/
-   0x0b4 (PIN_OUTPUT | MUX_MODE0)   /* dss_data4.dss_data4 
*/
-   0x0b6 (PIN_OUTPUT | MUX_MODE0)   /* dss_data5.dss_data5 
*/
-   0x0b8 (PIN_OUTPUT | MUX_MODE0)   /* dss_data6.dss_data6 
*/
-   0x0ba (PIN_OUTPUT | MUX_MODE0)   /* dss_data7.dss_data7 
*/
-   0x0bc (PIN_OUTPUT | MUX_MODE0)   /* dss_data8.dss_data8 
*/
-   0x0be (PIN_OUTPUT | MUX_MODE0)   /* dss_data9.dss_data9 
*/
-   0x0c0 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data10.dss_data10 */
-   0x0c2 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data11.dss_data11 */
-   0x0c4 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data12.dss_data12 */
-   0x0c6 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data13.dss_data13 */
-   0x0c8 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data14.dss_data14 */
-   0x0ca (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data15.dss_data15 */
-   0x0cc (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data16.dss_data16 */
-   0x0ce (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data17.dss_data17 */
-   0x0d0 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data18.dss_data18 */
-   0x0d2 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data19.dss_data19 */
-   0x0d4 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data20.dss_data20 */
-   0x0d6 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data21.dss_data21 */
-   0x0d8 (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data22.dss_data22 */
-   0x0da (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data23.dss_data23 */
+   OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_pclk.dss_pclk */
+   OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_hsync.dss_hsync */
+   OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_vsync.dss_vsync */
+   OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* 
dss_acbias.dss_acbias */
+   OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data0.dss_data0 */
+   OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data1.dss_data1 */
+   OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data2.dss_data2 */
+   OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data3.dss_data3 */
+   OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data4.dss_data4 */
+   OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data5.dss_data5 */
+   OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data6.dss_data6 */
+   OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data7.dss_data7 */
+   OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data8.dss_data8 */
+   OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data9.dss_data9 */
+   OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data10.dss_data10 */
+

Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

2015-10-19 Thread Tony Lindgren

* Lokesh Vutla  [151019 07:03]:
> 
> Since there is a big hole with in the memory space, we might also need
> to enable SPARSEMEM ?

No from what I remember that depends on section sizes and smaller
chunks of physical memory. For example, on the old Psions we had to
use DISCONTIGMEM/SPARSEMEM because of four discontiguous 8MB memory
chips.

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] ARM: dts: omap3: keep ssi ports by default

2015-10-19 Thread Tony Lindgren

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

Regards,

Tony


> 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

[PATCH 2/3] ARM: dts: am335x-igep0033: Use IOPAD pinmux macro

2015-10-19 Thread Javier Martinez Canillas

Use the AM33xx pinmux IOPAD macro to define the physical address instead
of the offset from the padconf address. It makes the DTS easier to read
since matches the addresses listed in the Technical Reference Manual.

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/am335x-igep0033.dtsi | 40 +-
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi 
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index c0e1135256cc..54f113546ecc 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -56,41 +56,41 @@
 _pinmux {
i2c0_pins: pinmux_i2c0_pins {
pinctrl-single,pins = <
-   0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
i2c0_sda.i2c0_sda */
-   0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
i2c0_scl.i2c0_scl */
+   AM33XX_IOPAD(0x988, PIN_INPUT_PULLUP | MUX_MODE0)   
/* i2c0_sda.i2c0_sda */
+   AM33XX_IOPAD(0x98c, PIN_INPUT_PULLUP | MUX_MODE0)   
/* i2c0_scl.i2c0_scl */
>;
};
 
nandflash_pins: pinmux_nandflash_pins {
pinctrl-single,pins = <
-   0x0 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad0.gpmc_ad0 */
-   0x4 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad1.gpmc_ad1 */
-   0x8 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad2.gpmc_ad2 */
-   0xc (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad3.gpmc_ad3 */
-   0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad4.gpmc_ad4 */
-   0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad5.gpmc_ad5 */
-   0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad6.gpmc_ad6 */
-   0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad7.gpmc_ad7 */
-   0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_wait0.gpmc_wait0 */
-   0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /* 
gpmc_wpn.gpio0_30 */
-   0x7c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn0.gpmc_csn0 */
-   0x90 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_advn_ale.gpmc_advn_ale */
-   0x94 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_oen_ren.gpmc_oen_ren */
-   0x98 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_wen.gpmc_wen */
-   0x9c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_be0n_cle.gpmc_be0n_cle */
+   AM33XX_IOPAD(0x800, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad0.gpmc_ad0 */
+   AM33XX_IOPAD(0x804, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad1.gpmc_ad1 */
+   AM33XX_IOPAD(0x808, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad2.gpmc_ad2 */
+   AM33XX_IOPAD(0x80c, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad3.gpmc_ad3 */
+   AM33XX_IOPAD(0x810, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad4.gpmc_ad4 */
+   AM33XX_IOPAD(0x814, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad5.gpmc_ad5 */
+   AM33XX_IOPAD(0x818, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad6.gpmc_ad6 */
+   AM33XX_IOPAD(0x81c, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_ad7.gpmc_ad7 */
+   AM33XX_IOPAD(0x870, PIN_INPUT_PULLUP | MUX_MODE0)   
/* gpmc_wait0.gpmc_wait0 */
+   AM33XX_IOPAD(0x874, PIN_INPUT_PULLUP | MUX_MODE7)   
/* gpmc_wpn.gpio0_30 */
+   AM33XX_IOPAD(0x87c, PIN_OUTPUT | MUX_MODE0) 
/* gpmc_csn0.gpmc_csn0 */
+   AM33XX_IOPAD(0x890, PIN_OUTPUT | MUX_MODE0) 
/* gpmc_advn_ale.gpmc_advn_ale */
+   AM33XX_IOPAD(0x894, PIN_OUTPUT | MUX_MODE0) 
/* gpmc_oen_ren.gpmc_oen_ren */
+   AM33XX_IOPAD(0x898, PIN_OUTPUT | MUX_MODE0) 
/* gpmc_wen.gpmc_wen */
+   AM33XX_IOPAD(0x89c, PIN_OUTPUT | MUX_MODE0) 
/* gpmc_be0n_cle.gpmc_be0n_cle */
>;
};
 
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
-   0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
uart0_rxd.uart0_rxd */
-   0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
uart0_txd.uart0_txd */
+   AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)   
/* uart0_rxd.uart0_rxd */
+   AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
/* uart0_txd.uart0_txd */
>;
};
 
leds_pins: pinmux_leds_pins {
pinctrl-single,pins = <
-   0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7)  /* 
gpmc_a7.gpio1_23 */
+   AM33XX_IOPAD(0x85c,

[PATCH 0/3] ARM: dts: Use IOPAD pinmux for IGEP boards

2015-10-19 Thread Javier Martinez Canillas

Hello,

This series use the IOPAD pinmux macros for the remaining IGEP boards that
still used the register offset instead of the physical address using these
macros so the DTS matches what is in the Technical Reference Manual.

The changes are only cosmetic since they make the DTS easier to read but
does not change functionality. I built tested and compared the binary DTB
MD5 checksum and both matches before and after the series applied:

Before

d7a56205bdc54365d49d9a90dfe3fafb  am335x-base0033.dtb
fa272fcdee65d7bf4c03bd5a6c5ec4fd  omap3-igep0020.dtb
ba65bf74d8c6ea8e7bd8face17179e6e  omap3-igep0020-rev-f.dtb

After

d7a56205bdc54365d49d9a90dfe3fafb  am335x-base0033.dtb
fa272fcdee65d7bf4c03bd5a6c5ec4fd  omap3-igep0020.dtb
ba65bf74d8c6ea8e7bd8face17179e6e  omap3-igep0020-rev-f.dtb

Best regards,
Javier


Javier Martinez Canillas (3):
  ARM: dts: omap3-igep0020: Use IOPAD pinmux macro
  ARM: dts: am335x-igep0033: Use IOPAD pinmux macro
  ARM: dts: am335x-base0033: Use IOPAD pinmux macro

 arch/arm/boot/dts/am335x-base0033.dts| 48 +++
 arch/arm/boot/dts/am335x-igep0033.dtsi   | 40 +--
 arch/arm/boot/dts/omap3-igep0020-common.dtsi | 58 ++--
 3 files changed, 73 insertions(+), 73 deletions(-)

-- 
2.4.3

--
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: am335x-base0033: Use IOPAD pinmux macro

2015-10-19 Thread Javier Martinez Canillas

Use the AM33XX pinmux IOPAD macro to define the physical address instead
of the offset from the padconf address. It makes the DTS easier to read
since matches the addresses listed in the Technical Reference Manual.

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/am335x-base0033.dts | 48 +--
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-base0033.dts 
b/arch/arm/boot/dts/am335x-base0033.dts
index 72a9b3fc4251..58a05f7d0b7c 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -46,39 +46,39 @@
 _pinmux {
nxp_hdmi_pins: pinmux_nxp_hdmi_pins {
pinctrl-single,pins = <
-   0x1b0 (PIN_OUTPUT | MUX_MODE3)  /* 
xdma_event_intr0.clkout1 */
-   0xa0 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data0 */
-   0xa4 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data1 */
-   0xa8 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data2 */
-   0xac (PIN_OUTPUT | MUX_MODE0)   /* lcd_data3 */
-   0xb0 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data4 */
-   0xb4 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data5 */
-   0xb8 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data6 */
-   0xbc (PIN_OUTPUT | MUX_MODE0)   /* lcd_data7 */
-   0xc0 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data8 */
-   0xc4 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data9 */
-   0xc8 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data10 */
-   0xcc (PIN_OUTPUT | MUX_MODE0)   /* lcd_data11 */
-   0xd0 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data12 */
-   0xd4 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data13 */
-   0xd8 (PIN_OUTPUT | MUX_MODE0)   /* lcd_data14 */
-   0xdc (PIN_OUTPUT | MUX_MODE0)   /* lcd_data15 */
-   0xe0 (PIN_OUTPUT | MUX_MODE0)   /* lcd_vsync */
-   0xe4 (PIN_OUTPUT | MUX_MODE0)   /* lcd_hsync */
-   0xe8 (PIN_OUTPUT | MUX_MODE0)   /* lcd_pclk */
-   0xec (PIN_OUTPUT | MUX_MODE0)   /* lcd_ac_bias_en */
+   AM33XX_IOPAD(0x9b0, PIN_OUTPUT | MUX_MODE3) /* 
xdma_event_intr0.clkout1 */
+   AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data0 */
+   AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data1 */
+   AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data2 */
+   AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data3 */
+   AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data4 */
+   AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data5 */
+   AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data6 */
+   AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data7 */
+   AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data8 */
+   AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data9 */
+   AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data10 */
+   AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data11 */
+   AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data12 */
+   AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data13 */
+   AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data14 */
+   AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE0) /* 
lcd_data15 */
+   AM33XX_IOPAD(0x8e0, PIN_OUTPUT | MUX_MODE0) /* 
lcd_vsync */
+   AM33XX_IOPAD(0x8e4, PIN_OUTPUT | MUX_MODE0) /* 
lcd_hsync */
+   AM33XX_IOPAD(0x8e8, PIN_OUTPUT | MUX_MODE0) /* 
lcd_pclk */
+   AM33XX_IOPAD(0x8ec, PIN_OUTPUT | MUX_MODE0) /* 
lcd_ac_bias_en */
>;
};
nxp_hdmi_off_pins: pinmux_nxp_hdmi_off_pins {
pinctrl-single,pins = <
-   0x1b0 (PIN_OUTPUT | MUX_MODE3)  /* 
xdma_event_intr0.clkout1 */
+   AM33XX_IOPAD(0x9b0, PIN_OUTPUT | MUX_MODE3) /* 
xdma_event_intr0.clkout1 */
>;
};
 
leds_base_pins: pinmux_leds_base_pins {
pinctrl-single,pins = <
-   0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7)  /* 
gpmc_a5.gpio1_21 */
-   0x88 (PIN_OUTPUT_PULLDOWN | MUX_MODE7)  /* 
gpmc_csn3.gpio2_0 */
+   AM33XX_IOPAD(0x854, PIN_OUTPUT_PULLDOWN | MUX_MODE7)
/* gpmc_a5.gpio1_21 */
+   AM33XX_IOPAD(0x888, PIN_OUTPUT_PULLDOWN | MUX_MODE7)
/*

Re: [PATCH v2 2/3] ARM: dts: AM43x-epos-evm: Add AM438x compatible string for epos

2015-10-19 Thread Tony Lindgren

* Keerthy  [151014 22:14]:
> Add AM438x compatible property to identify the SoCs on epos evms.
> 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v2:
> 
>   * Rebased to latest 4.3-rc5
> 
>  Documentation/devicetree/bindings/arm/omap/omap.txt | 5 -
>  arch/arm/boot/dts/am43x-epos-evm.dts| 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 9f4e513..dc3b5f2 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -100,6 +100,9 @@ SoCs:
>  - AM4372
>compatible = "ti,am4372", "ti,am43"
>  
> +- AM438x
> +  compatible = "ti,am438x", "ti,am43"
> +

The compatible strings should not have x, this should be
"ti,am438" instead. But my guess is that we are better off
adding proper SoC detection to avoid needing a separate dts
file for each SoC revision. Ideally booting with "ti,am43"
should be enough and we can initialize the rest during
runtime.

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: [BISECTED] Nokia 770 framebuffer breakage

2015-10-19 Thread Russell King - ARM Linux

On Mon, Oct 19, 2015 at 10:37:59PM +0300, Aaro Koskinen wrote:
> Hi,
> 
> Somewhere between 4.1 .. 4.3-rc6 framebuffer on Nokia 770 stopped working.
> 
> Bisection points to:
> 
> commit 2568999835d7797afce3dcc3a3f368051ffcaf1f
> Author: Russell King 
> Date:   Mon Mar 2 15:40:29 2015 +
> 
> clkdev: add clkdev_create() helper
> 
> The commit cannot be reverted cleanly from current trees, but I re-tested
> that commit 2568999835d7797afce3dcc3a3f368051ffcaf1f does not work and
> commit 2568999835d7797afce3dcc3a3f368051ffcaf1f^1 indeed works.

Really need more information than that, like a kernel log or something.

clk_register_clkdev() should not have changed in any way, since the
change there effectively changes the sequence from:

va_start(ap, dev_fmt);
-   cl = vclkdev_alloc(__clk_get_hw(clk), con_id, dev_fmt, ap);
va_end(ap);
-   if (!cl)
-   return -ENOMEM;
-   clkdev_add(cl);
-   return 0;

to:

va_start(ap, dev_fmt);
+   cl = vclkdev_alloc(__clk_get_hw(clk), con_id, dev_fmt, ap);
+   if (cl)
+   __clkdev_add(cl);
va_end(ap);
+   return cl ? 0 : -ENOMEM;

So I'm guessing this isn't the problem.

However, clk_add_alias() changes slightly, from:

fmt = alias_dev_name;
va_start(ap, fmt);
l = vclkdev_alloc(__clk_get_hw(clk), con_id, fmt, ap)
va_end(ap);
-   if (!l)
-   return -ENODEV;
-   clkdev_add(l);
-   return 0;

to (effectively):

fmt = "%s"
va_start(ap, fmt);
cl = vclkdev_alloc(__clk_get_hw(clk), con_id, fmt, ap);
if (cl)
clkdev_add(cl);
va_end(ap);
+   return l ? 0 : -ENODEV;

In other words, there's the addition of a "%s" in the format string
which wasn't there before - which is reasonable as clk_add_alias()
doesn't take a format string.  This should improve the safety of the
function.

I guess things might go wrong if you pass a NULL alias device name?

Can you try this patch please?

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index c0eaf0973bd2..779b6ff0c7ad 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -333,7 +333,8 @@ int clk_add_alias(const char *alias, const char 
*alias_dev_name,
if (IS_ERR(r))
return PTR_ERR(r);
 
-   l = clkdev_create(r, alias, "%s", alias_dev_name);
+   l = clkdev_create(r, alias, alias_dev_name ? "%s" : NULL,
+ alias_dev_name);
clk_put(r);
 
return l ? 0 : -ENODEV;


-- 
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/RESEND] ARM: Remove __ref on hotplug cpu die path

2015-10-19 Thread Stephen Boyd

Now that __cpuinit has been removed, the __ref markings on these
functions are useless. Remove them. This also reduces the size of
the multi_v7_defconfig image:

$ size before after
   textdata bss dec hex filename
   126835781470996  348904 14503478 dd4e36 before
   126832741470996  348904 14503174 dd4d06 after

presumably because now we don't have to jump to code in the
.ref.text section and/or the noinline marking is removed.

Cc: Tony Lindgren 
Acked-by: Barry Song 
Acked-by: Andy Gross 
Acked-by: Viresh Kumar 
Cc: Shiraz Hashim 
Cc: Stephen Warren 
Acked-by: Thierry Reding 
Cc: Alexandre Courbot 
Acked-by: Linus Walleij 
Acked-by: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: 
Cc: 
Cc: 
Cc: 
Signed-off-by: Stephen Boyd 
---

Collected the acks and resent.

 arch/arm/kernel/psci_smp.c   | 4 ++--
 arch/arm/mach-omap2/omap-hotplug.c   | 2 +-
 arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
 arch/arm/mach-prima2/hotplug.c   | 2 +-
 arch/arm/mach-qcom/platsmp.c | 2 +-
 arch/arm/mach-realview/hotplug.c | 2 +-
 arch/arm/mach-spear/hotplug.c| 2 +-
 arch/arm/mach-tegra/hotplug.c| 2 +-
 arch/arm/mach-ux500/hotplug.c| 2 +-
 arch/arm/mach-vexpress/hotplug.c | 2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
index 61c04b02faeb..9d479b2ea40d 100644
--- a/arch/arm/kernel/psci_smp.c
+++ b/arch/arm/kernel/psci_smp.c
@@ -71,7 +71,7 @@ int psci_cpu_disable(unsigned int cpu)
return 0;
 }
 
-void __ref psci_cpu_die(unsigned int cpu)
+void psci_cpu_die(unsigned int cpu)
 {
u32 state = PSCI_POWER_STATE_TYPE_POWER_DOWN <<
PSCI_0_2_POWER_STATE_TYPE_SHIFT;
@@ -83,7 +83,7 @@ void __ref psci_cpu_die(unsigned int cpu)
panic("psci: cpu %d failed to shutdown\n", cpu);
 }
 
-int __ref psci_cpu_kill(unsigned int cpu)
+int psci_cpu_kill(unsigned int cpu)
 {
int err, i;
 
diff --git a/arch/arm/mach-omap2/omap-hotplug.c 
b/arch/arm/mach-omap2/omap-hotplug.c
index 971791fe9a3f..593fec753b28 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -27,7 +27,7 @@
  * platform-specific code to shutdown a CPU
  * Called with IRQs disabled
  */
-void __ref omap4_cpu_die(unsigned int cpu)
+void omap4_cpu_die(unsigned int cpu)
 {
unsigned int boot_cpu = 0;
void __iomem *base = omap_get_wakeupgen_base();
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
b/arch/arm/mach-omap2/omap-wakeupgen.c
index db7e0bab3587..2da0d974f2f7 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -330,7 +330,7 @@ static int irq_cpu_hotplug_notify(struct notifier_block 
*self,
return NOTIFY_OK;
 }
 
-static struct notifier_block __refdata irq_hotplug_notifier = {
+static struct notifier_block irq_hotplug_notifier = {
.notifier_call = irq_cpu_hotplug_notify,
 };
 
diff --git a/arch/arm/mach-prima2/hotplug.c b/arch/arm/mach-prima2/hotplug.c
index 0ab2f8bae28e..a728c78b996f 100644
--- a/arch/arm/mach-prima2/hotplug.c
+++ b/arch/arm/mach-prima2/hotplug.c
@@ -32,7 +32,7 @@ static inline void platform_do_lowpower(unsigned int cpu)
  *
  * Called with IRQs disabled
  */
-void __ref sirfsoc_cpu_die(unsigned int cpu)
+void sirfsoc_cpu_die(unsigned int cpu)
 {
platform_do_lowpower(cpu);
 }
diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
index 5cde63a64b34..9b00123a315d 100644
--- a/arch/arm/mach-qcom/platsmp.c
+++ b/arch/arm/mach-qcom/platsmp.c
@@ -49,7 +49,7 @@ extern void secondary_startup_arm(void);
 static DEFINE_SPINLOCK(boot_lock);
 
 #ifdef CONFIG_HOTPLUG_CPU
-static void __ref qcom_cpu_die(unsigned int cpu)
+static void qcom_cpu_die(unsigned int cpu)
 {
wfi();
 }
diff --git a/arch/arm/mach-realview/hotplug.c b/arch/arm/mach-realview/hotplug.c
index ac22dd41b135..968e2d1964f6 100644
--- a/arch/arm/mach-realview/hotplug.c
+++ b/arch/arm/mach-realview/hotplug.c
@@ -90,7 +90,7 @@ static inline void platform_do_lowpower(unsigned int cpu, int 
*spurious)
  *
  * Called with IRQs disabled
  */
-void __ref realview_cpu_die(unsigned int cpu)
+void realview_cpu_die(unsigned int cpu)
 {
int spurious = 0;
 
diff --git a/arch/arm/mach-spear/hotplug.c b/arch/arm/mach-spear/hotplug.c
index d97749c642ce..12edd1cf8a12 100644
--- a/arch/arm/mach-spear/hotplug.c
+++ b/arch/arm/mach-spear/hotplug.c
@@ -80,7 +80,7 @@ static inline void

Re: [PATCH/RESEND] ARM: Remove __ref on hotplug cpu die path

2015-10-19 Thread Tony Lindgren

* Mark Rutland  [151019 13:27]:
> On Mon, Oct 19, 2015 at 01:05:33PM -0700, Stephen Boyd wrote:
> > Now that __cpuinit has been removed, the __ref markings on these
> > functions are useless. Remove them. This also reduces the size of
> > the multi_v7_defconfig image:
> > 
> > $ size before after
> >textdata bss dec hex filename
> >126835781470996  348904 14503478 dd4e36 before
> >126832741470996  348904 14503174 dd4d06 after
> > 
> > presumably because now we don't have to jump to code in the
> > .ref.text section and/or the noinline marking is removed.
> 
> FWIW:
> 
> Acked-by: Mark Rutland 

And if you need even more acks:

Acked-by: Tony Lindgren 
--
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/RESEND] ARM: Remove __ref on hotplug cpu die path

2015-10-19 Thread Mark Rutland

On Mon, Oct 19, 2015 at 01:05:33PM -0700, Stephen Boyd wrote:
> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
> 
> $ size before after
>textdata bss dec hex filename
>126835781470996  348904 14503478 dd4e36 before
>126832741470996  348904 14503174 dd4d06 after
> 
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.

FWIW:

Acked-by: Mark Rutland 

Mark.

> Cc: Tony Lindgren 
> Acked-by: Barry Song 
> Acked-by: Andy Gross 
> Acked-by: Viresh Kumar 
> Cc: Shiraz Hashim 
> Cc: Stephen Warren 
> Acked-by: Thierry Reding 
> Cc: Alexandre Courbot 
> Acked-by: Linus Walleij 
> Acked-by: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Mark Rutland 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Collected the acks and resent.
> 
>  arch/arm/kernel/psci_smp.c   | 4 ++--
>  arch/arm/mach-omap2/omap-hotplug.c   | 2 +-
>  arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
>  arch/arm/mach-prima2/hotplug.c   | 2 +-
>  arch/arm/mach-qcom/platsmp.c | 2 +-
>  arch/arm/mach-realview/hotplug.c | 2 +-
>  arch/arm/mach-spear/hotplug.c| 2 +-
>  arch/arm/mach-tegra/hotplug.c| 2 +-
>  arch/arm/mach-ux500/hotplug.c| 2 +-
>  arch/arm/mach-vexpress/hotplug.c | 2 +-
>  10 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> index 61c04b02faeb..9d479b2ea40d 100644
> --- a/arch/arm/kernel/psci_smp.c
> +++ b/arch/arm/kernel/psci_smp.c
> @@ -71,7 +71,7 @@ int psci_cpu_disable(unsigned int cpu)
>   return 0;
>  }
>  
> -void __ref psci_cpu_die(unsigned int cpu)
> +void psci_cpu_die(unsigned int cpu)
>  {
>   u32 state = PSCI_POWER_STATE_TYPE_POWER_DOWN <<
>   PSCI_0_2_POWER_STATE_TYPE_SHIFT;
> @@ -83,7 +83,7 @@ void __ref psci_cpu_die(unsigned int cpu)
>   panic("psci: cpu %d failed to shutdown\n", cpu);
>  }
>  
> -int __ref psci_cpu_kill(unsigned int cpu)
> +int psci_cpu_kill(unsigned int cpu)
>  {
>   int err, i;
>  
> diff --git a/arch/arm/mach-omap2/omap-hotplug.c 
> b/arch/arm/mach-omap2/omap-hotplug.c
> index 971791fe9a3f..593fec753b28 100644
> --- a/arch/arm/mach-omap2/omap-hotplug.c
> +++ b/arch/arm/mach-omap2/omap-hotplug.c
> @@ -27,7 +27,7 @@
>   * platform-specific code to shutdown a CPU
>   * Called with IRQs disabled
>   */
> -void __ref omap4_cpu_die(unsigned int cpu)
> +void omap4_cpu_die(unsigned int cpu)
>  {
>   unsigned int boot_cpu = 0;
>   void __iomem *base = omap_get_wakeupgen_base();
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
> b/arch/arm/mach-omap2/omap-wakeupgen.c
> index db7e0bab3587..2da0d974f2f7 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -330,7 +330,7 @@ static int irq_cpu_hotplug_notify(struct notifier_block 
> *self,
>   return NOTIFY_OK;
>  }
>  
> -static struct notifier_block __refdata irq_hotplug_notifier = {
> +static struct notifier_block irq_hotplug_notifier = {
>   .notifier_call = irq_cpu_hotplug_notify,
>  };
>  
> diff --git a/arch/arm/mach-prima2/hotplug.c b/arch/arm/mach-prima2/hotplug.c
> index 0ab2f8bae28e..a728c78b996f 100644
> --- a/arch/arm/mach-prima2/hotplug.c
> +++ b/arch/arm/mach-prima2/hotplug.c
> @@ -32,7 +32,7 @@ static inline void platform_do_lowpower(unsigned int cpu)
>   *
>   * Called with IRQs disabled
>   */
> -void __ref sirfsoc_cpu_die(unsigned int cpu)
> +void sirfsoc_cpu_die(unsigned int cpu)
>  {
>   platform_do_lowpower(cpu);
>  }
> diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
> index 5cde63a64b34..9b00123a315d 100644
> --- a/arch/arm/mach-qcom/platsmp.c
> +++ b/arch/arm/mach-qcom/platsmp.c
> @@ -49,7 +49,7 @@ extern void secondary_startup_arm(void);
>  static DEFINE_SPINLOCK(boot_lock);
>  
>  #ifdef CONFIG_HOTPLUG_CPU
> -static void __ref qcom_cpu_die(unsigned int cpu)
> +static void qcom_cpu_die(unsigned int cpu)
>  {
>   wfi();
>  }
> diff --git a/arch/arm/mach-realview/hotplug.c 
> b/arch/arm/mach-realview/hotplug.c
> index ac22dd41b135..968e2d1964f6 100644
> --- a/arch/arm/mach-realview/hotplug.c
> +++ b/arch/arm/mach-realview/hotplug.c
> @@ -90,7 +90,7 @@ static inline void platform_do_lowpower(unsigned int cpu, 
> int *spurious)
>   *
>   * Called with IRQs disabled
>

[BISECTED] Nokia 770 framebuffer breakage

2015-10-19 Thread Aaro Koskinen

Hi,

Somewhere between 4.1 .. 4.3-rc6 framebuffer on Nokia 770 stopped working.

Bisection points to:

commit 2568999835d7797afce3dcc3a3f368051ffcaf1f
Author: Russell King 
Date:   Mon Mar 2 15:40:29 2015 +

clkdev: add clkdev_create() helper

The commit cannot be reverted cleanly from current trees, but I re-tested
that commit 2568999835d7797afce3dcc3a3f368051ffcaf1f does not work and
commit 2568999835d7797afce3dcc3a3f368051ffcaf1f^1 indeed works.

A.
--
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: [BISECTED] Nokia 770 framebuffer breakage

2015-10-19 Thread Russell King - ARM Linux

On Tue, Oct 20, 2015 at 01:24:13AM +0300, Aaro Koskinen wrote:
> On Mon, Oct 19, 2015 at 09:05:22PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 10:37:59PM +0300, Aaro Koskinen wrote:
> > > Hi,
> > > 
> > > Somewhere between 4.1 .. 4.3-rc6 framebuffer on Nokia 770 stopped working.
> > > 
> > > Bisection points to:
> > > 
> > > commit 2568999835d7797afce3dcc3a3f368051ffcaf1f
> > > Author: Russell King 
> > > Date:   Mon Mar 2 15:40:29 2015 +
> > > 
> > > clkdev: add clkdev_create() helper
> > > 
> > > The commit cannot be reverted cleanly from current trees, but I re-tested
> > > that commit 2568999835d7797afce3dcc3a3f368051ffcaf1f does not work and
> > > commit 2568999835d7797afce3dcc3a3f368051ffcaf1f^1 indeed works.
> > 
> > Really need more information than that, like a kernel log or something.
> 
> This is a device with normal consumer electronics mechnics so serial
> port access is PITA. However I managed to get a boot log, see below,
> it's from commit 2568999835d7797afce3dcc3a3f368051ffcaf1f.

Hmm, that points to a driver that doesn't bother checking whether it
successfully got any resources:

hwa742.sys_ck = clk_get(NULL, "hwa_sys_ck");

spin_lock_init(_lock);

if ((r = hwa742.int_ctrl->init(fbdev, 1, req_vram)) < 0)
goto err1;

if ((r = hwa742.extif->init(fbdev)) < 0)
goto err2;

ext_clk = clk_get_rate(hwa742.sys_ck);

There's no check here that clk_get() actually worked, and this will be
why you then end up with the division by zeros.  That's someone elses
problem though. :)

> > Can you try this patch please?
> 
> Unfortunately with the patch it dies even earlier, without any output.

It shouldn't (I've been through the resulting assembly code.)  I wonder
if this is fixing the problem, but it's now failing elsewhere instead.

What happens if you change it to:

l = clkdev_create(r, alias, alias_dev_name);

which should be 100% identical to how older kernels behaved - if that
works, can you print out 'alias' and 'alias_dev_name' for every call
to clk_add_alias() and send that please?

-- 
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: [BISECTED] Nokia 770 framebuffer breakage

2015-10-19 Thread Aaro Koskinen

On Mon, Oct 19, 2015 at 09:05:22PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 10:37:59PM +0300, Aaro Koskinen wrote:
> > Hi,
> > 
> > Somewhere between 4.1 .. 4.3-rc6 framebuffer on Nokia 770 stopped working.
> > 
> > Bisection points to:
> > 
> > commit 2568999835d7797afce3dcc3a3f368051ffcaf1f
> > Author: Russell King 
> > Date:   Mon Mar 2 15:40:29 2015 +
> > 
> > clkdev: add clkdev_create() helper
> > 
> > The commit cannot be reverted cleanly from current trees, but I re-tested
> > that commit 2568999835d7797afce3dcc3a3f368051ffcaf1f does not work and
> > commit 2568999835d7797afce3dcc3a3f368051ffcaf1f^1 indeed works.
> 
> Really need more information than that, like a kernel log or something.

This is a device with normal consumer electronics mechnics so serial
port access is PITA. However I managed to get a boot log, see below,
it's from commit 2568999835d7797afce3dcc3a3f368051ffcaf1f.

> Can you try this patch please?

Unfortunately with the patch it dies even earlier, without any output.

...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.1.0-rc1-770_tiny-los_350d5+-6-g2568999 
(aaro@amd-fx-6350) (gcc version 5.2.0 (GCC) ) #1 Tue Oct 20 00:41:44 EEST 2015
[0.00] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Nokia 770
[0.00] Ignoring unrecognised tag 0x414f4d50
[0.00] earlycon: no match for ttyS0,115200
[0.00] Memory policy: Data cache writeback
[0.00] OMAP1710
[0.00]  revision 8 handled as 16xx id: 8b5f702f03330200
[0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2a93 ARM_CKCTL: 0x050e
[0.00] Clocking rate (xtal/DPLL1/MPU): 12.0/252.0/252.0 MHz
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 16256
[0.00] Kernel command line: mem=64M console=ttyS0,115200
[0.00] PID hash table entries: 256 (order: -2, 1024 bytes)
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Memory: 61296K/65536K available (1614K kernel code, 138K rwdata, 
532K rodata, 1124K init, 178K bss, 4240K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc480 - 0xff00   ( 936 MB)
[0.00] lowmem  : 0xc000 - 0xc400   (  64 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc0220d04   (2148 kB)
[0.00]   .init : 0xc0221000 - 0xc033a000   (1124 kB)
[0.00]   .data : 0xc033a000 - 0xc035c880   ( 139 kB)
[0.00].bss : 0xc035c880 - 0xc038914c   ( 179 kB)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:368
[0.00] Total of 128 interrupts in 4 interrupt banks
[0.00] clocksource 32k_counter: mask: 0x max_cycles: 
0x, max_idle_ns: 58327039986419 ns
[0.30] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
6553584741ns
[0.61] OMAP clocksource: 32k_counter at 32768 Hz
[0.000610] Console: colour dummy device 80x30
[0.000701] Calibrating delay loop... 125.33 BogoMIPS (lpj=626688)
[0.090118] pid_max: default: 32768 minimum: 301
[0.090423] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.090484] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.092102] CPU: Testing write buffer coherency: ok
[0.093048] Setting up static identity map for 0x10008400 - 0x1000843c
[0.096374] devtmpfs: initialized
[0.102111] clocksource jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.104034] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.107269] omap_gpio omap_gpio.1: Could not get gpio dbck
[0.107452] OMAP GPIO hardware version 1.1
[0.107635] omap_gpio omap_gpio.2: Could not get gpio dbck
[0.107940] omap_gpio omap_gpio.3: Could not get gpio dbck
[0.108245] omap_gpio omap_gpio.4: Could not get gpio dbck
[0.110229] MUX: initialized V6_USB0_TXD
[0.110290] MUX: initialized W5_USB0_SE0
[0.110321] MUX: initialized Y5_USB0_RCV
[0.110351] MUX: initialized AA9_USB0_VP
[0.110351] MUX: initialized R9_USB0_VM
[0.110382] USB: hmc 16, usb0 6 wires, Mini-AB on usb0
[0.110748] MUX: initialized W19_1610_MMC2_DATDIR1
[0.112640] Clocking rate (xtal/DPLL1/MPU): 12.0/216.0/216.0 MHz
[0.116882] OMAP DMA hardware version 1
[0.116943] DMA capabilities: 000c::01ff:003f:007f
[0.133392] omap-dma-engine

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

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

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

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

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

Re: [PATCH v3 2/3] iio:adc:palmas: add DT support

bug in omap3_rom_rng_idle()

Re: [RFC PATCH 1/3] arm: plat-omap: dmtimer: Add clock source from DT

Re: [PATCH v2 1/3] ARM: catch pending imprecise abort on unmask

Re: [PATCH v3 2/3] iio:adc:palmas: add DT support

[PATCH] irqchip: omap-intc: fix spurious irq handling

Re: [PATCH] irqchip: omap-intc: fix spurious irq handling

Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

Re: [PATCH 3/3] ARM: dts: Add basic support for isee igepv5

Re: [PATCH] irqchip: omap-intc: fix spurious irq handling

[RFC PATCH v2 1/3] arm: plat-omap: dmtimer: Add clock source from DT

[RFC PATCH v2 3/3] arm: plat-omap: Add PWM dmtimer platform data quirks

[RFC PATCH v2 0/3] pwm: omap: Add PWM support using dual-mode timers

[RFC PATCH v2 2/3] pwm: Add PWM driver for OMAP using dual-mode timers

[PATCH 1/3] ARM: dts: omap3-igep0020: Use IOPAD pinmux macro

Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

Re: [PATCH 2/2] ARM: dts: omap3: keep ssi ports by default

[PATCH 2/3] ARM: dts: am335x-igep0033: Use IOPAD pinmux macro

[PATCH 0/3] ARM: dts: Use IOPAD pinmux for IGEP boards

[PATCH 3/3] ARM: dts: am335x-base0033: Use IOPAD pinmux macro

Re: [PATCH v2 2/3] ARM: dts: AM43x-epos-evm: Add AM438x compatible string for epos

Re: [BISECTED] Nokia 770 framebuffer breakage

[PATCH/RESEND] ARM: Remove __ref on hotplug cpu die path

Re: [PATCH/RESEND] ARM: Remove __ref on hotplug cpu die path

Re: [PATCH/RESEND] ARM: Remove __ref on hotplug cpu die path

[BISECTED] Nokia 770 framebuffer breakage

Re: [BISECTED] Nokia 770 framebuffer breakage

Re: [BISECTED] Nokia 770 framebuffer breakage

33 matches

Site Navigation

Mail list logo

Footer information