| Age | Commit message (Collapse) | Author |
|---|
|
defined(@array) is deprecated in Perl and gives off a warning.
Restructure the code to remove that warning.
[ hpa: it would be interesting to revert to the timeconst.bc script.
It appears that the failures reported by akpm during testing of
that script was due to a known broken version of make, not a problem
with bc. The Makefile rules could probably be restructured to avoid
the make bug, or it is probably old enough that it doesn't matter. ]
Reported-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@vger.kernel.org>
(cherry picked from commit 63a3f603413ffe82ad775f2d62a5afff87fd94a0)
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
kconfig symbols"
This reverts commit 0b206b99b8b7c27e70fb91bc13e2255cb0cfeb28.
Unfortunately there is no CONFIG_AUDIO_SGTL5000_TEGRA!
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
Various Tegra HS UART backports
Signed-off-by: Mitja Spes <mitja@lxnav.com>
|
|
Fix HS UART HW buffer overrun issue when using no flow control
Signed-off-by: Mitja Spes <mitja@lxnav.com>
|
|
According to multi-touch-protocol.txt the kernel knows two type of
devices:
- Type A: devices which provide anonymous contacts
- Type B: devices which are capable of tracking individual contacts
The Fusion touch screen is a Type B device: The Touch ID field allows
to differentiate between 2 different fingers. This updates the driver
to properly allocate a slot for each identified contact and use the
helper functions available from the input core system.
(cherry picked from commit 698d0a9bb80d94adef58122717c61f55dd61e22d)
|
|
Use level triggered interrupt which makes sure that even we miss a
rising edge (due to latencies in the kernel), the interrupt still
will be handled later, and doesn't freeze the input device.
(cherry picked from commit ef25b8a9f9c0ca7cc0f0f955d89d112c3e19f75b)
|
|
Turns out the Tegra 3 USB PHY driver had some hard coded dependency on
the Tegra OTG driver but we usually just use our own OTG driver purely
relying on a cable detect GPIO to determine USB device vs. host role.
|
|
symbols
Signed-off-by: Tobias Klauser <tobias.klauser@zhinst.com>
|
|
sscanf() stops at first space it encounters, thus spaces are not represented
i.e. in iManufacturer or iProduct. Fix this by using strlcpy for string
attributes.
[ZI: Backported from upstream android gadget driver]
Signed-off-by: Tobias Klauser <tobias.klauser@zhinst.com>
|
|
Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.
As some of the other features like BKOPs/Cache/Sanitize are dependent on
HPI feature, those features would also get disabled if HPI is disabled.
Change-Id: I6a638ce089cbd977122e47aecb721bc3f0adf7b0
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Fix ported from the following Android MSM kernel commit:
https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/?id=84af3731019921a28d595dbf6cbf00539706a42c
|
|
It is fully legal for a controller to start handling busy-end interrupt
before it has signaled that the command has completed. So make sure
we do things in the proper order, Or it results that command interrupt
is ignored so it can cause unexpected operations. This is founded at some
toshiba emmc with the bellow warning.
"mmc0: Got command interrupt 0x00000001 even though
no command operation was in progress."
This issue has been also reported by Youssef TRIKI:
It is not specific to Toshiba devices, and happens with eMMC devices
as well as SD card which support Auto-CMD12 rather than CMD23.
Also, similar patch is submitted by:
Gwendal Grignou <gwendal@chromium.org>
Changes since v1:
Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git
and Tested if issue is fixed again.
Signed-off-by: Hankyung Yu <hankyung.yu@lge.com>
Signed-off-by: Chanho Min <chanho.min@lge.com>
Tested-by: Youssef TRIKI <youssef.triki@st.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit e99783a45220a2c5f5a598e0e81213ecf2dbcf2f)
|
|
When we wait for busy after sending a command, if there is
a timeout, we got SDHCI_INT_DATA_TIMEOUT flags.
Before this commit we got the message :
"Got data interrupt 0x00100000 even though no data operation was in progress."
and we need to wait 10s that sdhci_timeout_timer expires.
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit c5abd5e8998e20c2e82999670a03f26f1437d744)
|
|
We don't need to change the SDHCI_SDIO_IRQ_ENABLED flag when we're
merely receiving an interrupt - IRQ handling thread in the MMC core
will either re-enable or disable the interrupt via the enable_sdio_irq
callback, which will update this status appropriately.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
(cherry picked from commit ef104333a234f66cd13fd16632086a21b90fced6)
|
|
sdhci interrupt handling is a mess; there is a lot of code doing very
similar things. Let's clean this up a bit:
1. set's clear down cmd, data and bus power interrupts in one go - we're
always going to handle these.
2. use a do { } while () loop for looping while there are pending
interrupts.
3. group clearing of bits in intmask into one place.
This results in the code becoming simpler and easier to read.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
(cherry picked from commit 41005003bcaf4ecfc80e02af01247f2670269816)
|
|
When using MSI it is possible that a new MSI is sent while an earlier
MSI is currently handled. In this case SDHCI_INT_STATUS only contains
SDHCI_INT_RESPONSE and the ISR would not be called again. But at the end
of the ISR SDHCI_INT_DATA_END is now also pending which would be ignored.
Fix this by rereading the interrupt flags in the ISR until no interrupt
we care is pending.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 6379b2375a0c5a6ad437616a4018e6b8fd95e97c)
|
|
Ths patch allows runtime PM for sdhci-pci, runtime suspending after
inactivity of 50ms and ensuring runtime resume before SDHC registers
are accessed. During runtime suspend, interrupts are masked.
The host controller state is restored at runtime resume.
For Medfield, the host controller's card detect mechanism is
supplanted by an always-on GPIO which provides for card detect wake-up.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 66fd8ad5100b5003046aa744a4f12fa31bb831f9)
|
|
Unfortunately that utmi_phy_remotewake_detected() function gets called
one too many times even quite continuously during data transfers and
putting an mdelay() in there has a rather adverse effect on the overall
system performance including of course degrading USB transfer speeds.
Moving the system lock-up avoidance hack further down into the if
clause improves the performance again as this typically is only ever
evaluated once upon actually plugging something in behind a hub.
This fixes a performance regression introduced by the following commit:
apalis/colibri_t30: usb: fix low-speed issue hack
629b91fa046df5213ed3312d2e2b8683e6bdd70c
|
|
Add a comment about DAP FS pin mux requiring INPUT when operating as I2S slave.
Add a comment about DAP SCLK requiring INPUT even when operating as I2S master.
Add a comment about is_i2s_master in the platform data meaning T30 SoC is I2S
master.
|
|
A customer reported rare boot lock-ups every odd 500 software reboot
cycle. This patch removes the display clock initialisation from the
early clock initialisation as the boot loader anyway already
initialised the same.
|
|
Revise Ethernet MAC address assignment: should now handle up to two
instances of custom user MACs (2nd one with a 0x100000 offset). This
way customer does not have to worry about NVM on a secondary Ethernet
on the carrier board and still gets a valid official MAC address from
us (e.g. analogous to how we did it on our Protea carrier board).
Please note that instead of defaulting to the default ASIX MAC address
if no valid one is encountered this driver now generates a random one
pre-fixed with the ASIX OUI.
|
|
Integrate latest ASIX proprietary driver version 4.17.0
(AX88772C_772B_772A_760_772_178_LINUX_DRIVER_v4.17.0_Source.tar.bz2).
|
|
Integrate OV5640 CSI camera sensor support.
|
|
|
|
It looks like our crystal load capacitance is way off as we just copied
NVIDIA's default setting being the lowest possible 1.5 pF due to their
boards having 20 pF external caps while our hardware does not have any
external caps assembled and we should use the highest 12.5 pF setting.
|
|
On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound to happen
5 seconds after the end of a playback.
The SMALL_POP bit should fix this, but its definition is incorrect:
according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not
bit 1.
Fix the definition accordingly and enable the bit as intended per the code
comment.
After applying this change, no loud 'click' sound is heard after playback
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
(cherry picked from commit c251ea7bd7a04f1f2575467e0de76e803cf59149)
|
|
CHRGPUMP_POWERUP
The SGTL5000_CHIP_ANA_POWER register is cached. Update the cached
value instead of writing it directly.
Upstream-status: sent
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
(cherry picked from commit 309abdeda8c9331013f25b1a1209d9ce8334237b)
(cherry picked from commit 8a8b303a7431e66a7ec6ec52bc0e04ed0a1335d0)
|
|
Bring the kernel module configuration more in line with what we
currently really deploy. As a second step we can then change the way
kernel modules are actually deployed by just deploying them all.
|
|
Calculate the number of words in a transfer properly: if there are
129-131 bytes, then number of words is more than 32, therefore the
transfer should be handled with DMA rather than FIFO.
|
|
|
|
On Tegra30, on a high CPU load or operating at maximum frequency results
in continous interrupt generation, with the following log spewout:
(tegra_w1_irq: line 236) spurious interrupt, status = 0x800
(tegra_w1_irq: line 236) spurious interrupt, status = 0x800
(tegra_w1_irq: line 236) spurious interrupt, status = 0x800
(tegra_w1_irq: line 236) spurious interrupt, status = 0x800
which shows the TX_FIFO_DATA_REQ to be somehow continously being set. To
circumvent this specifically detect the bit transfer and presence done
IRQ's only, for generating a "completion" signal on which the core logic
waits. We anyhow only wait for these interrupts in particular. While at
it, also change the error message to be printed only if it is
conditionally enabled instead of all the time, which floods the serial
console and allows a wrong interpretation of the one wire device not
working at all.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
|
|
On Tegra3 at high CPU load, for example while running stress, reading
data from one wire results in the following stack trace:
[ 58.436052] [<c05e93d4>] (__raw_spin_lock_irqsave+0x3c/0xac) from
[<c05e945c>] (_raw_spin_lock_irqsave+0x18/0x1c)
[ 58.446322] [<c05e945c>] (_raw_spin_lock_irqsave+0x18/0x1c) from
[<c0048eb4>] (complete+0x28/0x64)
[ 58.455276] [<c0048eb4>] (complete+0x28/0x64) from [<c03e276c>]
(tegra_w1_irq+0x74/0xb4)
[ 58.463376] [<c03e276c>] (tegra_w1_irq+0x74/0xb4) from [<c009a1fc>]
(handle_irq_event_percpu+0x9c/0x278)
[ 58.472847] [<c009a1fc>] (handle_irq_event_percpu+0x9c/0x278) from
[<c009a424>] (handle_irq_event+0x4c/0x6c)
[ 58.482666] [<c009a424>] (handle_irq_event+0x4c/0x6c) from
[<c009cc40>] (handle_fasteoi_irq+0xe0/0x118)
[ 58.492048] [<c009cc40>] (handle_fasteoi_irq+0xe0/0x118) from
[<c0099bd8>] (generic_handle_irq+0x30/0x40)
[ 58.501616] [<c0099bd8>] (generic_handle_irq+0x30/0x40) from
[<c000ecfc>] (handle_IRQ+0x88/0xc8)
[ 58.510393] [<c000ecfc>] (handle_IRQ+0x88/0xc8) from [<c0008430>]
(asm_do_IRQ+0x18/0x1c)
[ 58.518475] [<c0008430>] (asm_do_IRQ+0x18/0x1c) from [<c000e098>]
(__irq_usr+0x38/0xc0)
[ 58.526464] Exception stack(0xe51a3fb0 to 0xe51a3ff8)
[ 58.531506] 3fa0: 00000000
bea29b04 4030b1b0 4030b4c8
[ 58.539673] 3fc0: 4030b22c 4fd2f305 0000d770 0000d6b0 00000000
00000001 0000000d 00000145
[ 58.547839] 3fe0: 193c62ce bea29af4 4030b22c 4020beb4 600b0010
ffffffff
[ 58.554445] Code: e5843004 e10f0000 f10c0080 e3a02001 (e1953f9f)
[ 58.560539] ---[ end trace fb2fc83ceb8e95c1 ]---
[ 58.565154] Kernel panic - not syncing: Fatal exception in interrupt
[ 58.571520] [<c0014ef4>] (unwind_backtrace+0x0/0xec) from
[<c05e10c8>] (dump_stack+0x20/0x24)
[ 58.580039] [<c05e10c8>] (dump_stack+0x20/0x24) from [<c05e16a0>]
(panic+0x7c/0x1ac)
[ 58.587783] [<c05e16a0>] (panic+0x7c/0x1ac) from [<c0012038>]
(die+0x280/0x2e8)
[ 58.595087] [<c0012038>] (die+0x280/0x2e8) from [<c05e1130>]
(__do_kernel_fault.part.3+0x64/0x84)
[ 58.603952] [<c05e1130>] (__do_kernel_fault.part.3+0x64/0x84) from
[<c0015c84>] (do_page_fault+0x204/0x21c)
[ 58.613681] [<c0015c84>] (do_page_fault+0x204/0x21c) from
[<c000830c>] (do_DataAbort+0x44/0xa8)
[ 58.622369] [<c000830c>] (do_DataAbort+0x44/0xa8) from [<c000de18>]
(__dabt_svc+0x38/0x60)
This seems to be generated due a possible race condition between the on
stack kernel completion being set to NULL in tegra_w1_touch_bit, while a
possible spurious IRQ calling this completion in the IRQ handler. This
is a temporary bandaid and the ideal solution would be to find why this
affects the Tegra3 and not Tegra2.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
|
|
CONFIG_SATA_AHCI=m
This allows using PCIe cards with a SATA interface.
|
|
As NVIDIA so far was unable to provide us with any proper speedo
numbers for their industrial temperature aka IT parts just make SKU
0xB0 aka T30IQS-Ax behave identical to the regular commercial
temperature 0xB1 aka T30MQS-Ax for the SKU to speedo ID conversion.
This prevents them to fall back to fixed 600 MHz operation and crashing
thermal throttling once kicking in due to missing table entry causing a
null pointer exception.
|
|
Springville/i211 with a blank Flash/iNVM use different PCI IDs. Extend
the driver to load despite i210/i211 data sheets claiming tools only,
not for driver.
Only warn rather than fail on NVM validation failures on Apalis T30.
Revise Ethernet MAC address assignment: should now handle up to two
instances of custom user MACs (2nd one with a 0x100000 offset). This
way customer does not have to worry about NVM on a secondary Ethernet
on the carrier board and still gets a valid official MAC address from
us (e.g. analogous to how we did it on our Protea carrier board).
Use the Toradex OUI as default MAC address if no valid one is
encountered.
Tested on samples of Apalis T30 2GB V1.0B, V1.0C, V1.1A, Apalis T30 1GB
V1.0A, V1.1A and Apalis T30 1GB IT V1.1A both with blank NVMs as well
as iNVMs programmed with Intel's defaults.
|
|
Springville/i211 with a blank Flash/iNVM use a different PCI ID (tools
only, not for driver) than properly programmed ones.
While at it also fix ethtool time stamping as well as RX flow hash
indirection functionality.
|
|
Integrate latest igb driver version 5.2.17
(igb-5.2.17.tar.gz from e1000.sf.net).
|
|
|
|
Conflicts:
drivers/mtd/ubi/ubi.h
drivers/mtd/ubi/wl.c
|
|
Enable module versioning support (CONFIG_MODVERSIONS and
CONFIG_MODULE_SRCVERSION_ALL) which allows using kernel modules across
different kernel builds/versions.
While at it also update the Android configurations.
|
|
|
|
|
|
|
|
This reverts commit bdf9e11d339ebc121e80e7ecdd44e0abcaf4ff38.
|
|
When commands timeout, previously we had code to
retry the same command 3 times. But under some
situations 3 retries do not suffice. Increasing
the retries to 10 does the trick. Also if the card
does not respond after 10 retries then the card is
dead for sure. But if the same card responds in
between 3 to 10 retries then it is always beneficial
to have retries as 10.
Bug 914934
Change-Id: I6b1e95c10ca5a62dde84ce8cacbe53ad2197ab33
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: http://git-master/r/72092
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Pavan Kunapuli <pkunapuli@nvidia.com>
(cherry picked from commit c4beda3e798ed91e1dadbce4206b407832fcc40b)
|
|
If the data commands fail due to some error, retry the transfer.
Add 3 retries for data commands.
for bug 914934
Change-Id: I53245ddd159abdbade09f841d9490d2f106e7c88
Signed-off-by: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Signed-off-by: Pavan Kunapuli <pkunapuli@nvidia.com>
Reviewed-on: http://git-master/r/71181
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Varun Wadekar <vwadekar@nvidia.com>
(cherry picked from commit fd804ee58d3f9ce10cb2fe16aa76ae0407912d32)
|
|
Add tracepoints to record the start and end of each mmc block
operation. This includes read, write, erase, secure erase,
trim, secure trim1 and secure trim 2, discard and
sanitize commands.
Change-Id: Ic5d1cbdb9adb940d8b1a2a13c73970023575df50
Signed-off-by: Ken Sumrall <ksumrall@android.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Conflicts:
drivers/mmc/card/block.c
drivers/mmc/core/core.c
(cherry picked from commit 4de9a433c26e47d9b4a93105eb92935321100786)
|
|
Support discard feature if MID field in the CID register is 0x15, EXT.CSD[192]
(device version) is 5 and Bit 0 in the EXT.CSD[64] is 1. Also removed REQ_SECURE flag
check to avoid kernel hang.
This patch is released from samsung.
Change-Id: I4023a900680e9bca10c40311b09ed077a22617db
(cherry picked from commit 4acc227edfb631d377e14911287c1b73682fc9c2)
Conflicts:
drivers/mmc/card/block.c
|
|
Change-Id: Ia56018522e5d18ca5bfd25858ec943da93d3edc3
(cherry picked from commit e363e576f448d6132340c5d0bda580fef212888d)
Conflicts:
drivers/mmc/host/sdhci-tegra.c
|
|
Change-Id: I46e3f1a158d61a0b255fae5d510c8f87579c435d
Reviewed-on: http://mcrd1-5.corpnet.asus/code-review/master/47847
Reviewed-by: Kirt Hsieh <Kirt_Hsieh@asus.com>
Tested-by: Kirt Hsieh <Kirt_Hsieh@asus.com>
Reviewed-by: Vincent Yue <Vincent_Yue@asus.com>
Reviewed-on: http://mcrd1-5.corpnet.asus/code-review/master/48199
Reviewed-by: Jim1 Lin <jim1_lin@asus.com>
Tested-by: Jim1 Lin <jim1_lin@asus.com>
Reviewed-by: Leslie Yu <Leslie_Yu@asus.com>
(cherry picked from commit 8eadc6d514b7838c398ff3499ab5f2e012e2fc06)
Conflicts:
drivers/mmc/host/sdhci.c
|
|
Change-Id: I40a8481618b1a5995a713ff343c7532badd20b65
Change-Id: I399302118c9d8d8246a4a304ff7a1ea80889dbc6
Reviewed-on: http://mcrd1-5.corpnet.asus/code-review/master/45568
Reviewed-by: Ban Feng <Ban_Feng@asus.com>
Tested-by: Ban Feng <Ban_Feng@asus.com>
Reviewed-by: Sam hblee <Sam_hblee@asus.com>
(cherry picked from commit 121c0c6dffe16c683f4dbf00ed841fb4de1f70a0)
Conflicts:
drivers/mmc/core/mmc.c
|
