rk2918 support

Tue Oct 7 01:11:58 PDT 2014

On Mon, 2014-10-06 at 15:25 +0100, Steven Newbury wrote:
> 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.
> 
That repo really is in a random state.  The rk29 support is 
interesting to say the least!  I've cleaned up the gpio code to make 
it consistent with the other rk platform code, that compiles fine now, 
though as yet untested.  I've run into quite a few probably bit-rot 
build bugs which must have been there for some time!  It doesn't seem 
like anybody has tried building rk29 from that tree.

I decided I'd finish up what I'd started, at least it should give me 
(hopefully) a working kernel to play with other than the stock 3.0.8 
version; which is too old to really be all that useful.  

I think it's definitely been worthwhile.  A lot of the drivers are 
going to have to be forward ported, so they're at least moving in the 
right direction.  I've come to realise, while very feature similar, 
just how different the rk2918 is to the later rk SoCs, even the 
rk2928.  As far as I can tell, even the memory controller is 
different.  Does anybody have register level documentation?

I've managed to fix nearly everything now, at least to the state where 
it compiles.  Once I'm done, I'm going to start porting the rk29 
specific drivers to the current kernel.

The USB Rockchip dwc OTG driver was restructured to utilise platform 
info and add support or newer SoCs along the way, and completely lost 
support for older SoCs, unfortunately, and I think unintentionally, 
including rk2918.  I say unintentionally, since there are still a few 
left-over "#ifdef CONFIG_ARCH_RK29".  I'm attempting to fix this.

Does the new Rockchip code have USB support yet?  Does it use an 
existing driver?  From grepping the device tree, I can only see USB 
mentioned for rk3288.  Is there a new driver pending?

I started having a look at creating rk2918/rk2906 dts files, there's 
probably too many differences to use a common compatible platform.

> > 
> > > 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?
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

-------------- 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/20141007/2cfefd11/attachment.sig>