| Message ID | 20170414102512.48834-2-hverkuil@xs4all.nl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil <hans.verkuil@cisco.com> > > The CEC pin was always pulled up, making it impossible to use it. > > Change to PIN_INPUT so it can be used by the new CEC support. > > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> > --- > arch/arm/boot/dts/omap4-panda-a4.dts | 2 +- > arch/arm/boot/dts/omap4-panda-es.dts | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts > index 78d363177762..f1a6476af371 100644 > --- a/arch/arm/boot/dts/omap4-panda-a4.dts > +++ b/arch/arm/boot/dts/omap4-panda-a4.dts > @@ -13,7 +13,7 @@ > /* Pandaboard Rev A4+ have external pullups on SCL & SDA */ > &dss_hdmi_pins { > pinctrl-single,pins = < > - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ > + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ > OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ > OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ > >; > diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts > index 119f8e657edc..940fe4f7c5f6 100644 > --- a/arch/arm/boot/dts/omap4-panda-es.dts > +++ b/arch/arm/boot/dts/omap4-panda-es.dts > @@ -34,7 +34,7 @@ > /* PandaboardES has external pullups on SCL & SDA */ > &dss_hdmi_pins { > pinctrl-single,pins = < > - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ > + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ > OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ > OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ > >; > Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tony, can you queue this? It's safe to apply separately from the rest of the HDMI CEC work. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: > > From: Hans Verkuil <hans.verkuil@cisco.com> > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > Change to PIN_INPUT so it can be used by the new CEC support. ... > Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > > Tony, can you queue this? It's safe to apply separately from the rest of > the HDMI CEC work. Sure will do. Thanks, Tony
Hi, On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: > > On 14/04/17 13:25, Hans Verkuil wrote: > > > From: Hans Verkuil <hans.verkuil@cisco.com> > > > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > > > Change to PIN_INPUT so it can be used by the new CEC support. > ... > > > Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > > > > Tony, can you queue this? It's safe to apply separately from the rest of > > the HDMI CEC work. > > Sure will do. I guess the same patch should be applied to Droid 4? -- Sebastian
* Sebastian Reichel <sre@kernel.org> [170428 11:29]: > Hi, > > On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: > > > On 14/04/17 13:25, Hans Verkuil wrote: > > > > From: Hans Verkuil <hans.verkuil@cisco.com> > > > > > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > > > > > Change to PIN_INPUT so it can be used by the new CEC support. > > ... > > > > > Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > > > > > > Tony, can you queue this? It's safe to apply separately from the rest of > > > the HDMI CEC work. > > > > Sure will do. > > I guess the same patch should be applied to Droid 4? I guess it depends if there is an external pull or not. If there's an external pull, the internal pull needs to be disabled as otherwise the resistors are parallel and pull value is much lower than intended. Looks like on droid 4 we have: $ grep 09a /sys/kernel/debug/pinctrl/4a100040.pinmux/pins pin 45 (PIN45) 4a10009a 00000118 pinctrl-single $ grep PULL_ENA ./include/dt-bindings/pinctrl/omap.h #define PULL_ENA (1 << 3) ... So bit 3 is set and internal pull is enabled in pinmux_dss_hdmi_pins for droid 4 also. The pull seems to be enabled in the Android kernel too: # rwmem -s16 0x4a10009a 0x4a10009a = 0x0118 So needs to be tested, what's the simplest test to check the CEC? Hmm I wonder if disabling the internal pull also allows removing the "regulator-always-on" hack for hdmi_regulator there? Without regulator-always-on I noticed that HDMI panel resolutions are not detected. This I can test easily.. Regards, Tony
* Tony Lindgren <tony@atomide.com> [170428 11:57]: > The pull seems to be enabled in the Android kernel too: > > # rwmem -s16 0x4a10009a > 0x4a10009a = 0x0118 > > So needs to be tested, what's the simplest test to check the CEC? So on droid 4, with the internal pull enabled cec-ctl -m does not show anything. With the internal pull disabled, cec-ctl -m produces the following with a lapdock: Initial Event: State Change: PA: 1.0.0.0, LA mask: 0x4000 Event: State Change: PA: f.f.f.f, LA mask: 0x0000 Event: State Change: PA: 1.0.0.0, LA mask: 0x0000 Transmitted by Specific to Specific (14 to 14): CEC_MSG_POLL Tx, Not Acknowledged (4), Max Retries Event: State Change: PA: 1.0.0.0, LA mask: 0x4000 Transmitted by Specific to all (14 to 15): CEC_MSG_REPORT_FEATURES (0xa6): cec-version: version-2-0 (0x06) all-device-types: switch (0x04) rc-profile: tv-profile-none (0x00) dev-features: 0 (0x00) Transmitted by Specific to all (14 to 15): CEC_MSG_REPORT_PHYSICAL_ADDR (0x84): phys-addr: 1.0.0.0 prim-devtype: processor (0x07) And looking at the ifixit.com board picture, there seems to be a IP4791CZ12 chip on droid 4. And it's docs seem to hint it has a pull in the IP4791CZ12. So yeah my guess is the cec internal pull should be disabled on all omap4 devices with HDMI. I'll send a follow-up patch for that. > Hmm I wonder if disabling the internal pull also allows removing > the "regulator-always-on" hack for hdmi_regulator there? Without > regulator-always-on I noticed that HDMI panel resolutions are not > detected. This I can test easily.. The regulator-fixed is still needed, I think this GPIO regulator powers the IP4791CZ12 which has no control channel. Not sure if we should still have encoder-ip4791cz12.c driver for it just to manage the regulator? Regards, Tony
Tomi, * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: > > From: Hans Verkuil <hans.verkuil@cisco.com> > > > > The CEC pin was always pulled up, making it impossible to use it. ... > Tony, can you queue this? It's safe to apply separately from the rest of > the HDMI CEC work. So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next? Regards, Tony
On 26/06/17 13:07, Tony Lindgren wrote: > Tomi, > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: >> On 14/04/17 13:25, Hans Verkuil wrote: >>> From: Hans Verkuil <hans.verkuil@cisco.com> >>> >>> The CEC pin was always pulled up, making it impossible to use it. > ... > >> Tony, can you queue this? It's safe to apply separately from the rest of >> the HDMI CEC work. > > So the dts changes are merged now but what's the status of the CEC driver > changes? Were there some issues as I don't see them in next? Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) this was still pending review. Tomi, any updates on this? It would be nice to get this in for 4.14. Regards, Hans
* Hans Verkuil <hverkuil@xs4all.nl> [170627 01:39]: > On 26/06/17 13:07, Tony Lindgren wrote: > > Tomi, > > > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: > >> On 14/04/17 13:25, Hans Verkuil wrote: > >>> From: Hans Verkuil <hans.verkuil@cisco.com> > >>> > >>> The CEC pin was always pulled up, making it impossible to use it. > > ... > > > >> Tony, can you queue this? It's safe to apply separately from the rest of > >> the HDMI CEC work. > > > > So the dts changes are merged now but what's the status of the CEC driver > > changes? Were there some issues as I don't see them in next? > > Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the > omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) > this was still pending review. OK thanks for the update. Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :) > Tomi, any updates on this? It would be nice to get this in for 4.14. Yeah seems like we have real mainline kernel user needs for this one. Regards, Tony
On 06/27/17 12:14, Tony Lindgren wrote: > * Hans Verkuil <hverkuil@xs4all.nl> [170627 01:39]: >> On 26/06/17 13:07, Tony Lindgren wrote: >>> Tomi, >>> >>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: >>>> On 14/04/17 13:25, Hans Verkuil wrote: >>>>> From: Hans Verkuil <hans.verkuil@cisco.com> >>>>> >>>>> The CEC pin was always pulled up, making it impossible to use it. >>> ... >>> >>>> Tony, can you queue this? It's safe to apply separately from the rest of >>>> the HDMI CEC work. >>> >>> So the dts changes are merged now but what's the status of the CEC driver >>> changes? Were there some issues as I don't see them in next? >> >> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the >> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) >> this was still pending review. > > OK thanks for the update. > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > HDMI audio volume level on devices implementing it? Or am I too > optimistic? :) > As long as you do not expect a regular ALSA-volume to work.. But I don't see why some CEC application would not work. However, I guess one could implement this as feature to ALSA too but AFAIK no such thing exists at the moment. Best regards, Jyri >> Tomi, any updates on this? It would be nice to get this in for 4.14. > > Yeah seems like we have real mainline kernel user needs for this one. > > Regards, > > Tony >
On 27/06/17 11:14, Tony Lindgren wrote: > * Hans Verkuil <hverkuil@xs4all.nl> [170627 01:39]: >> On 26/06/17 13:07, Tony Lindgren wrote: >>> Tomi, >>> >>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: >>>> On 14/04/17 13:25, Hans Verkuil wrote: >>>>> From: Hans Verkuil <hans.verkuil@cisco.com> >>>>> >>>>> The CEC pin was always pulled up, making it impossible to use it. >>> ... >>> >>>> Tony, can you queue this? It's safe to apply separately from the rest of >>>> the HDMI CEC work. >>> >>> So the dts changes are merged now but what's the status of the CEC driver >>> changes? Were there some issues as I don't see them in next? >> >> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the >> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) >> this was still pending review. > > OK thanks for the update. > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > HDMI audio volume level on devices implementing it? Or am I too > optimistic? :) I'm not quite sure what you mean. Do you want CEC to change the volume on the TV, or use the TV's remote to change the volume of the HDMI audio output of the omap4? Anyway, either is supported, but it requires a userspace implementation. Although TV remote control messages will be mapped to an input device, and if those are hooked up to the alsa audio volume, then this already works. Regards, Hans > >> Tomi, any updates on this? It would be nice to get this in for 4.14. > > Yeah seems like we have real mainline kernel user needs for this one. > > Regards, > > Tony >
On 06/27/17 12:27, Hans Verkuil wrote: > On 27/06/17 11:14, Tony Lindgren wrote: >> * Hans Verkuil <hverkuil@xs4all.nl> [170627 01:39]: >>> On 26/06/17 13:07, Tony Lindgren wrote: >>>> Tomi, >>>> >>>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [170428 04:15]: >>>>> On 14/04/17 13:25, Hans Verkuil wrote: >>>>>> From: Hans Verkuil <hans.verkuil@cisco.com> >>>>>> >>>>>> The CEC pin was always pulled up, making it impossible to use it. >>>> ... >>>> >>>>> Tony, can you queue this? It's safe to apply separately from the rest of >>>>> the HDMI CEC work. >>>> >>>> So the dts changes are merged now but what's the status of the CEC driver >>>> changes? Were there some issues as I don't see them in next? >>> >>> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the >>> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) >>> this was still pending review. >> >> OK thanks for the update. >> >> Adding Jyri to Cc, hopefully the CEC support allows also setting the >> HDMI audio volume level on devices implementing it? Or am I too >> optimistic? :) > > I'm not quite sure what you mean. Do you want CEC to change the volume on the > TV, or use the TV's remote to change the volume of the HDMI audio output of the > omap4? > There is no real volume on HDMI audio output as it is a digital interface, but it should be possible to provide some volume control using TV's volume trough CEC. > Anyway, either is supported, but it requires a userspace implementation. > A module to pulseaudio or some extra features to alsa-lib should be generic enough (who knows, maybe there is already something). Just an idea. If someone really needs this, the pieces to put it together should be there. Best regards, Jyri > Although TV remote control messages will be mapped to an input device, and if > those are hooked up to the alsa audio volume, then this already works. >> Regards, > > Hans > >> >>> Tomi, any updates on this? It would be nice to get this in for 4.14. >> >> Yeah seems like we have real mainline kernel user needs for this one. >> >> Regards, >> >> Tony >> >
* Hans Verkuil <hverkuil@xs4all.nl> [170627 02:27]: > On 27/06/17 11:14, Tony Lindgren wrote: > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > > HDMI audio volume level on devices implementing it? Or am I too > > optimistic? :) > > I'm not quite sure what you mean. Do you want CEC to change the volume on the > TV, or use the TV's remote to change the volume of the HDMI audio output of the > omap4? I'm hoping to change audio volume on a USB+HDMI lapdock from omap4. > Anyway, either is supported, but it requires a userspace implementation. > > Although TV remote control messages will be mapped to an input device, and if > those are hooked up to the alsa audio volume, then this already works. OK great thanks, Tony
* Jyri Sarha <jsarha@ti.com> [170627 02:47]: > There is no real volume on HDMI audio output as it is a digital > interface, but it should be possible to provide some volume control > using TV's volume trough CEC. OK great! Tony
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts index 78d363177762..f1a6476af371 100644 --- a/arch/arm/boot/dts/omap4-panda-a4.dts +++ b/arch/arm/boot/dts/omap4-panda-a4.dts @@ -13,7 +13,7 @@ /* Pandaboard Rev A4+ have external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = < - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ >; diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 119f8e657edc..940fe4f7c5f6 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -34,7 +34,7 @@ /* PandaboardES has external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = < - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ >;