From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 2 Jun 2015 09:35:57 -0400 Subject: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig In-Reply-To: <556D5649.1020801@redhat.com> References: <1433170917-13601-1-git-send-email-hdegoede@redhat.com> <1433182346.5748.285.camel@hellion.org.uk> <556CA22B.6010708@redhat.com> <20150601204652.GG1728@bill-the-cat> <556D5649.1020801@redhat.com> Message-ID: <20150602133557.GN1728@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Jun 02, 2015 at 09:07:53AM +0200, Hans de Goede wrote: > Hi, > > On 01-06-15 22:46, Tom Rini wrote: > >On Mon, Jun 01, 2015 at 08:19:23PM +0200, Hans de Goede wrote: > >>Hi, > >> > >>On 01-06-15 20:12, Ian Campbell wrote: > >>>On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote: > >>>>The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been > >>>>using the same defconfig (and dts on the kernel side) for both models. > >>>>Unfortunately this does not work for the otg controller, on the M9 this > >>>>is routed to a micro-usb connector on the outside, while as on the > >>>>A1000G-quad it is connected to an usb to sata bridge. > >>>> > >>>>This commit adds a new defconfig for the Mele-A1000G-quad to allow using > >>>>different otg controller settings on the 2 boards. > >>>> > >>>>Signed-off-by: Hans de Goede > >>>>diff --git a/configs/Mele_A1000G_quad_defconfig b/configs/Mele_A1000G_quad_defconfig > >>>>new file mode 100644 > >>>>index 0000000..b93dcf5 > >>>>--- /dev/null > >>>>+++ b/configs/Mele_A1000G_quad_defconfig > >>>>@@ -0,0 +1,24 @@ > >>>>+# The Mele A1000G quad is yet another Allwinnner based Android top set box > >>>>+# from Mele. > >>>>+# > >>>>+# It uses the same case as the original Mele A1000 and the same PCB as the M9, > >>>>+# the USM sata storage slot is connected via anusb to sata bridge connected to > >>>>+# the otg controller, this renders the micro USB B receptacle non functional. > >>>>+# > >>>>+# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out, > >>>>+# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif, > >>>>+# RTL R8188EU (USB) wifi and a full size sdcard slot > >>> > >>>Have you seen the thread "Clean all defconfigs with savedefconfig" which > >>>we were copied on today? It seems that these comments are subject to > >>>automated cleansing :-/ > >> > >> > >> > >>Tom, do we really want some autofoobar tool to mangle our defconfigs? Is there > >>a way we can opt out of this ? > >> > >>Reasons to opt out: > >> > >>1) Having comments like the one above on top of the defconfig files makes > >>it much easier for people to check if they are selecting the right defconfig > >> > >>2) We deliberately duplicate some settings in defconfig files even though > >>they are the default since new users submitting new boards tend to copy and > >>paste an existing defconfig of a similar board and this way they have a short > >>list of settings to check against the actual board, because their board may > >>not be using the reference design pins which we use as defaults ... > >> > >>So personally as sunxi maintainer I would like to opt out of this automatic > >>destruction of useful info in our defconfigs ... > > > >So, historically people have put a lot of odds and ends info into either > >include/configs/board.h or boards/vendor/board/board.c. With Kconfig > >we're moving away from the former and with things like sunxi where we > >just slightly tweak some parameters to run on many boards we don't have > >the latter the question is where to place otherwise generally useful > >info. > > > >The problem, to expand on what I said in the other thread, is that > >*_defconfig is treated as an auto-generated file in Kbuild projects (I > >know the kernel and I'm pretty sure elsewhere too). This is only going > >to get more noticable as we convert things over to real Kconfig choices, > >meaning that if we opt-out of changing sunxi configs they're going to > >get broken or make the conversion harder for everyone else. > > > >We should be able to add say board/sunxi/README.txt and keep it > >formatted such that new entries go on the bottom and have a predefined > >separator at the end so that adding more boards doesn't conflict. > > If we stuff everything in one file people need to match which board > description belongs to which defconfig manually at which point > we might just as well point them to the linux-sunxi.org wiki > which has all this info + actual pictures of the devices. > > So if there is no way to store this info in the defconfigs lets > just leave it out and will point people to the wiki. Yes, wiki it is then, thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: