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.
> 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?
Tomi
--
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
