Commit a66cb3454f (ARM: OMAP: Map SRAM
later on with ioremap_exec()) moved the SRAM init to happen later
to remove a dependency to early SoC detection for map_io.
This broke booting on some boards not using Kconfig option for
OMAP_CLOCKS_SET_BY_BOOTLOADER as the dpll1 reprogramming would
cause the following error:
kernel BUG at arch/arm/plat-omap/sram.c:226!
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
Modules linked in:
CPU: 0 Not tainted (3.2.0-rc1-e3 #9)
PC is at omap_sram_reprogram_clock+0x28/0x30
LR is at omap1_select_table_rate+0x88/0xb4
pc : [<c001b0c4>] lr : [<c0019f54>] psr: 600000d3
sp : c035bf10 ip : c035bf20 fp : c035bf1c
r10: c035bfd4 r9 : 54029252 r8 : c03f8120
r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40
r3 : 00000000 r2 : c0362b40 r1 : 0000010a r0 : 00002cb0
Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 0000317f Table: 10004000 DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc035a270)
Stack: (0xc035bf10 to 0xc035c000)
bf00: c035bf3c c035bf20 c0019f54 c001b0ac
bf20: 00001000 00002cb3 00000004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc
bf40: c02f526c 00000002 00000015 bc058c9b 93111a16 c035335c 02000000 c035ed4c
bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88
bf80: c033bc24 c00194a0 c035bf90 c035bf98 00000000 00000000 00000000 00000000
bfa0: 00000001 00000000 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8
bfc0: c0338574 c033b598 00000000 00000000 00000000 c035467c 0000317d c035c03c
bfe0: c0354678 c035ece4 00000000 c035bff8 10008040 c0338508 00000000 00000000
Backtrace:
[<c001b09c>] (omap_sram_reprogram_clock+0x0/0x30) from [<c0019f54>] (omap1_select_table_rate+0x88/0xb4)
[<c0019ecc>] (omap1_select_table_rate+0x0/0xb4) from [<c033ea24>] (omap1_clk_init+0x148/0x334)
r7:c035ed4c r6:00000004 r5:00002cb3 r4:00001000
[<c033e8dc>] (omap1_clk_init+0x0/0x334) from [<c00194c4>] (omap1_init_early+0x34/0x48)
r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:02000000 r4:c035335c
[<c0019490>] (omap1_init_early+0x0/0x48) from [<c033bc24>] (setup_arch+0x69c/0x79c)
[<c033b588>] (setup_arch+0x0/0x79c) from [<c0338574>] (start_kernel+0x7c/0x2f4)
[<c03384f8>] (start_kernel+0x0/0x2f4) from [<10008040>] (0x10008040)
r7:c035ece4 r6:c0354678 r5:c035c03c r4:0000317d
Code: 0a000002 e1a0e00f e12fff13 e89da800 (e7f001f2)
Fix this by adding omap1_clk_late_init() that only reprograms dpll1
if the bootloader rate is less than 60MHz. This also allows removing
of the OMAP_CLOCKS_SET_BY_BOOTLOADER option.
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ceph_osd_request struct allocates a 40-byte buffer for object names.
RBD image names can be up to 96 chars long (100 with the .rbd suffix),
which results in the object name for the image being truncated, and a
subsequent map failure.
Increase the oid buffer in request messages, in order to avoid the
truncation.
Signed-off-by: Stratos Psomadakis <psomas@grnet.gr>
Signed-off-by: Sage Weil <sage@newdream.net>
Set up d_fsdata on the root dentry. This fixes a NULL pointer dereference
in ceph_d_prune on umount. It also means we can eventually strip out all
of the conditional checks on d_fsdata because it is now set unconditionally
(prior to setting up the d_ops).
Fix the ceph_d_prune debug print while we're here.
Signed-off-by: Sage Weil <sage@newdream.net>
If the port supports Link speeds greater than 5.0 GT/s, we must wait
for 100 ms after Link training completes before sending configuration
request.
Acked-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We need to wait for 1000 ms after Data Link Layer Link Active (DLLLA)
bit reads 1b before sending configuration request. Currently pciehp
does this wait after checking Link Training (LT) bit. But we need it
before checking LT bit because LT is still set even after DLLLA bit is
set on some platforms.
Acked-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Firmware expects 'max_ssid_length' field in
'struct mwifiex_ie_types_wildcard_ssid_params' to be '0' for
performing SSID specific scan. Currently driver updates it with
an actual SSID length. Hence UUT is not able to find the AP
configured in hidden SSID mode in scan results and association
fails.
max_ssid_length is filled with '0' to fix the issue.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The following error is seen in some case when mounting rootfs from
SD/MMC cards.
Waiting for root device /dev/mmcblk0p1...
mmc1: host does not support reading read-only switch. assuming write-enable.
mmc1: new high speed SDHC card at address b368
mmcblk0: mmc1:b368 SDC 3.74 GiB
mmcblk0: p1
mmc1: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 3678224, nr 40, cmd response 0x900, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 3678225
Buffer I/O error on device mmcblk0p1, logical block 458754
lost page write due to I/O error on mmcblk0p1
This patch fixes the problem by lowering the usdhc clock and correcting
watermark configuration.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Chris Ball <cjb@laptop.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The AUTO_ZRELADDR selection for ARCH_IMX_V4_V5 and ARCH_MX5 should
really be mutually exclusive to ZBOOT_ROM just like what ARCH_IMX_V6_V7
does.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The config symbol ARCH_MX3 has been removed by commit 'a89cf59
arm/imx: merge i.MX3 and i.MX6', and it should not be referenced
any more.
The patch also change ARCH_MX* to SOC_IMX* for other platforms.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Rename no_space_cache option to nospace_cache to be more consistent with
the rest, where the simple prefix 'no' is used to negate an option.
The option has been introduced during the -rc1 cycle and there are has not been
widely used, so it's safe.
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
The patch removes imx_idle hook and use pm_idle instead to get imx
arch_idle prepared for the cleanup. It's suggested by Russel King
as below.
> The final removal of mach/system.h depends on getting rid of the arch_idle
> thing. While going through these headers, I was dismayed to find these:
>
> arch/arm/mach-s3c2410/include/mach/system.h:void (*s3c24xx_idle)(void);
> arch/arm/plat-mxc/include/mach/system.h:extern void (*imx_idle)(void);
>
> when we have a perfectly good pm_idle hook already in place - so there's
> no excuse for these especially when other platforms are already using
> pm_idle to hook their platform specific idle function into. This is
> something that better be gone at the next merge window!
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Since commit (167a19d2: ARM: imx: Introduce generic function for displaying silicon revision)
we no longer need the chip revision strings, so remove them.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Aacraid controller can hang on some nodes if kernel uses non-default
(powersave) ASPM policy. Controller hangs shortly after successful load and
hardware detection. Scsi error handler detects this hang and tries to restart
hardware but it does not help.
Initially it was noticed on RHEL6-based openVZ kernel after backporting
aacraid driver from mainline (RHEL6 kernel with original driver works well)
http://bugzilla.openvz.org/show_bug.cgi?id=2043
This issue happens because default ASPM policy was changed in Red Hat
kernels. Therefore guys from Red Hat have noticed this problem long time ago:
on Fedora 12
https://bugzilla.redhat.com/show_bug.cgi?id=540478
on Fedora 14
https://bugzilla.redhat.com/show_bug.cgi?id=679385
In RHEL6 kernel this issue was fixed, ASPM was disabled in aacraid driver. In
kernel changelog I've found that seems it was done by Matthew Garrett: -
[scsi] aacraid: Disable ASPM by default (Matthew Garrett) [599735]
However seems this patch was not submitted to mainline. I've reproduced this
issue on vanilla 3.1.0 kernel booted with "pcie_aspm.policy=powersave" option,
So I believe it makes sense to do it now.
Signed-off-by: Vasily Averin <vvs@sw.ru>
[mjg: Checking the Windows drivers indicates that they disable ASPM under all
circumstances, so:]
Acked-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Achim Leubner <Achim_Leubner@pmc-sierra.com>
Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
On newer chips the number of clock modes per power state varies.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Avoid a lot of extra loops through the pm state array.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The new power tables need to be handled differently when setting
up the profiles.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently scrub fails with ENOMEM when bio_add_page fails. Unfortunately
dm based targets accept only one page per bio, thus making scrub always
fails. This patch just submits the current bio when an error is encountered
and starts a new one.
Signed-off-by: Arne Jansen <sensille@gmx.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
bdi_prune_sb() in bdi_unregister() attempts to removes the bdi links
from all super_blocks and then del_timer_sync() the writeback timer.
However, this can race with __mark_inode_dirty(), leading to
bdi_wakeup_thread_delayed() rearming the writeback timer on the bdi
we're unregistering, after we've called del_timer_sync().
This can end up with the bdi being freed with an active timer inside it,
as in the case of the following dump after the removal of an SD card.
Fix this by redoing the del_timer_sync() in bdi_destory().
------------[ cut here ]------------
WARNING: at /home/rabin/kernel/arm/lib/debugobjects.c:262 debug_print_object+0x9c/0xc8()
ODEBUG: free active (active state 0) object type: timer_list hint: wakeup_timer_fn+0x0/0x180
Modules linked in:
Backtrace:
[<c00109dc>] (dump_backtrace+0x0/0x110) from [<c0236e4c>] (dump_stack+0x18/0x1c)
r6:c02bc638 r5:00000106 r4:c79f5d18 r3:00000000
[<c0236e34>] (dump_stack+0x0/0x1c) from [<c0025e6c>] (warn_slowpath_common+0x54/0x6c)
[<c0025e18>] (warn_slowpath_common+0x0/0x6c) from [<c0025f28>] (warn_slowpath_fmt+0x38/0x40)
r8:20000013 r7:c780c6f0 r6:c031613c r5:c780c6f0 r4:c02b1b29
r3:00000009
[<c0025ef0>] (warn_slowpath_fmt+0x0/0x40) from [<c015eb4c>] (debug_print_object+0x9c/0xc8)
r3:c02b1b29 r2:c02bc662
[<c015eab0>] (debug_print_object+0x0/0xc8) from [<c015f574>] (debug_check_no_obj_freed+0xac/0x1dc)
r6:c7964000 r5:00000001 r4:c7964000
[<c015f4c8>] (debug_check_no_obj_freed+0x0/0x1dc) from [<c00a9e38>] (kmem_cache_free+0x88/0x1f8)
[<c00a9db0>] (kmem_cache_free+0x0/0x1f8) from [<c014286c>] (blk_release_queue+0x70/0x78)
[<c01427fc>] (blk_release_queue+0x0/0x78) from [<c015290c>] (kobject_release+0x70/0x84)
r5:c79641f0 r4:c796420c
[<c015289c>] (kobject_release+0x0/0x84) from [<c0153ce4>] (kref_put+0x68/0x80)
r7:00000083 r6:c74083d0 r5:c015289c r4:c796420c
[<c0153c7c>] (kref_put+0x0/0x80) from [<c01527d0>] (kobject_put+0x48/0x5c)
r5:c79643b4 r4:c79641f0
[<c0152788>] (kobject_put+0x0/0x5c) from [<c013ddd8>] (blk_cleanup_queue+0x68/0x74)
r4:c7964000
[<c013dd70>] (blk_cleanup_queue+0x0/0x74) from [<c01a6370>] (mmc_blk_put+0x78/0xe8)
r5:00000000 r4:c794c400
[<c01a62f8>] (mmc_blk_put+0x0/0xe8) from [<c01a64b4>] (mmc_blk_release+0x24/0x38)
r5:c794c400 r4:c0322824
[<c01a6490>] (mmc_blk_release+0x0/0x38) from [<c00de11c>] (__blkdev_put+0xe8/0x170)
r5:c78d5e00 r4:c74083c0
[<c00de034>] (__blkdev_put+0x0/0x170) from [<c00de2c0>] (blkdev_put+0x11c/0x12c)
r8:c79f5f70 r7:00000001 r6:c74083d0 r5:00000083 r4:c74083c0
r3:00000000
[<c00de1a4>] (blkdev_put+0x0/0x12c) from [<c00b0724>] (kill_block_super+0x60/0x6c)
r7:c7942300 r6:c79f4000 r5:00000083 r4:c74083c0
[<c00b06c4>] (kill_block_super+0x0/0x6c) from [<c00b0a94>] (deactivate_locked_super+0x44/0x70)
r6:c79f4000 r5:c031af64 r4:c794dc00 r3:c00b06c4
[<c00b0a50>] (deactivate_locked_super+0x0/0x70) from [<c00b1358>] (deactivate_super+0x6c/0x70)
r5:c794dc00 r4:c794dc00
[<c00b12ec>] (deactivate_super+0x0/0x70) from [<c00c88b0>] (mntput_no_expire+0x188/0x194)
r5:c794dc00 r4:c7942300
[<c00c8728>] (mntput_no_expire+0x0/0x194) from [<c00c95e0>] (sys_umount+0x2e4/0x310)
r6:c7942300 r5:00000000 r4:00000000 r3:00000000
[<c00c92fc>] (sys_umount+0x0/0x310) from [<c000d940>] (ret_fast_syscall+0x0/0x30)
---[ end trace e5c83c92ada51c76 ]---
Cc: stable@kernel.org
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
* 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: Fix bandwidth calculation for DisplayPort
drm/nouveau: by default use low bpp framebuffer on low memory cards
drm/nv10: Change the BO size threshold determining the memory placement range.
drm/nvc0: enable acceleration for nvc1 by default
drm/nvc0/gr: fixup the mmio list register writes for 0xc1
drm/nvc1: hacky workaround to fix accel issues
drm/nvc0/gr: fix some bugs in grctx generation
drm/nvc0: enable acceleration on 0xc8 by default
drm/nvc0/vram: skip disabled PBFB subunits
drm/nv40/pm: fix issues on igp chipsets, which don't have memory
drm/nouveau: testing the wrong variable
drm/nvc0/vram: storage type 0xc3 is not compressed
drm/nv50: fix stability issue on NV86.
drm/nouveau: initialize chan->fence.lock before use
drm/nv50/vram: fix incorrect detection of bank count on newer chipsets
drm/nv50/gr: typo fix, how about we not reset fifo during graph init?
drm/nv50/bios: fixup mpll programming from the init table parser
drm/nouveau: fix oops if i2c bus not found in nouveau_i2c_identify()
drm: make sure drm_vblank_init() has been called before touching vbl_lock
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious flows in the code,
to prevent "false alarms" in the future
v2: incorporate comments received from Daniel Vetter
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon_benchmark_do_move() returns an int so "time" should be int
too. Making it unsigned breaks the error handling.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vblanks between the current and the
one it is waiting for. In some cases it can block the entire windowing
system.
v2: incorporate comments received from Daniel Vetter and
Michel Daenzer.
v3/v4: after a lengty discussion with Daniel Vetter, it was concluded
that the only thing not yet protected with locks and atomic
ops is the write to dev->last_vblank_wait. It's only used in a
debug file in proc, and the current code already employs no
correct locking: the proc file only takes dev->struct_mutex,
whereas drm_wait_vblank implicitly took the drm_global_mutex.
Given all this, it's not worth bothering to try to fix
the locks at this time.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As Exynos DRM is merged at mainline. Also update the maintainer entry.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We restore the CRTC, encoder, and connector configurations, but if the
mode set failed, the attached display may have been turned off, so we
need to try set_config again to restore things to the way they were.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Can happen when there is no DP panel attached, confusing
users. Make it debug only.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
slow-work got killed in commit 181a51f6e0. This means that since v2.6.36
there is no Kconfig symbol SLOW_WORK. Apparently selecting that symbol
is a nop. Drop that select.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This hunk seems to have gotten lost when I rebased the patch.
Reported-by: Sylvain Bertrand <sylvain.bertrand@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was only the case if the GPU reset was triggered from the CS ioctl,
otherwise other processes could happily enter the CS ioctl and wreak havoc
during the GPU reset.
This is a little complicated because the GPU reset can be triggered from the
CS ioctl, in which case we're already holding the mutex, or from other call
paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't
allow recursive locking or finding out the mutex owner, so we need to handle
this with helper functions which allow recursive locking from the same
process.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Snooping code expects this to be the case.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The following commits break cpuidle on SH-Mobile ARM:
46bcfad cpuidle: Single/Global registration of idle states
e978aa7 cpuidle: Move dev->last_residency update to driver enter routine; remove dev->last_state
This patch remedies these issues by up-porting the SH-Mobile
code to fit with the above introduced framework changes.
It is worth noting that the new code becomes significantly cleaner,
so these framework changes are very welcome. At the same time this
breakage could probably have been avoided by grepping for "last_state"
and "cpuidle_register_driver".
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch moves PORT_xx helper macro to sh_pfc.h,
and it expects CPU_ALL_PORT() macro for each CPU
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch move PORT_DATA_xx helper macro to sh_pfc.h.
and pfc-sh7372.c used it
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
it is not necessary to have sh7372_xxxx index on static variable
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch adds MMC data pin pull-up option for pfc-sh73a0.c,
and select it on ag5evm board.
The MMC read/write will be error without this patch.
Cc: Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Tested-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
