rk2918 support

[Steven Newbury]

On Mon, 2014-10-06 at 15:58 +0200, Heiko Stübner wrote:
> Am Montag, 6. Oktober 2014, 14:14:36 schrieb Steven Newbury:
> > Is there anything Cortex-A9 specific in the new Rockchip support?
> > Should a mach-rockchip kernel boot on my rk2918 (Cortex-A8), or 
> > should
> > I be looking at making it a separate "mach-rk29" as the original 
> > port
> > did?
> 
> Depends on if you want to have it in the mainline kernel or want to 
> keep it
> outside :-)
Absolutely want it in mainline! :)


>  . Also there shouldn't even be more in any new mach-X than is in
> mach-rockchip currently. Meaning the only thing that should be added 
> there is
> the "rockchip,rk2918" compatible string in rockchip.c

Okay, that's what I thought.  It seems the "generic" branch was 
somewhat moving torwards that goal, the various Rockchip mach-X have a 
common plat-rk, except rk2918 got left out, which is what I'm working 
on correcting at the moment.

> 
> 
> > I'm thinking I'll only going to put in the pieces to make it work 
> > with
> > my board, since I can't test anything else, unless somebody with 
> > the
> > hw wants to volunteer to test it?  I'm not sure whether I should 
> > port
> > the rk29sdk as the machine with my board as a variant, as the 
> > original
> > port did, or just create a port for my machine, maybe that will 
> > become
> > obvious as I dig into device-tree?
> 
> I'm not sure I understand you here. Nowadays the _only_ board-
> specific part is
> the rk2918-foo.dts devicetree file describing the actual board. The 
> rest is not
> supposed to have any board-specific code.
> 
As I said, I need to dig into devicetree, the last time I did any 
serious hacking in this area was with the Sharp Zaurus...

> The sane approach would still be:
> - debug serial
> - pinctrl
> - clock
> - any device drivers that need adapting

I'm probably deluding myself hoping to get away without using a debug 
serial.  Hopefully, I can get a console tty through the USB if I need 
to get a debug console.

Pinctrl and clock info seems to be easily extractable.  As I said, 
I've been cleaning up the vendor changes, so I think I know where 
everything is now.
> 
> But whatever you do, don't invest to much time in drivers, that 
> already have
> an equivalent in the kernel.
> 
> 
Yes, that's probably a good point.  I could spend a lot of time 
cleaning up the old port, but that is a complete dead-end.  The only 
useful thing is it gives me a better idea of what I'm working with 
(which I'm fairly clear about now), and possibly a kernel to use until 
the DRM driver supports Vivante GPUs...

... on that point, I'm still not entirely clear about the relationship 
between the video hardware and GPU in Rockchip SoCs.  The "etnaviv" 
Mesa driver can use any of the various "vivante" kernel drivers as 
appeared as blobs with different Android kernels (all use a common HAL 
approach with pre-compiled objects, although sources have been since 
released).  But the Rockchip kernel had an fbdev driver covering all 
SoCs, as I understand.  So what does the new DRM/KMS driver need to 
do, if anything to allow "etnaviv" to use the GPU?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20141006/e2dd106a/attachment.sig>