Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
* Pali Rohár[151126 01:08]: > On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote: > > > Or populate /proc/atags only for the ones that need it from machine > > > specific init_early? > > > > This is circling back to the first comment from Russell King where > > he suggested a legacy file for the N900 which calls save_atags(): > > > > Are the ATAGs at a fixed address on the N900? Can that be handled in > > some kind of legacy file for the N900 which calls save_atags() on it, so > > we don't end up introducing yet more stuff that we have to maintain into > > the distant future? If not, what about copying a known working atag > > structure into a legacy file for the N900? > > > > It seems to me that patches 1, 2, 4, and 5 could be replaced by this > > approach. > > Hi Frank, in this case I will ask my question again: It is possible to > read atags from that legacy file. And if yes how? I was not thinking > about this approach because somebody in past wrote that this is not > possible... Just to explore options.. How about make a minimal device driver that just loads the atags blob from /lib/firmware and then shows it in /proc/atags? Of course some checking on the atags should be done by the driver.. That would work as long as the kernel no longer needs it. 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On 26.11.2015 22:39, Tony Lindgren wrote: Just to explore options.. How about make a minimal device driver that just loads the atags blob from /lib/firmware and then shows it in /proc/atags? Of course some checking on the atags should be done by the driver.. What is the chance for such a driver to be accepted upstream? As IIRC the current situation is because similar driver was rejected. Might be wrong as well, it was about 2-3 years ago. 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] ARM: dts: dra72-evm: Mark uart1 rxd as wakeup capable
On 11/26/2015 02:31 AM, Vignesh R wrote: > Uart1 rxd is wakeup capable on DRA72 EVM. Hence, mark rxd line as > wakeup capable. This is similar to commit 66b0436977e2c ("ARM: dts: > dra7-evm: Mark uart1 rxd as wakeup capable") for DRA74 EVM. > > Signed-off-by: Vignesh R> --- > arch/arm/boot/dts/dra72-evm.dts | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts > index d6104d5f0c01..8bf36b0b3c33 100644 > --- a/arch/arm/boot/dts/dra72-evm.dts > +++ b/arch/arm/boot/dts/dra72-evm.dts > @@ -478,6 +478,8 @@ > > { > status = "okay"; > + interrupts-extended = <_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>, > + <_pmx_core 0x3e0>; > }; > > { > Acked-by: 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
[PATCH] ARM: dts: dra72-evm: Mark uart1 rxd as wakeup capable
Uart1 rxd is wakeup capable on DRA72 EVM. Hence, mark rxd line as wakeup capable. This is similar to commit 66b0436977e2c ("ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable") for DRA74 EVM. Signed-off-by: Vignesh R--- arch/arm/boot/dts/dra72-evm.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts index d6104d5f0c01..8bf36b0b3c33 100644 --- a/arch/arm/boot/dts/dra72-evm.dts +++ b/arch/arm/boot/dts/dra72-evm.dts @@ -478,6 +478,8 @@ { status = "okay"; + interrupts-extended = <_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>, + <_pmx_core 0x3e0>; }; { -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote: > > Or populate /proc/atags only for the ones that need it from machine > > specific init_early? > > This is circling back to the first comment from Russell King where > he suggested a legacy file for the N900 which calls save_atags(): > > Are the ATAGs at a fixed address on the N900? Can that be handled in > some kind of legacy file for the N900 which calls save_atags() on it, so > we don't end up introducing yet more stuff that we have to maintain into > the distant future? If not, what about copying a known working atag > structure into a legacy file for the N900? > > It seems to me that patches 1, 2, 4, and 5 could be replaced by this > approach. Hi Frank, in this case I will ask my question again: It is possible to read atags from that legacy file. And if yes how? I was not thinking about this approach because somebody in past wrote that this is not possible... -- 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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
Daniel, On 24/11/15 15:36, Daniel. wrote: > Hi Michael > > About this: > "Two bugs are fixed by this patch. First, OMAP hardware only supports > target CM_IDLEST register bits on ES2+ chips and beyond. ES1 chips > should not wait for these clocks to enable. So, split the appropriate > clocks into ES1 and ES2+ variants, so that kernels running on ES1 > devices won't try to wait." > > My chip is ES1. I think that ES2+ code is running since I see these waits > ocurring on code... I'll take a better look in this, thanks again! Did you figure out if this clock is really present in the ES1 TRM? If it is not then why is the kernel trying to enable this clock? If it is present in the ES1 TRM then why is the kernel trying to wait for it to be enabled? AFAIK there is no need to wait for the clock to be enabled as there is no such status bit on ES1. cheers, -roger > > Does anyone know how to check if a clock is enabled? > > Regards, > > 2015-11-23 18:24 GMT-02:00 Daniel.: >> I've already tried, it fails to apply. My tree is based on last commit from >> TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think* >> that this is already applied (since come from the same tree). >> >> I will try to apply it by hand >> Thanks! >> Regards, >> >> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi : >>> Hi >>> >>> Can you check if you have this patch in? >>> >>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2 >>> Author: Paul Walmsley >>> Date: Fri Jul 24 19:44:06 2009 -0600 >>> >>> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB >>> >>> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS, >>> USBHOST, and HSOTGUSB devices. These devices are both interconnect >>> initiators and targets. Without this patch, clk_enable()s on clocks for >>> these modules can be very high latency (potentially up to ~200 >>> milliseconds) and message such as the following are generated: >>> >>> Clock usbhost_48m_fck didn't enable in 10 tries >>> >>> Two bugs are fixed by this patch. First, OMAP hardware only supports >>> target CM_IDLEST register bits on ES2+ chips and beyond. ES1 chips >>> should not wait for these clocks to enable. So, split the appropriate >>> clocks into ES1 and ES2+ variants, so that kernels running on ES1 >>> devices won't try to wait. >>> >>> Second, the current heuristic in omap2_clk_dflt_find_idlest() will >>> fail for these clocks. It assumes that the CM_IDLEST bit to wait upon >>> is the same as the CM_*CLKEN bit, which is false[1]. Fix by >>> implementing custom clkops .find_idlest function pointers for the >>> appropriate clocks that return the correct slave IDLEST bit shift. >>> >>> This was originally fixed in the linux-omap kernel during 2.6.29 in a >>> slightly different manner[2][3]. >>> >>> >>> On Mon, Nov 23, 2015 at 9:06 PM, Daniel. wrote: Hi, Building as built-in doesn't solve my problem. The difference is that when compiled as module the dump shows up when I load it, and when is built-in the dump shows up at boot time. Also when built-in the problem seems to ocurr when device is reseted (on ehci_omap_stop) and the first stack dump is followed by much more other dumps. At the end I can see something like: "Fixing recursive fault but reboot is needed!" Here is the module info: root@csi:~# modinfo ehci-hcd filename: /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko author: Felipe Balbi author: Texas Instruments, Inc. alias: platform:omap-ehci license:GPL author: David Brownell description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver srcversion: B282C11CACFB9E75921367C depends: vermagic: 2.6.37+ mod_unload modversions ARMv7 parm: log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int) parm: park:park setting; 1-3 back-to-back async packets (uint) parm: ignore_oc:ignore bogus hardware overcurrent indications (bool) parm: hird:host initiated resume duration, +1 for each 75us (int) root@csi:~# Best regards, 2015-11-23 17:55 GMT-02:00 Michael Trimarchi : > Hi > > On Mon, Nov 23, 2015 at 8:05 PM, Daniel. wrote: >> Hi Michael, >> >> It's a plain linux. I'm considering upgrading kernel as last option. >> Variscite doesn't >> support another kernel for this SoM so this would be a really hard >> work. I'm looking >> for a solution on this kernel and mainly trying to understand why >> usbhost_48m_fck >> is not getting enabled. I'm contacting Variscite in
Re: [PATCH] remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias
On Wed, Sep 16, 2015 at 3:32 PM, Dave Gerlachwrote: > Use MODULE_DEVICE_TABLE with wkup_m3_rproc_of_match so the module alias > is exported and the wkup_m3_rproc driver can automatically probe. > > Signed-off-by: Dave Gerlach Applied to remoteproc-next, thanks. -- 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] regulator: tps65218: add support for LS3 current regulator
On Wed, 25 Nov 2015, Nikita Kiryanov wrote: > Add support for TPS65218 LS3 current regulator, which is capable of 4 > current input limit modes: 100, 200, 500, and 1000 uA. > > Signed-off-by: Nikita Kiryanov> Cc: Tony Lindgren > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Samuel Ortiz > Cc: Lee Jones > --- > drivers/regulator/tps65218-regulator.c | 137 > + > include/linux/mfd/tps65218.h | 7 +- Acked-by: Lee Jones > include/linux/regulator/driver.h | 2 + > 3 files changed, 115 insertions(+), 31 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead 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 06/14] ARM: am437x: cm-t43: dts: add dual emac support
On Tuesday 24 November 2015 06:49 PM, Nikita Kiryanov wrote: > CM-T43 comes with 2 ethernet ports connected to the cpsw subsystem, which > has 2 modes of operation: switch mode and dual emac mode. > Add the relevant muxing and set it up to work in dual emac mode by > default. > > Signed-off-by: Nikita Kiryanov> Cc: Tony Lindgren > Cc: Igor Grinberg > Cc: Dmitry Lifshitz > Cc: Ian Campbell Acked-by: Mugunthan V N Regards Mugunthan V N -- 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 v2] ARM: omap2+: enable REGULATOR_FIXED_VOLTAGE
Enable REGULATOR_FIXED_VOLTAGE for all OMAP2+ platforms otherwise system can't boot from SD-card when kernel is built for single SoC (for example, with CONFIG_SOC_DRA7XX=y only). It's also required for almost all TI SoC's platforms. Signed-off-by: Grygorii Strashko--- Link on v1: http://www.spinics.net/lists/linux-omap/msg12.html arch/arm/mach-omap2/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index d07887f..cda35a1 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -127,6 +127,7 @@ config ARCH_OMAP2PLUS_TYPICAL select NEON if CPU_V7 select PM select REGULATOR + select REGULATOR_FIXED_VOLTAGE select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 select VFP @@ -207,7 +208,6 @@ config MACH_OMAP3_PANDORA depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB - select REGULATOR_FIXED_VOLTAGE if REGULATOR config MACH_NOKIA_N810 bool -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2plus_defconfig: enable REGULATOR_FIXED_VOLTAGE
On 11/25/2015 10:57 PM, Tony Lindgren wrote: * Grygorii Strashko[151125 12:26]: On 11/25/2015 08:25 PM, Tony Lindgren wrote: * Grygorii Strashko [151105 08:45]: Enable REGULATOR_FIXED_VOLTAGE otherwise system can't boot from SD-card when kernel is buit with CONFIG_SOC_DRA7XX=y only. It's also required for almost all other TI SoC's platforms. This is already enabled by default when you do make omap2plus_defconfig? Yes. But only because it's hard-coded for MACH_OMAP3_PANDORA :( config MACH_OMAP3_PANDORA bool "OMAP3 Pandora" depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB select REGULATOR_FIXED_VOLTAGE if REGULATOR But I can't boot from SD-card if I'm trying SoC specific build, like only SOC_DRA7XX=y above. Well let's move to under config ARCH_OMAP2PLUS in the Kconfig? Otherwise if somebody does make savedefconfig it will disappear again from omap2plus_defconfig. Agree. Done. -- regards, -grygorii -- 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