Re: Tegra DRM with HDMI support (\o/)

[Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On 10/18/2012 01:55 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Oct 17, 2012 at 02:38:50PM -0600, Stephen Warren wrote:
>> On 10/16/2012 07:32 PM, Mark Zhang wrote:
>>> On 10/17/2012 12:03 AM, Stephen Warren wrote:
>>>> On 10/16/2012 02:18 AM, Mark Zhang wrote:
>>>>> Hi,
>>>>>
>>>>> I've made this drm driver worked on Tegra 3(LVDS and HDMI both).
>>>>> But the code that Thierry
>>>>> hosts(git://gitorious.org/thierryreding/linux.git) doesn't work
>>>>> directly. If you build and run it, you'll get a white blank screen on
>>>>> Tegra 3. I didn't find the root cause but I think this is not caused by
>>>>> drm driver itself(maybe the PCIE codes?). The main symptom is: some
>>>>> regulators can't be inited all the time. I tried to build drm driver as
>>>>> kernel module, after kernel booted, modprobe the drm driver, and you'll
>>>>> find there are a lot of error prints like this:
>>>>>
>>>>> =========================================================
>>>>> [   21.383529] reg-fixed-voltage 1.regulator: Failed to find supply vin
>>>>> [   21.390299] reg-fixed-voltage 1.regulator: Failed to register
>>>>> regulator: -517
>>>>> [   21.397645] platform 1.regulator: Driver reg-fixed-voltage requests
>>>>> probe deferral
>>>>> [   21.405604] platform 2.regulator: Driver reg-fixed-voltage requests
>>>>> probe deferral
>>>>> =========================================================
>>>>
>>>> This is normal; it's probe deferral. You'll find that those regulators
>>>> initialize correctly later. Hopefully tegra-drm handles this correctly,
>>>> and passes that error code through as the result of its probe.
>>>>
>>>
>>> I don't think so. In normal scenario, the regulator will be inited
>>> correctly finally. But in the scenario I described above, these
>>> regulators will not be inited correctly all the time. Just as I
>>> mentioned above, I tried to build drm driver as kernel module, that
>>> means I will load drm driver after kernel booting finished. Besides,
>>> during the loading of drm driver, these regulator probe error were still
>>> be printed out. And I'm sure this is not the normal case.
>>
>> The Cardhu PMIC driver isn't enabled in tegra_defconfig in Thierry's
>> branch. Do this:
>
> Yeah, I think my default configuration is pretty messed up by now. I'm
> in the process of merging down patches and along the way I planned to
> drop all the defconfig updates and do the from scratch so that these
> issues will hopefully be gone.
>
>>> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
>>> index c2a2f6e..90f4d5c 100644
>>> --- a/arch/arm/configs/tegra_defconfig
>>> +++ b/arch/arm/configs/tegra_defconfig
>>> @@ -124,16 +124,19 @@ CONFIG_SPI_OCORES=m
>>>   CONFIG_GPIO_SYSFS=y
>>>   CONFIG_GPIO_ADNP=y
>>>   CONFIG_GPIO_TPS6586X=y
>>> +CONFIG_GPIO_TPS65910=y
>>>   CONFIG_POWER_SUPPLY=y
>>>   CONFIG_BATTERY_SBS=y
>>>   CONFIG_SENSORS_LM90=y
>>> -CONFIG_SENSORS_ADC081C=m
>>>   CONFIG_MFD_TPS6586X=y
>>> +CONFIG_MFD_TPS65910=y
>>>   CONFIG_REGULATOR=y
>>>   CONFIG_REGULATOR_FIXED_VOLTAGE=y
>>>   CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
>>>   CONFIG_REGULATOR_GPIO=y
>>> +CONFIG_REGULATOR_TPS62360=y
>>>   CONFIG_REGULATOR_TPS6586X=y
>>> +CONFIG_REGULATOR_TPS65910=y
>>>   CONFIG_DRM=m
>>>   CONFIG_DRM_TEGRA=m
>>>   CONFIG_DRM_TEGRA_DEBUG=y
>>> @@ -172,7 +175,7 @@ CONFIG_RTC_CLASS=y
>>>   CONFIG_RTC_INTF_SYSFS=y
>>>   CONFIG_RTC_INTF_PROC=y
>>>   CONFIG_RTC_INTF_DEV=y
>>> -CONFIG_RTC_DRV_PCF8523=y
>>> +CONFIG_RTC_DRV_TPS65910=y
>>>   CONFIG_RTC_DRV_TEGRA=y
>>>   CONFIG_DMADEVICES=y
>>>   CONFIG_TEGRA20_APB_DMA=y
>>
>> (That still doesn't make tegradrm work for me on Cardhu, but it does
>> solve the regulator issue)
>
> I think Mark had some other modifications that were required to get HDMI
> working on CardHu. Something related to the clocks IIRC. Does LVDS work?
>
> Another thing I'm going to work into the cleaned up patches is support
> for the video mode helpers by Steffen. I actually like the approach
> better than the binary EDID blob, so I will probably replace the blob on
> Medcom Wide in favour of a display mode entry in DT.
>
> By the way, it would be nice if we could start to collect the various DT
> snippets for the different boards. For most of the NVIDIA designs these
> are still missing, just like for AC100. As for the TrimSlice I'm not
> sure if it works properly.
>

Yes, I have some DT snippets for Tegra 2 Ventana board. I'll send it to 
you later.

Mark
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>