Re: armv7/omap: introducing amdisplay(4) + nxptda(4)

2017-04-23 Thread Mark Kettenis
> Date: Mon, 3 Apr 2017 01:33:28 -0400
> From: Ian Sutton 
> 
> This patch introduces preliminary support for the display hardware
> onboard the am335x/BeagleBone Black. Included are two drivers,
> amdisplay(4) and nxptda(4), which run the LCD controller and HDMI PHY
> transmitter respectively. This patch follows work I've mailed to this
> list found here:
> 
> https://marc.info/?t=14704720461&r=1&w=2
> 
> The code below is a complete (fourth!) rewrite. It completely and
> correctly controls the hardware but still needs to be plugged into the
> rest of the system (wsdisplay for syscons, wsfb for Xorg, etc.) before
> it is useful. In the meantime, I feel that it is review-ready and worth
> the time for a dev to look over.
> 
> Here is a demonstration of my code working where the framebuffer is
> filled with entropy from arc4random_buf() every frame:
> 
> https://www.youtube.com/watch?v=yCzFyZlfbzQ
> 
> Here is the man page in HTML format for convenience:
> 
> https://ce.gl/amdisplay.4.html
> 
> Here is a link to the patch below for when the list mangles it:
> 
> https://ce.gl/amdisplay-apr2.diff.txt
> 
> Note: this driver currently only supports 640x480x16 mode, but is only
> one clock/math problem away from higher modes. Yes, I am aware of fdt
> simple-framebuffer node and yes, this code accomplishes useful things
> which the fdt framebuffer cannot.

Ian,

As you've noticed this diff hasn't seen any real review yet.  One of
the problems is that it adds support for something we don't really
consider to be very important for armv7, on hardware that most of us
consider to be mostly a (very slow) toy which is hard to actually use
as having a framebuffer doesn't really make sense as long as the
serial console is the only actual input device that works in OpenBSD
on the BBB.

The diff itself looks mostly reasonable.  It's probably better to
rename nxptda(4) into something like nxphdmi(4), as nxptda(4) isn't a
very descriptive name.  But before we ask you to make such changes, I
think we really need working USB support.  Without that, this code
really isn't very useful.

Mark

