[GIT PULL RESEND] arm-soc: vt8500: Convert mach-vt8500 to devicetree

[Tony Prisk]

On Fri, 2012-09-21 at 18:42 +0000, Tony Prisk wrote:
> On Fri, 2012-09-21 at 18:07 +0000, Tony Prisk wrote:
> > On Thu, 2012-09-20 at 16:28 -0700, Olof Johansson wrote:
> > > Hi,
> > > 
> > > On Thu, Sep 20, 2012 at 05:45:06PM +1200, Tony Prisk wrote:
> > > > Please disregard the last pull request - commit id's were invalid.
> > > > This one is now correct.
> > > > 
> > > > The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
> > > > 
> > > >   Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   git://git.code.sf.net/p/linuxwmt/code tags/vt8500-for-next
> > > > 
> > > > for you to fetch changes up to 0cd5434aae73698aa4a48542bd8d1428d44820cb:
> > > > 
> > > >   arm: vt8500: Update arch-vt8500 to devicetree support. (2012-09-20 07:23:26 +1200)
> > > > 
> > > > ----------------------------------------------------------------
> > > > Update mach-vt8500 to devicetree and remove non-dt code.
> > > > 
> > > > ----------------------------------------------------------------
> > > > Tony Prisk (8):
> > > >       arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
> > > >       rtc: vt8500: Add devicetree support for vt8500-rtc
> > > >       serial: vt8500: Add devicetree support for vt8500-serial
> > > >       video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb
> > > >       arm: vt8500: clk: Add Common Clock Framework support
> > > >       arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices
> > > >       arm: vt8500: gpio: Devicetree support for arch-vt8500
> > > >       arm: vt8500: Update arch-vt8500 to devicetree support.
> > > 
> > > Overall this series looks great, however I pinged Rob Herring about it
> > > since I didn't see his Acked-by on the bindings patch. It sounds like he
> > > has some comments on the display pieces, so unless you can break those
> > > out and do everything else for 3.7, we might need to hold off until that
> > > has been settled.
> > > 
> > > 
> > > -Olof
> > 
> > This was discussed when the series was originally posted. The display
> > mode binding was still floating around with V1 suggestions so I had to
> > make a best-guess as to how it would end up.
> > 
> > Without it, the patch will break support for 95% of users as framebuffer
> > is the only output device. 
> > 
> > Given that I can't fix it as the videomode helper patch is still getting
> > revisions (Last I saw v4 had outstanding queries against it) I guess it
> > will have to wait until next time around.
> > 
> > Regards
> > 
> > Tony P
> 
> I think I was a bit hasty in my reply.
> 
> Having looked at v4 of the videomode helper patch, there is only naming
> differences between my display node and the v4 binding. These could be
> fixed in a few minutes.
> 
> Given the late stage, how likely is it that the videomode helper is
> going to make it in to 3.7?
> 
> If not, couldn't this patchset go through with the board file changes to
> the display node to bring it inline with the expected binding? 
> 
> I plan to submit a new framebuffer driver for 3.8 which could be
> modified to use the helper when its in 3.8 (assuming it doesn't make
> 3.7) - or the existing framebuffer driver could be patched to use the
> of_helper. I realise this creates a bit of churn on the framebuffer
> code, but more than likely its going to occur anyway if the new driver
> is accepted.
> 
> Regards
> 
> Tony P

To clarify, I have made the following changes to try bringing the code
in line with the videomode_helper patch. I guess this is really a
question for Rob - Does this help??

In the soc dtsi:
		fb at d8050800 {
			compatible = "wm,wm8505-fb";
			reg = <0xd8050800 0x200>;
			display = <&display>;
			default-mode = <&mode0>;
		};


In the board dts:
	display: display at 0 {
		modes {
			mode0: mode at 0 {
				hactive = <800>;
				vactive = <480>;
				hback-porch = <88>;
				hfront-porch = <40>;
				hsync-len = <0>;
				vback-porch = <32>;
				vfront-porch = <11>;
				vsync-len = <1>;
				clock = <0>;	/* unused but required */
				bpp = <16>;	/* non-standard but required */
			};
		};
	};


In the framebuffer driver:
	...
	np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
	if (!np) {
		pr_err("%s: No display description in Device Tree\n", __func__);
		ret = -EINVAL;
		goto failed_free_res;
	}

	/*
	 * This code is copied from Sascha Hauer's of_videomode helper
	 * and can be replaced with a call to the helper once mainlined
	 */
	ret = 0;
	ret |= of_property_read_u32(np, "hactive", &of_mode.xres);
	ret |= of_property_read_u32(np, "vactive", &of_mode.yres);
	...


I realise this probably makes more sense to me than anyone else, so if
you would like a proper patch posted let me know.

Regards

Tony P