Re: [PATCH v2] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
On 2014-01-13 18:33, Ivaylo Dimitrov wrote: > From: Ivaylo Dimitrov > > commit 7faa92339bbb1e6b9a80983b206642517327eb75 OMAPDSS: DISPC: Handle > synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors > on OMAP3. However, it misses the logic found in Nokia kernels that is > needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as > well as the logic to fallback to 3 taps if 5 taps clock results in too > tight horizontal timings. Without that patch "horizontal timing too tight" > errors are seen when a video with resolution above 640x350 is tried to be > played. The patch is a forward-ported logic found in Nokia N900 and N9/50 > kernels. > > Signed-off-by: Ivaylo Dimitrov Queued for 3.14. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
On 13 January 2014 17:23, Nishanth Menon wrote: > On 01/13/2014 09:03 AM, Taras Kondratiuk wrote: >> From: Victor Kamensky >> >> Assembler functions defined in sleep44xx.S need to byteswap values >> after read / before write from h/w register if code compiled in big >> endian mode. Simple change to do 'rev x, x' before str instruction >> and after ldr instruction that deals with h/w registers. >> >> Signed-off-by: Victor Kamensky >> Signed-off-by: Taras Kondratiuk >> --- >> This is a part of RFC series [1]. >> Based on v3.13-rc8. >> >> [1] http://www.spinics.net/lists/linux-omap/msg99927.html >> >> arch/arm/mach-omap2/sleep44xx.S | 17 + >> 1 file changed, 17 insertions(+) >> > > OMAP4 is LE, and if there is a gcc flag for the same, is'nt it cleaner > to deal with it in Makefile rather than trying to make an assembly > meant only for LE by force building it for BE? Hi Nishanth I'm not sure I got your point. Do you propose to build this file as LE while the rest of kernel is BE? -- Regards, Taras Kondratiuk -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] drivers/usb/dwc3: don't check resource with devm_ioremap_resource
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang
---
Should go via subsystem tree
drivers/usb/dwc3/dwc3-omap.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 7f7ea62..cbcd972 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -432,11 +432,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "missing memory base resource\n");
- return -EINVAL;
- }
-
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
--
1.8.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/10/2014 08:51 PM, Tony Lindgren wrote: * Tero Kristo [140110 08:32]: On 01/10/2014 06:13 PM, Felipe Balbi wrote: On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote: On 01/10/2014 01:15 AM, Felipe Balbi wrote: On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: conflicts with be changes on Tony's be branch. commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 ARM: OMAP2+: raw read and write endian fix Conflict: arch/arm/mach-omap2/clkt_clksel.c arch/arm/mach-omap2/clkt_dpll.c arch/arm/mach-omap2/clkt_iclk.c arch/arm/mach-omap2/clock.c arch/arm/mach-omap2/clock36xx.c arch/arm/mach-omap2/dpll3xxx.c arch/arm/mach-omap2/dpll44xx.c Both change raw_readls -> should now be just clk api instead which already does readl_relaxed etc.. If Tony feels like, then we should probably post a branch based on 'be' branch for easy merge. This should be a trivial merge conflict to handle, so let's not base things on the BE changes. I think all of these fails are caused by the initially bugged Makefile + Kconfig under mach-omap2. Seems like they can be fixed by the patches I inlined at the end (will also post them as proper patches to l-o list after this.) The question is, should Mike go ahead and merge these along with the base clk patches or how should we handle them? Patch 1 must be merged, patch 2 is a nice to have one which allows DRA7 only builds (doing DRA7 only build currently seems not possible.) If it's OK with Tony, I would suggest having a branch with both patches below which both Tony and Mike merge before merging CCF series. That way we avoid bisection problems. I can queue those two separately as fixes. That reminds me, I think the baseline branch for the mach-omap2 patches is still somewhat unclear to me, what should be used for this? And which patches should be put there (the mach-omap2 patches depend on the drivers/clk/ti part basically, so I need to put at least those there also.) I would keep the clock patches against some mainline -rc commit if possible, and if there are non trivial merge conflicts, the omap to use as the base is commit adfe9361b236154215d4b0fc8b6d79995394b15c. In any case, it's probably best that Mike merges this all via his clock tree unless there non-trivial merge conflicts. I just pushed a branch against rc7 with makefile fixes in place to fix omap1 and omap2 only builds for this stuff. Inlined the delta here at the end. Do you want me to repost the series as v14 for this or is the attached delta ok for review purposes? All the changes have been squashed to existing patches (except the 2 patches I posted separately for DRA7xx / AM43xx only builds.) The test branch itself can be found here: tree: https://github.com/t-kristo/linux-pm.git branch: 3.13-rc7-dt-clks-v13-build-fixes Felipe, care to run your randconfig magic for this? -Tero diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index dc21df1..e65948a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -76,6 +76,16 @@ config SOC_AM43XX select ARM_GIC select MACH_OMAP_GENERIC +config SOC_DRA7XX + bool "TI DRA7XX" + depends on ARCH_MULTI_V7 + select ARCH_OMAP2PLUS + select ARM_CPU_SUSPEND if PM + select ARM_GIC + select CPU_V7 + select HAVE_SMP + select HAVE_ARM_ARCH_TIMER + config ARCH_OMAP2PLUS bool select ARCH_HAS_BANDGAP @@ -128,14 +138,6 @@ config SOC_HAS_REALTIME_COUNTER depends on SOC_OMAP5 || SOC_DRA7XX default y -config SOC_DRA7XX - bool "TI DRA7XX" - select ARM_ARCH_TIMER - select CPU_V7 - select ARM_GIC - select HAVE_SMP - select COMMON_CLK - comment "OMAP Core Type" depends on ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 088305f..8ebe9f3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -132,6 +132,7 @@ obj-$(CONFIG_SOC_AM33XX)+= $(voltagedomain-common) obj-$(CONFIG_SOC_AM43XX) += $(voltagedomain-common) obj-$(CONFIG_SOC_OMAP5)+= $(voltagedomain-common) obj-$(CONFIG_SOC_OMAP5)+= voltagedomains54xx_data.o +obj-$(CONFIG_SOC_DRA7XX) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -191,6 +192,9 @@ obj-$(CONFIG_ARCH_OMAP4)+= dpll3xxx.o dpll44xx.o obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX) += $(clock-common) +obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_AM43XX) += $(clock-common) dpll3xxx.o # OMAP2 clock rate set data (old "OPP" data) obj-$(CONFIG_S
Re: [PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
On Mon, Jan 13, 2014 at 06:19:23PM -0600, Suman Anna wrote: > The number of hwspinlocks are determined based on the value read > from the IP block's SYSSTATUS register. However, the module may > not be enabled and clocked, and the read may result in a bus error. > > This particular issue is seen rather easily on AM33XX, since the > module wakeup is software controlled, and it is disabled out of > reset. Make sure the module is enabled and clocked before reading > the SYSSTATUS register. > > Signed-off-by: Suman Anna > --- > drivers/hwspinlock/omap_hwspinlock.c | 21 ++--- > 1 file changed, 14 insertions(+), 7 deletions(-) > > diff --git a/drivers/hwspinlock/omap_hwspinlock.c > b/drivers/hwspinlock/omap_hwspinlock.c > index 9f56fb2..194886e 100644 > --- a/drivers/hwspinlock/omap_hwspinlock.c > +++ b/drivers/hwspinlock/omap_hwspinlock.c > @@ -101,10 +101,23 @@ static int omap_hwspinlock_probe(struct platform_device > *pdev) > if (!io_base) > return -ENOMEM; > > + /* > + * make sure the module is enabled and clocked before reading > + * the module SYSSTATUS register > + */ > + pm_runtime_enable(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > + > /* Determine number of locks */ > i = readl(io_base + SYSSTATUS_OFFSET); > i >>= SPINLOCK_NUMLOCKS_BIT_OFFSET; > > + /* > + * runtime PM will make sure the clock of this module is > + * enabled again iff at least one lock is requested > + */ > + pm_runtime_put(&pdev->dev); there is a small race here (which was already present previously) where you could return from probe() in a failure case before your PM runtime put request then you would disable pm_runtime while the device was still alive. -- balbi signature.asc Description: Digital signature
Re: [PATCHv4 0/7] omap hwspinlock dt support
On Mon, Jan 13, 2014 at 06:19:17PM -0600, Suman Anna wrote: > This is an updated series mainly addressing Mark Rutland's comments > about hwlock specifier being always one-cell. The series adds the > support for #hwlock-cells property and adds a simple default OF > translate function. > > The DTS patches from previous series have already been merged, and > needs this property to be added. This is handled in a separate series > that only deals with OMAP hwspinlock DTS patches. > > The series, along with the DTS patches, is tested on top of v3.13-rc8 > plus Tero's v13 clock DT series and Tony's 3.14 staged branches. The > validation on OMAP5, DRA7, AM437 requires Tero's series with couple of > additional base patches for AM43xx. AM43xx functionality needs a hwmod > fix [1] for creating the associated omap_device as well. > > The validation logs on all the applicable OMAP SoCs are at: > OMAP4 - http://paste2.org/YJ7ZwG80 > OMAP5 - http://paste2.org/c6vO96b9 > DRA7 - http://paste2.org/tHvxN439 > AM33x - http://paste2.org/AjCv0U4t > AM43x - http://paste2.org/2AKIPa55 I build tested your 3.13-rc8-v4 branch with the same script I used to build CCF series and hspinlock built without any problems ;-) Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCHv4 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote: > HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC > device families as well. The IPs are identical to that of > OMAP4/OMAP5, except for the number of locks. > > Add a depends on to the above family of SoCs to enable the > build support for OMAP hwspinlock driver for any of the above > SoC configs. > > Signed-off-by: Suman Anna > --- > drivers/hwspinlock/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig > index 70637d2..3612cb5 100644 > --- a/drivers/hwspinlock/Kconfig > +++ b/drivers/hwspinlock/Kconfig > @@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers" > > config HWSPINLOCK_OMAP > tristate "OMAP Hardware Spinlock device" > - depends on ARCH_OMAP4 || SOC_OMAP5 > + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || > SOC_AM43XX how about just using ARCH_OMAP2PLUS ? -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 9/9] arm: dts: am43x-gp-evm: Add matrix gpio keys.
On Mon, Jan 13, 2014 at 10:13:13PM +0530, sourav wrote:
> Benoit,
>
> On Thursday 19 December 2013 06:03 PM, Sourav Poddar wrote:
> >Add gpio keys node for am43x gp evm.
> >
> >Signed-off-by: Sourav Poddar
> >---
> > arch/arm/boot/dts/am437x-gp-evm.dts | 21 +
> > 1 file changed, 21 insertions(+)
> >
> >diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
> >b/arch/arm/boot/dts/am437x-gp-evm.dts
> >index 0dc248d..4eb72b8 100644
> >--- a/arch/arm/boot/dts/am437x-gp-evm.dts
> >+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> >@@ -13,6 +13,7 @@
> > #include "am4372.dtsi"
> > #include
> > #include
> >+#include
> >
> > / {
> > model = "TI AM437x GP EVM";
> >@@ -24,6 +25,26 @@
> > brightness-levels =<0 51 53 56 62 75 101 152 255>;
> > default-brightness-level =<8>;
> > };
> >+
> >+matrix_keypad: matrix_keypad@0 {
> >+compatible = "gpio-matrix-keypad";
> >+debounce-delay-ms =<5>;
> >+col-scan-delay-us =<2>;
> >+
> >+row-gpios =<&gpio3 21 GPIO_ACTIVE_HIGH /* Bank3, pin21 */
> >+&gpio4 3 GPIO_ACTIVE_HIGH /* Bank4, pin3 */
> >+&gpio4 2 GPIO_ACTIVE_HIGH>; /* Bank4, pin2 */
> >+
> >+col-gpios =<&gpio3 19 GPIO_ACTIVE_HIGH /* Bank3, pin19 */
> >+&gpio3 20 GPIO_ACTIVE_HIGH>; /* Bank3, pin20 */
> >+
> >+linux,keymap =<0x0201 /* P1 */
> >+0x00010202 /* P2 */
> >+0x0167 /* UP */
> >+0x0101006a /* RIGHT */
> >+0x0269 /* LEFT */
> >+0x0201006c>; /* DOWN */
> >+};
> > };
> >
> > &am43xx_pinmux {
>
> ping on this series, this series is lying for a while.
> This series is based on your for_3.14 branch.
Benoit, do you need us to do anything else to get this merged ? Sourav
already rebased the patches as you requested back in December 19th.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RFC 08/26] dmaengine: omap-dma: consolidate setup of CCR
On Mon, Jan 13, 2014 at 11:12:27PM +, Russell King - ARM Linux wrote: > On Mon, Jan 13, 2014 at 02:14:26PM -0800, Tony Lindgren wrote: > > * Russell King [140102 07:17]: > > > Consolidate the setup of the channel control register. Prepare the > > > basic value in the preparation of the DMA descriptor, and write it into > > > the register upon descriptor execution. > > > > FYI, this patch seems to be the one that causes the > > "DMA timeout with device 55" error for omap1. > > Okay, looks like I've missed some bit of muxing for DMA signals or > something. I've yet to find any information on this in the OMAP5912 > docs, so I guess I'm going to have to do this not only blind, but also > without hardware. GAH. Do you know which of the OMAP1 variants your device is? Is it OMAP15xx or OMAP16xx? It looks like OMAP15xx is easy to fix for this as it hasn't got the additional multiplexer on the DMA request signals. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit". -- 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: [PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
Hi again, On Tue, Jan 14, 2014 at 07:10:52AM -0600, Felipe Balbi wrote: > > diff --git a/drivers/hwspinlock/omap_hwspinlock.c > > b/drivers/hwspinlock/omap_hwspinlock.c > > index 9f56fb2..194886e 100644 > > --- a/drivers/hwspinlock/omap_hwspinlock.c > > +++ b/drivers/hwspinlock/omap_hwspinlock.c > > @@ -101,10 +101,23 @@ static int omap_hwspinlock_probe(struct > > platform_device *pdev) > > if (!io_base) > > return -ENOMEM; > > > > + /* > > +* make sure the module is enabled and clocked before reading > > +* the module SYSSTATUS register > > +*/ > > + pm_runtime_enable(&pdev->dev); > > + pm_runtime_get_sync(&pdev->dev); another thing, you need to check return of pm_runtime_get_sync() -- balbi signature.asc Description: Digital signature
Re: [PATCH 5/7] drivers/usb/dwc3: don't check resource with devm_ioremap_resource
On Tue, Jan 14, 2014 at 12:58:56PM +0100, Wolfram Sang wrote: > devm_ioremap_resource does sanity checks on the given resource. No need to > duplicate this in the driver. > > Signed-off-by: Wolfram Sang > --- > > Should go via subsystem tree too late for v3.14, I'll merge this for v3.15. -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 9/9] arm: dts: am43x-gp-evm: Add matrix gpio keys.
Hi Felipe,
On 14/01/2014 14:14, Felipe Balbi wrote:
On Mon, Jan 13, 2014 at 10:13:13PM +0530, sourav wrote:
Benoit,
On Thursday 19 December 2013 06:03 PM, Sourav Poddar wrote:
Add gpio keys node for am43x gp evm.
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/am437x-gp-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 0dc248d..4eb72b8 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -13,6 +13,7 @@
#include "am4372.dtsi"
#include
#include
+#include
/ {
model = "TI AM437x GP EVM";
@@ -24,6 +25,26 @@
brightness-levels =<0 51 53 56 62 75 101 152 255>;
default-brightness-level =<8>;
};
+
+ matrix_keypad: matrix_keypad@0 {
+ compatible = "gpio-matrix-keypad";
+ debounce-delay-ms =<5>;
+ col-scan-delay-us =<2>;
+
+ row-gpios =<&gpio3 21 GPIO_ACTIVE_HIGH /* Bank3, pin21 */
+ &gpio4 3 GPIO_ACTIVE_HIGH /* Bank4, pin3 */
+ &gpio4 2 GPIO_ACTIVE_HIGH>; /* Bank4, pin2 */
+
+ col-gpios =<&gpio3 19 GPIO_ACTIVE_HIGH /* Bank3, pin19 */
+ &gpio3 20 GPIO_ACTIVE_HIGH>; /* Bank3, pin20 */
+
+ linux,keymap =<0x0201 /* P1 */
+ 0x00010202 /* P2 */
+ 0x0167 /* UP */
+ 0x0101006a /* RIGHT */
+ 0x0269 /* LEFT */
+ 0x0201006c>; /* DOWN */
+ };
};
&am43xx_pinmux {
ping on this series, this series is lying for a while.
This series is based on your for_3.14 branch.
Benoit, do you need us to do anything else to get this merged ? Sourav
already rebased the patches as you requested back in December 19th.
Nope, I've just needed more BW. I'll apply it ASAP.
Thanks,
Benoit
--
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/5] phy: add support for indexed lookup
Hi Kishon, And happy new year.. On Tue, Jan 07, 2014 at 07:10:36PM +0530, Kishon Vijay Abraham I wrote: > >>> /** > >>> - * phy_get() - lookup and obtain a reference to a phy. > >>> + * phy_get_index() - obtain a phy based on index > >> > >> NAK. It still takes a 'char' argument and the name is misleading. > >> Btw are you replacing phy_get() or adding a new API in addition to > >> phy_get()? > > > > Additional API. The phy_get() would in practice act as a wrapper after > > In this patch it looks like you've replaced phy_get(). > > this. It could actually be just a #define macro in the include file. > > The function naming I just copied straight from gpiolib.c. I did not > > have the imagination for anything fancier. > > > > I would like to be able to use some function like phy_get_index() and > > be able to deliver it both the name and the index. With DT you guys > > will always be able to use the name (and the string will always > > supersede the index if we do it like this), but with ACPI, and possibly > > the platform lookup tables, the index can be used... > > I think in that case, we should drop the 'string' from phy_get_index since we > have the other API to handle that? I don't know about ACPI, but is it not > possible to use strings with ACPI? No unfortunately. We just have what the ACPI tables provide. The PHYs would be "child" device entries under the controller and we can only get handle to them based on the index. I think I'll skip this patch from this set. Let's wait until we have an actual ACPI DSDT describing some PHYs. Thanks, -- heikki -- 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 v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Pekon,
2014/1/6 Stefan Roese :
> Hi Pekon,
>
> On 06.01.2014 08:40, Gupta, Pekon wrote:
>> Hello Enric, Nikita, and other OMAP3 users,
>>
>>>
>>> As there were parallel set of patches running between u-boot and kernel.
>>> hence, some patch-sets caused regression for OMAP3x platforms when booting
>>> using u-boot specifically for ecc-schemes (like BCH4_SW).
>>>
>>> Hence this patch series fixes those regressions, and tests complete
>>> NAND boot sequence for multiple ecc-schemes on AM335x-EVM board.
>>> (following configurations are required for building u-boot driver which is
>>> compatible to kernel ecclayout for selected ecc-scheme)
>>>
>>>
>>>(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
>>> ROM -> SPL -> U-Boot -> Kernel ->
>>> File-System
>>>
>>>(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
>>> ROM -> SPL -> U-Boot -> Kernel ->
>>> File-System
>>>
>>>(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
>>> ROM -> SPL -> U-Boot -> Kernel ->
>>> File-System
>>>
>>> *Configurations used to build u-boot and kernel for end-to-end NAND boot*
>>> +++--+
>>> | ecc-scheme | u-boot/SPL configs| kernel DTS
>>> |
>>> +++--+
>>> |||
>>> |
>>> | HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \
>>> |ti,nand-ecc-opts= |
>>> || OMAP_ECC_HAM1_CODE_HW |"ham1"
>>> |
>>> | (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 |
>>> |
>>> | Hamming| #define CONFIG_SYS_NAND_ECCPOS \ |
>>> |
>>> | using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \|
>>> |
>>> ||10, 11, 12 }|
>>> |
>>> || (for NAND page-size=2048) |
>>> |
>>> |||
>>> |
>>> +++--+
>>> |||
>>> |
>>> | BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\
>>> |ti,nand-ecc-opts= |
>>> || OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |"bch8"
>>> |
>>> |(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM
>>> node)|
>>> | using s/w | #define CONFIG_BCH |
>>> |
>>> |library for | #undef CONFIG_SPL_NAND_AM33XX_BCH |
>>> |
>>> |for ECC | #define CONFIG_SPL_NAND_SIMPLE |
>>> |
>>> | error | #define CONFIG_SYS_NAND_ECCPOS \ |
>>> |
>>> |correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ |
>>> |
>>> || 11, 12, 13, 14, \ |
>>> |
>>> || 16, 17, 18, 19, 20, 21, 22, 23, 24, \ |
>>> |
>>> || 25, 26, 27, 28, \ |
>>> |
>>> || 30, 31, 32, 33, 34, 35, 36, 37, 38, \ |
>>> |
>>> || 39, 40, 41, 42, \ |
>>> |
>>> || 44, 45, 46, 47, 48, 49, 50, 51, 52, \ |
>>> |
>>> || 53, 54, 55, 56, } |
>>> |
>>> || (for NAND page-size=2048) |
>>> |
>>> || #define CONFIG_SYS_NAND_ECCSIZE 512 |
>>> |
>>> |||
>>> |
>>> +++--+
>>> |||
>>> |
>>> | BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\
>>> |ti,nand-ecc-opts= |
>>> || OMAP_ECC_BCH8_CODE_HW |"bch8"
>>> |
>>> |(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 |
>>> |
>>> | using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node)
>>> |
>>> | h/w engine | #define CONFIG_SYS_NAND_ECCPOS \ |ti,elm-id=<&elm>
>>> |
>>> |for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \|
>>> |
>>> | error | 10, 11, 12, 13, 14, 15, 16, 17, \|
>>> |
>>> |correction) | 18, 19, 20, 21, 22, 23, 24, 25, \|
>>> |
>>> || 26, 27, 28, 29, 30, 31, 32, 33, \|
>>>
Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote: > > In any case, having two device names to deal with does not add any > > more risk. These associations should always be made in the place where > > the phy device is created so you will always know it's device name. > > huh.. we should also know the 'controller' device name while defining these > associations and in some cases the controller device and phy device are > created > in entirely different places. If you don't want to use the controller device name to do the matching, we can use the con_id string as well. I believe the lookup method I use in this set just needs a small change. Is that OK with you? > > Normally the platform code creates these associations in the same > > place it creates the platform devices, so you definitely know what the > > device names will be. > > > > In this case it's actually created in drivers/mfd/twl-core.c, so I do > > need to update this and move the lookup table there. We can still > > deliver the user name as platform data, though I believe it's always > > "musb". Maybe we could actually skip that and just hard code the name? > > I would rather leave the way it is modelled now. Do you mean, leave it in the platform code? Why? We would reduce the platform code by moving it to the mfd driver. Or did I misunderstood something? Hope I'm not forgetting something we have talked before my vacation. Thanks, -- heikki -- 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: OMAP4: sleep: byteswap data for big-endian
On 01/14/2014 05:14 AM, Taras Kondratiuk wrote: > On 13 January 2014 17:23, Nishanth Menon wrote: >> On 01/13/2014 09:03 AM, Taras Kondratiuk wrote: >>> From: Victor Kamensky >>> >>> Assembler functions defined in sleep44xx.S need to byteswap values >>> after read / before write from h/w register if code compiled in big >>> endian mode. Simple change to do 'rev x, x' before str instruction >>> and after ldr instruction that deals with h/w registers. >>> >>> Signed-off-by: Victor Kamensky >>> Signed-off-by: Taras Kondratiuk >>> --- >>> This is a part of RFC series [1]. >>> Based on v3.13-rc8. >>> >>> [1] http://www.spinics.net/lists/linux-omap/msg99927.html >>> >>> arch/arm/mach-omap2/sleep44xx.S | 17 + >>> 1 file changed, 17 insertions(+) >>> >> >> OMAP4 is LE, and if there is a gcc flag for the same, is'nt it cleaner >> to deal with it in Makefile rather than trying to make an assembly >> meant only for LE by force building it for BE? > > Hi Nishanth > I'm not sure I got your point. > Do you propose to build this file as LE while the rest of kernel is BE? > I dont see why I should deal with the BE macro for every code change we have in omap4,am335x assembly. The hardware is LE and wont change just coz you are building it for BE. So I dont get the rationale for changing the assembly here - yes, if the assembly can be maintained as LE only mode and the build handling be adequately handled in Makefile (similar to SMC handling), that would be the best. is the idea of BE build meant to deal with having a single BE kernel build work for all platforms (including LE ones)? -- 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: [PATCHv4 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
Felipe, On 01/14/2014 07:12 AM, Felipe Balbi wrote: On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote: HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC device families as well. The IPs are identical to that of OMAP4/OMAP5, except for the number of locks. Add a depends on to the above family of SoCs to enable the build support for OMAP hwspinlock driver for any of the above SoC configs. Signed-off-by: Suman Anna --- drivers/hwspinlock/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig index 70637d2..3612cb5 100644 --- a/drivers/hwspinlock/Kconfig +++ b/drivers/hwspinlock/Kconfig @@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers" config HWSPINLOCK_OMAP tristate "OMAP Hardware Spinlock device" - depends on ARCH_OMAP4 || SOC_OMAP5 + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX how about just using ARCH_OMAP2PLUS ? We do not want the driver to build in OMAP2-only and/or OMAP3-only configurations, on which the hwspinlock IP is not even present. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
Felipe, On 01/14/2014 08:04 AM, Felipe Balbi wrote: Hi again, On Tue, Jan 14, 2014 at 07:10:52AM -0600, Felipe Balbi wrote: diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c index 9f56fb2..194886e 100644 --- a/drivers/hwspinlock/omap_hwspinlock.c +++ b/drivers/hwspinlock/omap_hwspinlock.c @@ -101,10 +101,23 @@ static int omap_hwspinlock_probe(struct platform_device *pdev) if (!io_base) return -ENOMEM; + /* +* make sure the module is enabled and clocked before reading +* the module SYSSTATUS register +*/ + pm_runtime_enable(&pdev->dev); + pm_runtime_get_sync(&pdev->dev); another thing, you need to check return of pm_runtime_get_sync() OK, let me check this and your other comment, and the fix is probably a separate patch. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 08/26] dmaengine: omap-dma: consolidate setup of CCR
* Russell King - ARM Linux [140114 05:41]: > On Mon, Jan 13, 2014 at 11:12:27PM +, Russell King - ARM Linux wrote: > > On Mon, Jan 13, 2014 at 02:14:26PM -0800, Tony Lindgren wrote: > > > * Russell King [140102 07:17]: > > > > Consolidate the setup of the channel control register. Prepare the > > > > basic value in the preparation of the DMA descriptor, and write it into > > > > the register upon descriptor execution. > > > > > > FYI, this patch seems to be the one that causes the > > > "DMA timeout with device 55" error for omap1. > > > > Okay, looks like I've missed some bit of muxing for DMA signals or > > something. I've yet to find any information on this in the OMAP5912 > > docs, so I guess I'm going to have to do this not only blind, but also > > without hardware. GAH. > > Do you know which of the OMAP1 variants your device is? Is it OMAP15xx > or OMAP16xx? It looks like OMAP15xx is easy to fix for this as it hasn't > got the additional multiplexer on the DMA request signals. This was with Nokia 770, which is 1710. Should be pretty much the same from SoC point of view as 5912 on OSK. 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: [PATCHv4 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
On Tue, Jan 14, 2014 at 10:51:31AM -0600, Anna, Suman wrote: > Felipe, > > On 01/14/2014 07:12 AM, Felipe Balbi wrote: > >On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote: > >>HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC > >>device families as well. The IPs are identical to that of > >>OMAP4/OMAP5, except for the number of locks. > >> > >>Add a depends on to the above family of SoCs to enable the > >>build support for OMAP hwspinlock driver for any of the above > >>SoC configs. > >> > >>Signed-off-by: Suman Anna > >>--- > >> drivers/hwspinlock/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >>diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig > >>index 70637d2..3612cb5 100644 > >>--- a/drivers/hwspinlock/Kconfig > >>+++ b/drivers/hwspinlock/Kconfig > >>@@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers" > >> > >> config HWSPINLOCK_OMAP > >>tristate "OMAP Hardware Spinlock device" > >>- depends on ARCH_OMAP4 || SOC_OMAP5 > >>+ depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || > >>SOC_AM43XX > > > >how about just using ARCH_OMAP2PLUS ? > > We do not want the driver to build in OMAP2-only and/or OMAP3-only > configurations, on which the hwspinlock IP is not even present. It won't be enabled by default, will it ? You're just saying that it _can_ be enabled. In fact, I would go one step further and use: depends on ARCH_OMAP2PLUS || COMPILE_TEST your choice though ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
Hi Nishanth, On 14 January 2014 07:51, Nishanth Menon wrote: > On 01/14/2014 05:14 AM, Taras Kondratiuk wrote: >> On 13 January 2014 17:23, Nishanth Menon wrote: >>> On 01/13/2014 09:03 AM, Taras Kondratiuk wrote: From: Victor Kamensky Assembler functions defined in sleep44xx.S need to byteswap values after read / before write from h/w register if code compiled in big endian mode. Simple change to do 'rev x, x' before str instruction and after ldr instruction that deals with h/w registers. Signed-off-by: Victor Kamensky Signed-off-by: Taras Kondratiuk --- This is a part of RFC series [1]. Based on v3.13-rc8. [1] http://www.spinics.net/lists/linux-omap/msg99927.html arch/arm/mach-omap2/sleep44xx.S | 17 + 1 file changed, 17 insertions(+) >>> >>> OMAP4 is LE, and if there is a gcc flag for the same, is'nt it cleaner >>> to deal with it in Makefile rather than trying to make an assembly >>> meant only for LE by force building it for BE? >> >> Hi Nishanth >> I'm not sure I got your point. >> Do you propose to build this file as LE while the rest of kernel is BE? >> > I dont see why I should deal with the BE macro for every code change > we have in omap4,am335x assembly. The hardware is LE and wont change > just coz you are building it for BE. So I dont get the rationale for > changing the assembly here - yes, if the assembly can be maintained as > LE only mode and the build handling be adequately handled in Makefile > (similar to SMC handling), that would be the best. ARM core is capable of running in LE or BE modes. Yes, OMAP memory mapped periphery gives data in LE form. When core runs in BE mode after reading h/w register it will byteswap it, also before writing h/w register it byteswap it. In such way BE kernel can work with LE periphery. When it comes to C code that works with LE periphery, if correct access functions are used like readl_relaxed and writel_relaxed (vs __raw_readl and __raw_writel), the functions will take care of the swaps. In case of asm files there is no other way than to insert those byteswaps manually and conditionally - they will be enabled only if kernel compiled in BE mode. The reason why it could be done only manually is that load/store opcodes behavior changes when core runs in BE mode (E bit set) in these case ldr/str treat memory as big endian. So when LE periphery register is read/stored additional byteswaps that compensate for it should be inserted. When BE kernel is built Makefile does take of compiling code in BE mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set. > is the idea of BE build meant to deal with having a single BE kernel > build work for all platforms (including LE ones)? Sort of. The idea here to run BE image on OMAP4 chip, with kernel that would deals with LE periphery correctly, but ARM core run in BE with special kernel that compiled for BE case (i.e CONFIG_CPU_BIG_ENDIAN is set). Thanks, Victor > -- > 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: [PATCHv2 9/9] arm: dts: am43x-gp-evm: Add matrix gpio keys.
On Tue, Jan 14, 2014 at 03:21:41PM +0100, Benoit Cousson wrote:
> Hi Felipe,
>
> On 14/01/2014 14:14, Felipe Balbi wrote:
> >On Mon, Jan 13, 2014 at 10:13:13PM +0530, sourav wrote:
> >>Benoit,
> >>
> >>On Thursday 19 December 2013 06:03 PM, Sourav Poddar wrote:
> >>>Add gpio keys node for am43x gp evm.
> >>>
> >>>Signed-off-by: Sourav Poddar
> >>>---
> >>> arch/arm/boot/dts/am437x-gp-evm.dts | 21 +
> >>> 1 file changed, 21 insertions(+)
> >>>
> >>>diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
> >>>b/arch/arm/boot/dts/am437x-gp-evm.dts
> >>>index 0dc248d..4eb72b8 100644
> >>>--- a/arch/arm/boot/dts/am437x-gp-evm.dts
> >>>+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> >>>@@ -13,6 +13,7 @@
> >>> #include "am4372.dtsi"
> >>> #include
> >>> #include
> >>>+#include
> >>>
> >>> / {
> >>> model = "TI AM437x GP EVM";
> >>>@@ -24,6 +25,26 @@
> >>> brightness-levels =<0 51 53 56 62 75 101 152 255>;
> >>> default-brightness-level =<8>;
> >>> };
> >>>+
> >>>+ matrix_keypad: matrix_keypad@0 {
> >>>+ compatible = "gpio-matrix-keypad";
> >>>+ debounce-delay-ms =<5>;
> >>>+ col-scan-delay-us =<2>;
> >>>+
> >>>+ row-gpios =<&gpio3 21 GPIO_ACTIVE_HIGH /* Bank3, pin21 */
> >>>+ &gpio4 3 GPIO_ACTIVE_HIGH /* Bank4, pin3 */
> >>>+ &gpio4 2 GPIO_ACTIVE_HIGH>; /* Bank4, pin2 */
> >>>+
> >>>+ col-gpios =<&gpio3 19 GPIO_ACTIVE_HIGH /* Bank3, pin19 */
> >>>+ &gpio3 20 GPIO_ACTIVE_HIGH>; /* Bank3, pin20 */
> >>>+
> >>>+ linux,keymap =<0x0201 /* P1 */
> >>>+ 0x00010202 /* P2 */
> >>>+ 0x0167 /* UP */
> >>>+ 0x0101006a /* RIGHT */
> >>>+ 0x0269 /* LEFT */
> >>>+ 0x0201006c>; /* DOWN */
> >>>+ };
> >>> };
> >>>
> >>> &am43xx_pinmux {
> >>
> >>ping on this series, this series is lying for a while.
> >>This series is based on your for_3.14 branch.
> >
> >Benoit, do you need us to do anything else to get this merged ? Sourav
> >already rebased the patches as you requested back in December 19th.
>
> Nope, I've just needed more BW. I'll apply it ASAP.
cool, thanks.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky wrote: > > When BE kernel is built Makefile does take of compiling code in BE > mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set. Agreed, and I assume you cannot instead switch to LE mode when entering assembly assuming LE? The reason I ask this is - most of our development is NOT in BE mode. we will continue to manipulate and add assembly - AM335x, DRA7/OMAP5 etc.. and obviously not every code change will indulge in ensuring right markers will be in place. by ensuring readl_relaxed handles the variations, you have ensured that I dont need to care about drivers other than to ensure they use _relaxed variants. in the case of assembly, this does not seem long term manageable. > >> is the idea of BE build meant to deal with having a single BE kernel >> build work for all platforms (including LE ones)? > > Sort of. The idea here to run BE image on OMAP4 chip, with > kernel that would deals with LE periphery correctly, but ARM > core run in BE with special kernel that compiled for BE case (i.e > CONFIG_CPU_BIG_ENDIAN is set). I still dont get the usecase - other than "hey, we do this coz we can do it!".. I mean, yep, it sounds great and all.. but 4 years down the line, is this still going to work? is this going to be interesting careabout? or we are just maintaining additional code for a passing fancy or proof-of-concept? 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: [PATCHv4 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
On 01/14/2014 11:29 AM, Felipe Balbi wrote: On Tue, Jan 14, 2014 at 10:51:31AM -0600, Anna, Suman wrote: Felipe, On 01/14/2014 07:12 AM, Felipe Balbi wrote: On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote: HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC device families as well. The IPs are identical to that of OMAP4/OMAP5, except for the number of locks. Add a depends on to the above family of SoCs to enable the build support for OMAP hwspinlock driver for any of the above SoC configs. Signed-off-by: Suman Anna --- drivers/hwspinlock/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig index 70637d2..3612cb5 100644 --- a/drivers/hwspinlock/Kconfig +++ b/drivers/hwspinlock/Kconfig @@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers" config HWSPINLOCK_OMAP tristate "OMAP Hardware Spinlock device" - depends on ARCH_OMAP4 || SOC_OMAP5 + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX how about just using ARCH_OMAP2PLUS ? We do not want the driver to build in OMAP2-only and/or OMAP3-only configurations, on which the hwspinlock IP is not even present. It won't be enabled by default, will it ? You're just saying that it _can_ be enabled. Yes, that's correct. The menuconfig will not even show this driver at present on OMAP2-only and/or OMAP3-only configs. I would prefer to keep it that way. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
On 14 January 2014 09:56, Nishanth Menon wrote: > On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky > wrote: >> >> When BE kernel is built Makefile does take of compiling code in BE >> mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set. > > Agreed, and I assume you cannot instead switch to LE mode when > entering assembly assuming LE? Yes. Note that this asm interacts with other data in kernel that would be in BE form. And after all linker will not allow to put together files that were compiled in different endianity. > The reason I ask this is - most of our development is NOT in BE mode. > we will continue to manipulate and add assembly - AM335x, DRA7/OMAP5 > etc.. and obviously not every code change will indulge in ensuring > right markers will be in place. > > by ensuring readl_relaxed handles the variations, you have ensured > that I dont need to care about drivers other than to ensure they use > _relaxed variants. in the case of assembly, this does not seem long > term manageable. Yes, I agree if it is outside of main use case it will get broken if not attended to. Definitely universe entropy increases :) - if left without attention things will decay. Note we admit that even with ARM CPU core BE changes similar decay can happen eventually ...that is what LNG BE group trying to prevent. I think the deal here is that next user of it can/need to fix things if they decayed. >> >>> is the idea of BE build meant to deal with having a single BE kernel >>> build work for all platforms (including LE ones)? >> >> Sort of. The idea here to run BE image on OMAP4 chip, with >> kernel that would deals with LE periphery correctly, but ARM >> core run in BE with special kernel that compiled for BE case (i.e >> CONFIG_CPU_BIG_ENDIAN is set). > > I still dont get the usecase - other than "hey, we do this coz we can > do it!".. I mean, yep, it sounds great and all.. but 4 years down the > line, is this still going to work? is this going to be interesting > careabout? or we are just maintaining additional code for a passing > fancy or proof-of-concept? Valid concern. From LNG BE group point of view it is not "we can do it". It is more like we've done it. We have Pandaboard ES running BE kernel for a while. It is in LNG BE tree. We used it as development and testing vehicle for BE work for a while. We are very grateful to the platform for that - it is affordable and easily available! Given, beyond ongoing BE testing on Pandaboard in LNG there may not be valid use case for further things on OMAP4 BE. We had discussion with Santosh Shilimkar from TI during last Linaro connect what to do with LNG BE Pandaboard series. Santosh suggested and we agreed that we would try to contribute them back to community. And that is what Taras is doing. IMHO even though there may not be real product use case for BE OMAP4, it could serve in kernel source as good example that shows how to work with LE periphery from BE kernel. After all, these changes are noop for LE case and they don't introduce a lot of clutter: all BE asm rev and rev16 instructions wrapped around with ARM_BE8 macro. Thanks, Victor > 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Tue, Jan 14, 2014 at 02:41:40PM +0200, Tero Kristo wrote: > On 01/10/2014 08:51 PM, Tony Lindgren wrote: > >* Tero Kristo [140110 08:32]: > >>On 01/10/2014 06:13 PM, Felipe Balbi wrote: > >>>On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote: > On 01/10/2014 01:15 AM, Felipe Balbi wrote: > >On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: > >> > >>conflicts with be changes on Tony's be branch. > >>commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 > >> ARM: OMAP2+: raw read and write endian fix > >> > >>Conflict: > >>arch/arm/mach-omap2/clkt_clksel.c > >>arch/arm/mach-omap2/clkt_dpll.c > >>arch/arm/mach-omap2/clkt_iclk.c > >>arch/arm/mach-omap2/clock.c > >>arch/arm/mach-omap2/clock36xx.c > >>arch/arm/mach-omap2/dpll3xxx.c > >>arch/arm/mach-omap2/dpll44xx.c > >> > >>Both change raw_readls -> should now be just clk api instead which > >>already does readl_relaxed etc.. If Tony feels like, then we should > >>probably post a branch based on 'be' branch for easy merge. > > > >This should be a trivial merge conflict to handle, so let's not base > >things on the BE changes. > > > I think all of these fails are caused by the initially bugged > Makefile + Kconfig under mach-omap2. Seems like they can be fixed by > the patches I inlined at the end (will also post them as proper > patches to l-o list after this.) The question is, should Mike go > ahead and merge these along with the base clk patches or how should > we handle them? Patch 1 must be merged, patch 2 is a nice to have one > which allows DRA7 only builds (doing DRA7 only build currently seems > not possible.) > >>> > >>>If it's OK with Tony, I would suggest having a branch with both patches > >>>below which both Tony and Mike merge before merging CCF series. That way > >>>we avoid bisection problems. > > > >I can queue those two separately as fixes. > > > >>That reminds me, I think the baseline branch for the mach-omap2 > >>patches is still somewhat unclear to me, what should be used for > >>this? And which patches should be put there (the mach-omap2 patches > >>depend on the drivers/clk/ti part basically, so I need to put at > >>least those there also.) > > > >I would keep the clock patches against some mainline -rc commit if > >possible, and if there are non trivial merge conflicts, the omap > >to use as the base is commit adfe9361b236154215d4b0fc8b6d79995394b15c. > > > >In any case, it's probably best that Mike merges this all via his > >clock tree unless there non-trivial merge conflicts. > > > > I just pushed a branch against rc7 with makefile fixes in place to > fix omap1 and omap2 only builds for this stuff. Inlined the delta > here at the end. Do you want me to repost the series as v14 for this > or is the attached delta ok for review purposes? All the changes have > been squashed to existing patches (except the 2 patches I posted > separately for DRA7xx / AM43xx only builds.) > > The test branch itself can be found here: > > tree: https://github.com/t-kristo/linux-pm.git > branch: 3.13-rc7-dt-clks-v13-build-fixes > > Felipe, care to run your randconfig magic for this? This branch builds just fine so far, I still have omap5 multiplaform and uniplatform builds, but since that was working before i'm assuming it won't break. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
On Tue, Jan 14, 2014 at 2:20 PM, Victor Kamensky wrote: > On 14 January 2014 09:56, Nishanth Menon wrote: >> On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky >> wrote: >>> >>> When BE kernel is built Makefile does take of compiling code in BE >>> mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set. >> >> Agreed, and I assume you cannot instead switch to LE mode when >> entering assembly assuming LE? > > Yes. Note that this asm interacts with other data in kernel that would > be in BE form. And after all linker will not allow to put together files > that were compiled in different endianity. > >> The reason I ask this is - most of our development is NOT in BE mode. >> we will continue to manipulate and add assembly - AM335x, DRA7/OMAP5 >> etc.. and obviously not every code change will indulge in ensuring >> right markers will be in place. >> >> by ensuring readl_relaxed handles the variations, you have ensured >> that I dont need to care about drivers other than to ensure they use >> _relaxed variants. in the case of assembly, this does not seem long >> term manageable. > > Yes, I agree if it is outside of main use case it will get broken if not > attended to. Definitely universe entropy increases :) - if left without > attention things will decay. Note we admit that even with ARM CPU > core BE changes similar decay can happen eventually ...that is > what LNG BE group trying to prevent. I think > the deal here is that next user of it can/need to fix things if they > decayed. > Personally, I have no idea what "LNG BE" stands for.. I see the approach we are attempting here is to do any interaction external to ARM boundary to go through the ARM_BE8 macro. If we want to make this something we can live with, then the platforms will have to ensure memory operations external to ARM must be operated upon by these macros. Instead, an approach that may be used is to introduce accessors macros that will provide right instruction based on BE/LE build and BE/LE SoC peripheral behavior. >>> is the idea of BE build meant to deal with having a single BE kernel build work for all platforms (including LE ones)? >>> >>> Sort of. The idea here to run BE image on OMAP4 chip, with >>> kernel that would deals with LE periphery correctly, but ARM >>> core run in BE with special kernel that compiled for BE case (i.e >>> CONFIG_CPU_BIG_ENDIAN is set). >> >> I still dont get the usecase - other than "hey, we do this coz we can >> do it!".. I mean, yep, it sounds great and all.. but 4 years down the >> line, is this still going to work? is this going to be interesting >> careabout? or we are just maintaining additional code for a passing >> fancy or proof-of-concept? > > Valid concern. From LNG BE group point of view it is not "we can do > it". It is more like we've done it. We have Pandaboard ES running BE > kernel for a while. It is in LNG BE tree. We used it as development > and testing vehicle for BE work for a while. We are very grateful to > the platform for that - it is affordable and easily available! Given, > beyond ongoing BE testing on Pandaboard in LNG there may not be valid > use case for further things on OMAP4 BE. We had discussion > with Santosh Shilimkar from TI during last Linaro connect what to > do with LNG BE Pandaboard series. Santosh suggested and we > agreed that we would try to contribute them back to community. And > that is what Taras is doing. IMHO even though there may not be real ok.. some sort of Linaro thing about which I have no background about - but dont really care in this context. > product use case for BE OMAP4, it could serve in kernel source as good > example that shows how to work with LE periphery from BE kernel. After > all, these changes are noop for LE case and they don't introduce > a lot of clutter: all BE asm rev and rev16 instructions wrapped around > with ARM_BE8 macro. > So, why are we not doing this for *all* OMAP platforms? we try very hard not to regress on features introduced and wish to ensure all platforms are equivalent in terms of usage. it makes code sharing a little harder if we have to ensure that ARM_BE8 is supported in a mix of reusable codebases. Personally, here is what I might expect to see: a) if we are going to force usage of BE and LE build options - then we *must* be able to reuse code across platforms without having to worry about breaking platform x etc.. b) this seems like - "take this code in" if something breaks, the guy who needs it later will come and fix - Shrug, I personally dont buy that. if something benefits many folks, lets all use it in upstream, if there is just an exception usage for a short duration which may impact code scalability and hard to maintain, keep it forked. c) considering this is non standard usage, some sort of regular test procedure and owner to ensure this feature is kept sane With out the above, we are just adding dead code IMHO. Regards, Nishanth Menon -- To unsubscribe from this list: sen
Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
On Tuesday 14 January 2014 03:56 PM, Nishanth Menon wrote: > On Tue, Jan 14, 2014 at 2:20 PM, Victor Kamensky > wrote: >> On 14 January 2014 09:56, Nishanth Menon wrote: >>> On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky >>> wrote: When BE kernel is built Makefile does take of compiling code in BE mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set. >>> >>> Agreed, and I assume you cannot instead switch to LE mode when >>> entering assembly assuming LE? >> >> Yes. Note that this asm interacts with other data in kernel that would >> be in BE form. And after all linker will not allow to put together files >> that were compiled in different endianity. >> >>> The reason I ask this is - most of our development is NOT in BE mode. >>> we will continue to manipulate and add assembly - AM335x, DRA7/OMAP5 >>> etc.. and obviously not every code change will indulge in ensuring >>> right markers will be in place. >>> >>> by ensuring readl_relaxed handles the variations, you have ensured >>> that I dont need to care about drivers other than to ensure they use >>> _relaxed variants. in the case of assembly, this does not seem long >>> term manageable. >> >> Yes, I agree if it is outside of main use case it will get broken if not >> attended to. Definitely universe entropy increases :) - if left without >> attention things will decay. Note we admit that even with ARM CPU >> core BE changes similar decay can happen eventually ...that is >> what LNG BE group trying to prevent. I think >> the deal here is that next user of it can/need to fix things if they >> decayed. >> > > Personally, I have no idea what "LNG BE" stands for.. I see the > approach we are attempting here is to do any interaction external to > ARM boundary to go through the ARM_BE8 macro. > > If we want to make this something we can live with, then the platforms > will have to ensure memory operations external to ARM must be operated > upon by these macros. Instead, an approach that may be used is to > introduce accessors macros that will provide right instruction based > on BE/LE build and BE/LE SoC peripheral behavior. > > is the idea of BE build meant to deal with having a single BE kernel > build work for all platforms (including LE ones)? Sort of. The idea here to run BE image on OMAP4 chip, with kernel that would deals with LE periphery correctly, but ARM core run in BE with special kernel that compiled for BE case (i.e CONFIG_CPU_BIG_ENDIAN is set). >>> >>> I still dont get the usecase - other than "hey, we do this coz we can >>> do it!".. I mean, yep, it sounds great and all.. but 4 years down the >>> line, is this still going to work? is this going to be interesting >>> careabout? or we are just maintaining additional code for a passing >>> fancy or proof-of-concept? >> >> Valid concern. From LNG BE group point of view it is not "we can do >> it". It is more like we've done it. We have Pandaboard ES running BE >> kernel for a while. It is in LNG BE tree. We used it as development >> and testing vehicle for BE work for a while. We are very grateful to >> the platform for that - it is affordable and easily available! Given, >> beyond ongoing BE testing on Pandaboard in LNG there may not be valid >> use case for further things on OMAP4 BE. We had discussion >> with Santosh Shilimkar from TI during last Linaro connect what to >> do with LNG BE Pandaboard series. Santosh suggested and we >> agreed that we would try to contribute them back to community. And >> that is what Taras is doing. IMHO even though there may not be real > > ok.. some sort of Linaro thing about which I have no background about > - but dont really care in this context. > Nothing related Linaro. Its just that platforms are supporting ARM BE mode and Linaro folks had working patches for Panda. So I suggested to get them on the lists. Regards, Santosh -- 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: OMAP4: sleep: byteswap data for big-endian
On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar wrote: > >> ok.. some sort of Linaro thing about which I have no background about >> - but dont really care in this context. >> > Nothing related Linaro. Its just that platforms are supporting ARM BE > mode and Linaro folks had working patches for Panda. So I suggested > to get them on the lists. I tend to think -> is this with OFF mode and CPUidle completely working? All context save and restore works with this? on HS and GP devices with BE mode builds? works on SDP4430,60 variations, considered reuse with AM43xx which could use parts of that logic? I mean to indicate that terms like "works on panda" tends always to be relative. It is nice to see it as a proof of concept, but I'd hate to see some dead code lying around in kernel and folks blindly following suit and introducing macros for new assembly for a feature that in practice just one group of folks care about and creates additional burden for rest of folks trying to keep that functionality going as we jump from one "device tree" style churn to another "framework"? Not to mean that good features should be kept away.. but personally, I could not find convincing arguments in this case.. 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 v2] ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
On Fri, Nov 15, 2013 at 8:12 AM, Santosh Shilimkar wrote: > On Friday 15 November 2013 11:11 AM, Tony Lindgren wrote: >> * Taras Kondratiuk [131115 08:03]: >>> On 11/15/2013 05:36 PM, Tony Lindgren wrote: * Tony Lindgren [131114 10:36]: > * Grygorii Strashko [131022 12:09]: >> The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859 >> "ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..." >> need to be applied not only when system is booting, but when MPUSS hits >> OSWR state through CPUIdle too. Without this WA the same issue is >> reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460 >> when CONFIG_CPU_IDLE is enabled. >> After MPUSS has enterred OSWR and waken up: >> - GIC distributor became disabled forever >> - scheduling is not performed any more >> >> Cc: Kevin Hilman >> Acked-by: Santosh Shilimkar >> Reported-by: Taras Kondratiuk >> Signed-off-by: Grygorii Strashko > > Applying into omap-for-v3.13/fixes thanks. Hmm looks like this breaks the build with randconfigs at least with the attached .config, so dropping for now. >>> >>> Hi Tony >>> Have you forgot to attach .config? >> >> Oops, sorry looks like I removed it already as I rebuilt the tree >> and started a new set of randconfig build tests. >> arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled': :(.text+0xb48c): undefined reference to `pm44xx_errata' >>> >>> I assume that .config doesn't have CONFIG_SMP enabled while >>> pm44xx_errata is defined in omap-smp.c. >>> I think it should be a separate patch to move pm44xx_errata somewhere >>> else, so this patch will remain the same. >> >> Yes something like that probably. Sounds like that should be then >> patches before this fix. >> >>> Btw, do we need omap_enter_idle_coupled() in UP? >> >> That should be checked, am43xx may need it. >> > Nope. omap_enter_idle_coupled() is needed only for SMP > systems. UP don't need couple idle functionality as > such. So what's the status of this fix and dependencies? Both linux-next[1] and arm-soc/for-next[2] are failing boot tests on omap4460/panda-es because multi_v7_defconfig now has CPUidle enabled by default. Kevin [1] http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001891.html [2] http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001898.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: [GIT PULL 1/4] non-urgent omap fixes for v3.14 merge window
Tony Lindgren writes: > The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: > > Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.14/fixes-not-urgent-signed > > for you to fetch changes up to bbc28cdbd003be5ceeaf644be3533e898c25da2b: > > ARM: OMAP2+: gpmc: Move legacy GPMC width setting (2014-01-08 09:49:47 > -0800) > > > Some non-urgent fixes to enable am335x features, update documentation, > and to remove unnecessary double initialization for the GPMC code. > > Thanks, adding to next/fixes-non-critical. Kevin -- 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/4] trivial omap big endian changes for v3.14 merge window
* Kevin Hilman [140114 14:33]: > Tony Lindgren writes: > > > The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: > > > > Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > > tags/omap-for-v3.14/be-signed > > > > for you to fetch changes up to fc6ca98c81bf0ea8b46064915b5947b971594101: > > > > ARM: OMAP: debug-leds: raw read and write endian fix (2014-01-07 16:09:45 > > -0800) > > > > > > Trivial search and replace of read and write functions to allow > > further patches to make omaps work also in big endian mode. > > > > > > I think this one should wait for v3.15. While a trivial rename, it's a > pretty broad change and risks having conflicts and fallouts with other > changes (thinking especially of ongoing clock changes.) Sure no problem. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 3/4] trivial omap big endian changes for v3.14 merge window
Tony Lindgren writes: > The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: > > Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.14/be-signed > > for you to fetch changes up to fc6ca98c81bf0ea8b46064915b5947b971594101: > > ARM: OMAP: debug-leds: raw read and write endian fix (2014-01-07 16:09:45 > -0800) > > > Trivial search and replace of read and write functions to allow > further patches to make omaps work also in big endian mode. > > I think this one should wait for v3.15. While a trivial rename, it's a pretty broad change and risks having conflicts and fallouts with other changes (thinking especially of ongoing clock changes.) Kevin -- 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/4] omap device tree fixes for v3.14 merge window
Tony Lindgren writes: > The following changes since commit adfe9361b236154215d4b0fc8b6d79995394b15c: > > ARM: dts: Add basic devices on am3517-evm (2013-12-08 14:15:46 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.14/dt-signed > > for you to fetch changes up to e37e1cb0ee231ffdc9b5ef1da63a0c7e1077c603: > > ARM: dts: OMAP2: fix interrupt number for rng (2014-01-08 10:24:44 -0800) > > > Split omap3 core padconf area into two as some of the registers in > the padconf area are not accessible and used for other devices. > Also fix the interrupt number for omap2 RNG, and add basic support > for sbc-3xxx with cm-t3730. > > Note that the minor merge conflicts for omap_hwmod_2xxx_ipblock_data.c > can be solved by just dropping the legacy hwmod data for interrupts > for v3.14. > > Applying to next/fixes-non-critical. Kevin -- 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 4/4] GIC crossbar support for v3.14 merge window
Tony Lindgren writes: > The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: > > Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.14/crossbar-signed > > for you to fetch changes up to 70d4545544853e2d95909b919d4565ff32c3e3c5: > > ARM: DRA: Enable Crossbar IP support for DRA7XX (2014-01-08 09:21:42 -0800) > > > Add support for GIC crossbar that routes interrupts on newer omaps. > > I think this one is a little late for v3.14 also, and should spend some more time in -next before v3.15. Also... > Sricharan R (4): > irqchip: irq-gic: Add support for routable irqs ... I see a Reviewed-by from tglx on this one... > irqchip: crossbar: Add support for Crossbar IP ...but no signs of irqchip mainainer review/ack on this one. Ideally, these two irqchip ones would be merged through the irqchip maintainers... > ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number > ARM: DRA: Enable Crossbar IP support for DRA7XX .. and then we'd take these two through arm-soc. If there are strong dependencies, we can take them all through arm-soc, but I'd like to see the tags from the irqchip maintainers first. Kevin -- 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: OMAP4: sleep: byteswap data for big-endian
On 14 January 2014 23:13, Nishanth Menon wrote: > On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar > wrote: >> >>> ok.. some sort of Linaro thing about which I have no background about >>> - but dont really care in this context. >>> >> Nothing related Linaro. Its just that platforms are supporting ARM BE >> mode and Linaro folks had working patches for Panda. So I suggested >> to get them on the lists. > > I tend to think -> is this with OFF mode and CPUidle completely > working? All context save and restore works with this? on HS and GP > devices with BE mode builds? works on SDP4430,60 variations, > considered reuse with AM43xx which could use parts of that logic? > > I mean to indicate that terms like "works on panda" tends always to be > relative. Nishanth, let's be objective here. CPUidle on 4460 does *not* work in mainline for at least two kernel releases even for LE [1]. That fix exists because that "one group of folks" faced the issue during BE testing. Looks like not much people care about CPUIdle on OMAP4. > It is nice to see it as a proof of concept, but I'd hate to see some > dead code lying around in kernel and folks blindly following suit and > introducing macros for new assembly for a feature that in practice > just one group of folks care about and creates additional burden for > rest of folks trying to keep that functionality going as we jump from > one "device tree" style churn to another "framework"? Not to mean that > good features should be kept away.. but personally, I could not find > convincing arguments in this case.. In general I understand your concerns from previous e-mails, but I don't see a point to spend time for a generic solution for a single user. If there will be other platforms which need similar changes, then we can think of some generic solution. Let's drop this patch for now. We can just disable CPUidle for BE tasks or keep this patch forked. [1] https://lkml.org/lkml/2013/10/22/401 -- Regards, Taras Kondratiuk -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
On Tuesday 14 January 2014 04:26 PM, Kevin Hilman wrote: > On Fri, Nov 15, 2013 at 8:12 AM, Santosh Shilimkar > wrote: >> On Friday 15 November 2013 11:11 AM, Tony Lindgren wrote: >>> * Taras Kondratiuk [131115 08:03]: On 11/15/2013 05:36 PM, Tony Lindgren wrote: > * Tony Lindgren [131114 10:36]: >> * Grygorii Strashko [131022 12:09]: >>> The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859 >>> "ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..." >>> need to be applied not only when system is booting, but when MPUSS hits >>> OSWR state through CPUIdle too. Without this WA the same issue is >>> reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460 >>> when CONFIG_CPU_IDLE is enabled. >>> After MPUSS has enterred OSWR and waken up: >>> - GIC distributor became disabled forever >>> - scheduling is not performed any more >>> >>> Cc: Kevin Hilman >>> Acked-by: Santosh Shilimkar >>> Reported-by: Taras Kondratiuk >>> Signed-off-by: Grygorii Strashko >> >> Applying into omap-for-v3.13/fixes thanks. > > Hmm looks like this breaks the build with randconfigs at least > with the attached .config, so dropping for now. Hi Tony Have you forgot to attach .config? >>> >>> Oops, sorry looks like I removed it already as I rebuilt the tree >>> and started a new set of randconfig build tests. >>> > arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled': > :(.text+0xb48c): undefined reference to `pm44xx_errata' I assume that .config doesn't have CONFIG_SMP enabled while pm44xx_errata is defined in omap-smp.c. I think it should be a separate patch to move pm44xx_errata somewhere else, so this patch will remain the same. >>> >>> Yes something like that probably. Sounds like that should be then >>> patches before this fix. >>> Btw, do we need omap_enter_idle_coupled() in UP? >>> >>> That should be checked, am43xx may need it. >>> >> Nope. omap_enter_idle_coupled() is needed only for SMP >> systems. UP don't need couple idle functionality as >> such. > > So what's the status of this fix and dependencies? > > Both linux-next[1] and arm-soc/for-next[2] are failing boot tests on > omap4460/panda-es because multi_v7_defconfig now has CPUidle enabled > by default. > I think Taras needs to refresh the patch based on discussion and then it can be merged. > > [1] > http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001891.html > [2] > http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001898.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] ARM: OMAP4: sleep: byteswap data for big-endian
On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote: > On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar > wrote: >> >>> ok.. some sort of Linaro thing about which I have no background about >>> - but dont really care in this context. >>> >> Nothing related Linaro. Its just that platforms are supporting ARM BE >> mode and Linaro folks had working patches for Panda. So I suggested >> to get them on the lists. > > I tend to think -> is this with OFF mode and CPUidle completely > working? All context save and restore works with this? on HS and GP > devices with BE mode builds? works on SDP4430,60 variations, > considered reuse with AM43xx which could use parts of that logic? > > I mean to indicate that terms like "works on panda" tends always to be > relative. > Fair enough. > It is nice to see it as a proof of concept, but I'd hate to see some > dead code lying around in kernel and folks blindly following suit and > introducing macros for new assembly for a feature that in practice > just one group of folks care about and creates additional burden for > rest of folks trying to keep that functionality going as we jump from > one "device tree" style churn to another "framework"? Not to mean that > good features should be kept away.. but personally, I could not find > convincing arguments in this case.. > I haven't looked at patch myself but as you pointed out if it adds dead code and makes the code un-readable then probably that something we shouldn't merge. Regards, Santosh -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: > > Felipe, care to run your randconfig magic for this? > > This branch builds just fine so far, I still have omap5 multiplaform and > uniplatform builds, but since that was working before i'm assuming it > won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi cheers -- balbi signature.asc Description: Digital signature
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Felipe Balbi (2014-01-14 18:04:21) > Hi, > > On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: > > > Felipe, care to run your randconfig magic for this? > > > > This branch builds just fine so far, I still have omap5 multiplaform and > > uniplatform builds, but since that was working before i'm assuming it > > won't break. > > No build failures in any of my 18 seeds (5 randconfigs of each), I'd > attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can > send it. > > FWIW: > > Acked-by: Felipe Balbi Felipe, That's great to hear. Thanks for testing. Tero & Tony, These 40 patches apply very cleanly on top of clk-next with 2 exceptions: 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based on 3.13-rc1). 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I resolved correctly but would like verification. I'd prefer to simply merge these patches into clk-next, which is the most straightforward route. Any ideas on how to handle the missing AM35xx dtsi data? It can always go as a separate fix after this stuff gets merged which, ironically, is how that file was created in the first place. Regards, Mike > > cheers > > -- > balbi -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Mike Turquette (2014-01-14 19:16:32) > Quoting Felipe Balbi (2014-01-14 18:04:21) > > Hi, > > > > On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: > > > > Felipe, care to run your randconfig magic for this? > > > > > > This branch builds just fine so far, I still have omap5 multiplaform and > > > uniplatform builds, but since that was working before i'm assuming it > > > won't break. > > > > No build failures in any of my 18 seeds (5 randconfigs of each), I'd > > attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can > > send it. > > > > FWIW: > > > > Acked-by: Felipe Balbi > > Felipe, > > That's great to hear. Thanks for testing. > > Tero & Tony, > > These 40 patches apply very cleanly on top of clk-next with 2 > exceptions: > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based > on 3.13-rc1). > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I > resolved correctly but would like verification. > > I'd prefer to simply merge these patches into clk-next, which is the > most straightforward route. Any ideas on how to handle the missing > AM35xx dtsi data? It can always go as a separate fix after this stuff > gets merged which, ironically, is how that file was created in the first > place. I've pushed my branch. Tero can you take a look and let me know if you see any problems? git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap Thanks! Mike > > Regards, > Mike > > > > > cheers > > > > -- > > balbi -- 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 v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Brian,
>From: Enric Balletbo Serra [mailto:eballe...@gmail.com]
>>2014/1/6 Stefan Roese :
...
As there were parallel set of patches running between u-boot and kernel.
hence, some patch-sets caused regression for OMAP3x platforms when booting
using u-boot specifically for ecc-schemes (like BCH4_SW).
Hence this patch series fixes those regressions, and tests complete
NAND boot sequence for multiple ecc-schemes on AM335x-EVM board.
(following configurations are required for building u-boot driver which is
compatible to kernel ecclayout for selected ecc-scheme)
(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
ROM -> SPL -> U-Boot -> Kernel ->
File-System
(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
ROM -> SPL -> U-Boot -> Kernel ->
File-System
(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
ROM -> SPL -> U-Boot -> Kernel ->
File-System
*Configurations used to build u-boot and kernel for end-to-end NAND boot*
+++--+
| ecc-scheme | u-boot/SPL configs| kernel DTS
|
+++--+
|||
|
| HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \
|ti,nand-ecc-opts= |
|| OMAP_ECC_HAM1_CODE_HW |"ham1"
|
| (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 |
|
| Hamming| #define CONFIG_SYS_NAND_ECCPOS \ |
|
| using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \|
|
||10, 11, 12 }|
|
|| (for NAND page-size=2048) |
|
|||
|
+++--+
|||
|
| BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\
|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |"bch8"
|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM
node)|
| using s/w | #define CONFIG_BCH |
|
|library for | #undef CONFIG_SPL_NAND_AM33XX_BCH |
|
|for ECC | #define CONFIG_SPL_NAND_SIMPLE |
|
| error | #define CONFIG_SYS_NAND_ECCPOS \ |
|
|correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ |
|
|| 11, 12, 13, 14, \ |
|
|| 16, 17, 18, 19, 20, 21, 22, 23, 24, \ |
|
|| 25, 26, 27, 28, \ |
|
|| 30, 31, 32, 33, 34, 35, 36, 37, 38, \ |
|
|| 39, 40, 41, 42, \ |
|
|| 44, 45, 46, 47, 48, 49, 50, 51, 52, \ |
|
|| 53, 54, 55, 56, } |
|
|| (for NAND page-size=2048) |
|
|| #define CONFIG_SYS_NAND_ECCSIZE 512 |
|
|||
|
+++--+
|||
|
| BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\
|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW |"bch8"
|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 |
|
| using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node)
|
| h/w engine | #define CONFIG_SYS_NAND_ECCPOS \
|ti,elm-id=<&elm> |
|for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \|
|
| error | 10, 11, 12, 13, 14, 15, 16, 17, \|
|
|correction) | 18, 19, 20, 21, 22, 23, 24, 25, \|
|
|| 26,
