On Thu, 16 Oct 2014 10:23:42 +0200 Hans de Goede <[email protected]> wrote:
> Hi, > > On 10/16/2014 12:44 AM, Julian Calaby wrote: > > Hi Hans, > > > > On Wed, Oct 15, 2014 at 9:04 PM, Hans de Goede <[email protected]> wrote: > >> Hi, > >> > >> On 10/14/2014 11:25 PM, Siarhei Siamashka wrote: > >>> On Mon, 13 Oct 2014 13:10:28 +0200 > >>> Hans de Goede <[email protected]> wrote: > >>> > >>>> Hi, > >>>> > >>>> On 10/04/2014 07:53 AM, Siarhei Siamashka wrote: > >>>>> When PLL5P is used as a parent clock for some of the peripherals, > >>>>> the current code just selects some hardcoded divisors. This happens > >>>>> to work, but only under assumption that the PLL5P clock speed is > >>>>> somewhere between 360MHz and 480MHz (the typical DRAM clock speeds). > >>>>> > >>>>> However with some tweaks for the DRAM parameters, it is possible to > >>>>> clock DRAM up to 600MHz and more on some devices: > >>>>> > >>>>> http://lists.denx.de/pipermail/u-boot/2014-July/183981.html > >>>>> > >>>>> And this introduces concerns about the hardcoded divisors in the > >>>>> kernel, which may cause some peripherals to operate at abnormally > >>>>> high clock speeds if the PLL5 clock speed is too fast (PLL5 is used > >>>>> for clocking DRAM). > >>>>> > >>>>> Moreover, it makes sense to avoid pre-dividing PLL5P and make it run > >>>>> even faster than DRAM. This provides better granularity of the clock > >>>>> speed selection for MBUS, G2D and everything else that is using PLL5P > >>>>> as the parent clock. but running PLL5P faster means that the hardcoded > >>>>> divisors become even more inappropriate. > >>>>> > >>>>> This patch improves the clock divisors selection for G2D, ACE and > >>>>> DEBE to insure that they can work correctly with any PLL5P clock > >>>>> speed. > >>>>> > >>>>> Signed-off-by: Siarhei Siamashka <[email protected]> > >>>> > >>>> Looks good: > >>>> > >>>> Acked-by: Hans de Goede <[email protected]> > >>>> > >>>> Can we please get this merged, > >>> > >>> You know the rules. Every patch needs to be approved by at least one > >>> person other than the submitter. > >>> > >>> Thanks for the review. Pushed to stage/sunxi-3.4 > >>> > >>>> I'm working on getting the sunxi-3.4 kernels to work with upstream > >>>> u-boot, so that we can stop maintaining our own fork, > >>>> and this is necessary for this. > >>> > >>> I hope we don't get in each other's way with this stuff. > >> > >> I hope so too :) > >> > >> I'm actually more or less done now, I've just send out 2 sunxi-3.4 patches > >> (which are quite similar to your 2, but for slightly different areas), > >> which completes my sunxi-3.4 work. > >> > >> With these patches the 3.4 kernels will work on sun4i / sun5i with > >> an unmodified upstream u-boot. Still I've decided to revert your > >> PLL5 changes in upstream u-boot (for now) as I really want people to > >> be able to run unmodified android kernels on the upstream u-boot. > >> > >> My main reason for this is that I want to take away any reasons > >> people may have to keep using the linux-sunxi/u-boot-sunxi u-boot "fork", > >> so that we can focus all u-boot work upstream. > > > > I assume this means that u-boot-sunxi is going away (or at least only > > being kept for historical reasons) > > > > A couple of quick questions: > > > > 1. What happens to all the device memory info / configuration we have > > in our "fork" of u-boot? I assume that'll all have to get ported > > across at some point. (I don't have the code in front of me so if this > > has already happened, then please ignore this) > > Yeah that needs to be ported over my plan is to first get upstream u-boot > in a state where it can run unmodified android kernels, Do you mean the kernels from the Allwinner SDK? > and then send a > mail to ask people to submit their board configs upstream. Upstream we > would like to have per board contact-persons (who actually own the board), > so blindly copy and pasting is undesirable. In the end we may end up just > copying the last few boards without having a contact person for them. > > > 2. I produced a script to detect duplicate dram_*.c files, will this > > be useful upstream? > > In the end we want to move to devicetree and have the dram timings in > devicetree. So I don't think having this in the tree is a good idea, > running it every now and then on the upstream code OTOH is a very good > idea :) Adding libfdt bloat to SPL? There is just no extra space to waste. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
