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

[Kalle Valo]

Uri Mashiach  writes:

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

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

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

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

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

[Uri Mashiach]

Hi Kalle Valo,

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

Uri Mashiach  writes:


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

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

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


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


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



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



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

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

[Pavel Machek]

Hi!

> On Thursday 07 January 2016 02:16 AM, Pavel Machek wrote:
> > Hi!
> > 
> > In v4.1, both internal MMC and u-SD cards work ok.
> > 
> > In v4.2, only the internal MMC is detected. In v4.3, not even internal
> > MMC works. In v4.4, only the internal MMC is detected.
> > 
> > Does it work for you? Any patches?
> 
> I don't have Nokia N900 to check this, but can you share your config and 
> kernel
> logs? Check if CONFIG_REGULATOR_PBIAS is present in your config.
> CONFIG_REGULATOR_PBIAS is now mandatory for all omap3+ SoCs to work.

I enabled CONFIG_REGULATOR_PBIAS and both MMCs now work.

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

Thanks,

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

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

[Pali Rohár]

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

Great! Thank you for fixing and testing this problem!

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

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

[Ivaylo Dimitrov]

On  6.01.2016 00:49, Tony Lindgren wrote:


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

Regards,

Tony

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

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

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

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

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

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

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


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


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

Tested-by: Ivaylo Dimitrov 


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

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

[Rob Herring]

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

These should have a ti prefix.

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

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

[Rob Herring]

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

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

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

[Nishanth Menon]

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


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

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

Re: OMAP4430 power management support

[Nishanth Menon]

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


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

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

Re: OMAP4430 power management support

[Adam Ford]

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

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

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

adam

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

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

Re: OMAP4430 power management support

[Frank Jenner]

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

Sorry my original post might have been TL;DR, but is there a public
fork/branch that does have the support?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP4430 power management support

[Nishanth Menon]

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


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

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

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

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

[Sebastian Reichel]

Hi,

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

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

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

-- Sebastian


signature.asc
Description: PGP signature

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

[Ivaylo Dimitrov]

On  6.01.2016 19:47, Tony Lindgren wrote:

* Sebastian Reichel <s...@kernel.org> [160106 09:41]:

Hi,

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

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

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


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


Thanks will do.

Tony




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


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

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

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


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

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

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

[Tony Lindgren]

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

Thanks will do.

Tony


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

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

[Tony Lindgren]

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

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

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

Regards,

Tony

8< --
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 0;
}
 
+   pr_info("onenand rate detected: %i\n", freq);
+
return freq;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ivaylo Dimitrov]

Hi,

On  6.01.2016 20:26, Tony Lindgren wrote:



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


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




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


CONFIG_OMAP_GPMC_DEBUG is disabled, shall I enable it?


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

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



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


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


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

Re: OMAP4430 power management support

[Nishanth Menon]

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


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


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

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

[Rob Herring]

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

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

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

Re: OMAP4430 power management support

[Adam Ford]

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

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

adam

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

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

[Tony Lindgren]

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

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

Regards,

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

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

[Tony Lindgren]

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

OK

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

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

Regards,

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

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

[Tony Lindgren]

Hi,

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

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

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

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

Regards,

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

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

[Aaro Koskinen]

Hi,

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

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

Tested-by: Aaro Koskinen 

A.

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

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

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 17:41 schrieb Tony Lindgren :

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

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

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

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

BR,
Nikolaus

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

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

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 02:00 schrieb Tony Lindgren :

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

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

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

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

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

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

BR,
Nikolaus

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

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

[Laxman Dewangan]

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

Hi,

Am 06.01.2016 um 00:40 schrieb Nishanth Menon :


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

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

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

Well, it just translates IRQ_TYPE_NONE through

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

to

interrupts = <8 0>;

which is given as an example in

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

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



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

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

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





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

Re: [PATCH v3] PCI: hosts: mark pcie/pci (msi) irq cascade handler as IRQF_NO_THREAD

[Bjorn Helgaas]

Hi Grygorii,

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

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

Bjorn

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

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

[Kishon Vijay Abraham I]

Hi,

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

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

Thanks
Kishon

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

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

[Kishon Vijay Abraham I]

Hi,

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

Okay. Will fix that and post a new version.

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

Re: OMAP4430 power management support

[Nishanth Menon]

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

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

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

Logic PD probably should talk with TI on the topic.

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

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

[Nishanth Menon]

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

 Am 06.01.2016 um 00:40 schrieb Nishanth Menon :

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

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

 to

 interrupts = <8 0>;

 which is given as an example in

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

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

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

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

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


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

Re: Nokia N900: Broken lirc ir-rx51 driver

