From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Thu, 12 Jun 2008 21:49:35 +0200 Subject: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB Support v2 (SDHC support part 1) References: <1213280100-26596-1-git-send-email-antonio.costa@atmel.com><1213280100-26596-2-git-send-email-antonio.costa@atmel.com><20080612183610.6e3e632b@siona.local><005801c8ccb1$1cd66730$0c0514ac@atmel.com> <20080612193101.29d3aa70@siona.local> Message-ID: <013d01c8ccd8$594cd970$0c0514ac@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Haavard Skinnemoen wrote: > On Thu, 12 Jun 2008 19:19:47 +0200 > "Ulf Samuelsson" wrote: > >> Haavard Skinnemoen wrote: >>> It's a bit hard to see what your proposal is all about when you >>> create a new file instead of modifying the exising one... >>> >> >> If you want to see changes right now, >> then just replace the existing file with the Diopsis file and do a >> diff. > > The whole idea about e-mail review is that someone posts a patch and > someone else reviews it. >>> So how about we start by introducing a new drivers/mmc directory and >>> move the existing AVR32 driver there? After that, you can apply your >>> changes to it and send a patch which clearly shows the differences >>> from the old code. Don't worry about breaking AVR32 -- I'll help you >>> test it before it gets merged upstream. >>> >> >> Why not get the Diopsis support in first, and then do the merge >> afterwards. I do agree that they should be merged, but that does not >> mean >> that delaying the availability of Diopsis support in U-Boot is a >> good idea. > > I disagree. Why do a half-assed job when you can do it properly? Some times half-assed jobs, are good enough, and if you concentrate all your efforts on one parts, then everything else suffers. Currently the Diopsis configuration does not support environment variables, and I much rather have Antonio spend time on fixing that problem, than merging the MCI support. Either by using the onboard parallel flash (which is complicated since it is 2 x 16 bit AT45BV64x chips in a by 32 configuration). I am really unsure U-boot supports this... Or figures out a way to read/write the environment from/to the SD-Card. While the duplication is unfortunate, the end user will not suffer too much compared to not having environment variables. > Besides, the merge window is closed now, isn't it? So we have lots of > time to review and test things before the next merge window. > > Haavard Best Regards Ulf Samuelsson