On 28 June 2012 21:18, Jassi Brar wrote:
> On 28 June 2012 20:57, Tomi Valkeinen wrote:
>>> > By the way, when the device is in system suspend, we surely won't detect
>>> > the HPD even if we kept the HPD always enabled. So there we'll miss the
>>> > HPD interrupt anyway, and the EDID cache woul
On 28 June 2012 20:57, Tomi Valkeinen wrote:
> On Thu, 2012-06-28 at 20:44 +0530, Jassi Brar wrote:
>> it has, some user action should enable it while 'making the device
>> ready for new display'.
>> IOW, how do you envision an OMAP4 based tablet with HDMI port react to
>> display connections ?
>
On Thu, 2012-06-28 at 20:44 +0530, Jassi Brar wrote:
> I won't press further with my Utopian ideas, but I think we need to
> segregate 5V/HPD enabling from PHY enabling somehow. Because that is
> already failing slow but otherwise perfectly legit displays (like
> Andy's "HPD taking 700ms" TV)
Yes
On 28 June 2012 20:44, Tomi Valkeinen wrote:
> On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
>
>> A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during
>> probe and disable during remove.
>> HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
>> HDMI_PHY on/off.
On 28 June 2012 19:01, Tomi Valkeinen wrote:
> On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
>> On 28 June 2012 17:33, Andy Green wrote:
>
>> > If Jassi's alright with it we might have a go at implementing this, but can
>> > you define a bit more about how we logically tell DSS that we wan
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
> A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during
> probe and disable during remove.
> HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
> HDMI_PHY on/off.
> The user selecting "Autodetect and Configure" opti
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
> > I think among the first things, while enabling HDMI, should be to see
> > if there is really some display connected on the port i.e, HPD
> > asserted. Only if ti_hdmi_4_detect() returned true, should we
> > proceed otherwise wait for HPQ irq
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
> On 28 June 2012 17:33, Andy Green wrote:
> > If Jassi's alright with it we might have a go at implementing this, but can
> > you define a bit more about how we logically tell DSS that we want to, eg,
> > disable HDMI totally?
> >
> A quick re
On 28 June 2012 17:33, Andy Green wrote:
> On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included:
>
>> On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
>>>
>>> On 28 June 2012 16:17, Jassi Brar wrote:
On 28 June 2012 15:44, Tomi Valkeinen wrote:
>
> On Thu, 20
On Thu, 2012-06-28 at 20:03 +0800, Andy Green wrote:
> On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included:
> > For this to work like you want we need a bigger restructuring of HDMI
> > and partly omapdss also. Currently we have just one big "enabled" or
> > "disabled" state. We ne
On 28 June 2012 16:40, Tomi Valkeinen wrote:
> On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
> >
>> Sorry a correction. Reading detect() won't work. I suggest we keep HPD
>> IRQ enabled for the lifetime of the driver.
>
> Ok, I see. But that's not acceptable. It would require us to keep the
On 06/28/12 19:38, the mail apparently from Tomi Valkeinen included:
On Thu, 2012-06-28 at 14:10 +0300, Tomi Valkeinen wrote:
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
Sorry a correction. Reading detect() won't work. I suggest we keep HPD
IRQ enabled for the lifetime of the driver.
On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included:
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
On 28 June 2012 16:17, Jassi Brar wrote:
On 28 June 2012 15:44, Tomi Valkeinen wrote:
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
--- a/drivers/video/omap2/ds
On Thu, 2012-06-28 at 14:10 +0300, Tomi Valkeinen wrote:
> On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
> > Sorry a correction. Reading detect() won't work. I suggest we keep HPD
> > IRQ enabled for the lifetime of the driver.
>
> Ok, I see. But that's not acceptable. It would require us
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
> On 28 June 2012 16:17, Jassi Brar wrote:
> > On 28 June 2012 15:44, Tomi Valkeinen wrote:
> >> On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
> >
> >>> >> --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> >>> >> +++ b/drivers/video/omap
On Thu, 2012-06-28 at 16:17 +0530, Jassi Brar wrote:
> On 28 June 2012 15:44, Tomi Valkeinen wrote:
> > When the display device is disabled, we're not listening to the hpd
> > interrupt anymore. So when it's disabled, the cable can be replugged and
> > the monitor changed, and the driver won't kn
On 28 June 2012 16:17, Jassi Brar wrote:
> On 28 June 2012 15:44, Tomi Valkeinen wrote:
>> On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
>
>>> >> --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
>>> >> +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
>>> >> @@ -243,10 +243,13 @@ static int h
On 28 June 2012 15:44, Tomi Valkeinen wrote:
> On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
>> >> --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
>> >> +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
>> >> @@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
>> >> *i
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
> On 28 June 2012 13:18, Tomi Valkeinen wrote:
> > On Wed, 2012-06-27 at 19:35 +0530, jaswinder.si...@linaro.org wrote:
> >> From: Jassi Brar
> >>
> >> We can easily keep track of latest EDID from the display and hence avoid
> >> expensive EDID
On 28 June 2012 13:18, Tomi Valkeinen wrote:
> On Wed, 2012-06-27 at 19:35 +0530, jaswinder.si...@linaro.org wrote:
>> From: Jassi Brar
>>
>> We can easily keep track of latest EDID from the display and hence avoid
>> expensive EDID re-reads over I2C.
>> This could also help some cheapo displays
On Wed, 2012-06-27 at 19:35 +0530, jaswinder.si...@linaro.org wrote:
> From: Jassi Brar
>
> We can easily keep track of latest EDID from the display and hence avoid
> expensive EDID re-reads over I2C.
> This could also help some cheapo displays that provide EDID reliably only
> immediately after
From: Jassi Brar
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C.
This could also help some cheapo displays that provide EDID reliably only
immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPD
22 matches
Mail list logo