[Pali Rohár]

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

Ok. Is PWM driver included in mainline kernel?

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

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

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

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

Re: Nokia N900: Adjust MPU OPP values

[Pali Rohár]

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

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

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

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

[Pali Rohár]

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

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

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

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

[Mark Brown]

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

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


signature.asc
Description: PGP signature

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

[H. Nikolaus Schaller]

Hi,

Am 06.01.2016 um 00:40 schrieb Nishanth Menon :

> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>> tested on OMP5432 EVM
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 
>> 1 file changed, 8 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
>> b/arch/arm/boot/dts/omap5-board-common.dtsi
>> index 5cf76a1..30c0d3b 100644
>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>> @@ -358,6 +358,14 @@
>>  #clock-cells = <0>;
>>  };
>> 
>> +rtc {
>> +compatible = "ti,palmas-rtc";
>> +interrupt-parent = <>;
>> +interrupts = <8 IRQ_TYPE_NONE>;
> 
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?

Well, it just translates IRQ_TYPE_NONE through

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

to 

interrupts = <8 0>;

which is given as an example in

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

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

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


BR,
Nikolaus

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

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

[Tony Lindgren]

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

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

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

Regards,

Tony

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

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

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

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

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

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

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

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

[Arnd Bergmann]

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

Yes.

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

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

[Pali Rohár]

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

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

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

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

[Pali Rohár]

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

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

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

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

[Tony Lindgren]

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

Also I'm not seeing just zeroes coming from RTC after typing hwclock
on omap5-uevm. It's working on x15 though.

Nikolaus, is hwclock command working for you on omap5-uevm?

Regards,

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

Re: Nokia N900: Broken lirc ir-rx51 driver

[Tony Lindgren]

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

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

Regards,

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

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

[dbasehore .]

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

It was a reply to the second patch in the series. Here's a link to it
https://lkml.org/lkml/2015/11/10/107
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nishanth Menon]

On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> tested on OMP5432 EVM
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap5-board-common.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
> b/arch/arm/boot/dts/omap5-board-common.dtsi
> index 5cf76a1..30c0d3b 100644
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -358,6 +358,14 @@
>   #clock-cells = <0>;
>   };
>  
> + rtc {
> + compatible = "ti,palmas-rtc";
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_NONE>;

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

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


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

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

[Rafael J. Wysocki]

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

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

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

Thanks,
Rafael

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

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

[Tero Kristo]

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

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

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

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

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


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


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


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



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


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



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


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

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

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

[Ivaylo Dimitrov]

Hi,

On  4.01.2016 19:40, Tony Lindgren wrote:

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

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


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


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

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

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

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

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

[Geert Uytterhoeven]

Hi Tero,

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

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

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

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

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Tomi Valkeinen]

Hi,

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

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

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

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

 Tomi



signature.asc
Description: OpenPGP digital signature

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

[Sekhar Nori]

Hi Thomas,

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

Can you please apply this if it looks good?

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

Re: Nokia N900 - audio TPA6130A2 problems

[Pali Rohár]

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

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

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


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

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

[Michael Turquette]

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

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

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

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

Regards,
Mike

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

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

[Derek Basehore]

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

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

Is there a new revision of the patch series being worked on?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tony Lindgren]

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

Thanks. I got the problem reproduced here too.

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

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

Regards,

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

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

[Michael Turquette]

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

Let's not ruin system PM.

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

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

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

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

> Typically 
> clk_enable/disable just becomes a NOP

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

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

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

Regards,
Mike

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

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Ivaylo Dimitrov]

Hi Tomi,

On  4.01.2016 13:37, Tomi Valkeinen wrote:


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



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


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



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



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



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



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


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

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

[Tero Kristo]

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

Hi Tero,

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

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

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

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


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


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

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

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


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


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


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


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


-Tero





Gr{oetje,eeting}s,

 Geert

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

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



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

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

[Vignesh R]

Hi Brian,

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

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

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

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

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

[Russell King - ARM Linux]

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

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

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

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

[Tony Lindgren]

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

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

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

Regards,

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

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

[Tony Lindgren]

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

OK

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

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

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

Regards,

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

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

[Pali Rohár]

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

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

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

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


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

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

[Tony Lindgren]

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

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

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

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

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

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

Regards,

Tony


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

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

[Tony Lindgren]

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

Same to you :)

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

Oh crap, sorry to hear that :(

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

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

Regards,

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

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

[Tero Kristo]

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

Hi Tero,

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

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

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


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


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


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


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


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

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


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


-Tero



Regards,
Mike



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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

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

Makes sense, I'll keep that in mind.

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

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

Thanks!

-- 
Paul Kocialkowski, Replicant developer

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

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



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

Re: Nokia N900: Adjust MPU OPP values

[Tony Lindgren]

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

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

Regards,

Tony

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

Re: Nokia N900: Broken lirc ir-rx51 driver

[Tony Lindgren]

Hi,

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

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

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

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

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

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

Regards,

Tony


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

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

[Pali Rohár]

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

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

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


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

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

[Tony Lindgren]

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

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

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

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

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

Regards,

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

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

[Arnd Bergmann]

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

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

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


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

Re: Nokia N900: Adjust MPU OPP values

[Nishanth Menon]

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

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


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

Re: Nokia N900: Proper C-states

[Daniel Lezcano]

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

Hello,

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

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

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

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

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


Hi Pali,

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


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


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




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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

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

[Pali Rohár]

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

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

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

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


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

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

[Arnd Bergmann]

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

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

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

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

[Pali Rohár]

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

Ok.

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

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

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

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

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

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

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


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

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

[Dave Young]

Hi, Grygorii

Thanks fot your reply.

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

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

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

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

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

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

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

[Ivaylo Dimitrov]

Hi Tony,

On 21.05.2015 00:21, Tony Lindgren wrote:

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

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

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



1. Happy new year :)

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


Please advice on how to proceed.

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

Re: [PATCH 2/2] OMAP: RX51: save ATAGS data in the early boot stage

[Ivaylo Dimitrov]

Hi,

On 24.12.2015 20:56, Tony Lindgren wrote:


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



OK, will do.


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



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



Acked-by: Tony Lindgren 



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

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Pali Rohár]

Hi Tomi! Can you review this patch? It is waiting here for two years!

On Thursday 26 December 2013 00:12:39 Ivaylo Dimitrov wrote:
> From: Ivaylo Dimitrov 
> 
> On memory limited devices, CMA fails easily when asked to allocate
> big chunks of memory like framebuffer memory needed for video
> playback.
> 
> Add boot parameter "omapfb_memsize" which allocates memory to be used
> as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator
> when trying to allocate memory for the framebuffers
> 
> Signed-off-by: Ivaylo Dimitrov 
> ---
>  arch/arm/mach-omap2/common.c |1 +
>  arch/arm/mach-omap2/common.h |2 +
>  arch/arm/mach-omap2/fb.c |   46
> +- 3 files changed, 48
> insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/common.c
> b/arch/arm/mach-omap2/common.c index 2dabb9e..9beecde 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -33,4 +33,5 @@ void __init omap_reserve(void)
>   omap_dsp_reserve_sdram_memblock();
>   omap_secure_ram_reserve_memblock();
>   omap_barrier_reserve_memblock();
> + omap_fb_reserve_memblock();
>  }
> diff --git a/arch/arm/mach-omap2/common.h
> b/arch/arm/mach-omap2/common.h index e30ef67..21afdc0 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -304,6 +304,8 @@ extern void omap_reserve(void);
>  struct omap_hwmod;
>  extern int omap_dss_reset(struct omap_hwmod *);
> 
> +extern void omap_fb_reserve_memblock(void);
> +
>  /* SoC specific clock initializer */
>  extern int (*omap_clk_init)(void);
> 
> diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
> index 26e28e9..0eacbe9 100644
> --- a/arch/arm/mach-omap2/fb.c
> +++ b/arch/arm/mach-omap2/fb.c
> @@ -30,6 +30,7 @@
>  #include 
> 
>  #include 
> +#include 
> 
>  #include "soc.h"
>  #include "display.h"
> @@ -106,10 +107,53 @@ static struct platform_device omap_fb_device =
> { .num_resources = 0,
>  };
> 
> +static phys_addr_t omapfb_mem_base __initdata;
> +static phys_addr_t omapfb_mem_size __initdata;
> +
> +void __init omap_fb_reserve_memblock(void)
> +{
> + if (omapfb_mem_size) {
> + omapfb_mem_base = arm_memblock_steal(omapfb_mem_size, SZ_1M);
> + if (omapfb_mem_base)
> + pr_info("omapfb: reserved %u bytes at %x\n",
> + omapfb_mem_size, omapfb_mem_base);
> + else
> + pr_err("omapfb: arm_memblock_steal failed\n");
> + }
> +}
> +
>  int __init omap_init_fb(void)
>  {
> - return platform_device_register(_fb_device);
> + int ret;
> +
> + ret = platform_device_register(_fb_device);
> +
> + if (ret)
> + return ret;
> +
> + if (!omapfb_mem_base)
> + return 0;
> +
> + ret = dma_declare_coherent_memory(_fb_device.dev,
> +   omapfb_mem_base, omapfb_mem_base,
> +   omapfb_mem_size, DMA_MEMORY_MAP |
> +   DMA_MEMORY_EXCLUSIVE);
> + if (!(ret & DMA_MEMORY_MAP))
> + pr_err("omapfb: dma_declare_coherent_memory failed\n");
> +
> + return 0;
> +}
> +
> +static int __init early_omapfb_memsize(char *p)
> +{
> + omapfb_mem_size = ALIGN(memparse(p, ), SZ_1M);
> +
> + if(!omapfb_mem_size)
> + pr_err("omapfb: bad memsize parameter\n");
> +
> + return 0;
>  }
> +early_param("omapfb_memsize", early_omapfb_memsize);
>  #else
>  int __init omap_init_fb(void) { return 0; }
>  #endif

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


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

Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

[Ivaylo Dimitrov]

On 29.12.2015 09:46, Tomi Valkeinen wrote:


Oh, I'm sorry, I must have forgotten about that. Please, send a new patch.

  Tomi



Actually it is me to be sorry for making noise, I've missed 
0eb0dafb674cd6bfac2e3204b2f8b907e26b1138 with all those patches moving 
files around.


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

Re: [GIT PULL 2/3] reworked soc changes for ti81xx devices and minimal dra62x j5ec-evm support

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:46 Tony Lindgren wrote:
> Add minimal SoC support for dra62x also known as j5eco. As it's closely
> related to dm814x, we can treat it as a dm814x variant for now and do
> rest of the configuration with DTS just files. And let's add hwmod
> support for MMC and USB on dm814x and dra62x.
> 

Pulled into omap/soc, 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: [GIT PULL 3/3] reworked dts changes for ti81xx devices and minimal dra62x j5ec-evm support

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:47 Tony Lindgren wrote:
> Add minimal device tree support for dra62x also known j5eco. It is
> related to dm814x, just the clocks are a bit different and it has a
> different set of integrated devices. And let's get some basic dm814x
> and dra62x devices working as many of the devices are like on am33xx::
> 
> - pinctrl using the pinctrl defines as for am33xx
> 
> - Updated EDMA bindings with support for using exma_xbar
> 
> - MMC support for dm814x-evm, t410 and dra62x-j5eco-evm
> 
> - USB support for dm814x-evm, t410 and dra62x-j5eco-evm
> 
> This branch depends on an earlier omap-for-v4.5/81xx-fixes-signed
> branch that has dm814x dts fixes interlaced with SoC related fixes to
> keep things booting. The interlaced SoC and dts fixes were needed
> because of issues with the device tree defined clocks that just
> happened to work on bootloader timings for t410 earlier.
> 

Merged into next/dt, 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: [GIT PULL 1/3] reworked fix for earlier ti81xx changes for v4.5 merge window

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:45 Tony Lindgren wrote:
> Here are reworked pull requests to separate the dts changes as requested
> by Olof.
> 
> The pull request below, and the third pull request in this series,
> still depend on the earlier branch omap-for-v4.5/81xx-fixes-signed.
> The pull request number two in this series does not.
> 
> My updated for-next has zero diff with these merged in compared to the
> earlier single branch merged in, so this is just regrouping of the patches
> into three separate pull requests.
> 

Merged into next/fixes-non-critical, 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: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Eduardo Valentin]

can we have a shorter title?

On Tue, Dec 29, 2015 at 02:46:49PM +0530, Keerthy wrote:
> Hi Nishanth,
> 

 
> >
> >I am not sure if this #ifdeffery is even needed.
> >
> >
> >Eduardo, Rui: If this is not the suggested technique, maybe you guys
> >could suggest how we could handle a case where userspace might be
> >hungup due to some reason and a case where a critical temperature
> >event in the middle of device probe was triggered?

Orderly power off is supposed to take care of this. Looking at the code,
it will force a shutdown in case execution of userland command fails:

