(Dropping Mark, whose Rockchip address is dead; and fixing Chris's email again)
On Mon, Nov 27, 2017 at 4:29 PM, Brian Norris <briannorris@xxxxxxxxxxxx> wrote:
> On Thu, Oct 26, 2017 at 09:44:14AM +0000, Philippe CORNU wrote:
>> On 10/26/2017 06:13 AM, Archit Taneja wrote:
>> > On 10/26/2017 06:39 AM, Brian Norris wrote:
>> >> somebody already working on refactoring existing Rockchip code to use
>> >> this?
>> >
>> > I don't know. If rockchip isn't interested in doing it, we can check with
>> > Philippe from ST if he can try creating a RFC that converts the rockchip
>> > driver to use the dw-mipi-dsi driver.
>>
>> I am not really interested in doing this port for Rockchip (or Hisilicon
>> or i.MX...) but happy to help anyone that wants to use the dw-mipi-dsi
>> bridge driver :)
>
> Ugh, this stuff is worse than I expected. I'm helping Rockchip along
> with getting this rewritten, but there are some hiccups.
>
> Among other things, the bridge driver is assuming it can set the
> device's drvdata itself. This works because the STM MIPI driver is
> simple, but the Rockchip one registers stuff via component_add(), and so
> it *needs* to handle drvdata between probe() and bind()...but then the
> "common" bridge driver is going to clobber it (dev_set_drvdata()).
>
> Along the way, I'm noticing that the STM driver just steps around this
> at times by referencing a static (!!) instance of its priv_data. See:
>
> static int dw_mipi_dsi_stm_remove(struct platform_device *pdev)
> {
> struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
> ...
>
>
> I might rewrite this, but it's not fun to have to fix somebody else's
> fork for them...
>
> Brian
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
