Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

[Sean Paul]

On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae <inki.dae@xxxxxxxxxxx> wrote:
> 2013/10/4 Sean Paul <seanpaul@xxxxxxxxxxxx>:
>> On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae <inki.dae@xxxxxxxxxxx> wrote:
>>> 2013/10/4 Sean Paul <seanpaul@xxxxxxxxxxxx>:
>>>> 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@xxxxxxxxxxxx>
>>>> ---
>>>>
>>>> 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?
>

The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.

Sean

>
>> 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@xxxxxxxxxxxxxxx
>>>> 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@xxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/