U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig
Date: Tue, 2 Jun 2015 09:35:57 -0400	[thread overview]
Message-ID: <20150602133557.GN1728@bill-the-cat> (raw)
In-Reply-To: <556D5649.1020801@redhat.com>

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@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>

  reply	other threads:[~2015-06-02 13:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-01 15:01 [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig Hans de Goede
2015-06-01 18:12 ` Ian Campbell
2015-06-01 18:19   ` Hans de Goede
2015-06-01 20:46     ` Tom Rini
2015-06-02  7:07       ` Hans de Goede
2015-06-02 13:35         ` Tom Rini [this message]
2015-06-03  7:49         ` Ian Campbell
2015-06-03  8:15           ` Hans de Goede
2015-06-03 12:52           ` Tom Rini
2015-06-03 14:09             ` Hans de Goede
2015-06-03 19:08               ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150602133557.GN1728@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox