On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote:
> "Ong, Hean Loong" <hean.loong.ong@xxxxxxxxx> writes:
>
> >
> > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote:
> > >
> > > "Ong, Hean Loong" <hean.loong.ong@xxxxxxxxx> writes:
> > >
> > > >
> > > >
> > > > On Wed, 2017-05-03 at 13:28 -0700, Eric Anholt wrote:
> > > > >
> > > > >
> > > > > hean.loong.ong@xxxxxxxxx writes:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Ong Hean Loong <hean.loong.ong@xxxxxxxxx>
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > The new Intel Arria10 SOC FPGA devkit has a Display Port IP
> > > > > > component
> > > > > > which requires a new driver. This is a virtual driver in
> > > > > > which
> > > > > > the
> > > > > > FGPA hardware would enable the Display Port based on the
> > > > > > information
> > > > > > and data provided from the DRM frame buffer from the OS.
> > > > > > Basically
> > > > > > all
> > > > > > all information with reagrds to resolution and bits per
> > > > > > pixel
> > > > > > are
> > > > > > pre-configured on the FPGA design and these information are
> > > > > > fed
> > > > > > to
> > > > > > the driver via the device tree information as part of the
> > > > > > hardware
> > > > > > information.
> > > > > I started reviewing the code, but I want to make sure I
> > > > > understand
> > > > > what's going on:
> > > > >
> > > > > This IP core isn't displaying contents from system memory on
> > > > > some
> > > > > sort
> > > > > of actual physical display, right? It's a core that takes
> > > > > some
> > > > > input
> > > > > video stream (not described in the DT or in this driver) and
> > > > > stores
> > > > > it
> > > > > to memory?
> > > > If the IP Core you are referring to is some form of GPU then in
> > > > this
> > > > case we are using the Intel FPGA Display Port Framebuffer IP.
> > > > It
> > > > does
> > > > display contents streamed from the ARM/Linux system to the
> > > > Display
> > > > Port
> > > > of the physical Monitor.
> > > >
> > > > Below a simple illustration of the system:
> > > >
> > > > ARM/Linux --DMA-->Intel FPGA Display Port Framebuffer IP
> > > > |
> > > > |
> > > > Physical Connection
> > > > Display Port
> > > The "DMA" in this diagram is the frame reader IP, right? The
> > > frame
> > > reader, as described in the spec, sounds approximately like a DRM
> > > plane,
> > > so if you have that in your system then that needs to be part of
> > > this
> > > DRM driver (otherwise you won't be putting the right things on
> > > the
> > > screen!).
> > Would the drm_simple_display_pipe_init be able to handle this ? It
> > seems to be displaying the proper images on screen, based on my
> > current
> > changes. There were recommendations to use the
> > drm_simple_display_pipe_init instead of creating the CRTC and
> > planes
> > myself
> The docs I've read for the Frame Buffer IP don't fit into any current
> DRM component, since it's what we're currently calling a "writeback
> connector".
>
While running my own test (since the intel-gpu-tools doesn't seems
applicable.) The drm_simple_display_pipe_init seems to be simple enough
for displaying a matchbox console. The use case for this driver is only
part of the enablemennt of the reference design board so that users of
the Arria10 devkit can use this as base for their own designs.
> I don't understand your system enough to answer. You didn't answer
> if
> the "DMA" block you diagrammed was the frame reader IP (or maybe the
> frame reader IP comes after). I also don't see how the frame buffer
> IP
> could possibly be connected directly to a physical display connector.
The FPGA FrameBuffer 2 soft IP reads the information provided to it
from the Linux Kernel via the platform device register provided in the
DT. The Linux driver here allocates a chunk of coherent memory that
directly maps to the SDRAM. The FPGA soft IP would stream the display
out to the Display Port based on the information that was written to
the SDRAM.
The FrameBuffer 2 IP or previously used Frame Reader IP are soft IP is
programmed as part of the FPGA which is connected to the Display Port
via a native physical transceiver. The Soft IP are driven by the NIOS 2
soft core which is also the soft processor.
Note however whatever that goes beyond the the memory bus (between ARM
and FPGA) known as Avalon is no longer under the control of the Linux
Driver (as we only establish connection on the ARM side)
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