static int __orderly_poweroff(bool force)
{
int ret;

ret = run_cmd(poweroff_cmd);

if (ret && force) {
pr_warn("Failed to start orderly shutdown: forcing the 
issue\n");

/*
 * I guess this should try to kick off some daemon to sync and
 * poweroff asap.  Or not even bother syncing if we're doing an
 * emergency shutdown?
 */
emergency_sync();
kernel_power_off();
}

> >
> >Obviously, we'd like to take into consideration userspace latencies as
> >well- but that is very specific to fs being run.. not really a simple
> >problem, IMHO..
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Nishanth Menon]

On 12/31/2015 12:20 PM, Eduardo Valentin wrote:
> On Thu, Dec 31, 2015 at 11:47:57AM -0600, Nishanth Menon wrote:
>> On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
>>> can we have a shorter title?
>>>
>>>
>>> Orderly power off is supposed to take care of this. Looking at the code,
>>> it will force a shutdown in case execution of userland command fails:
>>>
>>> static int __orderly_poweroff(bool force)
>>> {
>>> int ret;
>>>
>>> ret = run_cmd(poweroff_cmd);
>>>
>>> if (ret && force) {
>>> pr_warn("Failed to start orderly shutdown: forcing the 
>>> issue\n");
>>>
>>> /*
>>>  * I guess this should try to kick off some daemon to sync 
>>> and
>>>  * poweroff asap.  Or not even bother syncing if we're 
>>> doing an
>>>  * emergency shutdown?
>>>  */
>>> emergency_sync();
>>> kernel_power_off();
>>> }
>>
>> Yes, it will *IF* userspace fails. the condition that I had tracked
>> was before identifying the following fix[1] - Example fail is here[2]
>>
> 
> OK. But still, why other users of orderly_poweroff do not
> deserve to be fixed, then?
> 


I'd agree as well.. I guess the comment from Robin Holt 
anticipated something like this will eventually occur.

"* I guess this should try to kick off some daemon to sync and
* poweroff asap.  Or not even bother syncing if we're doing an
* emergency shutdown?
"

Keerthy - would you spin this as a generic fix?

>>
>> I hope this explains the problem.
>>
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
>> [2] http://pastebin.ubuntu.com/14326688/
>>
>> [3]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738
>>
>> -- 
>> Regards,
>> Nishanth Menon


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

Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Eduardo Valentin]

On Mon, Dec 21, 2015 at 11:16:18AM +0530, Keerthy wrote:
> In few rare conditions like during boot up the orderly_poweroff
> function might not be able to complete fully leaving the device
> running at dangerously high temperatures. Hence adding a backup
> workqueue to act after a known period of time and poweroff the device.

I really wish a better description of what is going on. I am not really
sure why thermal subsystem must deal with the case of a failing kernel
API. If orderly power off is failing, why don't we fix it instead?
What are the failing conditions? few rare conditions seams very odd.
How does it fail? Why fixing it in thermal? Other users of it don't
deserver the same fix?

>   }
>  }
> -- 
> 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: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Eduardo Valentin]

On Thu, Dec 31, 2015 at 11:47:57AM -0600, Nishanth Menon wrote:
> On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
> > can we have a shorter title?
> > 
> > 
> > Orderly power off is supposed to take care of this. Looking at the code,
> > it will force a shutdown in case execution of userland command fails:
> > 
> > static int __orderly_poweroff(bool force)
> > {
> > int ret;
> > 
> > ret = run_cmd(poweroff_cmd);
> > 
> > if (ret && force) {
> > pr_warn("Failed to start orderly shutdown: forcing the 
> > issue\n");
> > 
> > /*
> >  * I guess this should try to kick off some daemon to sync 
> > and
> >  * poweroff asap.  Or not even bother syncing if we're 
> > doing an
> >  * emergency shutdown?
> >  */
> > emergency_sync();
> > kernel_power_off();
> > }
> 
> Yes, it will *IF* userspace fails. the condition that I had tracked
> was before identifying the following fix[1] - Example fail is here[2]
> 

OK. But still, why other users of orderly_poweroff do not
deserve to be fixed, then?

> 
> I hope this explains the problem.
> 
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
> [2] http://pastebin.ubuntu.com/14326688/
> 
> [3]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738
> 
> -- 
> Regards,
> Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eduardo Valentin]

Hello,

On Sat, Dec 26, 2015 at 12:32:25AM +0100, Pali Rohár wrote:
> Driver for omap3 with documentation is there since v4.4-rc1.
> 
> Signed-off-by: Pali Rohár 


> ---
>  arch/arm/boot/dts/omap34xx.dtsi |5 +
>  arch/arm/boot/dts/omap36xx.dtsi |5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
> index 4f6b2d5..c3f488f 100644
> --- a/arch/arm/boot/dts/omap34xx.dtsi
> +++ b/arch/arm/boot/dts/omap34xx.dtsi
> @@ -54,6 +54,11 @@
>   #size-cells = <0>;
>   };
>   };
> +
> + bandgap {
> + reg = <0x48002524 0x4>;
> + compatible = "ti,omap34xx-bandgap";
> + };
>   };
>  };
>  
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> index 86253de..00f98c1 100644
> --- a/arch/arm/boot/dts/omap36xx.dtsi
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -86,6 +86,11 @@
>   #size-cells = <0>;
>   };
>   };
> +
> + bandgap {
> + reg = <0x48002524 0x4>;
> + compatible = "ti,omap36xx-bandgap";

Can you please already add on both cases

#thermal-sensor-cells = <0>;
?

This way we can already use them to define thermal zones. Of course,
that alone won't add the thermal zones. A separated patch would be
needed to add the thermal zone for OMAP3.

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

Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Nishanth Menon]

