From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755086AbcEDSCD (ORCPT ); Wed, 4 May 2016 14:02:03 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:51625 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754940AbcEDSCA (ORCPT ); Wed, 4 May 2016 14:02:00 -0400 Subject: Re: [PATCH] ARM: dts: omap5-igep0050: Correct hdmi regulator To: Tony Lindgren , Peter Ujfalusi References: <1461925297-9734-1-git-send-email-peter.ujfalusi@ti.com> <6ee9d67a-e907-715a-f3f5-d90a470314c3@ti.com> <20160504172634.GS5995@atomide.com> CC: , , , From: Nishanth Menon X-Enigmail-Draft-Status: N1110 Message-ID: <572A38FD.9050801@ti.com> Date: Wed, 4 May 2016 13:01:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160504172634.GS5995@atomide.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/04/2016 12:26 PM, Tony Lindgren wrote: > Hi, > > Adding Nishanth to Cc. > > * Peter Ujfalusi [160429 05:15]: >> ldo7_reg, obviously ;) >> >>> status = "okay"; >>> regulator-min-microvolt = <1800000>; >>> regulator-max-microvolt = <1800000>; >>> }; > > It really seems to be ldo7, otherwise there's no HDMI output. I don't > have the schematics either. > > But it seems we have at least two other regressions in Linux next that > prevent me from testing this properly: > > 1. On igepv5, I get this for the MMC regulator > > ldo9: bypassed regulator has no supply! > ldo9: failed to get the current voltage(-517) > palmas-pmic 48070000.i2c:palmas@48:palmas_pmic: failed to register 48070000.i2c:palmar > > I'm pretty sure it really is using the ldo9 for MMC just like > omap5-uevm.. Nishanth suggested it may use something else, but > why would it as ldo9 has a nice voltage range? > > 2. On both omap5-uevm and igepv5, NFSroot hangs > > It seems that NFSroot boots to the point where PM runtime now > just shuts down some regulator affecting the USB connected > smsc Ethernet adapter? > > Regards, This one is interesting.. BayLibre uEVM: https://storage.kernelci.org/next/next-20160504/arm-omap2plus_defconfig/lab-baylibre-seattle/boot-omap5-uevm_rootfs:mmc.txt My uEVM: https://github.com/nmenon/kernel-test-logs/blob/next-20160504/omap2plus_defconfig/omap5-evm.txt Mine boots, but BayLibre one does not. So, that got me started thinking it was bootloader... but then I realize it could be SDCard since they are dual voltage. U-boot starting v2013.07-rc1 included code that would set to bypass or program voltage for LDO9 based on card voltage needed. It is possible (since my card seems to need 3.0v, not 3.3v), that bypass to VCC_3v3_SDIO was never needed - but the cards that Baylibre board could probably be setup in bypass. I will send in a patch assuming (without access to igev5 schematics - based on how it seems to be booting), that sdio path. -- Regards, Nishanth Menon From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Subject: Re: [PATCH] ARM: dts: omap5-igep0050: Correct hdmi regulator Date: Wed, 4 May 2016 13:01:33 -0500 Message-ID: <572A38FD.9050801@ti.com> References: <1461925297-9734-1-git-send-email-peter.ujfalusi@ti.com> <6ee9d67a-e907-715a-f3f5-d90a470314c3@ti.com> <20160504172634.GS5995@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160504172634.GS5995@atomide.com> Sender: linux-kernel-owner@vger.kernel.org To: Tony Lindgren , Peter Ujfalusi Cc: linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org List-Id: devicetree@vger.kernel.org On 05/04/2016 12:26 PM, Tony Lindgren wrote: > Hi, > > Adding Nishanth to Cc. > > * Peter Ujfalusi [160429 05:15]: >> ldo7_reg, obviously ;) >> >>> status = "okay"; >>> regulator-min-microvolt = <1800000>; >>> regulator-max-microvolt = <1800000>; >>> }; > > It really seems to be ldo7, otherwise there's no HDMI output. I don't > have the schematics either. > > But it seems we have at least two other regressions in Linux next that > prevent me from testing this properly: > > 1. On igepv5, I get this for the MMC regulator > > ldo9: bypassed regulator has no supply! > ldo9: failed to get the current voltage(-517) > palmas-pmic 48070000.i2c:palmas@48:palmas_pmic: failed to register 48070000.i2c:palmar > > I'm pretty sure it really is using the ldo9 for MMC just like > omap5-uevm.. Nishanth suggested it may use something else, but > why would it as ldo9 has a nice voltage range? > > 2. On both omap5-uevm and igepv5, NFSroot hangs > > It seems that NFSroot boots to the point where PM runtime now > just shuts down some regulator affecting the USB connected > smsc Ethernet adapter? > > Regards, This one is interesting.. BayLibre uEVM: https://storage.kernelci.org/next/next-20160504/arm-omap2plus_defconfig/lab-baylibre-seattle/boot-omap5-uevm_rootfs:mmc.txt My uEVM: https://github.com/nmenon/kernel-test-logs/blob/next-20160504/omap2plus_defconfig/omap5-evm.txt Mine boots, but BayLibre one does not. So, that got me started thinking it was bootloader... but then I realize it could be SDCard since they are dual voltage. U-boot starting v2013.07-rc1 included code that would set to bypass or program voltage for LDO9 based on card voltage needed. It is possible (since my card seems to need 3.0v, not 3.3v), that bypass to VCC_3v3_SDIO was never needed - but the cards that Baylibre board could probably be setup in bypass. I will send in a patch assuming (without access to igev5 schematics - based on how it seems to be booting), that sdio path. -- Regards, Nishanth Menon From mboxrd@z Thu Jan 1 00:00:00 1970 From: nm@ti.com (Nishanth Menon) Date: Wed, 4 May 2016 13:01:33 -0500 Subject: [PATCH] ARM: dts: omap5-igep0050: Correct hdmi regulator In-Reply-To: <20160504172634.GS5995@atomide.com> References: <1461925297-9734-1-git-send-email-peter.ujfalusi@ti.com> <6ee9d67a-e907-715a-f3f5-d90a470314c3@ti.com> <20160504172634.GS5995@atomide.com> Message-ID: <572A38FD.9050801@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/04/2016 12:26 PM, Tony Lindgren wrote: > Hi, > > Adding Nishanth to Cc. > > * Peter Ujfalusi [160429 05:15]: >> ldo7_reg, obviously ;) >> >>> status = "okay"; >>> regulator-min-microvolt = <1800000>; >>> regulator-max-microvolt = <1800000>; >>> }; > > It really seems to be ldo7, otherwise there's no HDMI output. I don't > have the schematics either. > > But it seems we have at least two other regressions in Linux next that > prevent me from testing this properly: > > 1. On igepv5, I get this for the MMC regulator > > ldo9: bypassed regulator has no supply! > ldo9: failed to get the current voltage(-517) > palmas-pmic 48070000.i2c:palmas at 48:palmas_pmic: failed to register 48070000.i2c:palmar > > I'm pretty sure it really is using the ldo9 for MMC just like > omap5-uevm.. Nishanth suggested it may use something else, but > why would it as ldo9 has a nice voltage range? > > 2. On both omap5-uevm and igepv5, NFSroot hangs > > It seems that NFSroot boots to the point where PM runtime now > just shuts down some regulator affecting the USB connected > smsc Ethernet adapter? > > Regards, This one is interesting.. BayLibre uEVM: https://storage.kernelci.org/next/next-20160504/arm-omap2plus_defconfig/lab-baylibre-seattle/boot-omap5-uevm_rootfs:mmc.txt My uEVM: https://github.com/nmenon/kernel-test-logs/blob/next-20160504/omap2plus_defconfig/omap5-evm.txt Mine boots, but BayLibre one does not. So, that got me started thinking it was bootloader... but then I realize it could be SDCard since they are dual voltage. U-boot starting v2013.07-rc1 included code that would set to bypass or program voltage for LDO9 based on card voltage needed. It is possible (since my card seems to need 3.0v, not 3.3v), that bypass to VCC_3v3_SDIO was never needed - but the cards that Baylibre board could probably be setup in bypass. I will send in a patch assuming (without access to igev5 schematics - based on how it seems to be booting), that sdio path. -- Regards, Nishanth Menon