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, 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 :) Regards, Hans -- 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.
