All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.