[U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

[Tom Rini]

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 <hdegoede at redhat.com>
> >>>>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 :-/
> >>
> >><Explictly adding Tom to the list of recipients>
> >>
> >>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: <http://lists.denx.de/pipermail/u-boot/attachments/20150602/f5ce64cc/attachment.sig>