> Index: sys/arch/armv7/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
> retrieving revision 1.71
> diff -u -p -p -u -r1.71 GENERIC
> --- sys/arch/armv7/conf/GENERIC   23 Jan 2017 22:43:17 -  1.71
> +++ sys/arch/armv7/conf/GENERIC   3 Apr 2017 05:24:32 -
> @@ -81,6 +81,9 @@ sdmmc*  at ommmc?   # SD/MMC bus
>  
>  omehci*  at fdt? # EHCI
>  usb* at omehci?
> +nxptda*  at iic? # TDA19988 HDMI PHY
> +amdisplay*   at fdt? # AM335x LCD controller
> +wsdisplay*   at amdisplay?
>  
>  # Sunxi A1x/A20 SoC
>  sxiintc* at fdt? # A1x interrupt controller
> Index: sys/arch/armv7/omap/am335x_prcmreg.h
> ===
> RCS file: /cvs/src/sys/arch/armv7/omap/am335x_prcmreg.h,v
> retrieving revision 1.4
> diff -u -p -p -u -r1.4 am335x_prcmreg.h
> --- sys/arch/armv7/omap/am335x_prcmreg.h  18 Mar 2014 07:34:17 -  
> 1.4
> +++ sys/arch/armv7/omap/am335x_prcmreg.h  3 Apr 2017 05:24:33 -
> @@ -20,6 +20,7 @@
>  #define AM335X_CLKCTRL_MODULEMODE_MASK   0x0003
>  
>  #define PRCM_AM335X_CM_PER   0x
> +#define PRCM_AM335X_LCDC_CLKCTRL 0x0018
>  #define PRCM_AM335X_USB0_CLKCTRL 0x001c
>  #define PRCM_AM335X_TPTC0_CLKCTRL0x0024
>  #define PRCM_AM335X_MMC0_CLKCTRL 0x003c
> @@ -38,6 +39,10 @@
>  #define PRCM_AM335X_CM_WKUP  0x0400
>  #define PRCM_AM335X_GPIO0_CLKCTRL0x0408
>  #define PRCM_AM335X_TIMER0_CLKCTRL   0x0410
> +#define PRCM_AM335X_DISP_IDLEST  0x0448
> +#define PRCM_AM335X_DISP_CLKSEL  0x0454
> +#define PRCM_AM335X_DISP_CLKMODE 0x0498
> +#define PRCM_AM335X_DISP_M2  0x04a4
>  #define PRCM_AM335X_I2C0_CLKCTRL 0x04b8
>  #define PRCM_AM335X_CM_DPLL  0x0500
>  #define PRCM_AM335X_CLKSEL_TIMER2_CLK0x0508
> Index: sys/arch/armv7/omap/amdisplay.c
> ===
> RCS file: sys/arch/armv7/omap/amdisplay.c
> diff -N sys/arch/armv7/omap/amdisplay.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ sys/arch/armv7/omap/amdisplay.c   3 Apr 2017 05:24:33 -
> @@ -0,0 +1,628 @@
> +/*
> + * Copyright (c) 2016 Ian Sutton 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, I

Re: armv7/omap: introducing amdisplay(4) + nxptda(4)

2017-04-17 Thread Matthieu Herrb
xOn Sun, Apr 16, 2017 at 12:07:34AM -0400, Ian Sutton wrote:
> 
> The USB host controller on the am335x isn't EHCI compatible and is currently
> unsupported, the only direct interface with the board is via a com(4) ftdi
> serial port that doesn't provide a wskbd(4) device which Xorg demands. None
> of the config options that would seem to suggest allowing you to bypass this
> work, but removing the xf86-input-kbd object files does (?). I'm not sure 
> whether
> it's appropriate to fix this in xenocara or through something like comkbd(4).
> 

Hi,

While it's technically possible (and has been done in the past) to
attach other keyboard devices directly to Xorg, it's not the direction
we're heading to with the work done by mpi@ and ulf@ on input
devices.

you should definatly have something that hooks into wskbd(4). Look at
how various keyboard protocols are hooked into wskbd for various
architectures. And I believe keyboards are a bit easier to handle than
pointing devices.

-- 
Matthieu Herrb



Re: armv7/omap: introducing amdisplay(4) + nxptda(4)

2017-04-15 Thread Ian Sutton
On Mon, Apr 03, 2017 at 01:33:28AM -0400, Ian Sutton wrote:
> The code below is a complete (fourth!) rewrite. It completely and
> correctly controls the hardware but still needs to be plugged into the
> rest of the system (wsdisplay for syscons, wsfb for Xorg, etc.) before
> it is useful. In the meantime, I feel that it is review-ready and worth

amdisplay(4) now plugs into wsdisplay(4) allowing Xorg to run via wsfb(4)
driver:

https://ce.gl/hooraydisplay.png

Additionally, amdisplay(4) also now supports higher resolutions, choosing the
highest mode the monitor purports to support or the highest mode the LCDC
is capable of running, whichever comes first (I think the max for now is
1600x1200@60).

I feel this driver is functionally complete at this point and now needs wiser
eyes than mine for review. It is a functional piece of software. Patch, compile,
`startx`.

There are some unavoidable caveats worth mentioning.

A silicon bug scrambled the bit ordering of pixel information in the 
framebuffer. So
long as rasops requires each color's bits to be contiguous we are stuck at 
16bpp.

The USB host controller on the am335x isn't EHCI compatible and is currently
unsupported, the only direct interface with the board is via a com(4) ftdi
serial port that doesn't provide a wskbd(4) device which Xorg demands. None
of the config options that would seem to suggest allowing you to bypass this
work, but removing the xf86-input-kbd object files does (?). I'm not sure 
whether
it's appropriate to fix this in xenocara or through something like comkbd(4).

Very thrilled to finally get this working!
Ian

Index: share/man/man4/man4.armv7/amdisplay.4
===
RCS file: share/man/man4/man4.armv7/amdisplay.4
diff -N share/man/man4/man4.armv7/amdisplay.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/amdisplay.4   16 Apr 2017 03:33:08 -
@@ -0,0 +1,73 @@
+.\" Copyright (c) 2017 Ian Sutton $
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: April 2 2017 $
+.Dt AMDISPLAY 4 armv7
+.Os
+.Sh NAME
+.Nm amdisplay ,
+.Nm nxptda
+.Nd Texas Instruments AM335x LCD display driver
+.Sh SYNOPSIS
+.Nm "amdisplay* at simplebus0"
+.Nm "nxptda* at iic*"
+.Nm "wsdisplay* at amdisplay*"
+.Sh DESCRIPTION
+The
+.Nm
+driver supports the LCD controller integrated in Texas Instruments' line of
+AM335x SoCs.
+The LCDC reads a framebuffer from memory via DMA and scans it out
+at the proper frequency to suit a display (along with the nessecary
+hsync/vsync/etc signals) to a PHY transmitter.
+The BeagleBone Black uses
+NXP/Freescale's TDA19988 HDMI transmitter which is additionally supported by 
the
+.Nm nxptda
+driver.
+.Sh SEE ALSO
+.Xr intro 4 ,
+.Xr wsdisplay 4 ,
+.Xr wsfb 4
+.Sh HISTORY
+The
+.Nm
+driver does not appear in
+.Ox 6.1
+currently.
+.Sh AUTHORS
+.An -nosplit
+The
+.Nm
+driver was written by
+.An Ian Sutton Aq Mt i...@ce.gl .
+The
+.Nm nxptda
+driver was written by
+.An Oleksandr Tymoshenko Aq Mt go...@freebsd.org
+and later ported to OpenBSD.
+.Sh CAVEATS
+On the BeagleBone Black, the LCDC and onboard eMMC NAND chip share the same set
+of pads such that only one can be wired and used at a time.
+If you wish to boot from or use the onboard storage, you must disable
+.Nm
+via
+.Xr config 8
+in your kernel.
+.Pp
+Display must be attached at boot time, otherwise
+.Nm
+will fail to configure.
+Hotplugging is not supported.
+.Pp
+Only 16 bit color depth is supported due to a silicon bug.
Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -r1.71 GENERIC
--- sys/arch/armv7/conf/GENERIC 23 Jan 2017 22:43:17 -  1.71
+++ sys/arch/armv7/conf/GENERIC 16 Apr 2017 03:33:23 -
@@ -81,6 +81,9 @@ sdmmc*at ommmc?   # SD/MMC bus
 
 omehci*at fdt? # EHCI
 usb*   at omehci?
+nxptda*at iic? # TDA19988 HDMI PHY
+amdisplay* at fdt? # AM335x LCD controller
+wsdisplay* at amdisplay?
 
 # Sunxi A1x/A20 SoC
 sxiintc*   at fdt? # A1x interrupt controller
Index: sys/arch/armv7/omap/am

armv7/omap: introducing amdisplay(4) + nxptda(4)

2017-04-02 Thread Ian Sutton
This patch introduces preliminary support for the display hardware
onboard the am335x/BeagleBone Black. Included are two drivers,
amdisplay(4) and nxptda(4), which run the LCD controller and HDMI PHY
transmitter respectively. This patch follows work I've mailed to this
list found here:

https://marc.info/?t=14704720461&r=1&w=2

The code below is a complete (fourth!) rewrite. It completely and
correctly controls the hardware but still needs to be plugged into the
rest of the system (wsdisplay for syscons, wsfb for Xorg, etc.) before
it is useful. In the meantime, I feel that it is review-ready and worth
the time for a dev to look over.

Here is a demonstration of my code working where the framebuffer is
filled with entropy from arc4random_buf() every frame:

https://www.youtube.com/watch?v=yCzFyZlfbzQ

Here is the man page in HTML format for convenience:

https://ce.gl/amdisplay.4.html

Here is a link to the patch below for when the list mangles it:

https://ce.gl/amdisplay-apr2.diff.txt

Note: this driver currently only supports 640x480x16 mode, but is only
one clock/math problem away from higher modes. Yes, I am aware of fdt
simple-framebuffer node and yes, this code accomplishes useful things
which the fdt framebuffer cannot.

Ian

Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -p -u -r1.71 GENERIC
--- sys/arch/armv7/conf/GENERIC 23 Jan 2017 22:43:17 -  1.71
+++ sys/arch/armv7/conf/GENERIC 3 Apr 2017 05:24:32 -
@@ -81,6 +81,9 @@ sdmmc*at ommmc?   # SD/MMC bus
 
 omehci*at fdt? # EHCI
 usb*   at omehci?
+nxptda*at iic? # TDA19988 HDMI PHY
+amdisplay* at fdt? # AM335x LCD controller
+wsdisplay* at amdisplay?
 
 # Sunxi A1x/A20 SoC
 sxiintc*   at fdt? # A1x interrupt controller
Index: sys/arch/armv7/omap/am335x_prcmreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/am335x_prcmreg.h,v
retrieving revision 1.4
diff -u -p -p -u -r1.4 am335x_prcmreg.h
--- sys/arch/armv7/omap/am335x_prcmreg.h18 Mar 2014 07:34:17 -  
1.4
+++ sys/arch/armv7/omap/am335x_prcmreg.h3 Apr 2017 05:24:33 -
@@ -20,6 +20,7 @@
 #define AM335X_CLKCTRL_MODULEMODE_MASK 0x0003
 
 #define PRCM_AM335X_CM_PER 0x
+#define PRCM_AM335X_LCDC_CLKCTRL   0x0018
 #define PRCM_AM335X_USB0_CLKCTRL   0x001c
 #define PRCM_AM335X_TPTC0_CLKCTRL  0x0024
 #define PRCM_AM335X_MMC0_CLKCTRL   0x003c
@@ -38,6 +39,10 @@
 #define PRCM_AM335X_CM_WKUP0x0400
 #define PRCM_AM335X_GPIO0_CLKCTRL  0x0408
 #define PRCM_AM335X_TIMER0_CLKCTRL 0x0410
+#define PRCM_AM335X_DISP_IDLEST0x0448
+#define PRCM_AM335X_DISP_CLKSEL0x0454
+#define PRCM_AM335X_DISP_CLKMODE   0x0498
+#define PRCM_AM335X_DISP_M20x04a4
 #define PRCM_AM335X_I2C0_CLKCTRL   0x04b8
 #define PRCM_AM335X_CM_DPLL0x0500
 #define PRCM_AM335X_CLKSEL_TIMER2_CLK  0x0508
Index: sys/arch/armv7/omap/amdisplay.c
===
RCS file: sys/arch/armv7/omap/amdisplay.c
diff -N sys/arch/armv7/omap/amdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/omap/amdisplay.c 3 Apr 2017 05:24:33 -
@@ -0,0 +1,628 @@
+/*
+ * Copyright (c) 2016 Ian Sutton 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#ifdef LCD_DEBUG
+int lcd_dbg_thresh = 20;
+#define DPRINTF(n,s)   do { if ((n) <= lcd_dbg_thresh) printf s; } while (0)
+#else
+#define DPRINTF(n,s)   do {} while (0)
+#endif
+
+#define str(X) #X
+#define DEVNAME(_s) ((_s)->sc_dev.dv_xname)
+#define PALETTE_BPP 0x4000
+
+#define HREAD4(sc, reg)
\
+   (bus_space_read_4((sc)->sc_iot, (sc)->sc_ioh, (reg)))
+#define HWRITE4(sc, reg, val)