On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
> can we have a shorter title?
> 
> On Tue, Dec 29, 2015 at 02:46:49PM +0530, Keerthy wrote:
>> Hi Nishanth,
>>
> 
>  
>>>
>>> I am not sure if this #ifdeffery is even needed.
>>>
>>>
>>> Eduardo, Rui: If this is not the suggested technique, maybe you guys
>>> could suggest how we could handle a case where userspace might be
>>> hungup due to some reason and a case where a critical temperature
>>> event in the middle of device probe was triggered?
> 
> Orderly power off is supposed to take care of this. Looking at the code,
> it will force a shutdown in case execution of userland command fails:
> 
> static int __orderly_poweroff(bool force)
> {
> int ret;
> 
> ret = run_cmd(poweroff_cmd);
> 
> if (ret && force) {
> pr_warn("Failed to start orderly shutdown: forcing the 
> issue\n");
> 
> /*
>  * I guess this should try to kick off some daemon to sync and
>  * poweroff asap.  Or not even bother syncing if we're doing 
> an
>  * emergency shutdown?
>  */
> emergency_sync();
> kernel_power_off();
> }

Yes, it will *IF* userspace fails. the condition that I had tracked
was before identifying the following fix[1] - Example fail is here[2]

In this case, tmp102 is setup for X15 as [3] - and built as a module.
as the kernel startsup filesystem and starts a modprobe of all modules
via udev rules, the probe of tmp102 detects (falsely) a critical
temperature condition. Shutdown attempt in the middle of driver probe
is always a tricky business.

As we look at the log in [2], Line  472
> thermal thermal_zone3: critical temperature reached(108 C),shutting down
We have userspace trigger for shutdown taking place.

Line 495: INIT: Sending processes the TERM signal

userspace starts shutting down services. (but note that probe for
other devices were either in progress or queued up to complete)..

at line 647 - we are in a weird place -> sysrq shows that system is
idled and userspace is shutdown and system is still active.


In this case, we entered the case thanks to a driver bug, but if this
situation was a real world temperature scenario, then we'd probably in
an overtemp scenario, then device damage could take place OR something
much worse.

The only alternative is to run a parallel thread in case userspace
fails to complete the job in some given period of time - due to what
ever be the condition triggering the problem.

I hope this explains the problem.

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
[2] http://pastebin.ubuntu.com/14326688/

[3]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Mark Brown]

On Thu, Dec 31, 2015 at 10:59:06PM +0100, Paul Kocialkowski wrote:

> I understand, thanks for pointing this out. Well, for my use case, there
> is no use in disabling the chip at any point as it powers the external
> mmc.

Presumably someone might decide not to use the MMC in some case (perhaps
only mounting it when explicitly needed in order to save power for
example, or the MMC subsystem might figure out a way to power down an
idle MMC block device).

> Would you agree to have the enable pin handled directly (and by that, I
> mean enabled once, when requested, as I first suggested in the patchset)
> in the driver then?

That's probably fine, or do it via runtime PM (the framework is fairly
simple to use, I'll probably go add support in the core for it in the
next day or two as this seems like a sensible use case).  I can't
remember if this device is a MFD or not and I'm just on my way out the
door.


signature.asc
Description: PGP signature

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Le jeudi 31 décembre 2015 à 21:40 +, Mark Brown a écrit :
> On Wed, Dec 30, 2015 at 07:37:19PM +0100, Paul Kocialkowski wrote:
> > Le mercredi 30 décembre 2015 à 16:33 +, Mark Brown a écrit :
> > > On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:
> 
> > > > In my opinion, it would be more elegant to adapt the core regulator
> > > > framework to first enable the GPIO and then call the regulator enable
> > > > ops callback instead of handling the GPIO in the driver.
> 
> > > Why would we want to actively manage both things at runtime?  It's more
> > > work, what do we gain from it?
> 
> > Well, I figured that it would be best to disable the EN pin when we're
> > not using any of the regulators, since that allows the chip to enter
> > standby mode (and thus consume less power).
> 
> This doesn't sound like it's anything to do with the regulators, that's
> a chip wide power management function which should be implemented via
> runtime PM if there's any value in implementing it at all (if the device
> is a primary PMIC normally this would be handled by the CPU core when it
> enters low power state without any software).  It's not something we
> should be considering on a per regulator basis since it's at the chip
> level and on a per regulator basis it's not doing anything useful for
> the reasons above.

I understand, thanks for pointing this out. Well, for my use case, there
is no use in disabling the chip at any point as it powers the external
mmc.

Would you agree to have the enable pin handled directly (and by that, I
mean enabled once, when requested, as I first suggested in the patchset)
in the driver then?

> > It also doesn't hurt regulators that only use a GPIO for enable.
> 
> It causes problems for any device with an optional GPIO,  it means that
> we end up mantaining both GPIO and register which as I've said a couple
> of times now defeats the point of having the GPIO.

Fair enough.


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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Mark Brown]

On Wed, Dec 30, 2015 at 07:37:19PM +0100, Paul Kocialkowski wrote:
> Le mercredi 30 décembre 2015 à 16:33 +, Mark Brown a écrit :
> > On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:

> > > In my opinion, it would be more elegant to adapt the core regulator
> > > framework to first enable the GPIO and then call the regulator enable
> > > ops callback instead of handling the GPIO in the driver.

> > Why would we want to actively manage both things at runtime?  It's more
> > work, what do we gain from it?

> Well, I figured that it would be best to disable the EN pin when we're
> not using any of the regulators, since that allows the chip to enter
> standby mode (and thus consume less power).

This doesn't sound like it's anything to do with the regulators, that's
a chip wide power management function which should be implemented via
runtime PM if there's any value in implementing it at all (if the device
is a primary PMIC normally this would be handled by the CPU core when it
enters low power state without any software).  It's not something we
should be considering on a per regulator basis since it's at the chip
level and on a per regulator basis it's not doing anything useful for
the reasons above.

> It also doesn't hurt regulators that only use a GPIO for enable.

It causes problems for any device with an optional GPIO,  it means that
we end up mantaining both GPIO and register which as I've said a couple
of times now defeats the point of having the GPIO.


signature.asc
Description: PGP signature

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

[Michael Turquette]

Hi Tero,

Quoting Tero Kristo (2015-12-18 05:58:58)
> Previously, hwmod core has been used for controlling the hwmod level
> clocks. This has certain drawbacks, like being unable to share the
> clocks for multiple users, missing usecounting and generally being
> totally incompatible with common clock framework.
> 
> Add support for new clock type under the TI clock driver, which will
> be used to convert all the existing hwmdo clocks to. This helps to
> get rid of the clock related hwmod data from kernel and instead
> parsing this from DT.

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

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

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

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

Re: Routable IRQs

[Thomas Gleixner]

Felipe,

On Tue, 29 Dec 2015, Felipe Balbi wrote:
> Anyway, the interesting part is that PRUSS has 64 events (on current
> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
> land. Each of these 64 events can be routed to any of these 10 IRQ
> lines. This might not be very useful on UP (AM335x & AM437x) other than
> the fact that soft-IP drivers running on Linux would need to guarantee
> they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
> could have real tangible benefits by means of IRQ affinity, etc.
> 
> So, the question is, what is there in IRQ subsystem today for routable
> IRQ support ?
> 
> If a Diagram helps here's a simple one. Note that I'm not showing
> details on the PRUSS side, but that side can also map events pretty much
> any way it wants.
> 
>  .. ..
>  |  HOST CPU  | |   PRUSS|
>  || ||
>  || ||
>  |   irq0 |<-.--|evt0|
>  ||  |  ||
>  |   irq1 |  |  .---|evt1|
>  ||  |  |   ||
>  |   irq2 |  '--|evt2|
>  || |   ||
>  |   irq3 | |   ||
>  || |   ||
>  |   irq4 | |   | .  |
>  || |   ||
>  |   irq5 | |   | .  |
>  || |   ||
>  |   irq6 | |   | .  |
>  || |   ||
>  |   irq7 |<'   ||
>  || ||
>  |   irq8 | ||
>  || ||
>  |   irq9 |<|evtN|
>  '' ''
> 
> Given this setup, what I want to do, is let soft-IP drivers running on
> linux rely on standard *request_*irq() calls and DTS descrition. But I'm
> still considering how/if we should describe the routing itself or just
> go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
> irq0 -> evt10, ...).
> 
> Thoughts ?

I have a few questions:

 - Is there a "mapping" block between PRUSS and the host interrupt controller
   or is this "mapping" block part of PRUSS?

 - We all know how well shared interrupts work. Is there a point of supporting
   64 interrupts when you only have 10 irq lines available?

 - I assume that the PRUSS interrupt mapping is more or less a question of the
   firmware implementation. So you either have a fixed association in the
   firmware which is reflected in the DT description of the IP block or you
   need an interface to tell the PRUSS firmware which event it should map to
   which irq line. Is there actually a value in doing the latter?

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 2/3] wlcore/wl12xx: spi: add device tree support

[Rob Herring]

On Wed, Dec 23, 2015 at 10:35:43AM +0200, Uri Mashiach wrote:
> Add DT support for the wl1271 SPI WiFi.
> 
> Add documentation file for the wl1271 SPI WiFi.
> 
> Signed-off-by: Uri Mashiach 
> Acked-by: Igor Grinberg 
> ---
>  .../bindings/net/wireless/ti,wlcore,spi.txt| 35 +++

For the binding:

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Mark Brown]

On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:

> In my opinion, it would be more elegant to adapt the core regulator
> framework to first enable the GPIO and then call the regulator enable
> ops callback instead of handling the GPIO in the driver.

Why would we want to actively manage both things at runtime?  It's more
work, what do we gain from it?


signature.asc
Description: PGP signature

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Le mercredi 30 décembre 2015 à 16:33 +, Mark Brown a écrit :
> On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:
> 
> > In my opinion, it would be more elegant to adapt the core regulator
> > framework to first enable the GPIO and then call the regulator enable
> > ops callback instead of handling the GPIO in the driver.
> 
> Why would we want to actively manage both things at runtime?  It's more
> work, what do we gain from it?

Well, I figured that it would be best to disable the EN pin when we're
not using any of the regulators, since that allows the chip to enter
standby mode (and thus consume less power).

Implementing that logic in the driver seems very redundant when we're
one step away from doing it with the core regulator framework.
It is also likely that in the future, other chips will use and need to
handle a global enable pin for the same purpose, while allowing
regulator configuration and enable via registers.

It also doesn't hurt regulators that only use a GPIO for enable.

The diff to do this is very minimal, I already have a patch ready, that
I could send if there is a chance for it to get through.

-- 
Paul Kocialkowski, Replicant developer

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

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



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

Re: Routable IRQs

[Thomas Gleixner]

Felipe,

On Wed, 30 Dec 2015, Felipe Balbi wrote:
> Thomas Gleixner  writes:
> >  - Is there a "mapping" block between PRUSS and the host interrupt 
> > controller
> >or is this "mapping" block part of PRUSS?
> 
> The description in TRM is a bit "poor", but from what I can gather, the
> mapping is done on an interrupt controller inside the PRUSS. However,
> Linux is the one who's got the driver for that INTC (well, Linux will be
> the one with the soft ethernet/uart/whatever IP to talk to). All of its
> (INTC's) registers are memory mapped to the ARM side.

Ok. And the INTC registers include the "mapping" configuration, right?
 
> >  - We all know how well shared interrupts work. Is there a point of 
> > supporting
> >64 interrupts when you only have 10 irq lines available?
> 
> I'm looking at these 64 events more like MSI kind of events. It's just

Well, that's fine to look at them this way, but they will end up shared no
matter what.

> that the events themselves can be routed to any of the 10 available HW
> IRQ lines.
> 
> >  - I assume that the PRUSS interrupt mapping is more or less a question of 
> > the
> >firmware implementation. So you either have a fixed association in the
> >firmware which is reflected in the DT description of the IP block or you
> >need an interface to tell the PRUSS firmware which event it should map to
> >which irq line. Is there actually a value in doing the latter?
> 
> right, I'd say the mapping is pretty static. Unless Suman has some extra
> information which I don't. I guess the question was really to see if
> there was an easy way for doing this so we don't have to mess with DTS
> for every other FW and their neighbor.

Well, you will need information about every other firmware simply because you
need to know which events the firmware is actually using and what the purpose
of the particular event is.

Assume you have a simple uart with 3 events (RX, TX, status). So how will the
firmware tell you which event is which? You have a few options:

 1) DT + fixed mapping scheme: 

Describe the PRUSS event number in DT and have a fixed mapping scheme like
the one you mentioned evt0 -> irq0 .

 2) DT + DT mapping scheme

Describe the PRUSS event number in DT and describe the mapping scheme in
DT as well

 3) DT + dynamic mapping scheme

Describe the PRUSS event number in DT and let your interrupt controller
associate the irq number dynamically. That's kind of similar to MSI with
the exception that it needs to support shared interrupts.

 4) Fully dynamic association

Have a query interface to the firmware which tells you which event it uses
for which particular purpose (RX, TX ...) and then establish a dynamic
mapping to one of the interrupts.

Not sure which level of complexity you want :)

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