From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Wed, 11 Jul 2012 11:52:13 +0200 Subject: [U-Boot] FDT driver initialization function declaration In-Reply-To: <201207101512.30389.marex@denx.de> References: <4FFC02BD.7060106@monstr.eu> <4FFC1EF8.9060705@monstr.eu> <20120710130331.854362026C4@gemini.denx.de> <201207101512.30389.marex@denx.de> Message-ID: <4FFD4CCD.2080204@monstr.eu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/10/2012 03:12 PM, Marek Vasut wrote: > Dear Wolfgang Denk, > >> Dear Michal Simek, >> >> In message<4FFC1EF8.9060705@monstr.eu> you wrote: >>> The hardest part I have identify on microblaze was about u-boot >>> variables. Because based on information from device-tree you can choose >>> where variables should be stored and also this memory should be >>> accessible before u-boot try to read variables. It mean in very early >>> state. >> >> Device initialization before relocation is already hard enough; > > +1 > >> resources are very limited then. > > And we'll be introducing the early mallocator. This is where MPC85x will blow my > mind :) (I'm repeating myself here, but it might help getting others unaware of > the DM work better in line). > >> You will add the additional need to >> have the FDT library available then, too. Not to mention that you >> need to load the DT blob, too. > > DT blob can be read from ROM if that was the problem. The DT library and parser > might be an issue. > >> This will be a lot of added complexity. > > And therefore slowing down the boot. But I believe it can be optimized to > leverage this to some point. Though I'm not quite sure how much. This is worthy > investigation. > > Michal, can you try investigating how will the DT probing intertwine with the > DM? I have read your documentation and there are some things I would like to discuss. UDM-design.txt How do you want to distinguish between early drivers(console/memory) and common drivers? struct driver: - for device-tree support there must be any pointer to matching table defined in every device driver. - struct driver *cores[array] - can you please clear this usage? For example for any device on spi/i2c bus. What cores will depends on it? All SPI/I2C devices/device-drivers, just one, which one? Isn't it better to do it by priorities I mentioned above? struct driver_info - Where do you want to fill the platform_data? Because for current u-boot configuration style this will be setup statically and for device-tree dynamically. probe function require struct instance as parameter and how is it passed that platform data from struct driver_info which probably contains information required for probing - like address and other parameters required for configuration. For device-tree all these options should be selected at run time. It means remove all ifdefs from drivers which of course increase u-boot binary size. UDM-cores.txt about driver cores initialization at runtime. Do you need to initialized all driver cores at early-init stage? Or just that crucial one? I am missing how you want to pass driver configuration data(addresses, settings) to the driver. I expect that this must be done out of device drivers. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian