On 10/7/20 7:53 AM, Dmitry Osipenko wrote:
> 07.10.2020 16:36, Bob Ham пишет:
>> Hi all,
>>
>> The Bluetooth controller driver sent to linux-input by Lukas Rusak
>> (CC'd) is a bit of a concern. Here is the original driver:
>>
>> https://github.com/ouya/ouya_1_1-kernel/blob/master/drivers/hid/hid-
On 5/13/20 4:41 AM, Mian Yousaf Kaukab wrote:
> On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote:
>> On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
>>> Add documentation for the new optional flag added for SRAM driver.
>>
>>> diff --git a/Docum
On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
> Add documentation for the new optional flag added for SRAM driver.
> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml
> b/Documentation/devicetree/bindings/sram/sram.yaml
> + reserved-only:
> +description:
> + The flag indica
. What I wonder here is that
> processor is speculating on an address range which kernel has never accessed.
> Is it correct behavior that cpu is speculating in EL1/EL2 on an address
> accessed in EL3?
That is indeed the way the ARM architecture is defined (at least the
version that t
On 9/30/19 4:02 AM, Mian Yousaf Kaukab wrote:
On Sun, Sep 29, 2019 at 11:28:43PM -0600, Stephen Warren wrote:
On 9/29/19 2:08 PM, Mian Yousaf Kaukab wrote:
Most of the SysRAM is secure and only accessible by TF-A.
Don't map this inaccessible memory in kernel. Only map pages
used by bpmp d
On 9/29/19 2:08 PM, Mian Yousaf Kaukab wrote:
> Most of the SysRAM is secure and only accessible by TF-A.
> Don't map this inaccessible memory in kernel. Only map pages
> used by bpmp driver.
I don't believe this change is correct. The actual patch doesn't
implement mapping a subset of the RAM (a
also result in a proper hardware description
in the code.
I'm now also vaguely recalling that Stephen Warren had some kind of a "code
generator"
for the pinctrl drivers. So I guess all those tables were auto-generated
initially.
Stephen, maybe you could adjust the generator to t
On 1/16/19 9:32 AM, Vincent Whitchurch wrote:
The Virtio-over-PCIe framework living under drivers/misc/mic/vop implements a
generic framework to use virtio between two Linux systems, given shared memory
and a couple of interrupts. It does not actually require the Intel MIC
hardware, x86-64, or e
On 10/21/18 2:54 PM, Dmitry Osipenko wrote:
Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts
b/arch/arm/boot/dts/tegra20-harmony.dts
- sm0 {
+
mc call implementations e.g. in qcom_scm-32.c and
bcm_kona_smc.c.
Cc: Dmitry Osipenko
Cc: Stephen Warren
Cc: Thierry Reding
Signed-off-by: Stefan Agner
---
Changes in v2:
- Keep stmfd/ldmfd to avoid potential ABI issues
arch/arm/firmware/trusted_foundations.c | 14 +-
1 fi
On 03/21/2018 09:26 AM, Dmitry Osipenko wrote:
On 21.03.2018 17:09, Stefan Agner wrote:
On 21.03.2018 13:13, Robin Murphy wrote:
On 20/03/18 23:02, Stefan Agner wrote:
As documented in GCC naked functions should only use Basic asm
syntax. The Extended asm or mixture of Basic asm and "C" code i
On 02/22/2018 04:04 PM, Marcel Ziswiler wrote:
Turns out latest upstream U-Boot does not configure/enable pllu which
leaves it at some default rate of 500 kHz:
I assume this is only because U-Boot just happened not to access any USB
devices. In other words, if you break into the U-Boot boot fl
On 02/21/2018 09:20 AM, Tomasz Maciej Nowak wrote:
W dniu 20.02.2018 o 20:55, Stephen Warren pisze:
On 02/19/2018 01:16 PM, Tomasz Maciej Nowak wrote:
Adds device nodes for two front panel LEDs.
Why do you need to change the pinmux settings? Configuring a pin as a
GPIO should override any
On 02/19/2018 01:16 PM, Tomasz Maciej Nowak wrote:
Adds device nodes for two front panel LEDs.
Why do you need to change the pinmux settings? Configuring a pin as a
GPIO should override any pinmux special function selection and hence
make it irrelevant, so I don't think you should need to cha
On 10/03/2017 04:32 AM, Jon Hunter wrote:
On 03/10/17 00:02, Dmitry Osipenko wrote:
On 02.10.2017 20:05, Stephen Warren wrote:
On 09/29/2017 09:11 PM, Dmitry Osipenko wrote:
On 29.09.2017 22:30, Stephen Warren wrote:
On 09/27/2017 02:34 AM, Jon Hunter wrote:
On 27/09/17 02:57, Dmitry
On 09/29/2017 09:11 PM, Dmitry Osipenko wrote:
On 29.09.2017 22:30, Stephen Warren wrote:
On 09/27/2017 02:34 AM, Jon Hunter wrote:
On 27/09/17 02:57, Dmitry Osipenko wrote:
On 26.09.2017 17:50, Jon Hunter wrote:
On 26/09/17 00:22, Dmitry Osipenko wrote:
Document DT bindings for NVIDIA
On 09/27/2017 02:34 AM, Jon Hunter wrote:
On 27/09/17 02:57, Dmitry Osipenko wrote:
On 26.09.2017 17:50, Jon Hunter wrote:
On 26/09/17 00:22, Dmitry Osipenko wrote:
Document DT bindings for NVIDIA Tegra AHB DMA controller that presents
on Tegra20/30 SoC's.
Signed-off-by: Dmitry Osipenko
--
On 09/25/2017 05:45 PM, Dmitry Osipenko wrote:
> On 26.09.2017 02:01, Stephen Warren wrote:
>> On 09/25/2017 04:15 PM, Dmitry Osipenko wrote:
>>> Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of
>>> video formats like H.264 / MPEG-4 / WMV / VC1
On 09/25/2017 04:15 PM, Dmitry Osipenko wrote:
Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of
video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports
decoding of CAVLC H.264 only.
Note: I don't know anything much about video decoding on Tegra (just NV
d
From: Stephen Warren
When the gadget serial device has no associated TTY, do not pass any
received data into the TTY layer for processing; simply drop it instead.
This prevents the TTY layer from calling back into the gadget serial
driver, which will then crash in e.g. gs_write_room() due to
On 08/02/2017 11:19 PM, Peter Rosin wrote:
On 2017-08-03 00:50, Stephen Warren wrote:
On 08/02/2017 03:25 PM, Peter Rosin wrote:
(and muxc->max_adapters == num_names)
Well, unless muxc->deselect is true...
No, deselect does not affect neither max_adapters nor num_names. They
are
On 08/02/2017 03:25 PM, Peter Rosin wrote:
On 2017-08-02 21:06, Stephen Warren wrote:
On 08/02/2017 01:27 AM, Peter Rosin wrote:
The information is available elsewhere.
diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c
b/drivers/i2c/muxes/i2c-mux-pinctrl.c
static int
excluded the idle state (if present) from the child bus count passed to
i2c_mux_alloc(), which was aided by the fact that it parsed the DT
before calling i2c_mux_alloc().
If those two things are OK, then:
Reviewed-by: Stephen Warren
i < num_names - !!muxc->deselect; i++) {
I think that "num_names - !!muxc->deselect" could just be
muxc->num_adapters? Otherwise,
Reviewed-by: Stephen Warren
On 05/31/2017 10:28 AM, Phil Elwell wrote:
On 31/05/2017 16:58, Stefan Wahren wrote:
Am 31.05.2017 um 17:27 schrieb Stephen Warren:
On 05/30/2017 06:23 AM, Phil Elwell wrote:
Hi,
I've run into a problem using the fixed-factor clock on Raspberry Pi
and I'd
like some advice before
On 05/30/2017 06:23 AM, Phil Elwell wrote:
Hi,
I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd
like some advice before I submit a patch.
Some context: the aim is to use a standard UART and some external circuitry
as a MIDI interface. This would be straightforward ex
On 05/22/2017 02:24 AM, Peter Rosin wrote:
Hi Stephen,
I was looking at the i2c-mux-pinctrl driver and noticed that it has
code to feed it platform data from C code. There has never been any
in-kernel users of this interface and I would like to remove it. I
wonder if you added it way back when j
On 05/07/2017 12:12 PM, Paul Kocialkowski wrote:
Hi,
Le mardi 25 avril 2017 à 10:57 -0600, Stephen Warren a écrit :
On 04/24/2017 12:41 PM, Paul Kocialkowski wrote:
Le lundi 24 avril 2017 à 09:35 -0600, Stephen Warren a écrit :
On 04/24/2017 09:07 AM, Paul Kocialkowski wrote:
Le mercredi 19
On 04/24/2017 12:41 PM, Paul Kocialkowski wrote:
Le lundi 24 avril 2017 à 09:35 -0600, Stephen Warren a écrit :
On 04/24/2017 09:07 AM, Paul Kocialkowski wrote:
Le mercredi 19 avril 2017 à 16:00 -0600, Stephen Warren a écrit :
On 04/18/2017 10:38 AM, Paul Kocialkowski wrote:
Le mardi 18
On 04/24/2017 09:07 AM, Paul Kocialkowski wrote:
Le mercredi 19 avril 2017 à 16:00 -0600, Stephen Warren a écrit :
On 04/18/2017 10:38 AM, Paul Kocialkowski wrote:
Le mardi 18 avril 2017 à 10:15 -0600, Stephen Warren a écrit :
On 04/18/2017 09:11 AM, Paul Kocialkowski wrote:
This selects the
On 04/18/2017 10:38 AM, Paul Kocialkowski wrote:
Le mardi 18 avril 2017 à 10:15 -0600, Stephen Warren a écrit :
On 04/18/2017 09:11 AM, Paul Kocialkowski wrote:
This selects the tegra30 i2s and ahub controllers for the tegra124 SoC.
These are needed when building without ARCH_TEGRA_3x_SOC set
On 04/18/2017 09:11 AM, Paul Kocialkowski wrote:
This selects the tegra30 i2s and ahub controllers for the tegra124 SoC.
These are needed when building without ARCH_TEGRA_3x_SOC set.
diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig
index efbe8d4c019e..bcd18d2cf7a7 100644
--- a/so
On 03/09/2017 01:51 PM, Scott Branden wrote:
Hi Julia,
On 17-03-09 12:36 PM, Julia Lawall wrote:
Hello,
I discussed the issue of outreachy patches for bcm with Greg, and we are
not convinced that not having the patches CCd to you is such a good idea.
While we don't want to spam you with noise,
On 03/09/2017 12:42 PM, Thierry Reding wrote:
On Mon, Feb 27, 2017 at 12:09:02PM +0200, Mikko Perttunen wrote:
On 23.02.2017 19:24, Thierry Reding wrote:
From: Thierry Reding
Program the receive queue size based on the RX FIFO size and enable
hardware flow control for large FIFOs.
diff --g
On 01/31/2017 12:48 PM, Eric Anholt wrote:
I've been maintaining the bcm2835 branches here for a year or so.
Acked-by: Stephen Warren
On 12/15/2016 05:21 AM, Peter Rosin wrote:
The ACOK pin on the bq24735 is active-high, of course meaning that when
AC is OK the pin is high. However, all Tegra dts files have incorrectly
specified active-high even though the signal is inverted on the Tegra
boards. This has worked since the Linux
On 11/02/2016 04:48 AM, Suresh Mangipudi wrote:
Add GPIO driver for T186 based platforms.
Adds support for MAIN and AON GPIO's from T186.
I'm not sure how you/Thierry will approach merging this with the other
GPIO driver he has, but here's a very quick review of this one in case
it's useful.
On 11/08/2016 08:55 AM, Thierry Reding wrote:
On Mon, Nov 07, 2016 at 05:42:33PM -0800, Olof Johansson wrote:
On Mon, Nov 7, 2016 at 5:21 AM, Thierry Reding wrote:
On Mon, Nov 07, 2016 at 08:53:37AM +0100, Linus Walleij wrote:
On Wed, Nov 2, 2016 at 11:48 AM, Suresh Mangipudi wrote:
Add GP
On 10/27/2016 10:52 AM, Eric Anholt wrote:
From: Linus Walleij
The idea is to give useful names to GPIO lines that an implementer
will be using from userspace, e.g. for maker type projects. These are
user-visible using tools/gpio/lsgpio.c
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +
On 09/26/2016 12:42 PM, Stefan Wahren wrote:
Stephen Warren hat am 26. September 2016 um 18:38
geschrieben:
On 09/23/2016 12:39 PM, Stefan Wahren wrote:
Hi Eric,
Eric Anholt hat am 19. September 2016 um 18:13
geschrieben:
The RPi firmware exposes all of the board's GPIO lines th
On 09/23/2016 07:15 AM, Eric Anholt wrote:
Linus Walleij writes:
On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt wrote:
This driver will be used for accessing the FXL6408 GPIO exander on the
Pi3. We can't drive it directly from Linux because the firmware is
continuously polling one of the exp
On 09/23/2016 07:08 AM, Eric Anholt wrote:
Linus Walleij writes:
On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt wrote:
The RPi firmware exposes all of the board's GPIO lines through
property calls. Linux chooses to control most lines directly through
the pinctrl driver, but for the FXL6408 G
On 09/23/2016 12:39 PM, Stefan Wahren wrote:
Hi Eric,
Eric Anholt hat am 19. September 2016 um 18:13 geschrieben:
The RPi firmware exposes all of the board's GPIO lines through
property calls. Linux chooses to control most lines directly through
the pinctrl driver, but for the FXL6408 GPIO
On 09/06/2016 04:57 AM, Mark Rutland wrote:
On Tue, Sep 06, 2016 at 06:20:48PM +0800, Jisheng Zhang wrote:
Hi Mark,
On Tue, 6 Sep 2016 11:22:08 +0100 Mark Rutland wrote:
On Tue, Sep 06, 2016 at 04:55:55PM +0800, Jisheng Zhang wrote:
This patch fixes the following DTC warning with W=1:
"Node
On 08/26/2016 10:38 AM, Jon Hunter wrote:
On 26/08/16 16:55, Stephen Warren wrote:
On 08/26/2016 07:09 AM, Jon Hunter wrote:
On Tegra124/132 the pins for I2C6 are shared with the Display Port AUX
(DPAUX) channel and on Tegra210 the pins for I2C4 and I2C6 are shared
with DPAUX1 and DPAUX0
On 08/26/2016 07:09 AM, Jon Hunter wrote:
On Tegra124/132 the pins for I2C6 are shared with the Display Port AUX
(DPAUX) channel and on Tegra210 the pins for I2C4 and I2C6 are shared
with DPAUX1 and DPAUX0, respectively. The multiplexing of the pins is
handled by a register in the DPAUX and so th
On 07/29/2016 12:40 AM, Josh Triplett wrote:
I'd like to announce a project I've been working on for a while:
git-series provides a tool for managing patch series with git, tracking
the "history of history". git series tracks changes to the patch series
over time, including rebases and other non
the BPMP firmware driver,
which can create the interprocessor communication (IPC) between the CPU
and BPMP.
Acked-by: Stephen Warren
interprocessor communication (IPC)
protocols can use hardware synchronization primitive, when operating
between two processors not in an SMP relationship.
Acked-by: Stephen Warren
A couple of nits below that you might want to fix up when posting the
final version of the series; your call.
diff
On 07/11/2016 10:08 AM, Stephen Warren wrote:
On 07/11/2016 08:14 AM, Rob Herring wrote:
On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote:
On 07/07/2016 12:13 PM, Sivaram Nair wrote:
On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote:
Add DT binding for the Hardware
On 07/18/2016 01:44 AM, Joseph Lo wrote:
Hi Rob,
Thanks for your reviewing.
On 07/12/2016 12:05 AM, Stephen Warren wrote:
On 07/11/2016 08:22 AM, Rob Herring wrote:
On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote:
The BPMP is a specific processor in Tegra chip, which is designed
On 07/15/2016 03:37 AM, Ralf Ramsauer wrote:
On 07/15/2016 12:02 AM, Thierry Reding wrote:
On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
specification inside the dts is wrong. Fix it and use the correct
address
On 07/05/2016 03:04 AM, Joseph Lo wrote:
The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management, clock
management, and reset control tasks from the CPU. The binding document
defines the resources that would be used by the
On 07/11/2016 08:14 AM, Rob Herring wrote:
On Thu, Jul 07, 2016 at 12:35:02PM -0600, Stephen Warren wrote:
On 07/07/2016 12:13 PM, Sivaram Nair wrote:
On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote:
Add DT binding for the Hardware Synchronization Primitives (HSP). The
HSP is
On 07/11/2016 08:22 AM, Rob Herring wrote:
On Tue, Jul 05, 2016 at 05:04:24PM +0800, Joseph Lo wrote:
The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management, clock
management, and reset control tasks from the CPU. The bi
On 07/07/2016 04:18 AM, Alexandre Courbot wrote:
On Thu, Jul 7, 2016 at 5:17 PM, Joseph Lo wrote:
On 07/06/2016 07:39 PM, Alexandre Courbot wrote:
Sorry, I will probably need to do several passes on this one to
understand everything, but here is what I can say after a first look:
On Tue, Jul
On 07/07/2016 12:13 PM, Sivaram Nair wrote:
On Tue, Jul 05, 2016 at 05:04:22PM +0800, Joseph Lo wrote:
Add DT binding for the Hardware Synchronization Primitives (HSP). The
HSP is designed for the processors to share resources and communicate
together. It provides a set of hardware synchronizati
interprocessor communication (IPC)
protocols can use hardware synchronization primitive, when operating
between two processors not in an SMP relationship.
Acked-by: Stephen Warren
the BPMP firmware driver,
which can create the interprocessor communication (IPC) between the CPU
and BPMP.
Acked-by: Stephen Warren
On 07/06/2016 03:06 AM, Joseph Lo wrote:
On 07/06/2016 03:05 PM, Alexandre Courbot wrote:
On Tue, Jul 5, 2016 at 6:04 PM, Joseph Lo wrote:
The Tegra HSP mailbox driver implements the signaling doorbell-based
interprocessor communication (IPC) for remote processors currently. The
HSP HW modules
On 07/06/2016 05:39 AM, Alexandre Courbot wrote:
Sorry, I will probably need to do several passes on this one to
understand everything, but here is what I can say after a first look:
On Tue, Jul 5, 2016 at 6:04 PM, Joseph Lo wrote:
The Tegra BPMP (Boot and Power Management Processor) is design
On 06/30/2016 03:25 AM, Joseph Lo wrote:
On 06/29/2016 11:28 PM, Stephen Warren wrote:
On 06/28/2016 11:56 PM, Joseph Lo wrote:
On 06/29/2016 03:08 AM, Stephen Warren wrote:
On 06/28/2016 03:15 AM, Joseph Lo wrote:
On 06/27/2016 11:55 PM, Stephen Warren wrote:
On 06/27/2016 03:02 AM, Joseph
On 06/28/2016 11:56 PM, Joseph Lo wrote:
On 06/29/2016 03:08 AM, Stephen Warren wrote:
On 06/28/2016 03:15 AM, Joseph Lo wrote:
On 06/27/2016 11:55 PM, Stephen Warren wrote:
On 06/27/2016 03:02 AM, Joseph Lo wrote:
snip.
Currently the usage of HSP HW in the downstream kernel is something
On 06/28/2016 03:15 AM, Joseph Lo wrote:
On 06/27/2016 11:55 PM, Stephen Warren wrote:
On 06/27/2016 03:02 AM, Joseph Lo wrote:
Add DT binding for the Hardware Synchronization Primitives (HSP). The
HSP is designed for the processors to share resources and communicate
together. It provides a
On 06/27/2016 03:02 AM, Joseph Lo wrote:
The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management tasks
from the CPU. The binding document defines the resources that would be
used by the BPMP firmware driver, which can crea
On 06/27/2016 03:02 AM, Joseph Lo wrote:
Add DT binding for the Hardware Synchronization Primitives (HSP). The
HSP is designed for the processors to share resources and communicate
together. It provides a set of hardware synchronization primitives for
interprocessor communication. So the interpro
On 06/24/2016 10:10 AM, Rob Herring wrote:
On Wed, Jun 22, 2016 at 02:46:14PM +0200, Thierry Reding wrote:
On Wed, Jun 22, 2016 at 05:17:22PM +0530, Laxman Dewangan wrote:
Tegra186 has 8 different PWM controller and each controller has only
one output. Earlier generation SoCs have the 4 PWM out
On 06/20/2016 10:40 AM, Thierry Reding wrote:
On Mon, Jun 20, 2016 at 09:50:26AM -0600, Stephen Warren wrote:
On 06/18/2016 07:04 PM, Marcel Ziswiler wrote:
Remove commas from unit addresses as suggested by Rob Herring upon me
posting initial Apalis TK1 support:
http://article.gmane.org
On 06/18/2016 07:04 PM, Marcel Ziswiler wrote:
Remove commas from unit addresses as suggested by Rob Herring upon me
posting initial Apalis TK1 support:
http://article.gmane.org/gmane.linux.ports.tegra/26608
Acked-by: Stephen Warren
On 05/27/2016 10:27 AM, Marcel Ziswiler wrote:
Remove commas from unit addresses as suggested by Rob Herring upon me
posting initial Apalis TK1 support:
http://article.gmane.org/gmane.linux.ports.tegra/26608
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-
On 05/26/2016 03:17 PM, Stephen Warren wrote:
On 05/26/2016 09:40 AM, Thierry Reding wrote:
From: Thierry Reding
All of these Tegra SoC generations have a ChipIdea UDC IP block that can
be used for device mode communication with a host. Implement rudimentary
support that doesn't
On 05/26/2016 09:40 AM, Thierry Reding wrote:
From: Thierry Reding
All of these Tegra SoC generations have a ChipIdea UDC IP block that can
be used for device mode communication with a host. Implement rudimentary
support that doesn't allow switching between host and device modes.
Are you sure
On 05/22/2016 03:05 AM, Geert Uytterhoeven wrote:
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
@@ -2505,6 +2505,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated
for non-subscribers)
T: git git://git.kernel.or
On 05/11/2016 03:19 AM, Linus Walleij wrote:
On Mon, May 2, 2016 at 2:17 PM, Laxman Dewangan wrote:
NVIDIA Tegra210 supports the IO pads which can operate at 1.8V
or 3.3V I/O voltage levels. Also the IO pads can be configured
for power down state if it is not used. SW needs to configure the
vo
On 05/10/2016 11:16 AM, Jon Hunter wrote:
On 10/05/16 17:34, Stephen Warren wrote:
On 05/10/2016 10:13 AM, Jon Hunter wrote:
[snip]
Stephen, for your u-boot testing, do you are set the bit in the vendor
misc register to enable version 3.0 support for sdhci on tegra30? This
is what the
On 05/10/2016 10:13 AM, Jon Hunter wrote:
On 09/05/16 16:15, Jon Hunter wrote:
Support for SD cards is not working on the Tegra30 Beaver board and on
boot the following error message is seen if an SD card is present:
mmc0: error -110 whilst initialising SD card
In addition to this, Tegra30
On 05/09/2016 09:29 PM, Jassi Brar wrote:
On Tue, May 10, 2016 at 5:15 AM, Stephen Warren wrote:
Jassi,
Does the HW described below sound like something that should be represented
using the Linux kernel's mailbox subsystem, and related DT bindings? I think
the existing drivers/mailbox/
Jassi,
Does the HW described below sound like something that should be
represented using the Linux kernel's mailbox subsystem, and related DT
bindings? I think the existing drivers/mailbox/pcc.c is similar, but
wanted to double-check.
We have some HW that literally just allows a SW-generated
Tegra114 and
hence couldn't even verify that the binding was valid. Any preference as
to the name in this particular case?
You meant Stephen Warren right? I don't care either way.
Sorry, I wasn't really paying attention to patches.
Yes, using "124" seems to make sense;
On 05/05/2016 02:05 AM, Hans de Goede wrote:
Hi,
On 04-05-16 22:25, Thierry Reding wrote:
On Wed, May 04, 2016 at 11:23:20AM -0600, Stephen Warren wrote:
On 05/04/2016 08:40 AM, Thierry Reding wrote:
From: Thierry Reding
Starting with commit 0b52297f2288 ("reset: Add support for s
On 05/04/2016 08:40 AM, Thierry Reding wrote:
From: Thierry Reding
Starting with commit 0b52297f2288 ("reset: Add support for shared reset
controls") there is a reference count for reset control assertions. The
goal is to allow resets to be shared by multiple devices and an assert
will take eff
On 05/04/2016 08:39 AM, Thierry Reding wrote:
From: Thierry Reding
There are three EHCI controllers on Tegra SoCs, each with its own reset
line. However, the first controller contains a set of UTMI configuration
registers that are shared with its siblings. These registers will only
be reset as
ot by parked_bit.
This is to make the parked bit handling same as other fields of mux
registers.
Acked-by: Stephen Warren
On 05/02/2016 01:06 PM, Laxman Dewangan wrote:
On Tuesday 03 May 2016 12:14 AM, Stephen Warren wrote:
On 05/02/2016 11:58 AM, Laxman Dewangan wrote:
Toggling OE bit is something emulating the open drain here.
From the perspective of the external HW that's attached to the GPIO, I
be
On 05/02/2016 11:58 AM, Laxman Dewangan wrote:
On Monday 02 May 2016 09:42 PM, Stephen Warren wrote:
On 04/30/2016 05:07 AM, Linus Walleij wrote:
On Fri, Apr 29, 2016 at 11:20 AM, Laxman Dewangan
wrote:
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM
Laxman Dewangan
Nit: There shouldn't be a blank line between the Fixes: and
Signed-off-by: lines. I assume this can be fixed when the patch is applied.
Acked-by: Stephen Warren
On 05/02/2016 08:28 AM, Laxman Dewangan wrote:
The pincontrol registers of Tegra chips has multiple filed per
registers. There is two type of registers mux and drive. All
configurations belongs to one of these registers.
If any configurations are supported then _bit is set to
bit position of the
On 04/30/2016 05:07 AM, Linus Walleij wrote:
On Fri, Apr 29, 2016 at 11:20 AM, Laxman Dewangan wrote:
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan
wrote:
Add support for the debounce as Tegra210 support debounce in HW.
Also do the
On 04/29/2016 10:25 AM, Laxman Dewangan wrote:
Implement gpio_get_direction() callback for Tegra GPIO.
The direction is only valid if the pin is configured as
GPIO. If pin is not configured in GPIO mode then this
function return error.
Reviewed-by: Stephen Warren
On 04/29/2016 06:31 AM, Laxman Dewangan wrote:
Implement gpio_get_direction() callback for Tegra GPIO.
The direction is only valid if the pin is configured as
GPIO. If pin is not configured in GPIO mode then this
function return error.
This makes debugfs and initial reading of the state of
the l
On 04/26/2016 07:32 AM, Laxman Dewangan wrote:
On Friday 15 April 2016 05:17 PM, Laxman Dewangan wrote:
On Friday 15 April 2016 04:45 PM, Linus Walleij wrote:
On Fri, Apr 15, 2016 at 11:55 AM, Laxman Dewangan
wrote:
On Friday 15 April 2016 02:55 PM, Linus Walleij wrote:
If the pin could ac
On 04/22/2016 04:09 AM, Laxman Dewangan wrote:
NVIDIA's Tegra210 support the HW debounce in the GPIO controller
for all its GPIO pins.
Add support for setting debounce timing by implementing the
set_debounce callback of gpiochip.
Reviewed-by: Stephen Warren
On 04/21/2016 12:35 PM, Laxman Dewangan wrote:
On Friday 22 April 2016 12:03 AM, Stephen Warren wrote:
On 04/20/2016 07:30 AM, Laxman Dewangan wrote:
Move the file scoped multiple global variable from Tegra GPIO
driver to the structure and make this as gpiochip data which
can be referred from
On 04/20/2016 07:30 AM, Laxman Dewangan wrote:
NVIDIA's Tegra210 support the HW debounce in the GPIO
controller for all its GPIO pins.
Add support for setting debounce timing by implementing the
set_debounce callback of gpiochip.
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegr
you explain that change? I'm not sure it's correct, but don't know
why it was made.
Once those are fixed,
Reviewed-by: Stephen Warren
On 04/20/2016 07:30 AM, Laxman Dewangan wrote:
The data member of the of_device_id is the constant type
and hence all static structure which is used for this
initialisation as static.
Reviewed-by: Stephen Warren
On 04/20/2016 01:40 AM, Patrice Chotard wrote:
On 04/19/2016 05:53 PM, Stephen Warren wrote:
On 04/19/2016 06:18 AM, patrice.chot...@st.com wrote:
From: Patrice Chotard
This series cleans and fixes some bugs in MFD/GPIO STMPE drivers and
prepare
the ground to add new STMPE1600 support
On 04/19/2016 10:19 AM, Laxman Dewangan wrote:
On Tuesday 19 April 2016 09:41 PM, Stephen Warren wrote:
On 04/19/2016 03:43 AM, Laxman Dewangan wrote:
NVIDIA's Tegra210 support the HW debounce in the GPIO
controller for all its GPIO pins.
Add support for setting debounce timi
On 04/19/2016 03:43 AM, Laxman Dewangan wrote:
NVIDIA's Tegra210 support the HW debounce in the GPIO
controller for all its GPIO pins.
Add support for setting debounce timing by implementing the
set_debounce callback of gpiochip.
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegr
On 04/19/2016 06:43 AM, Laxman Dewangan wrote:
On Tuesday 19 April 2016 06:03 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Apr 19, 2016 at 03:13:39PM +0530, Laxman Dewangan wrote:
Remove the file static device handle variable for keeping device handle
of driver as this is
1 - 100 of 2891 matches
Mail list logo
