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:
>> > On Wed, 2011-09-14 at 11:04 +0530, K, Mythri P wrote:
>> >> Hi,
>> >>
>> >> On Mon, Sep 12, 2011 at 10:16 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
>> >> > On Mon, Sep 12, 2011 at 8:24 AM, K, Mythri P <mythripk@xxxxxx> wrote:
>> >> >>> +bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
>> >> >>> +{
>> >> >>> + int r;
>> >> >>> +
>> >> >>> + void __iomem *base = hdmi_core_sys_base(ip_data);
>> >> >>> +
>> >> >>> + /* HPD */
>> >> >>> + r = REG_GET(base, HDMI_CORE_SYS_SYS_STAT, 1, 1);
>> >> >>> +
>> >> >>> + return r == 1;
>> >> >>> +}
>> >> >>> +
>> >> >> For HPD the probe should also be on the core interrupt first , and the
>> >> >> detect should be dynamic, ie based on the cable connect and disconnect
>> >> >> event.So this approach for HPD is not really the way.
>> >> >> Also that should be based on the GPIO(63) , I am planning to push a
>> >> >> patch on that shortly.
>> >> >
>> >> >
>> >> > Fwiw, we do still need a dssdrv->detect() function from omapdrm
>> >> > driver.. if there is another way to implement that function, such as
>> >> > with a GPIO, that is great. But somehow or another we need the detect
>> >> > function. The implementation can always change later.
>> >> Yes we still need a detect , but the implementation would be different
>> >> , from the prior experience with the Hot-plug detection it wad found
>> >> that the interrupt based way to handle HPD was not the best ,but if
>> >> this is just to poll the status then it should be fine.
>> >
>> > I'm not sure I understood. First you say the implementation should be
>> > different, but then you say this should be fine. So is this a valid
>> > implementation for detect() or is there a better way to do it?
>> >
>> There is a better way to handle Hot-plug detection and notification..
>> But depends on what is the purpose of this function, Ideally a detect
>
> The purpose of the detect function is to return true or false, depending
> on whether a (preferably powered-on) monitor is connecter via a cable or
> not. So it tells if there's a display that can be used or not.
>
>> would be the case to dynamically detect whether the cable is connected
>> on not , But all this function does is to see the state of the HPD bit
>> in core state statically.
>
> 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?
>
>> 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
ready to be read, But this is a static check that is done in this
function.
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
