XO 1.75 mainlining status

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

XO 1.75 mainlining status

Lubomir Rintel
In case anyone's interested, rough status of mainlining things follows.

EC: Works, passed review. Hopes for 5.2.

Battery: Queued for 5.2. Doesn't make much sense w/o the EC driver.

Camera: Works, needs some more works. May make it into 5.2.

Armada LCDC: Russel King's devel branch has things that we need and
I've sent MMP2 patches his way. I have asked him a few days ago about
his 5.2 plans, but got no response.

HiMax DCON: Needs rework.

Audio: Doesn't seem to work, haven't looked into.

Etnaviv GPU: The kernel driver seems to work; however something's wrong
with MESA (kmscube renders the background color, but not more than
that).  I understand very little about this. I also need some help;
more below:

I'm wondering how the clocks are determined for the GC860.
That should be the APMU + 0xcc register (0xd42828cc)

Sources [1] and [2] suggest that there is a multiplexer that chooses
between PLL1, PLL2 and USB PLL along with a divisor and that there are
separate bus and GPU core clocks. It is not clear to me which bits
control which clock.  The Etnaviv driver also expects another "shader"
clock for the core that executes the 3D command buffers. Apart from the
meaning of the bits set in gc800_clk_enable(), I wonder what is the
purpose of the udelay()s. I've noticed that if I just set the register
as a whole the board sometimes hangs and I'm wondering why could that
be.

[1] http://dev.laptop.org/git/olpc-kernel/tree/arch/arm/mach-mmp/include/mach/regs-apmu.h?h=arm-3.0-wip#n72
[2] http://dev.laptop.org/git/olpc-kernel/commit/arch/arm/mach-mmp/mmp2.c?h=arm-3.0-wip&id=8ce9f6122

Other: Some MMC cards that work with the OLPC kernel don't work with
mainine. In general, the class 4 cards work while faster ones don't
seem to. I haven't investigated this yet.

Lubo

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: XO 1.75 mainlining status

James Cameron-2
On Fri, Apr 19, 2019 at 04:23:28PM +0200, Lubomir Rintel wrote:
> I'm wondering how the clocks are determined for the GC860.
> That should be the APMU + 0xcc register (0xd42828cc)

Got it.

> Sources [1] and [2] suggest that there is a multiplexer that chooses
> between PLL1, PLL2 and USB PLL along with a divisor and that there are
> separate bus and GPU core clocks. It is not clear to me which bits
> control which clock.

Bit 12 is a clock select,

bits 7:6 are clock source multiplexor,

when bit 12 is 0, bits 6:7 have meaning; 0x0 selects PLL1 divided by
two, 0x1 is PLL1 divided by three, 0x2 is PLL2, 0x3 is PLL2 divided by
three.

when bit 12 is 1, bits 6:7 have meaning; 0x0 selects PLL2 divided by
four, 0x1 USB PLL, remainder reserved.

> The Etnaviv driver also expects another "shader" clock for the core
> that executes the 3D command buffers. Apart from the meaning of the
> bits set in gc800_clk_enable(), I wonder what is the purpose of the
> udelay()s. I've noticed that if I just set the register as a whole
> the board sometimes hangs and I'm wondering why could that be.

Other bits in the register let me put a story to this;

1.  the module is powered up (3<<9), and the peripheral (1<<3) and AXI
bus clocks (1<<2) are turned on, then there is a udelay(150),

2.  isolation is disabled (1<<8), and then there is a udelay(1),

3.  reset is released on the AXI2MC interface (1<<15), reset is
released on the GC controller (1<<0), and then there is a udelay(100),

4   reset is released on the GPU AXI (1<<1), and then there is a
udelay(100).

Don't know why the delays are needed, sorry.

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel