| Message ID | 1423731078-26681-10-git-send-email-tomeu.vizoso@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote: > As there isn't a way for the firmware on the Nyan chromebooks to hand > over the display to the kernel. Could this have a side-effect on models for which the firmware *does* hand over the display to the kernel? E.g. temporary glitch or black screen? This is probably ok though, as such a handing over would need to be documented in the firmware/kernel command line, and could thus be caught to disable that code block if needed.
Hi, On 2 March 2015 at 01:41, Alexandre Courbot <gnurou@gmail.com> wrote: > > On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso > <tomeu.vizoso@collabora.com> wrote: > > As there isn't a way for the firmware on the Nyan chromebooks to hand > > over the display to the kernel. > > Could this have a side-effect on models for which the firmware *does* > hand over the display to the kernel? E.g. temporary glitch or black > screen? > > This is probably ok though, as such a handing over would need to be > documented in the firmware/kernel command line, and could thus be > caught to disable that code block if needed. Is there a general way in which this hand-over is done, e.g. with a device tree binding? Regards, Simon
On Tue, Mar 3, 2015 at 12:46 AM, Simon Glass <sjg@chromium.org> wrote: > Hi, > > On 2 March 2015 at 01:41, Alexandre Courbot <gnurou@gmail.com> wrote: >> >> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso >> <tomeu.vizoso@collabora.com> wrote: >> > As there isn't a way for the firmware on the Nyan chromebooks to hand >> > over the display to the kernel. >> >> Could this have a side-effect on models for which the firmware *does* >> hand over the display to the kernel? E.g. temporary glitch or black >> screen? >> >> This is probably ok though, as such a handing over would need to be >> documented in the firmware/kernel command line, and could thus be >> caught to disable that code block if needed. > > Is there a general way in which this hand-over is done, e.g. with a > device tree binding? simple-framebuffer has bindings that describe a framebuffer handed over by the firmware, and they look like the right way to describe this. simplefb however is a framebuffer driver - a DRM driver would need to seamlessly take over the display at some point and disable simplefb. I don't know if this is possible at the moment. Or maybe the DRM framework could look for a simple-framebuffer compatible node, extract the framebuffer information, and pass it to DRM drivers at probe time. That supposes a kernel in which simple-framebuffer is not compiled in to prevent it from taking over the display.
On 2 March 2015 at 09:41, Alexandre Courbot <gnurou@gmail.com> wrote: > On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso > <tomeu.vizoso@collabora.com> wrote: >> As there isn't a way for the firmware on the Nyan chromebooks to hand >> over the display to the kernel. > > Could this have a side-effect on models for which the firmware *does* > hand over the display to the kernel? E.g. temporary glitch or black > screen? > > This is probably ok though, as such a handing over would need to be > documented in the firmware/kernel command line, and could thus be > caught to disable that code block if needed. Hi, my understanding from talking with Thierry is that the kernel will read the current state of the hw as the fw left it, and just carry on if it's compatible with the currently-requested mode. If it's not compatible, then the SOR should better be resetted to get it into a known state. But he's currently rewriting the SOR driver, so I don't know if it makes sense to merge this patch. Thanks, Tomeu > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index 2afe478..e6caacc 100644 --- a/drivers/gpu/drm/tegra/sor.c +++ b/drivers/gpu/drm/tegra/sor.c @@ -1458,6 +1458,20 @@ static int tegra_sor_probe(struct platform_device *pdev) mutex_init(&sor->lock); + err = reset_control_assert(sor->rst); + if (err < 0) { + dev_err(&pdev->dev, "failed to assert SOR reset: %d\n", err); + return err; + } + + msleep(20); + + err = reset_control_deassert(sor->rst); + if (err < 0) { + dev_err(&pdev->dev, "failed to deassert SOR reset: %d\n", err); + return err; + } + err = host1x_client_register(&sor->client); if (err < 0) { dev_err(&pdev->dev, "failed to register host1x client: %d\n",
As there isn't a way for the firmware on the Nyan chromebooks to hand over the display to the kernel. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> --- drivers/gpu/drm/tegra/sor.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)