| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAAQKjZMfP_Cgo5hPPTiwKa_+Ph+GUt2Fbdtipd5V=CQEDy3eSQ@mail.gmail.com>
Date: Fri, 4 Oct 2013 13:18:41 +0900
From: Inki Dae <inki.dae@...sung.com>
To: Sean Paul <seanpaul@...omium.org>
Cc: Kukjin Kim <kgene.kim@...sung.com>,
DRI mailing list <dri-devel@...ts.freedesktop.org>,
"linux-samsung-soc@...r.kernel.org"
<linux-samsung-soc@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Dave Airlie <airlied@...ux.ie>
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul <seanpaul@...omium.org>:
> On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae <inki.dae@...sung.com> wrote:
>> 2013/10/4 Sean Paul <seanpaul@...omium.org>:
>>> This patch adds code to look for the ptn3460 in the device tree file on
>>> exynos initialization. If ptn node is found, the driver will initialize
>>> the ptn3460 driver and skip creating a DP connector (since the bridge
>>> driver will register its own connector).
>>>
>>> Signed-off-by: Sean Paul <seanpaul@...omium.org>
>>> ---
>>>
>>> v2:
>>> - Changed include from of_i2c.h to i2c.h
>>> - Changed of_find_by_name to of_find_compatible
>>>
>>> drivers/gpu/drm/exynos/exynos_drm_core.c | 44 +++++++++++++++++++++++++++++++-
>>> 1 file changed, 43 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c b/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> index 1bef6dc..08ca4f9 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> @@ -12,7 +12,9 @@
>>> * option) any later version.
>>> */
>>>
>>> +#include <linux/i2c.h>
>>> #include <drm/drmP.h>
>>> +#include <drm/bridge/ptn3460.h>
>>> #include "exynos_drm_drv.h"
>>> #include "exynos_drm_encoder.h"
>>> #include "exynos_drm_connector.h"
>>> @@ -20,6 +22,40 @@
>>>
>>> static LIST_HEAD(exynos_drm_subdrv_list);
>>>
>>> +struct bridge_init {
>>> + struct i2c_client *client;
>>> + struct device_node *node;
>>> +};
>>> +
>>> +static bool find_bridge(const char *compat, struct bridge_init *bridge)
>>> +{
>>> + bridge->client = NULL;
>>> + bridge->node = of_find_compatible_node(NULL, NULL, compat);
>>
>> Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
>> that such tricky isn't needed? Is there any reason you use such tricky
>> codes?
>>
>
> This is what I was explaining earlier today. If the bridge driver is
> just an i2c driver, it won't get a pointer to drm_device, and can't
> register itself as a drm_bridge or drm_connector. To solve this, you
> need the ptn3460_init callback.
>
No, I think you can use sub driver. how about registering to exynos
drm core that driver using exynos_drm_subdrv_register function after
probed? Is there something I am missing?
> If it's an i2c driver with the ptn3460_init callback, where it parses
> the dt in probe, then you have a race between the ptn probe and the
> ptn init/drm hooks. ie: it's possible drm will initialize and call
> disable/post_disable/pre_enable/enable before things have been probed.
And also, exynos drm core will call a probe callback of the sub driver
after _drm is initialized_. Is there something I am missing?
> To solve this, you need to use some global state and/or locking.
>
> So, to summarize. We can have this of_find_compatible with a init
> callback, or we can have an i2c driver + global state/locking + init
> callback. I chose the former, since it seemed easier.
>
> If you have a better way to achieve this, I'm definitely interested,
> but I saw this as the lesser of two evils.
>
> Sean
>
>> I think you need to implement the lvds-bridge driver as i2c driver,
>> and then consider how to take care of this. I mean let's find a better
>> way how we could take care of the i2c based driver in exynos drm
>> framework or driver. In all cases, such tricky codes are not good.
>>
>>> + if (!bridge->node)
>>> + return false;
>>> +
>>> + bridge->client = of_find_i2c_device_by_node(bridge->node);
>>> + if (!bridge->client)
>>> + return false;
>>> +
>>> + return true;
>>> +}
>>> +
>>> +/* returns the number of bridges attached */
>>> +static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
>>> + struct drm_encoder *encoder)
>>> +{
>>> + struct bridge_init bridge;
>>> + int ret;
>>> +
>>> + if (find_bridge("nxp,ptn3460", &bridge)) {
>>> + ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
>>> + if (!ret)
>>> + return 1;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> static int exynos_drm_create_enc_conn(struct drm_device *dev,
>>> struct exynos_drm_subdrv *subdrv)
>>> {
>>> @@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
>>> DRM_ERROR("failed to create encoder\n");
>>> return -EFAULT;
>>> }
>>> + subdrv->encoder = encoder;
>>> +
>>> + if (subdrv->manager->display_ops->type == EXYNOS_DISPLAY_TYPE_LCD) {
>>> + ret = exynos_drm_attach_lcd_bridge(dev, encoder);
>>> + if (ret)
>>> + return 0;
>>> + }
>>>
>>> /*
>>> * create and initialize a connector for this sub driver and
>>> @@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
>>> goto err_destroy_encoder;
>>> }
>>>
>>> - subdrv->encoder = encoder;
>>> subdrv->connector = connector;
>>>
>>> return 0;
>>> --
>>> 1.8.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists