Re: [PATCH v3 0/3] Support NVIDIA Tegra-based Ouya game console

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: >> >>

Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag

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

Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag

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

Re: arm64: tegra186: bpmp: kernel crash while decompressing initrd

hat > 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 this CPU implements; maybe

Re: [PATCH] arm64: tegra: only map accessible sysram

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 driver

Re: [PATCH] arm64: tegra: only map accessible sysram

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

Re: [PATCH V3 02/17] pinctrl: tegra: add suspend and resume support

t 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 take into a

Re: [PATCH 0/8] Virtio-over-PCIe on non-MIC

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

Re: [RFC PATCH v2 09/17] ARM: dts: tegra20: harmony: Setup voltage regulators for DVFS

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 { +

Re: [RFC PATCH v2 09/17] ARM: dts: tegra20: harmony: Setup voltage regulators for DVFS

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 { +

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

mc call implementations e.g. in qcom_scm-32.c and bcm_kona_smc.c. Cc: Dmitry Osipenko <dig...@gmail.com> Cc: Stephen Warren <swar...@nvidia.com> Cc: Thierry Reding <tred...@nvidia.com> Signed-off-by: Stefan Agner <ste...@agner.ch> --- Changes in v2: - Keep

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

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

Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function

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

Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function

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

Re: [PATCH] clk: tegra: fix pllu rate configuration

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

Re: [PATCH] clk: tegra: fix pllu rate configuration

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

Re: [PATCH] ARM: dtc: tegra: enable front panel leds in TrimSlice

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

Re: [PATCH] ARM: dtc: tegra: enable front panel leds in TrimSlice

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

Re: [PATCH] ARM: dtc: tegra: enable front panel leds in TrimSlice

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

Re: [PATCH] ARM: dtc: tegra: enable front panel leds in TrimSlice

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

Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller

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

Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller

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

Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller

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

Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller

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

Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller

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

Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller

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

Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

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

Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

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

Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

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

Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

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

[PATCH] usb: gadget: serial: fix oops when data rx'd after close

From: Stephen Warren <swar...@nvidia.com> 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

[PATCH] usb: gadget: serial: fix oops when data rx'd after close

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

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

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

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

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

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

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

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

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

Re: [PATCH 1/2] i2c: mux: pinctrl: remove platform_data

resent) 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 <swar...@nvidia.com>

Re: [PATCH 1/2] i2c: mux: pinctrl: remove platform_data

resent) 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

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

t; num_names - !!muxc->deselect; i++) { I think that "num_names - !!muxc->deselect" could just be muxc->num_adapters? Otherwise, Reviewed-by: Stephen Warren <swar...@nvidia.com>

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

t; num_names - !!muxc->deselect; i++) { I think that "num_names - !!muxc->deselect" could just be muxc->num_adapters? Otherwise, Reviewed-by: Stephen Warren

Re: CLK_OF_DECLARE advice required

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 I submit

Re: CLK_OF_DECLARE advice required

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 I submit

Re: CLK_OF_DECLARE advice required

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

Re: CLK_OF_DECLARE advice required

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

Re: struct i2c_mux_pinctrl_platform_data for the i2c-mux-pinctrl driver

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

Re: struct i2c_mux_pinctrl_platform_data for the i2c-mux-pinctrl driver

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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 ---

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

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 ---

Re: outreachy

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

Re: outreachy

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

Re: [PATCH 5/7] net: stmmac: Program RX queue size and flow control

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

Re: [PATCH 5/7] net: stmmac: Program RX queue size and flow control

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

Re: [PATCH] MAINTAINERS: Update for the current location of the bcm2835 tree.

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 <swar...@wwwdotorg.org>

Re: [PATCH] MAINTAINERS: Update for the current location of the bcm2835 tree.

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

Re: [PATCH v3] dt-bindings: power: supply: bq24735: reverse the polarity of ac-detect

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

Re: [PATCH v3] dt-bindings: power: supply: bq24735: reverse the polarity of ac-detect

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

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

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.

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

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.

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

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

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

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

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

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

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

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

Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

On 09/26/2016 12:42 PM, Stefan Wahren wrote: Stephen Warren <swar...@wwwdotorg.org> hat am 26. September 2016 um 18:38 geschrieben: On 09/23/2016 12:39 PM, Stefan Wahren wrote: Hi Eric, Eric Anholt <e...@anholt.net> hat am 19. September 2016 um 18:13 geschrieben: The

Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

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 through

Re: [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.

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

Re: [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.

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

Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

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

Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

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

Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

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

Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

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

Re: [PATCH 1/3] arm64: dts: berlin4ct: add missing unit name to /soc node

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:

Re: [PATCH 1/3] arm64: dts: berlin4ct: add missing unit name to /soc node

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:

Re: [PATCH V2 9/9] i2c: tegra: Add pinctrl support

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

Re: [PATCH V2 9/9] i2c: tegra: Add pinctrl support

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

Re: [PATCH V2 9/9] i2c: tegra: Add pinctrl support

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

Re: [PATCH V2 9/9] i2c: tegra: Add pinctrl support

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

Re: [ANNOUNCE] git-series: track changes to a patch series over time

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

Re: [ANNOUNCE] git-series: track changes to a patch series over time

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

Re: [PATCH V3 3/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

by the BPMP firmware driver, which can create the interprocessor communication (IPC) between the CPU and BPMP. Acked-by: Stephen Warren <swar...@nvidia.com>

Re: [PATCH V3 3/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

by the BPMP firmware driver, which can create the interprocessor communication (IPC) between the CPU and BPMP. Acked-by: Stephen Warren

Re: [PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

the interprocessor communication (IPC) protocols can use hardware synchronization primitive, when operating between two processors not in an SMP relationship. Acked-by: Stephen Warren <swar...@nvidia.com> A couple of nits below that you might want to fix up when posting the final version of the

Re: [PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

the 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

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

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

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

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

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

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

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

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

Re: [PATCH] ARM: tegra: fix erroneous address in dts

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

Re: [PATCH] ARM: tegra: fix erroneous address in dts

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

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

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

Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add bindings of the BPMP

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

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

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

Re: [PATCH V2 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox

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

  1   2   3   4   5   6   7   8   9   10   >