Now as we have removed the last user (pandora_wl1251_init_card)
of this callback, we can remove it from the hsmmc code.
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The OMAP HSMMC driver has some elaborate and hairy handling for
passing GPIO card detect and write protect lines from a boardfile
into the driver: the machine defines a struct omap2_hsmmc_info
that is copied into struct omap_hsmmc_platform_data by
omap_hsmmc_pdata_init() in arch/arm/mach-omap2/hsmmc.c.
However the .gpio_cd and .gpio_wp fields are not copied from
omap2_hsmmc_info to omap_hsmmc_platform_data by
omap_hsmmc_pdata_init() so they remain unused. The only platform
defining omap2_hsmmc_info also define both to -1, unused.
It turn out there are no boardfiles passing any valid GPIO
lines into the OMAP HSMMC driver at all. And since we are not
going to add any more OMAP2 boardfiles, we can delete this
card detect and write protect handling altogether.
This seems to also fix a bug: the card detect callback
mmc_gpio_get_cd() in the slot GPIO core needs to be called
by drivers utilizing slot GPIO. It appears the the boardfile
quirks were not doing this right, so this would only get
called for boardfiles, i.e. since no boardfile was using it,
never.
Just assign mmc_gpio_get_cd() unconditionally to omap_hsmmc_ops
.get_cd() so card detects from the device tree works.
AFAICT card detect with GPIO lines assigned from
mmc_of_parse() are not working at the moment, but that is
no regression since it probably never worked.
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Cover detection appears to be a feature protecting the SD
card on mobile phones with a slide-cover, such as some Nokia
phones. The idea seems to be to not allow access to the
SD card when the cover is open.
It is only usable with platform data from board files, but
no board file in the kernel is using it, yet it takes up
a sizeable chunk of code in the OMAP HSMMC driver.
Since we do not add new board files for the OMAPs any target
that need this should anyway reimplement it properly using
the device tree, so delete this legacy code.
The driver is marked as orphan in MAINTAINERS by the way.
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
support for new dra762 SoC. The other changes are are for legacy
DMA code removal, and MMC quirk and iodelay config for dra7.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAlmTIokRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXPLXw//bdosInQAgxNoRHOeXt8B8U4kmHrWVHIj
DDuuY2Vh5/DBUbXFizpWi2O7LrzXOFMw3zWLzRnZsA56/sNlojwW70NV4J/KGHVa
tmVQ12iEV+blLdt9rypoUgHT4XFtYZ8WEfo4XPjDB23DhPcRYgRikn0O0LqvUV2r
nPMemfhGc/E1SIN/hGFUG7AqL3N+TPlFhmzZRLYsrbWECnSr17dpIgYbSD7Dviiq
PuSd8jbj88ugPjtUjb6CXyV04o2uRcxFqHceJOghc0jQtARxJBxCzInMLZ4JPPH5
ZBRNKfervmpc4b24Vmlf+23t2iMieOHpqrSvfYy1ErBzyWFgOF32w2kkqbBWO+oB
TLd02DdX5ks3bnG6C5fVDk4ztSB6vUO8K+MatdDGnqbAc8f+RRUmYVDE35TTfyHK
QcjG8fkC3sze3iO+Jlg6UPO8uGYXYN7wVxm6oJqnQ5R1gVSXTbt2LEDNuKy3usxR
IkvkdjkVOei4pYrewgc7bkNLOQ+XMY1Mxy0G/XwoEG9SlCVcEi4N0Vn9LptgJRph
Mm3kpb3E93U8qUCR0NnXCpMqrek4foSoOKGcOFFukvSWF67xvnoUbooIIzEtXh/R
9K5ftL1XlgPzYcQEWEp3MT7q4FkgKSpDup+8eHOUH+ozhWi3n4umlm3FzqiT3vXM
ADACrqr8CgM=
=FBGl
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.14/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/soc
Pull "soc changes for omaps for v4.14" from Tony Lindgren:
SoC updates for omaps for v4.14. Most of the chages are to add
support for new dra762 SoC. The other changes are are for legacy
DMA code removal, and MMC quirk and iodelay config for dra7.
* tag 'omap-for-v4.14/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP: dra7: powerdomain data: Register SoC specific powerdomains
ARM: dra762: Enable SMP for dra762
ARM: dra7: hwmod: Register dra76x specific hwmod
ARM: dra762: Add support for device identification
ARM: OMAP2+: board-generic: add support for dra762 family
ARM: OMAP2+: Select PINCTRL_TI_IODELAY for SOC_DRA7XX
ARM: OMAP2+: Add pdata-quirks for MMC/SD on DRA74x EVM
ARM: OMAP2+: Remove unused legacy code for DMA
DRA74x EVM Rev H EVM comes with revision 2.0 silicon.
However, earlier versions of EVM can come with either
revision 1.1 or revision 1.0 of silicon.
The device-tree file is written to support rev 2.0 of
silicon. pdata quirks are used to then override the
settings needed for PG 1.1 silicon.
PG 1.1 silicon has limitations w.r.t frequencies at
which MMC1/2/3 can operate as well as different IOdelay
numbers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Remove unused callbacks in the omap_hsmmc_platform_data structure
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
board-rx51 has no card detect pin in the mmc slot, but can detect that
the (cell-phone) cover has been removed and the card is accessible.
The semantics between cover/card detect differ, the gpio on the slot
informs you after the card has been removed, cover removal does not
necessarily mean that the card has been removed.
This means different code paths are necessary. To complete this we
also want different fields in the platform data for cover and card
detect. This separation is not pushed all the way down into struct
omap2_hsmmc_info which is used to initialize the platform data.
If we did that we had to go over all board files and set the new
gpio_cod pin to -EINVAL. If we forget one board or some out-of-tree
archicture forgets that the default '0' is used which is a valid pin
number.
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
omap_hsmmc only supports one slot. So slot id is always zero, and
slot id was never used in the callbacks anyway
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
These callbacks are set during driver probe and not from the platform
init, -- evtl. they had been for oamp 1/2 -- for omap3 they are local
functions of the driver. These indirection could be dropped
altogether in favor of regular function calls TODO
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
omap_hsmmc supports only one slot per controller, see OMAP_MMC_MAX_SLOTS.
This unnecessary indirection leads to confusion in the omap_hsmmc driver.
For example the card_detect callback is not installed by platform code
but from the driver probe function. So it should be a field of
omap_hsmmc_host. But since it is declared under the platform slot while
the drivers struct omap_hsmmc_host has no slot abstraction, this looks
like a bug, especially when not familiar that this driver only supports
1 slot anyway.
Either we should add a slot abstraction to omap_hsmmc_host or remove
it from the platform data struct. Removed since slot multiplexing is
an un-implemented feature
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
trigger of this callback has been removed in 0a82e06e61
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
these callbacks are not set, probably legacy omap 1/2 features
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
platform data is built from omap2_hsmmc_info, remove all fields that
are never set in omap_hsmmc_info, hence never copied to platform data.
Note that the omap_hsmmc driver is not affected by this patch those
fields were completely unused.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
- omap mmc driver supports multiplexing, omap_mmc_hs doesn't
this leads to one of the major confusions in the omap_hsmmc driver
- platform data should be read-only for the driver
most callbacks are not set by the omap3 platform init code while still
required. So they are set from the driver probe function, which is against
the paradigm that platform-data should not be modified by the driver
typical examples are card_detect, read_only callbacks
un-bundling by searching for driver name \"omap_hsmmc in the
arch/arm folder. omap_hsmmc_platform_data is not initialized directly,
but from omap2_hsmmc_info, which is defined in a separate header file
not touched by this patch
hwmod includes platform headers to declare features of the platform. All
the declared features are prefixed OMAP_HSMMC. There is no need to
include platform header from hwmod other except for feature defines
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
