On Thu, Jun 14, 2012 at 1:13 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> On Thu, 2012-06-14 at 00:59 -0700, Russ Dill wrote:
>> On Thu, Jun 14, 2012 at 12:18 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
>> > On Wed, 2012-06-13 at 23:58 -0700, Russ Dill wrote:
>> >> On Wed, Jun 13, 2012 at 2:20 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
>> >> > Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 ("OMAP: board-files:
>> >> > remove custom PD GPIO handling for DVI output") moved TFP410 chip's
>> >> > powerdown-gpio handling from the board files to the tfp410 driver. One
>> >> > gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
>> >> > the Beagle board file. This causes the tfp410 driver to fail to request
>> >> > the gpio on Beagle, causing the driver to fail and thus the DVI output
>> >> > doesn't work.
>> >>
>> >> Can you take the one I sent earlier instead?
>> >>
>> >> http://www.spinics.net/lists/linux-omap/msg69913.html
>> >
>> > Hmm, that probably doesn't apply. The power-down GPIO is now handled in
>> > the tfp410 driver, not in the board files.
>>
>> Give me a branch to rebase it onto and I will.
>
> v3.5-rc2
>
>> > Looking more closely at the board file, what are these nDVI_PWR_EN,
>> > DVI_LDO_EN and DVI_PU gpios? There's no "enable line" on tfp410. Only
>> > the power-down gpio, which is none of the above...
>>
>> On my schematic, DVI_LDO_EN is labeled more sanely, DVI_PU. I'm not
>> sure of the history of that. My patch does remove any reference to
>> DVI_LDO_EN.
>>
>> nDVI_PWR_EN is labeled AUX_3V3_DIS on my schematic. AUX_3V3_DIS is
>> connected to the disable pin of an LDO that provides power for the DVI
>> transceiver.
>
> Okay. These are a bit problematic, because we're in the process of
> removing these kinds of things from the board file, as they cannot be
> supported with device tree. The tfp410 driver in v3.5 doesn't even have
> the platform_enable/disable callback anymore.
>
> Those do not belong to tfp410 driver, but I don't really know how they
> should be handled. This is one of the questions about device tree that
> is unclear to me...
Are you talking about the AUX_3V3_DIS pin? The boardfile currently
just initializes that low, that should be too much of a problem to put
into DT, or if someone is so inclined assign it to a regulator via DT.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
