All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jassi Brar <jaswinder.singh@linaro.org>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
Date: Mon, 18 Jun 2012 12:24:36 +0000	[thread overview]
Message-ID: <1340022276.4012.23.camel@deskari> (raw)
In-Reply-To: <CAJe_ZhfJV6kYvSkU+4RGywv80A47=CxnoCy2rr-x=c2LFDGb7A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
> On 18 June 2012 16:24, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
> 
> >> BTW, coming to think about it, I am not sure what we need the
> >> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ?  It
> >> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
> >> expensive and is already unprotected elsewhere.
> >
> > It's needed when enabling the hdmi output. In phy_enable() the irq is
> > requested first, and then the phy_enable() runs hdmi_check_hpd_state().
> > So there's a chance to run hdmi_check_hpd_state() from both
> > hpd-interrupt and phy_enable() at the same time.
> >
> > The hdmi_set_phy_pwr() is not called in many places, but I think there's
> > indeed a problem there. It is called after free_irq(), but I think
> > (guess) the irq handler could still be running after free_irq. So those
> > should be protected by the same spinlock too.
> >
> You know TI HDMI better than I do, so I assume your concerns are valid.
> So preferably I would move request_threaded_irq() to after
> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the

No, you can't move the check. If you move it, the HPD state could change
between the check and the request_irq, and we'd miss it.

> spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't
> want irqs disabled so long as it takes for phy to power on/off).

Yes, I guess a mutex is better.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jassi Brar <jaswinder.singh@linaro.org>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
Date: Mon, 18 Jun 2012 15:24:36 +0300	[thread overview]
Message-ID: <1340022276.4012.23.camel@deskari> (raw)
In-Reply-To: <CAJe_ZhfJV6kYvSkU+4RGywv80A47=CxnoCy2rr-x=c2LFDGb7A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
> On 18 June 2012 16:24, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
> 
> >> BTW, coming to think about it, I am not sure what we need the
> >> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ?  It
> >> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
> >> expensive and is already unprotected elsewhere.
> >
> > It's needed when enabling the hdmi output. In phy_enable() the irq is
> > requested first, and then the phy_enable() runs hdmi_check_hpd_state().
> > So there's a chance to run hdmi_check_hpd_state() from both
> > hpd-interrupt and phy_enable() at the same time.
> >
> > The hdmi_set_phy_pwr() is not called in many places, but I think there's
> > indeed a problem there. It is called after free_irq(), but I think
> > (guess) the irq handler could still be running after free_irq. So those
> > should be protected by the same spinlock too.
> >
> You know TI HDMI better than I do, so I assume your concerns are valid.
> So preferably I would move request_threaded_irq() to after
> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable()  and convert the

No, you can't move the check. If you move it, the HPD state could change
between the check and the request_irq, and we'd miss it.

> spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't
> want irqs disabled so long as it takes for phy to power on/off).

Yes, I guess a mutex is better.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-06-18 12:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15 22:01 [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member jaswinder.singh
2012-06-15 22:13 ` jaswinder.singh
2012-06-17 23:44 ` Jingoo Han
2012-06-17 23:44   ` Jingoo Han
2012-06-18  8:11 ` Tomi Valkeinen
2012-06-18  8:11   ` Tomi Valkeinen
2012-06-18 10:12   ` Jassi Brar
2012-06-18 10:24     ` Jassi Brar
2012-06-18 10:54     ` Tomi Valkeinen
2012-06-18 10:54       ` Tomi Valkeinen
2012-06-18 11:46       ` Jassi Brar
2012-06-18 11:58         ` Jassi Brar
2012-06-18 12:24         ` Tomi Valkeinen [this message]
2012-06-18 12:24           ` Tomi Valkeinen
2012-06-18 13:07           ` Jassi Brar
2012-06-18 13:19             ` Jassi Brar
2012-06-18 13:11             ` Tomi Valkeinen
2012-06-18 13:11               ` Tomi Valkeinen
2012-06-18 13:24               ` Jassi Brar
2012-06-18 13:36                 ` Jassi Brar
  -- strict thread matches above, loose matches on Subject: below --
2012-06-23  8:07 jaswinder.singh
2012-06-23  8:19 ` jaswinder.singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1340022276.4012.23.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=jaswinder.singh@linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.