Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Tony Lindgren]

* 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

[Ivaylo Dimitrov]

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

[Nishanth Menon]

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

[Vignesh R]

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

[Pali Rohár]

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

[Roger Quadros]

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

[Ohad Ben-Cohen]

On Wed, Sep 16, 2015 at 3:32 PM, Dave Gerlach  wrote:
> 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

[Lee Jones]

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

[Mugunthan V N]

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

[Grygorii Strashko]

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

[Grygorii Strashko]

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