[PATCH v5 00/11] Improvements to Tegra-based Chromebook support

[PATCH v5 00/11] Improvements to Tegra-based Chromebook support

[Tomeu Vizoso]

v5:	* Moved to use gpio-restart for reboots, had to make tegra_pmc_restart
	a notification handler

v4:	* Added support for the system reset GPIO, for proper reboots
	* Moved out changes to ASOC to their own series, as requested by Mark
	Brown
	* Added patch to reset the SOR, to make sure it's in a known state
	* Changed nvidia,model property of the sound nodes to GoogleNyanBig
	and GoogleNyanBlaze so they can be told apart in userspace

v3:	* Added bindings for the LTN140AT29 panel
	* Removed the delay in pwrseq, as what was actually needed was to add
	a dependency on the power supplies of the host
	* Uses the pinmux for the Blaze as generated by tegra-pinmux-scripts
	* Uses the pinmux for the Big as in the last patch from Simon Glass

Hello,

this series adds support for the Tegra-based HP Chromebook 14 (aka nyan
blaze), which is very similar to the Acer Chromebook 13 (aka nyan big).
Because they both include tegra124-nyan.dtsi, some improvements to Blaze
support have also benefitted the Big. I have tested that USB2, the panels,
HDMI, the trackpad, Wifi and sound work on both.

The leaf DTs contain the whole pinmux configuration as generated by
tegra-pinmux-scripts. I chose to not put the common configuration in the
common dtsi so we can paste the output as is and be sure that the kernel
doesn't diverge from the canonical data.

These patches are based on top of linux-next 20150212.

http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=nyan-v5

Regards,

Tomeu

David Riley (1):
  soc/tegra: pmc: move to using a restart handler

Stéphane Marchesin (1):
  drm/panel: add support for Samsung LTN140AT29 panel

Tomeu Vizoso (9):
  ARM: tegra: Change model of sound card in Nyan Big
  ARM: tegra: Move out nyan-generic parts out from the nyan-big DT
  ARM: tegra: Add DTS for the nyan-blaze board
  ARM: tegra: Add node for trackpad in Nyan boards
  ARM: tegra: Use pwrseq-simple for the wifi in Nyan
  ARM: tegra: Use the generated pinmux data
  ARM: tegra: Set spi-max-frequency property to flash node
  drm/tegra: Reset the SOR on probe
  ARM: tegra: Add gpio-restart node

 .../bindings/panel/samsung,ltn140at29-301.txt      |    7 +
 arch/arm/boot/dts/Makefile                         |    1 +
 arch/arm/boot/dts/tegra124-nyan-big.dts            | 2119 +++++++++++---------
 arch/arm/boot/dts/tegra124-nyan-blaze.dts          | 1332 ++++++++++++
 arch/arm/boot/dts/tegra124-nyan.dtsi               |  694 +++++++
 arch/arm/mach-tegra/tegra.c                        |    1 -
 drivers/gpu/drm/panel/panel-simple.c               |   26 +
 drivers/gpu/drm/tegra/sor.c                        |   14 +
 drivers/soc/tegra/pmc.c                            |   31 +-
 9 files changed, 3253 insertions(+), 972 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
 create mode 100644 arch/arm/boot/dts/tegra124-nyan-blaze.dts
 create mode 100644 arch/arm/boot/dts/tegra124-nyan.dtsi

-- 
1.9.3

[PATCH v5 03/11] drm/panel: add support for Samsung LTN140AT29 panel

[Tomeu Vizoso]

From: Stéphane Marchesin <marcheu@chromium.org>

This panel is used by the Nyan Blaze board and supported by the simple-panel
driver.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
[tomeu.vizoso@collabora.com: add device tree binding document]
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---
 .../bindings/panel/samsung,ltn140at29-301.txt      |  7 ++++++
 drivers/gpu/drm/panel/panel-simple.c               | 26 ++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt b/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
new file mode 100644
index 0000000..e7f969d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
@@ -0,0 +1,7 @@
+Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
+
+Required properties:
+- compatible: should be "samsung,ltn140at29-301"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 39806c3..2da2285 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -779,6 +779,29 @@ static const struct panel_desc samsung_ltn101nt05 = {
 	},
 };
 
