Re: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> On Wed, 2011-09-14 at 17:50 +0530, K, Mythri P wrote:
>> Hi,
>>
>> On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
>> > On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
>> >> On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
>> >> > On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
>> >> >> On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
>> >
>> > <snip>
>> >
>> >> > I don't understand this one. How could this be more dynamic? The
>> >> > function checks the HPD bit, which (based on my observation) shows the
>> >> > status whether a display is connected or not.
>> >> There is a GPIO which detects the +3.3V on the line and detects the
>> >> cable connect , there is also an interrupt based way.This is ideally
>> >> called a Hot-plug detect event according to the spec in HDMI terms.
>> >> But what you are saying here is that it is just a poll on the state?
>> >
>> > Yes, it's just for polling, but I don't quite see the difference. A
>> > hot-plug event notifies when the display is connected or disconnected,
>> > and detect() tells if a display is connected. They are all about the
>> > same thing.
>> >
>> >> >> So I said if the purpose of this function is only to check for the HPD
>> >> >> state bit it is fine.
>> >> >
>> >> > What does HPD bit tell us then?
>> >>
>> >> HPD state bit tells whether the cable is connected and whether EDID is
>> >
>> > This sounds like a good bit to test then. So is there something wrong
>> > with using HPD? How does the GPIO differ from HPD bit?
>> >
>> >> ready to be read, But this is a static check that is done in this
>> >> function.
>> >
>> > I don't understand what you mean with "static". The bit changes
>> > dynamically according to the connect/disconnect state, and the bit is
>> > checked dynamically when detect() is called.
>> >
>> Well ! Who would call the detect and why ? By Dynamic i meant when the
>> cable is physically disconnected and connected there is detection
>> logic which can be implemented either by GPIo/Interrupts.
>> When you say the cable is connected , what happens in this case when
>> the cable is connected to say monitor of one resolution and then
>> plugged out and put to the other. Instead with dynamic method the
>> based on the physical connect and disconnect the notification would be
>> sent to any listener.
>
> Ok, I see now what you mean.
>
> Yes, you are right, detect() does not "know" if the monitor has changed
> between polls, so both notification and polling are needed. I
> implemented only polling as there's no HPD event mechanism yet in
> omapdss, and also because this was simple and gives DRM basic ability to
> detect a monitor.
>
If it is needed for DRM then it is fine, but with detect renamed to
poll. By next week i should have a patch ready for HPD event
mechanism.

>  Tomi
>
>
>
Thanks and regards,
Mythri.
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux