On Fri, Nov 22, 2013 at 12:51 AM, Sebastian Reichel <sre@xxxxxxxx> wrote:
> Hi Tony,
>
> On Thu, Nov 21, 2013 at 10:58:45AM -0800, Tony Lindgren wrote:
>> Also, I just posted a patch to fix the eMMC that you may want to
>> try out.
>
> Let's move eMMC diskussion to that patch :)
>
>> > > > [...]
>> > > >
>> > > > My suggestion would be:
>> > > > 1. Find a better workaround for omapdss to acquire the SDI
>> > > > regulator. My current hack is obviously not acceptable.
>> > > > 2. Load the panel driver via DT as seen above and reference
>> > > > the omapdss interface with something like the above
>> > > > "ti,dss-source".
>> > >
>> > > To me it seems that we should be able to add minimal panel entries to DT
>> > > if we stick to existing standard bindings. Then the timings etc can be
>> > > set up based on the compatible flag. So I would leave out the properties
>> > > for ti,sdi-datapairs and ti,dss-source for now, and just set those in
>> > > the driver based on the sony,acx565akm compatible flag. Or maybe it should
>> > > be sony,acx565akm-n900 if there's some board specific configuration info.
>> >
>> > So we add reset-gpio and label to the DT data (they are panel
>> > specific and independent of omapdss) and just hardcode "dsi.0"
>> > with 2 data lanes into the driver? That sounds fine for me.
>> >
>> > If neither Tomi nor anybody else has better ideas I will cook a
>> > patch for that. I'm not sure how to setup the vdds_sdi regulator for
>> > omapdss, though. Is there an example for a legacy driver using a DT
>> > regulator available?
>>
>> Not that I know of :)
>
> Javier Martinez Canillas patch did what I was thinking of in [0].
I dropped that patch from my series and posted a v2 that just name the
VPLL2 regulator as vdds_dsi [1]. That way will be safer for Tony and
Benoit to take this series as a fix for the -rc cycle since the
changes are contained within IGEP boards DTS.
> My suggestion would be to add something like this pseudocode to
> omapdss:
>
> if(board_is_n900_dt()) {
> vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "V28");
> }
>
> The problem is, that we do not want to name the regulator
> "vdds_dsi", since it's not used exclusivly for omapdss.
>
> In the future it can get the regulator via phandle of course.
>
For what is worth I think that your suggestion is a good workaround.
Please just add a comment specifying that it is a hack and that we
have to get rid of these once the DSS DT bindings land on mainline and
we can use a phandle to get the regulator.
>> But I guess only the panel driver would need to parse the
>> compatible flag and the rest of the DSS could still be initialize
>> the legacy way if needed.
>
> Yes, except of the regulator. I will try to get this working
> tomorrow.
>
> [0] http://www.spinics.net/lists/arm-kernel/msg286896.html
>
> -- Sebastian
[1]: http://www.spinics.net/lists/arm-kernel/msg287703.html
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
