No HDMI output on AC100

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 <marvin24@gmx.de>
---
 drivers/regulator/tps6586x-regulator.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 06/09/2013 06:22 AM, Marc Dietrich wrote:
...
> Subject: [PATCH] regulator: tps6586x: correct module alias
> 
> Set the module alias to the actual driver name tps6586x-pmic. This
> fixes kernel module loading.

> diff --git a/drivers/regulator/tps6586x-regulator.c 

> -MODULE_ALIAS("platform:tps6586x-regulator");
> +MODULE_ALIAS("platform:tps6586x-pmic");

This patch highlights the issue correctly, but I think it'd be better to
change tps6586x_cell[] in drivers/mfd/tps6586x.c instead; that keeps the
module alias and module filename more consistent (and really, pmic is
the whole chip, whereas regulator is the sub-component, I think).
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html