+static const struct drm_display_mode samsung_ltn140at29_301_mode = {
+	.clock = 76300,
+	.hdisplay = 1366,
+	.hsync_start = 1366 + 64,
+	.hsync_end = 1366 + 64 + 48,
+	.htotal = 1366 + 64 + 48 + 128,
+	.vdisplay = 768,
+	.vsync_start = 768 + 2,
+	.vsync_end = 768 + 2 + 5,
+	.vtotal = 768 + 2 + 5 + 17,
+	.vrefresh = 60,
+};
+
+static const struct panel_desc samsung_ltn140at29_301 = {
+	.modes = &samsung_ltn140at29_301_mode,
+	.num_modes = 1,
+	.bpc = 6,
+	.size = {
+		.width = 320,
+		.height = 187,
+	},
+};
+
 static const struct of_device_id platform_of_match[] = {
 	{
 		.compatible = "auo,b101aw03",
@@ -841,6 +864,9 @@ static const struct of_device_id platform_of_match[] = {
 		.compatible = "samsung,ltn101nt05",
 		.data = &samsung_ltn101nt05,
 	}, {
+		.compatible = "samsung,ltn140at29-301",
+		.data = &samsung_ltn140at29_301,
+	}, {
 		/* sentinel */
 	}
 };
-- 
1.9.3

[PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Tomeu Vizoso]

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(+)

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",
-- 
1.9.3

Re: [PATCH v5 00/11] Improvements to Tegra-based Chromebook support

[Stephen Warren]

On 02/12/2015 01:50 AM, Tomeu Vizoso wrote:
> Hello,
>
> this series adds support for the Tegra-based HP Chromebook 14 (aka nyan
> blaze), which is very similar to the Acer Chromebook 13 (aka nyan big).
> Because they both include tegra124-nyan.dtsi, some improvements to Blaze
> support have also benefitted the Big. I have tested that USB2, the panels,
> HDMI, the trackpad, Wifi and sound work on both.
>
> The leaf DTs contain the whole pinmux configuration as generated by
> tegra-pinmux-scripts. I chose to not put the common configuration in the
> common dtsi so we can paste the output as is and be sure that the kernel
> doesn't diverge from the canonical data.

At a quick glance this series looks OK,
Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Re: [PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Alexandre Courbot]

On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
<tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> 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.

Re: [PATCH v5 00/11] Improvements to Tegra-based Chromebook support

[Alexandre Courbot]

On Thu, Feb 12, 2015 at 5:50 PM, Tomeu Vizoso
<tomeu.vizoso@collabora.com> wrote:
> v5:     * Moved to use gpio-restart for reboots, had to make tegra_pmc_restart
>         a notification handler
>
> v4:     * Added support for the system reset GPIO, for proper reboots
>         * Moved out changes to ASOC to their own series, as requested by Mark
>         Brown
>         * Added patch to reset the SOR, to make sure it's in a known state
>         * Changed nvidia,model property of the sound nodes to GoogleNyanBig
>         and GoogleNyanBlaze so they can be told apart in userspace
>
> v3:     * Added bindings for the LTN140AT29 panel
>         * Removed the delay in pwrseq, as what was actually needed was to add
>         a dependency on the power supplies of the host
>         * Uses the pinmux for the Blaze as generated by tegra-pinmux-scripts
>         * Uses the pinmux for the Big as in the last patch from Simon Glass
>
> Hello,
>
> this series adds support for the Tegra-based HP Chromebook 14 (aka nyan
> blaze), which is very similar to the Acer Chromebook 13 (aka nyan big).
> Because they both include tegra124-nyan.dtsi, some improvements to Blaze
> support have also benefitted the Big. I have tested that USB2, the panels,
> HDMI, the trackpad, Wifi and sound work on both.
>
> The leaf DTs contain the whole pinmux configuration as generated by
> tegra-pinmux-scripts. I chose to not put the common configuration in the
> common dtsi so we can paste the output as is and be sure that the kernel
> doesn't diverge from the canonical data.

FWIW, the series:

Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>

Re: [PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Simon Glass]

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

Re: [PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Alexandre Courbot]

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.

Re: [PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Tomeu Vizoso]

On 2 March 2015 at 09:41, Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
> <tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/