From: Tony Lindgren <tony@atomide.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-omap@vger.kernel.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: CEC blocks idle on omap4
Date: Mon, 25 Mar 2019 09:33:59 -0700 [thread overview]
Message-ID: <20190325163359.GN19425@atomide.com> (raw)
In-Reply-To: <ce79cce0-bbd7-95e3-2035-c99be6c94cb4@xs4all.nl>
* Hans Verkuil <hverkuil@xs4all.nl> [190325 16:28]:
> On 3/25/19 5:21 PM, Tony Lindgren wrote:
> > * Hans Verkuil <hverkuil@xs4all.nl> [190325 16:12]:
> >> On 3/25/19 4:55 PM, Laurent Pinchart wrote:
> >>>> The reality is that HDMI CEC and HDMI video are really independent of
> >>>> one another. So I wonder if it isn't better to explain the downsides
> >>>> of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC
> >>>> description. And perhaps disable it by default?
> >>>
> >>> This should be controllable by userspace. From a product point of view,
> >>> it should be possible to put the system in a deep sleep state where CEC
> >>> isn't available, or in a low sleep state where CEC works as expected.
> >>>
> >>
> >> Userspace can always disable CEC. The hdmi_cec_adap_enable() callback in
> >> hdmi4_cec.c is called whenever the CEC adapter is enabled or disabled.
> >
> > OK
> >
> >> I'm not actually sure why hdmi4_cec_init() would block anything since it
> >> just registers the CEC device. It does not enable it until userspace
> >> explicitly enables it with e.g. 'cec-ctl --playback'.
> >>
> >> hdmi4_cec_init() does configure a CEC clock, but that can be moved to
> >> hdmi_cec_adap_enable() if necessary.
> >
> > Hey I'm pretty sure that's the right fix then :)
> >
> >> Note that I am not sure what is meant with 'SoC core retention idle',
> >> so perhaps I just misunderstand the problem.
> >
> > If certain SoC clocks are busy, the SoC will not enter deeper
> > idle states. The hardware has autoidle type features on omaps.
>
> Can you make a patch? It is very easy to test:
Sure. Hmm then we just clear HDMI_WP_CLK values then for disable
too I guess.
> To configure the CEC adapter: cec-ctl --playback
> To unconfigure the CEC adapter: cec-ctl --clear
>
> As long as the CEC adapter is unconfigured you should be able to enter
> the deeper idle states. But not if it is configured.
OK will test tonight.
> And if you are moving code anyway, can you fix the typo in the comment?
> devider -> divider
>
> That hurts my eyes...
Sure.
Thanks,
Tony
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-omap@vger.kernel.org
Subject: Re: CEC blocks idle on omap4
Date: Mon, 25 Mar 2019 09:33:59 -0700 [thread overview]
Message-ID: <20190325163359.GN19425@atomide.com> (raw)
In-Reply-To: <ce79cce0-bbd7-95e3-2035-c99be6c94cb4@xs4all.nl>
* Hans Verkuil <hverkuil@xs4all.nl> [190325 16:28]:
> On 3/25/19 5:21 PM, Tony Lindgren wrote:
> > * Hans Verkuil <hverkuil@xs4all.nl> [190325 16:12]:
> >> On 3/25/19 4:55 PM, Laurent Pinchart wrote:
> >>>> The reality is that HDMI CEC and HDMI video are really independent of
> >>>> one another. So I wonder if it isn't better to explain the downsides
> >>>> of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC
> >>>> description. And perhaps disable it by default?
> >>>
> >>> This should be controllable by userspace. From a product point of view,
> >>> it should be possible to put the system in a deep sleep state where CEC
> >>> isn't available, or in a low sleep state where CEC works as expected.
> >>>
> >>
> >> Userspace can always disable CEC. The hdmi_cec_adap_enable() callback in
> >> hdmi4_cec.c is called whenever the CEC adapter is enabled or disabled.
> >
> > OK
> >
> >> I'm not actually sure why hdmi4_cec_init() would block anything since it
> >> just registers the CEC device. It does not enable it until userspace
> >> explicitly enables it with e.g. 'cec-ctl --playback'.
> >>
> >> hdmi4_cec_init() does configure a CEC clock, but that can be moved to
> >> hdmi_cec_adap_enable() if necessary.
> >
> > Hey I'm pretty sure that's the right fix then :)
> >
> >> Note that I am not sure what is meant with 'SoC core retention idle',
> >> so perhaps I just misunderstand the problem.
> >
> > If certain SoC clocks are busy, the SoC will not enter deeper
> > idle states. The hardware has autoidle type features on omaps.
>
> Can you make a patch? It is very easy to test:
Sure. Hmm then we just clear HDMI_WP_CLK values then for disable
too I guess.
> To configure the CEC adapter: cec-ctl --playback
> To unconfigure the CEC adapter: cec-ctl --clear
>
> As long as the CEC adapter is unconfigured you should be able to enter
> the deeper idle states. But not if it is configured.
OK will test tonight.
> And if you are moving code anyway, can you fix the typo in the comment?
> devider -> divider
>
> That hurts my eyes...
Sure.
Thanks,
Tony
next prev parent reply other threads:[~2019-03-25 16:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 15:32 CEC blocks idle on omap4 Tony Lindgren
2019-03-25 15:32 ` Tony Lindgren
2019-03-25 15:51 ` Hans Verkuil
2019-03-25 15:51 ` Hans Verkuil
2019-03-25 15:55 ` Laurent Pinchart
2019-03-25 15:55 ` Laurent Pinchart
2019-03-25 16:12 ` Hans Verkuil
2019-03-25 16:12 ` Hans Verkuil
2019-03-25 16:21 ` Tony Lindgren
2019-03-25 16:21 ` Tony Lindgren
2019-03-25 16:27 ` Hans Verkuil
2019-03-25 16:27 ` Hans Verkuil
2019-03-25 16:33 ` Tony Lindgren [this message]
2019-03-25 16:33 ` Tony Lindgren
2019-03-25 16:18 ` Tony Lindgren
2019-03-25 16:18 ` Tony Lindgren
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=20190325163359.GN19425@atomide.com \
--to=tony@atomide.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tomi.valkeinen@ti.com \
/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.