Up until now we had ARC PGU not enabled in axs10x defconfigs trying
to not bloat kernel image again with yet another drivers and subsystems.

This change configures ARC PGU (as well as DRM bits it depends on)
to be built as a module and so those who need LCD screen to work on
axs10x may bundle built .ko files in their target's file-system with
help of the following command on host:
------------->8-------------
make INSTALL_MOD_PATH=_path_to_target_fs_ modules_install
------------->8-------------

and later on target with commands as simple as:
------------->8-------------
modprobe adv7511.ko
modprobe arcpgu.ko
------------->8-------------
get LCD working.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

As mentioned in LTP's README.ARC:
------------->8------------
 Requirements for the environment

* Linux must be built with support of loop block devices. Thus it's
  necessary to enable these Linux kernel options:
  CONFIG_BLK_DEV
  CONFIG_BLK_DEV_LOOP
------------->8------------
enabling loop block devices.

That among other things lead to additional 10 fatal signals
appearing during LTP run.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

The problem is with CONFIG_CPU_BIG_ENDIAN=y we still needed .config
fixup to override the the defconfig prefix to arceb-linux-

So remove these from defconfig and let user pass this via CROSS_COMPILE
environment var or use the default for ENDIAN (per previous patch)

No other arch carries them in defconfigs anyways !

Cc: Noam Camus <noamc@ezchip.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synosys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Even though DEVTMPFS is required when our pre-built initramfs
is used it is not the case in general. It is perfectly possible
to use initramfs with device nodes already populated or there
could be other usages, see discussion below for more detials:
http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/37819/focus=37821

This change removes mentioned dependency from arch/arc/Kconfig
updating instead those defconfigs that are usually used with this
kind of pre-build initramfs.

And while at it all touched defconfigs were regenerated via
savedefconfig and some options were removed:
 * USB is selected by other options implicitly
 * VGA_CONSOLE is disableb for ARC since
   031e29b5
 * EXT3_FS automatically selects EXT4_FS
 * MTDxxx and JFFS2_FS make no sense for AXS because
   AXS NAND controller is not upstreamed
 * NET_OSCI_LAN is not in upstream as well
 * ARCPGU_xxx options make no sense because ARC PGU is not yet
   in upstream and when it gets there all config options would
   be taken from devicetree
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

When building kernel with buildroot built toolchain, CROSS_COMPILE
currently needs adjustment even if minor. This is because the defconfigs
prefer "arc-linux-uclibc-" prefix from hand built (non buildroot) toolchain
while buildroot provides "arc-buildroot-linux-uclibc-"

To avoid this use the common "arc-linux-" prefix which is provided by
buildroot and has also been in hand built tools for quite some time.
Signed-off-by: Nsujayraaj <sujayraaj@gmail.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
[vgupta: updated changelog]

DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

The AXS10x platforms consist of a mainboard with peripherals,
on which several daughter cards can be placed. The daughter cards
typically contain a CPU and memory.
Signed-off-by: NMischa Jonker <mjonker@synopsys.com>
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>