of IRQs at the LIC level
works again, but more importantly it fixes the resulting memory corruption.
Tested-by: Stephen Warren
Tested on NVIDIA Seaboard (which is affected by the bug in the default
configuration/DT) with the patch applied on to of 4.1-rc3.
--
To unsubscribe from this list: send
of IRQs at the LIC level
works again, but more importantly it fixes the resulting memory corruption.
Tested-by: Stephen Warren swar...@nvidia.com
Tested on NVIDIA Seaboard (which is affected by the bug in the default
configuration/DT) with the patch applied on to of 4.1-rc3.
--
To unsubscribe from
On 05/08/2015 01:19 PM, Eric Anholt wrote:
> Alexander Stein writes:
>
>> On Thursday 07 May 2015, 12:54:20 wrote Eric Anholt:
>>> Noralf Trønnes writes:
>>>
Den 05.05.2015 22:27, skrev Eric Anholt:
> From: Lubomir Rintel
>
> This mailbox driver provides a single mailbox
On 05/08/2015 01:19 PM, Eric Anholt wrote:
Alexander Stein alexander...@web.de writes:
On Thursday 07 May 2015, 12:54:20 wrote Eric Anholt:
Noralf Trønnes nor...@tronnes.org writes:
Den 05.05.2015 22:27, skrev Eric Anholt:
From: Lubomir Rintel lkund...@v3.sk
This mailbox driver
On 05/04/2015 02:25 PM, Noralf Trønnes wrote:
Den 04.05.2015 21:33, skrev Eric Anholt:
There exists a tiny MMU, configurable only by the VC (running the
closed firmware), which maps from the ARM's physical addresses to bus
addresses. These bus addresses determine the caching behavior in the
I had been avoiding looking into
fixing the kernel for this since I was worried it'd be rather complex!
I'm puzzled why the length cell of ranges and dma-ranges differs though?
Assuming there's a good explanation for that,
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the lin
the kernel for this since I was worried it'd be rather complex!
I'm puzzled why the length cell of ranges and dma-ranges differs though?
Assuming there's a good explanation for that,
Acked-by: Stephen Warren swar...@wwwdotorg.org
--
To unsubscribe from this list: send the line unsubscribe linux
On 05/04/2015 02:25 PM, Noralf Trønnes wrote:
Den 04.05.2015 21:33, skrev Eric Anholt:
There exists a tiny MMU, configurable only by the VC (running the
closed firmware), which maps from the ARM's physical addresses to bus
addresses. These bus addresses determine the caching behavior in the
On 04/23/2015 08:06 AM, Johan Hovold wrote:
Make sure only to copy any actual data rather than the whole buffer,
when releasing the temporary buffer used for unaligned non-isochronous
transfers.
Compile-tested only.
Tested-by: Stephen Warren
(Tested a USB network device attached to Jetson
On 04/23/2015 08:06 AM, Johan Hovold wrote:
Make sure only to copy any actual data rather than the whole buffer,
when releasing the temporary buffer used for unaligned non-isochronous
transfers.
Compile-tested only.
Tested-by: Stephen Warren swar...@nvidia.com
(Tested a USB network device
On 04/13/2015 10:52 AM, Jim Davis wrote:
Building with the attached random configuration file,
drivers/spi/spi-bcm2835.c: In function 'chip_match_name':
drivers/spi/spi-bcm2835.c:356:21: error: dereferencing pointer to
incomplete type
return !strcmp(chip->label, data);
On 04/13/2015 10:52 AM, Jim Davis wrote:
Building with the attached random configuration file,
drivers/spi/spi-bcm2835.c: In function 'chip_match_name':
drivers/spi/spi-bcm2835.c:356:21: error: dereferencing pointer to
incomplete type
return !strcmp(chip-label, data);
^
On 04/08/2015 08:43 AM, Linus Walleij wrote:
> On Tue, Apr 7, 2015 at 12:43 PM, Charles Keepax
> wrote:
>
>> Currently, the driver uses handle_simple_irq for all IRQ types and hard
>> codes the acknowledge for different IRQ types into the handler. It is
>> better to use the IRQ core as intended
On 04/08/2015 08:43 AM, Linus Walleij wrote:
On Tue, Apr 7, 2015 at 12:43 PM, Charles Keepax
ckee...@opensource.wolfsonmicro.com wrote:
Currently, the driver uses handle_simple_irq for all IRQ types and hard
codes the acknowledge for different IRQ types into the handler. It is
better to use
On 04/02/2015 03:37 AM, Marc Dietrich wrote:
Am Mittwoch, 1. April 2015, 11:28:32 schrieb Stephen Warren:
On 03/31/2015 09:46 AM, Andrey Danin wrote:
On 31.03.2015 17:09, Stephen Warren wrote:
On 03/31/2015 12:40 AM, Andrey Danin wrote:
Hi,
Thanks for the review.
On 03.02.2015 0:20
On 04/02/2015 03:37 AM, Marc Dietrich wrote:
Am Mittwoch, 1. April 2015, 11:28:32 schrieb Stephen Warren:
On 03/31/2015 09:46 AM, Andrey Danin wrote:
On 31.03.2015 17:09, Stephen Warren wrote:
On 03/31/2015 12:40 AM, Andrey Danin wrote:
Hi,
Thanks for the review.
On 03.02.2015 0:20
On 03/31/2015 09:46 AM, Andrey Danin wrote:
On 31.03.2015 17:09, Stephen Warren wrote:
On 03/31/2015 12:40 AM, Andrey Danin wrote:
Hi,
Thanks for the review.
On 03.02.2015 0:20, Stephen Warren wrote:
On 01/29/2015 12:20 AM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c
On 03/31/2015 09:46 AM, Andrey Danin wrote:
On 31.03.2015 17:09, Stephen Warren wrote:
On 03/31/2015 12:40 AM, Andrey Danin wrote:
Hi,
Thanks for the review.
On 03.02.2015 0:20, Stephen Warren wrote:
On 01/29/2015 12:20 AM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c
On 03/31/2015 12:40 AM, Andrey Danin wrote:
Hi,
Thanks for the review.
On 03.02.2015 0:20, Stephen Warren wrote:
On 01/29/2015 12:20 AM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
diff --git a/Documentation/devicetree
On 03/31/2015 12:40 AM, Andrey Danin wrote:
Hi,
Thanks for the review.
On 03.02.2015 0:20, Stephen Warren wrote:
On 01/29/2015 12:20 AM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
diff --git a/Documentation/devicetree
On 03/27/2015 05:35 AM, Peter Ujfalusi wrote:
> The vd->node is removed from the lists when the transfer started so the
> vchan_get_all_descriptors() will not find it. This results memory leak.
Acked-by: Stephen Warren
(I'm just assuming the explanation makes sense and is corr
On 03/27/2015 05:35 AM, Peter Ujfalusi wrote:
The vd-node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Acked-by: Stephen Warren swar...@wwwdotorg.org
(I'm just assuming the explanation makes sense
On 03/20/2015 09:36 AM, Dmitry Osipenko wrote:
Convert CPU reset vector address to LE to support big-endian kernel.
Naively this sounds a little odd; the value here is in a CPU register
all the time, not in memory, so I'm not sure why endianness is relevant?
Presumably the CPU doesn't end up
On 03/20/2015 12:11 AM, Paul Walmsley wrote:
Per Stephen Warren, note in the Tegra AHB DT binding documentation
that we specifically deprecate any attempt to use the IP block's
actual hardware base address, and advocate the use of the legacy
"off-by-four" address in the 'regs
On 03/20/2015 12:11 AM, Paul Walmsley wrote:
Per Stephen Warren, note in the Tegra AHB DT binding documentation
that we specifically deprecate any attempt to use the IP block's
actual hardware base address, and advocate the use of the legacy
off-by-four address in the 'regs' property, for Tegra
On 03/20/2015 09:36 AM, Dmitry Osipenko wrote:
Convert CPU reset vector address to LE to support big-endian kernel.
Naively this sounds a little odd; the value here is in a CPU register
all the time, not in memory, so I'm not sure why endianness is relevant?
Presumably the CPU doesn't end up
I guess pretend like I never made the suggestion.
On 03/19/2015 12:42 PM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 10:34 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 09:33 AM, Paul Walmsley wrote:
On Tue, 17 Mar
On 03/19/2015 11:55 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
The binding document is supposed to say what value the reg property should
have.
If you look at other DT binding documentation in the kernel, this is
generally not the case. Consider these examples
On 03/19/2015 10:34 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 09:33 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Stephen Warren wrote:
On 03/17/2015 02:32 AM, Paul Walmsley wrote:
For Tegra132 and later chips, we can now use the correct hardware
On 03/19/2015 10:17 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 09:26 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Russell King - ARM Linux wrote:
On Tue, Mar 17, 2015 at 01:32:21AM -0700, Paul Walmsley wrote:
Required properties:
- compatible
On 03/19/2015 10:02 AM, Wolfram Sang wrote:
- /* Only register child devices if the adapter has a node pointer set */
- if (!adap->dev.of_node)
+ /* Only register childs if adapter has a node pointer with enabled
status */
+ if (!adap->dev.of_node ||
On 03/19/2015 04:09 AM, Wolfram Sang wrote:
Possible. But this change just makes i2c-mux-pinctrl honor status
property at all. There is no functional change except it now allows
you to disable any of the sub-busses.
Actually, this is the feature I like. However, I wonder if we shouldn't
have
On 03/19/2015 09:33 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Stephen Warren wrote:
On 03/17/2015 02:32 AM, Paul Walmsley wrote:
For Tegra132 and later chips, we can now use the correct hardware base
address for the Tegra AHB IP block in the DT data. Update the DT binding
documentation
On 03/19/2015 09:26 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Russell King - ARM Linux wrote:
On Tue, Mar 17, 2015 at 01:32:21AM -0700, Paul Walmsley wrote:
Required properties:
- compatible : For Tegra20, must contain "nvidia,tegra20-ahb". For
- Tegra30, must contain
On 03/18/2015 08:07 PM, Alexandre Courbot wrote:
On Thu, Mar 19, 2015 at 5:16 AM, David Cohen
wrote:
Some gpio controllers are capable of programming its pins' active-low
state. Let's add this new gpio_chip function for such cases and use it
in gpiolib.
When set_active_low() is implemented,
I guess pretend like I never made the suggestion.
On 03/19/2015 12:42 PM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 10:34 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 09:33 AM, Paul Walmsley wrote:
On Tue, 17 Mar
On 03/19/2015 11:55 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
The binding document is supposed to say what value the reg property should
have.
If you look at other DT binding documentation in the kernel, this is
generally not the case. Consider these examples
On 03/19/2015 10:17 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 09:26 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Russell King - ARM Linux wrote:
On Tue, Mar 17, 2015 at 01:32:21AM -0700, Paul Walmsley wrote:
Required properties:
- compatible
On 03/19/2015 10:34 AM, Paul Walmsley wrote:
On Thu, 19 Mar 2015, Stephen Warren wrote:
On 03/19/2015 09:33 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Stephen Warren wrote:
On 03/17/2015 02:32 AM, Paul Walmsley wrote:
For Tegra132 and later chips, we can now use the correct hardware
On 03/19/2015 09:33 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Stephen Warren wrote:
On 03/17/2015 02:32 AM, Paul Walmsley wrote:
For Tegra132 and later chips, we can now use the correct hardware base
address for the Tegra AHB IP block in the DT data. Update the DT binding
documentation
On 03/19/2015 04:09 AM, Wolfram Sang wrote:
Possible. But this change just makes i2c-mux-pinctrl honor status
property at all. There is no functional change except it now allows
you to disable any of the sub-busses.
Actually, this is the feature I like. However, I wonder if we shouldn't
have
On 03/18/2015 08:07 PM, Alexandre Courbot wrote:
On Thu, Mar 19, 2015 at 5:16 AM, David Cohen
david.a.co...@linux.intel.com wrote:
Some gpio controllers are capable of programming its pins' active-low
state. Let's add this new gpio_chip function for such cases and use it
in gpiolib.
When
On 03/19/2015 09:26 AM, Paul Walmsley wrote:
On Tue, 17 Mar 2015, Russell King - ARM Linux wrote:
On Tue, Mar 17, 2015 at 01:32:21AM -0700, Paul Walmsley wrote:
Required properties:
- compatible : For Tegra20, must contain nvidia,tegra20-ahb. For
- Tegra30, must contain
On 03/19/2015 10:02 AM, Wolfram Sang wrote:
- /* Only register child devices if the adapter has a node pointer set */
- if (!adap-dev.of_node)
+ /* Only register childs if adapter has a node pointer with enabled
status */
+ if (!adap-dev.of_node ||
On 03/18/2015 03:53 PM, Scott Branden wrote:
Hi Stephen,
On 15-03-18 12:42 PM, Stephen Warren wrote:
On 03/18/2015 01:24 PM, Scott Branden wrote:
This patchset attempts to standarize the naming of dt-bindings
documents based on the Broadcom vendor prefix of brcm.
Although
is in use by
some of the other vendors.
Conceptually I'm fine with this.
Acked-by: Stephen Warren
The only comment I have is that some bindings refer to other bindings,
e.g. an I2C controller binding might refer to the core I2C binding to
define core I2C properties. Since this patch move
by
some of the other vendors.
Conceptually I'm fine with this.
Acked-by: Stephen Warren swar...@wwwdotorg.org
The only comment I have is that some bindings refer to other bindings,
e.g. an I2C controller binding might refer to the core I2C binding to
define core I2C properties. Since this patch
On 03/18/2015 03:53 PM, Scott Branden wrote:
Hi Stephen,
On 15-03-18 12:42 PM, Stephen Warren wrote:
On 03/18/2015 01:24 PM, Scott Branden wrote:
This patchset attempts to standarize the naming of dt-bindings
documents based on the Broadcom vendor prefix of brcm.
Although
ing unrelated to AHB. This is certainly
the explanation for some other interesting reg value in DT on other HW
modules in Tegra. However as best I can tell that isn't the case for
this HW module; we just mapped the start of the reg value to the first
defined register for some reason rather
mapped the start of the reg value to the first
defined register for some reason rather than aligning it with the entry
in the address map. So, this series makes sense to me.
The series,
Acked-by: Stephen Warren swar...@nvidia.com
(it'd be nice if the DT doc was modified as I described above
will reject
them and hence not program any later pinmux configurations in the "list"
in DT. However, I suspect the risk is quite small and won't be an issue.
Acked-by: Stephen Warren
I also tested this on Beaver, Dalmore, and Jetson TK1 using Paul
Walmsley's automated test system, and saw
On 03/14/2015 06:05 PM, Stefan Agner wrote:
Optional fields are set to -1 by various preprocessor macros. Make
sure the struct fields can actually store them.
diff --git a/drivers/pinctrl/pinctrl-tegra.h b/drivers/pinctrl/pinctrl-tegra.h
- u32 mux_bit:6;
- u32 pupd_bit:6;
-
On 03/14/2015 06:05 PM, Stefan Agner wrote:
Optional fields are set to -1 by various preprocessor macros. Make
sure the struct fields can actually store them.
diff --git a/drivers/pinctrl/pinctrl-tegra.h b/drivers/pinctrl/pinctrl-tegra.h
- u32 mux_bit:6;
- u32 pupd_bit:6;
-
will reject
them and hence not program any later pinmux configurations in the list
in DT. However, I suspect the risk is quite small and won't be an issue.
Acked-by: Stephen Warren swar...@nvidia.com
I also tested this on Beaver, Dalmore, and Jetson TK1 using Paul
Walmsley's automated test system
devicetree binding documentation to
reflect the new functionality to disable unused sub-nodes. While at it,
also fix two references to binding documentation files that miss an "i2c-"
prefix.
The DT binding changes at least,
Acked-by: Stephen Warren
--
To unsubscribe from this
binding documentation to
reflect the new functionality to disable unused sub-nodes. While at it,
also fix two references to binding documentation files that miss an i2c-
prefix.
The DT binding changes at least,
Acked-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list: send
On 03/07/2015 01:10 PM, Linus Walleij wrote:
On Tue, Feb 24, 2015 at 10:00 PM, Stephen Warren wrote:
From: Stephen Warren
Both nvidia,io-hv and nvidia,rcv-sel represent the fact that a particular
pin's IO buffers are configured to accept "high voltage" input signals.
The TRM for
On 03/07/2015 01:10 PM, Linus Walleij wrote:
On Tue, Feb 24, 2015 at 10:00 PM, Stephen Warren swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com
Both nvidia,io-hv and nvidia,rcv-sel represent the fact that a particular
pin's IO buffers are configured to accept high voltage
On 02/24/2015 02:00 PM, Stephen Warren wrote:
From: Stephen Warren
Various non-semantic tweaks and layout/consistency fixes for existing
Tegra pinctrl drivers.
Move the definition of DRV_PINGROUP_REG() before the definition of
PINGROUP() so that a future SoC driver can invoke the former from
On 02/24/2015 02:00 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Various non-semantic tweaks and layout/consistency fixes for existing
Tegra pinctrl drivers.
Move the definition of DRV_PINGROUP_REG() before the definition of
PINGROUP() so that a future SoC driver can
On 02/27/2015 05:24 AM, Sebastian Hesselbarth wrote:
I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
incarnation of the devicetree node with different available sub-busses
to be rewritten.
This patch
On 02/27/2015 05:24 AM, Sebastian Hesselbarth wrote:
I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
incarnation of the devicetree node with different available sub-busses
to be rewritten.
This patch
devicetree binding documentation to
reflect the new functionality to disable unused sub-nodes. While at it,
also fix two references to binding documentation files that miss an "i2c-"
prefix.
Tested-by: Stephen Warren
(Both the HDMI and LCD panel DDC busses on NVIDIA Tegra
Springbank/Se
On 02/26/2015 12:39 PM, Sebastian Hesselbarth wrote:
On 26.02.2015 18:55, Gregory CLEMENT wrote:
On 17/02/2015 19:52, Sebastian Hesselbarth wrote:
This patch set improves current mainline support for the Compulab
CM-A510 System-on-Module (SoM) and its default Compulab SBC-A510
base board.
On 02/26/2015 10:42 AM, Russell King - ARM Linux wrote:
On Thu, Feb 26, 2015 at 11:37:08AM +0100, Geert Uytterhoeven wrote:
When trying to kexec into a new kernel on a platform where multiple CPU
cores are present, but no SMP bringup code is available yet, the
kexec_load system call fails with:
to disable them later at
kexec time. Hence skip the test in the absence of SMP bringup code.
This allows to add all CPU cores to the DTS from the beginning, without
having to implement SMP bringup first, improving DT compatibility.
Acked-by: Stephen Warren
--
To unsubscribe from this list: sen
them later at
kexec time. Hence skip the test in the absence of SMP bringup code.
This allows to add all CPU cores to the DTS from the beginning, without
having to implement SMP bringup first, improving DT compatibility.
Acked-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list
On 02/26/2015 12:39 PM, Sebastian Hesselbarth wrote:
On 26.02.2015 18:55, Gregory CLEMENT wrote:
On 17/02/2015 19:52, Sebastian Hesselbarth wrote:
This patch set improves current mainline support for the Compulab
CM-A510 System-on-Module (SoM) and its default Compulab SBC-A510
base board.
On 02/26/2015 10:42 AM, Russell King - ARM Linux wrote:
On Thu, Feb 26, 2015 at 11:37:08AM +0100, Geert Uytterhoeven wrote:
When trying to kexec into a new kernel on a platform where multiple CPU
cores are present, but no SMP bringup code is available yet, the
kexec_load system call fails with:
binding documentation to
reflect the new functionality to disable unused sub-nodes. While at it,
also fix two references to binding documentation files that miss an i2c-
prefix.
Tested-by: Stephen Warren swar...@nvidia.com
(Both the HDMI and LCD panel DDC busses on NVIDIA Tegra
Springbank/Seaboard
From: Stephen Warren
Various non-semantic tweaks and layout/consistency fixes for existing
Tegra pinctrl drivers.
Move the definition of DRV_PINGROUP_REG() before the definition of
PINGROUP() so that a future SoC driver can invoke the former from the
latter.
PINGROUP_BIT_Y(n) is just n, so
From: Stephen Warren
Some of the pinmux configuration bits that exist in "drive group"
registers in Tegra30..Tegra124 move to the "pinmux" registers on future
chips. Add a flag to support this.
Signed-off-by: Stephen Warren
---
drivers/pinctrl/pin
From: Stephen Warren
Tegra210's pinmux supports a different set of pins/options than earlier
SoCs, so requires its own driver (well, table of pin-specific data).
Cc: devicet...@vger.kernel.org
Signed-off-by: Stephen Warren
---
.../bindings/pinctrl/nvidia,tegra210-pinmux.txt| 166
From: Stephen Warren
Both nvidia,io-hv and nvidia,rcv-sel represent the fact that a particular
pin's IO buffers are configured to accept "high voltage" input signals.
The TRM for different chips names the register field rcv-sel on older
SoCs and io_hv on newer SoCs. Add the new nam
From: Stephen Warren swar...@nvidia.com
Tegra210's pinmux supports a different set of pins/options than earlier
SoCs, so requires its own driver (well, table of pin-specific data).
Cc: devicet...@vger.kernel.org
Signed-off-by: Stephen Warren swar...@nvidia.com
---
.../bindings/pinctrl/nvidia
From: Stephen Warren swar...@nvidia.com
Some of the pinmux configuration bits that exist in drive group
registers in Tegra30..Tegra124 move to the pinmux registers on future
chips. Add a flag to support this.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/pinctrl/pinctrl-tegra.c
From: Stephen Warren swar...@nvidia.com
Various non-semantic tweaks and layout/consistency fixes for existing
Tegra pinctrl drivers.
Move the definition of DRV_PINGROUP_REG() before the definition of
PINGROUP() so that a future SoC driver can invoke the former from the
latter.
PINGROUP_BIT_Y(n
From: Stephen Warren swar...@nvidia.com
Both nvidia,io-hv and nvidia,rcv-sel represent the fact that a particular
pin's IO buffers are configured to accept high voltage input signals.
The TRM for different chips names the register field rcv-sel on older
SoCs and io_hv on newer SoCs. Add the new
On 02/22/2015 09:59 AM, Charles Keepax wrote:
This patch adds a header file for the constants used in pincontrol
configuration for the bcm2835.
This seems like a duplicate of the following series:
https://lkml.org/lkml/2015/1/16/402
[PATCH 0/4] ARM: bcm2835: DT improvements
[PATCH 1/4]
On 02/22/2015 01:13 PM, Arnd Bergmann wrote:
On Sunday 22 February 2015 16:59:56 Charles Keepax wrote:
+
+/* IRQ Flags */
+#define BCM2835_PIN_IRQ_RISING 1
+#define BCM2835_PIN_IRQ_FALLING2
+#define BCM2835_PIN_IRQ_EDGE
On 02/22/2015 09:59 AM, Charles Keepax wrote:
This patch adds a header file for the constants used in pincontrol
configuration for the bcm2835.
This seems like a duplicate of the following series:
https://lkml.org/lkml/2015/1/16/402
[PATCH 0/4] ARM: bcm2835: DT improvements
[PATCH 1/4]
On 02/22/2015 01:13 PM, Arnd Bergmann wrote:
On Sunday 22 February 2015 16:59:56 Charles Keepax wrote:
+
+/* IRQ Flags */
+#define BCM2835_PIN_IRQ_RISING 1
+#define BCM2835_PIN_IRQ_FALLING2
+#define BCM2835_PIN_IRQ_EDGE
On 02/17/2015 02:08 PM, Sebastian Hesselbarth wrote:
On 17.02.2015 21:46, Stephen Warren wrote:
On 02/17/2015 11:52 AM, Sebastian Hesselbarth wrote:
I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
that the kernel
doesn't diverge from the canonical data.
At a quick glance this series looks OK,
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
On 02/17/2015 11:52 AM, Sebastian Hesselbarth wrote:
I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
incarnation of the devicetree node with different available sub-busses
to be rewritten.
Can you be
On 02/17/2015 11:52 AM, Sebastian Hesselbarth wrote:
I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
incarnation of the devicetree node with different available sub-busses
to be rewritten.
Can you be
that the kernel
doesn't diverge from the canonical data.
At a quick glance this series looks OK,
Acked-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 02/17/2015 02:08 PM, Sebastian Hesselbarth wrote:
On 17.02.2015 21:46, Stephen Warren wrote:
On 02/17/2015 11:52 AM, Sebastian Hesselbarth wrote:
I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
On 02/11/2015 07:49 AM, Tomeu Vizoso wrote:
Hello,
we need some more controls in userspace so policy can be applied at events
such as microphone and headphone jacks being plugged in, to be used by
Tegra-based Chromebooks.
The series,
Acked-by: Stephen Warren
--
To unsubscribe from this list
On 02/11/2015 07:49 AM, Tomeu Vizoso wrote:
Hello,
we need some more controls in userspace so policy can be applied at events
such as microphone and headphone jacks being plugged in, to be used by
Tegra-based Chromebooks.
The series,
Acked-by: Stephen Warren swar...@nvidia.com
On 01/19/2015 12:01 PM, Stefan Wahren wrote:
Hi Stephen,
Stephen Warren hat am 19. Januar 2015 um 18:13
geschrieben:
On 01/19/2015 04:00 AM, Stefan Wahren wrote:
This patch adds root compatible properties for the following boards:
- Raspberry Pi Model A
- Raspberry Pi Model A+
- Raspberry
On 01/19/2015 12:01 PM, Stefan Wahren wrote:
Hi Stephen,
Stephen Warren swar...@wwwdotorg.org hat am 19. Januar 2015 um 18:13
geschrieben:
On 01/19/2015 04:00 AM, Stefan Wahren wrote:
This patch adds root compatible properties for the following boards:
- Raspberry Pi Model A
- Raspberry Pi
On 02/04/2015 02:13 AM, Tomeu Vizoso wrote:
On 02/03/2015 05:35 PM, Stephen Warren wrote:
On 02/03/2015 06:13 AM, Tomeu Vizoso wrote:
On 2 February 2015 at 22:08, Stephen Warren wrote:
On 01/28/2015 03:50 AM, Tomeu Vizoso wrote:
Patches are on its way to add a config file to alsaucm
On 02/04/2015 02:13 AM, Tomeu Vizoso wrote:
On 02/03/2015 05:35 PM, Stephen Warren wrote:
On 02/03/2015 06:13 AM, Tomeu Vizoso wrote:
On 2 February 2015 at 22:08, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/28/2015 03:50 AM, Tomeu Vizoso wrote:
Patches are on its way to add a config
On 02/03/2015 06:13 AM, Tomeu Vizoso wrote:
On 2 February 2015 at 22:08, Stephen Warren wrote:
On 01/28/2015 03:50 AM, Tomeu Vizoso wrote:
Patches are on its way to add a config file to alsaucm for the Nyan
boards. Use the same card ID that alsaucm will expect.
diff --git a/arch/arm/boot
On 02/03/2015 06:13 AM, Tomeu Vizoso wrote:
On 2 February 2015 at 22:08, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/28/2015 03:50 AM, Tomeu Vizoso wrote:
Patches are on its way to add a config file to alsaucm for the Nyan
boards. Use the same card ID that alsaucm will expect.
diff
On 01/29/2015 12:20 AM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
The changes to this file make more
On 01/28/2015 03:50 AM, Tomeu Vizoso wrote:
Patches are on its way to add a config file to alsaucm for the Nyan
boards. Use the same card ID that alsaucm will expect.
diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts
b/arch/arm/boot/dts/tegra124-nyan-big.dts
sound {
-
On Sat, Jan 31, 2015 at 05:24:42PM +0530, varsharamt wrote:
The task was to fix a warning which was shown while compiling a driver
called NVEC. I wrote a brief description about how to enable support for
a nVidya complaint embedded controller.
Please note that NVIDIA is spelled/capitalized
On 01/29/2015 12:20 AM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
The changes to this file make more
501 - 600 of 5773 matches
Mail list logo
