Hi, On 10/16/2014 12:14 PM, Siarhei Siamashka wrote: > 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?
Preferably yes, not sure how doable that is, at a minimum we should support the linux-sunxi-3.4 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 :) > > Adding libfdt bloat to SPL? There is just no extra space to waste. This is something which still needs to be hashed out, one idea is to still have per board spl binaries, and do the fdt parsing build-time. 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.
