All of lore.kernel.org
 help / color / mirror / Atom feed
From: hverkuil@xs4all.nl (Hans Verkuil)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support
Date: Mon, 24 Jul 2017 14:16:40 +0200	[thread overview]
Message-ID: <fba25a7e-671a-f7f4-93d6-68b004191675@xs4all.nl> (raw)
In-Reply-To: <35c2af77-b717-b86a-1f19-b3571d2fe156@xs4all.nl>

Hi Russell,

On 07/17/2017 02:23 PM, Hans Verkuil wrote:
> On 17/07/17 14:05, Russell King - ARM Linux wrote:
>> On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
>>> On 17/07/17 11:05, Russell King - ARM Linux wrote:
>>>> On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
>>>>> Hi Russell,
>>>>>
>>>>> On 09/06/17 16:10, Russell King - ARM Linux wrote:
>>>>>> On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
>>>>>>> Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
>>>>>>> not used, but a custom one, so this notifier is actually useful for
>>>>>>> this platform and maybe others.
>>>>>>
>>>>>> Is the CEC controller configured into dw-hdmi (is the config bit set?)
>>>>>> I'm just wondering if we're going to end up with two CEC drivers trying
>>>>>> to bind to the same notifier.
>>>>>>
>>>>>>> Should we really wait until I push the Amlogic AO CEC driver ? Having a
>>>>>>> notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
>>>>>>
>>>>>> It sounds like this adds additional information that has been missing
>>>>>> from the review of my patches - and I suspect changes Hans' comments.
>>>>>> So, I'll wait, it seems pointless to try and update the patches when
>>>>>> it's not clear how to proceed due to other dependencies, especially
>>>>>> when it means that their existing state is what's required (I'm pleased
>>>>>> that I've held off modifying the patches so far.)
>>>>>>
>>>>>> If that means having to wait another kernel revision, then I guess that's
>>>>>> what will have to happen.
>>>>>
>>>>> Can you respin your patch series, keeping the notifier support? The CEC
>>>>> kernel config handling has been cleaned up (just select CEC_CORE and
>>>>> CEC_NOTIFIER) so you should be good to go.
>>>>
>>>> Not yet - the change to the way you're dealing with Kconfig in CEC is
>>>> fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
>>>> support.
>>>>
>>>> As a result of these Kconfig changes, dw-hdmi-cec now fails if:
>>>>
>>>> 1. You build the CEC part as a module
>>>> 2. You build the HDMI part into the kernel
>>>>
>>>> This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
>>>> gets built, results in the stubs in the notifier code being used, rather
>>>> than the real functions.  This in turn causes the CEC part to never
>>>> receive a physical address, which is therefore non-functional.
>>>>
>>>> I did have a patch to fix this, but it was never committed, and I got
>>>> busy with other stuff (so it ended up being git reset --hard away.)
>>>>
>>>
>>> This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
>>>
>>> This will fix this:
>>>
>>> config DRM_DW_HDMI
>>>          tristate
>>>          select DRM_KMS_HELPER
>>>          select REGMAP_MMIO
>>>          select CEC_CORE if CEC_NOTIFIER			<<<<<<
>>>
>>> config DRM_DW_HDMI_CEC
>>>          tristate "Synopsis Designware CEC interface"
>>>          depends on DRM_DW_HDMI
>>>          select CEC_CORE
>>>          select CEC_NOTIFIER
>>>          help
>>>            Support the CE interface which is part of the Synopsis
>>>            Designware HDMI block.
>>>
>>> This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
>>> used instead (as is apparently the case for amlogic), then the
>>>
>>> 	select CEC_CORE if CEC_NOTIFIER
>>>
>>> line ensures that CONFIG_CEC_CORE has the right m/y value.
>>
>> I disagree with this approach.
>>
>> If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
>> that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
>> through dw-hdmi, even though we haven't asked for the CEC part to be
>> enabled.
> 
> If CEC_NOTIFIER is enabled by a CEC driver, then CEC_CORE will also be
> enabled (without CEC_CORE that driver wouldn't compile, obviously).
> 
> So I don't see the problem. All the select...if does is make sure that
> the CEC_CORE can be reached from the HDMI driver if someone enabled the
> CEC notifier (and thus CEC_CORE).
> 
>> You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
>> with it, because that's basically what this boils down to.
> 
> That makes no sense.
> 
> If CEC_NOTIFIER is set, then both the CEC driver and the HDMI driver have to
> select CEC_CORE to ensure the right dependency. If CEC_NOTIFIER is not set,
> then only the CEC driver has to select CEC_CORE. In that case the CEC code
> is typically either integrated into the HDMI driver or it is a standalone
> device like the USB pulse8-cec driver.

Just to make sure you aren't waiting for me to do anything: as far as I can tell
the Kconfig above will ensure the right dependencies. If you have an example
where this fails, then let me know. I am not planning on making any changes.
Frankly, I wouldn't know what to change since AFAICT it is all working with
the above Kconfig.

Regards,

	Hans

WARNING: multiple messages have this Message-ID (diff)
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	Neil Armstrong <narmstrong@baylibre.com>
Subject: Re: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support
Date: Mon, 24 Jul 2017 14:16:40 +0200	[thread overview]
Message-ID: <fba25a7e-671a-f7f4-93d6-68b004191675@xs4all.nl> (raw)
In-Reply-To: <35c2af77-b717-b86a-1f19-b3571d2fe156@xs4all.nl>

Hi Russell,

On 07/17/2017 02:23 PM, Hans Verkuil wrote:
> On 17/07/17 14:05, Russell King - ARM Linux wrote:
>> On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
>>> On 17/07/17 11:05, Russell King - ARM Linux wrote:
>>>> On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
>>>>> Hi Russell,
>>>>>
>>>>> On 09/06/17 16:10, Russell King - ARM Linux wrote:
>>>>>> On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
>>>>>>> Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
>>>>>>> not used, but a custom one, so this notifier is actually useful for
>>>>>>> this platform and maybe others.
>>>>>>
>>>>>> Is the CEC controller configured into dw-hdmi (is the config bit set?)
>>>>>> I'm just wondering if we're going to end up with two CEC drivers trying
>>>>>> to bind to the same notifier.
>>>>>>
>>>>>>> Should we really wait until I push the Amlogic AO CEC driver ? Having a
>>>>>>> notifier in the DW-HDMI driver won't harm anybody since it *will be used*.
>>>>>>
>>>>>> It sounds like this adds additional information that has been missing
>>>>>> from the review of my patches - and I suspect changes Hans' comments.
>>>>>> So, I'll wait, it seems pointless to try and update the patches when
>>>>>> it's not clear how to proceed due to other dependencies, especially
>>>>>> when it means that their existing state is what's required (I'm pleased
>>>>>> that I've held off modifying the patches so far.)
>>>>>>
>>>>>> If that means having to wait another kernel revision, then I guess that's
>>>>>> what will have to happen.
>>>>>
>>>>> Can you respin your patch series, keeping the notifier support? The CEC
>>>>> kernel config handling has been cleaned up (just select CEC_CORE and
>>>>> CEC_NOTIFIER) so you should be good to go.
>>>>
>>>> Not yet - the change to the way you're dealing with Kconfig in CEC is
>>>> fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
>>>> support.
>>>>
>>>> As a result of these Kconfig changes, dw-hdmi-cec now fails if:
>>>>
>>>> 1. You build the CEC part as a module
>>>> 2. You build the HDMI part into the kernel
>>>>
>>>> This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
>>>> gets built, results in the stubs in the notifier code being used, rather
>>>> than the real functions.  This in turn causes the CEC part to never
>>>> receive a physical address, which is therefore non-functional.
>>>>
>>>> I did have a patch to fix this, but it was never committed, and I got
>>>> busy with other stuff (so it ended up being git reset --hard away.)
>>>>
>>>
>>> This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
>>>
>>> This will fix this:
>>>
>>> config DRM_DW_HDMI
>>>          tristate
>>>          select DRM_KMS_HELPER
>>>          select REGMAP_MMIO
>>>          select CEC_CORE if CEC_NOTIFIER			<<<<<<
>>>
>>> config DRM_DW_HDMI_CEC
>>>          tristate "Synopsis Designware CEC interface"
>>>          depends on DRM_DW_HDMI
>>>          select CEC_CORE
>>>          select CEC_NOTIFIER
>>>          help
>>>            Support the CE interface which is part of the Synopsis
>>>            Designware HDMI block.
>>>
>>> This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
>>> used instead (as is apparently the case for amlogic), then the
>>>
>>> 	select CEC_CORE if CEC_NOTIFIER
>>>
>>> line ensures that CONFIG_CEC_CORE has the right m/y value.
>>
>> I disagree with this approach.
>>
>> If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
>> that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
>> through dw-hdmi, even though we haven't asked for the CEC part to be
>> enabled.
> 
> If CEC_NOTIFIER is enabled by a CEC driver, then CEC_CORE will also be
> enabled (without CEC_CORE that driver wouldn't compile, obviously).
> 
> So I don't see the problem. All the select...if does is make sure that
> the CEC_CORE can be reached from the HDMI driver if someone enabled the
> CEC notifier (and thus CEC_CORE).
> 
>> You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
>> with it, because that's basically what this boils down to.
> 
> That makes no sense.
> 
> If CEC_NOTIFIER is set, then both the CEC driver and the HDMI driver have to
> select CEC_CORE to ensure the right dependency. If CEC_NOTIFIER is not set,
> then only the CEC driver has to select CEC_CORE. In that case the CEC code
> is typically either integrated into the HDMI driver or it is a standalone
> device like the USB pulse8-cec driver.

Just to make sure you aren't waiting for me to do anything: as far as I can tell
the Kconfig above will ensure the right dependencies. If you have an example
where this fails, then let me know. I am not planning on making any changes.
Frankly, I wouldn't know what to change since AFAICT it is all working with
the above Kconfig.

Regards,

	Hans

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-07-24 12:16 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-30 14:22 [PATCH 0/4] dw-hdmi CEC support Russell King - ARM Linux
2017-05-30 14:22 ` Russell King - ARM Linux
2017-05-30 14:23 ` [PATCH 1/4] drm/bridge: dw-hdmi: remove CEC engine register definitions Russell King
2017-05-30 14:23   ` Russell King
2017-06-09 14:24   ` Hans Verkuil
2017-06-09 14:24     ` Hans Verkuil
2017-05-30 14:23 ` [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support Russell King
2017-05-30 14:23   ` Russell King
2017-06-09 12:59   ` Neil Armstrong
2017-06-09 12:59     ` Neil Armstrong
2017-06-09 13:38     ` Russell King - ARM Linux
2017-06-09 13:38       ` Russell King - ARM Linux
2017-06-09 13:51       ` Hans Verkuil
2017-06-09 13:51         ` Hans Verkuil
2017-06-09 13:56       ` Neil Armstrong
2017-06-09 13:56         ` Neil Armstrong
2017-06-09 14:04         ` Hans Verkuil
2017-06-09 14:04           ` Hans Verkuil
2017-06-09 14:10         ` Russell King - ARM Linux
2017-06-09 14:10           ` Russell King - ARM Linux
2017-06-09 14:38           ` Hans Verkuil
2017-06-09 14:38             ` Hans Verkuil
2017-07-17  8:56           ` Hans Verkuil
2017-07-17  8:56             ` Hans Verkuil
2017-07-17  9:05             ` Russell King - ARM Linux
2017-07-17  9:05               ` Russell King - ARM Linux
2017-07-17 11:19               ` Hans Verkuil
2017-07-17 11:19                 ` Hans Verkuil
2017-07-17 11:39               ` Hans Verkuil
2017-07-17 11:39                 ` Hans Verkuil
2017-07-17 12:05                 ` Russell King - ARM Linux
2017-07-17 12:05                   ` Russell King - ARM Linux
2017-07-17 12:23                   ` Hans Verkuil
2017-07-17 12:23                     ` Hans Verkuil
2017-07-24 12:16                     ` Hans Verkuil [this message]
2017-07-24 12:16                       ` Hans Verkuil
2017-07-24 13:07                       ` Russell King - ARM Linux
2017-07-24 13:07                         ` Russell King - ARM Linux
2017-07-24 16:34                         ` Russell King - ARM Linux
2017-07-24 16:34                           ` Russell King - ARM Linux
2017-06-09 14:27   ` Hans Verkuil
2017-06-09 14:27     ` Hans Verkuil
2017-05-30 14:23 ` [PATCH 3/4] drm/bridge: dw-hdmi: add better clock disable control Russell King
2017-05-30 14:23   ` Russell King
2017-06-01  0:55   ` Jose Abreu
2017-06-01  0:55     ` Jose Abreu
2017-06-09 14:28   ` Hans Verkuil
2017-06-09 14:28     ` Hans Verkuil
2017-05-30 14:23 ` [PATCH 4/4] drm/bridge: dw-hdmi: add cec driver Russell King
2017-05-30 14:23   ` Russell King
2017-06-01  0:53   ` Jose Abreu
2017-06-01  0:53     ` Jose Abreu
2017-06-01 22:30     ` Russell King - ARM Linux
2017-06-01 22:30       ` Russell King - ARM Linux
2017-06-02  5:02       ` Jose Abreu
2017-06-02  5:02         ` Jose Abreu
2017-06-02  9:15         ` Russell King - ARM Linux
2017-06-02  9:15           ` Russell King - ARM Linux
2017-06-02  9:28           ` Hans Verkuil
2017-06-02  9:28             ` Hans Verkuil
2017-06-02  9:36             ` Russell King - ARM Linux
2017-06-02  9:36               ` Russell King - ARM Linux
2017-06-01  8:31   ` Hans Verkuil
2017-06-01  8:31     ` Hans Verkuil
2017-06-01  9:46     ` Russell King - ARM Linux
2017-06-01  9:46       ` Russell King - ARM Linux
2017-06-01 10:44       ` Hans Verkuil
2017-06-01 10:44         ` Hans Verkuil
2017-06-02 12:07     ` Russell King - ARM Linux
2017-06-02 12:07       ` Russell King - ARM Linux
2017-06-02 12:29       ` Hans Verkuil
2017-06-02 12:29         ` Hans Verkuil
2017-06-12  8:42     ` Hans Verkuil
2017-06-12  8:42       ` Hans Verkuil
2017-06-01 13:47   ` Neil Armstrong
2017-06-01 13:47     ` Neil Armstrong
2017-06-02  6:31     ` Hans Verkuil
2017-06-02  6:31       ` Hans Verkuil
2017-06-02  6:43       ` Jose Abreu
2017-06-02  6:43         ` Jose Abreu
2017-06-02  9:06         ` Hans Verkuil
2017-06-02  9:06           ` Hans Verkuil
2017-06-02  9:18           ` Russell King - ARM Linux
2017-06-02  9:18             ` Russell King - ARM Linux

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=fba25a7e-671a-f7f4-93d6-68b004191675@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=linux-arm-kernel@lists.infradead.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.