From patchwork Sun Jun 9 12:22:16 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Dietrich X-Patchwork-Id: 250035 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 555B72C02EF for ; Sun, 9 Jun 2013 22:22:58 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753727Ab3FIMW5 (ORCPT ); Sun, 9 Jun 2013 08:22:57 -0400 Received: from mout.gmx.net ([212.227.15.18]:54758 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753710Ab3FIMW4 (ORCPT ); Sun, 9 Jun 2013 08:22:56 -0400 Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MWdXB-1UsxrJ2BtD-00XwtD for ; Sun, 09 Jun 2013 14:22:54 +0200 Received: (qmail invoked by alias); 09 Jun 2013 12:22:54 -0000 Received: from pD9E5C67A.dip0.t-ipconnect.de (EHLO ax5200p.localnet) [217.229.198.122] by mail.gmx.net (mp029) with SMTP; 09 Jun 2013 14:22:54 +0200 X-Authenticated: #9962044 X-Provags-ID: V01U2FsdGVkX1+noDl0le6nZKUeWg/LINqINb5PDNl4Qe2Botmgoz yZJA+ui+tNekTx From: Marc Dietrich To: Stephen Warren Cc: linux-tegra , Lucas Stach , Thomas Meyer , Laxman Dewangan Subject: Re: No HDMI output on AC100 Date: Sun, 09 Jun 2013 14:22:16 +0200 Message-ID: <3787332.hnuOIkUjPE@ax5200p> User-Agent: KMail/4.8.5 (Linux/3.5.0-27-generic; KDE/4.8.5; x86_64; ; ) In-Reply-To: <1963558.n4FXxA4Dl5@ax5200p> References: <1370680435.24531.12.camel@localhost.localdomain> <5714076.saxNrNAXNW@ax5200p> <1963558.n4FXxA4Dl5@ax5200p> MIME-Version: 1.0 X-Y-GMX-Trusted: 0 Sender: linux-tegra-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On Sunday 09 June 2013 14:02:16 Marc Dietrich wrote: > On Sunday 09 June 2013 13:42:46 Marc Dietrich wrote: > > On Saturday 08 June 2013 20:45:17 Stephen Warren wrote: > > > On 06/08/2013 02:07 PM, Marc Dietrich wrote: > > > > On Saturday 08 June 2013 18:05:52 Lucas Stach wrote: > > > >> Am Samstag, den 08.06.2013, 16:21 +0200 schrieb Thomas Meyer: > > > >>>> On Saturday 08 June 2013 10:33:55 Thomas Meyer wrote: > > > >>>>> Kernel version: 3.10.0-0.rc4.git0.1.fc20.armv7hl > > > >>>>> > > > >>>>> This is the latest Fedora ARM kernel. Config is available here: > > > >>>>> http://pkgs.fedoraproject.org/cgit/kernel.git/tree/config-armv7 > > > >>>>> > > > >>>>> This is what I see in the kernel log: > > > >>>>> > > > >>>>> $ dmesg |grep hdmi > > > >>>>> [ 33.403417] tegra-hdmi 54280000.hdmi: failed to get VDD > > > >>>>> regulator > > > >>>>> [ 33.403441] platform 54280000.hdmi: Driver tegra-hdmi requests > > > >>>>> probe > > > >>>>> > > > >>>>> any ideas? > > > >>>> > > > >>>> is the regulator (tps6586x) build-in? > > > >>> > > > >>> No, it's a module. > > > >>> > > > >>>> The make everything a module path isn't > > > >>>> well tested I guess. > > > >> > > > >> It's not the problem here. The driver requests to be probed again and > > > >> comes up once the regulator is there. > > > >> > > > >> Though the pixel clock looks odd for a HD HDMI monitor. Try looking > > > >> at > > > >> the Xorg log to see what mode of your monitor get's chosen and why it > > > >> fails. > > > > > > > > I just checked myself. Found that tps6586x-regulator module can't be > > > > autoloaded, so I connected my TV, booted and modprobed the module by > > > > hand. > > > > All works more or less fine, so probe deferral is no problem. > > > > > > It could well just be that the tps6586x driver is missing the module > > > correct MODULE_ALIAS that makes the module auto-load when the relevant > > > entry is in the DT. The top-level MFD driver does have a > > > MODULE_DEVICE_TABLE which should set this up automatically, so perhaps > > > it's because there's nothing causing the regulator MFD component to load > > > when the top-level MFD component loads? > > > > the core driver adds sub devices, but in case of DT, the number of > > subdevices is zero AFAICS (tps6586x_parse_dt). However, these subdevs do > > not include the regulators. > > ah, the driver is named tps6586x-pmic (and the module alias is tps6586x- > regulator), so in case of platform_device type init, it is probed. > > > Also, the regulator nodes don't have a compatibly property, so direct > > probing won't work. > > > > I have no idea how the regulators are probed at all... > looks like this will become one of the my famous self-talks. I just changed the module alias as Stephen suggested and this seems to load the driver magically. Patch below: Subject: [PATCH] regulator: tps6586x: correct module alias Set the module alias to the actual driver name tps6586x-pmic. This fixes kernel module loading. Signed-off-by: Marc Dietrich --- drivers/regulator/tps6586x-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/tps6586x-regulator.c b/drivers/regulator/tps6586x-regulator.c index d8fa37d..c2e57ea 100644 --- a/drivers/regulator/tps6586x-regulator.c +++ b/drivers/regulator/tps6586x-regulator.c @@ -461,4 +461,4 @@ module_exit(tps6586x_regulator_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Mike Rapoport "); MODULE_DESCRIPTION("Regulator Driver for TI TPS6586X PMIC"); -MODULE_ALIAS("platform:tps6586x-regulator"); +MODULE_ALIAS("platform:tps6586x-pmic");