Hello. On Mon, 2007-12-10 at 23:02, Daniel Ribeiro wrote: > > Stefan Schmidt wrote: > > o Split it into one patch with start.S, Kconfig, Makefile, header > > files and ezx.c plus dedicated patches for each phone. Later with > > Kconfig, Makefile and phone c file. > Good.
OK, settled. > > o Cleanup the header files. Do we need ezx.h? All of it? Where to put > > the defines? > I think that ezx.h is not needed. Almost all the defines are GPIO > assignments, and probably none of them are being used by ezx-core.patch > code. Oh, I never tried if it is needed at all for ezx-core. :) Bagging this out, even if we have to define some GPIO elsewhere, makes it much cleaner for now. > > o The change to head.S makes me worry a bit without ifdefs. What else > > do we break here? > We should not submit this to mainline. I think it is best to fix the > bootloader. > Adding a line of code to blob solves it, but (unless you flash the > bootloader) enforces the chained booting. The changes to head-xscale.S > are unnecessary too if we do this on blob code. Hmm, this brings the burden of not being able to boot a kernel on an unmodifed device. I would really like to see it possible that one get a supported EZX device, compile a vanilla kernel with the defconfig and being able to just boot_usb it for some first tests. ON the other hand it will never go mainline if it is to ugly anyway. :) So the solution would be to move these parts over in a separate patch for the time being and work on the changes in the bootloader? Would be fine with me as long as we will not break it to long during the transition. > > o For what did we need the changes in uncompress.h? Perhaps also a > > problem without ifdef > The first changes the UART output for the decompressor, the second > disables it (much faster boot in case nothing is connected). I think > that these changes should not go mainline, and a clean solution for > disabling the decompressor UART output should be proposed. Move also to the to-ugly-for-upstream-but still-needed.patch > > o When submitting this patches as RFC to the arm kernel ml we should > > also ask about how we should handle the different phones with regards > > to the machine registry. I would prefer to discuss this with some > > code in the back instead of a theoretical discussion. > > Did I miss something? Comments? > I think we should remove ezx.c, and move the code to the ezx-phone.c files. OK > And i believe that we should try to submit code for one phone model > initially and submit the other phones after the PCAP driver, this will > show some differences and justify a discussion on how to handle the > registry thing. That will definitely give us stronger arguments in this discussion, indeed. The cost is the delay from some more code until pcap driver is ready. Personally I have no clue when that could happen, not even a wild guess. How is your feeling about that one? Just some known bugs that needs to get fixed or still a lot of black magic we don't know about? If we go this way, with which phone should we start? As A780/E680 is the most supported devices I would lean towards them. The zImage would boot on both devices then. I have scheduled some hours to work on this at wednesday. If somebody beat me, great. ;) That would also include a test against something like 2.6.24-rc4 to see if we get any fallout with mainline changes. regards Stefan Schmidt
signature.asc
Description: Digital signature
