On 06/11/2014 06:53 PM, Kuninori Morimoto wrote:
From: Kuninori Morimoto kuninori.morimoto...@renesas.com
Current vendor-prefixes.txt already has
ak prefix for Asahi Kasei Corp by
ae8c4209af2cec065fef15d200a42a04130799f7
(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the
On 06/12/2014 09:58 AM, Peter De Schrijver wrote:
This patchset introduces support for Tegra's microsecond counter as the
udelay() timer. This is useful on Tegra SoCs which do not have an arch timer
such as Tegra20 and Tegra30. Using the microsecond counter instead of a delay
based loop avoids
also be found on the Colibri T30
module.
While at it move the NEON entry down to its proper place to have it all
nicely ordered again.
Acked-by: Stephen Warren swar...@nvidia.com
I assume this will be applied directly to the arm-soc tree.
--
To unsubscribe from this list: send the line
On 06/09/2014 04:52 PM, Marcel Ziswiler wrote:
This patch adds the device tree to support Toradex Apalis T30, a
computer on module which can be used on different carrier boards.
This looks OK; I'll apply once the merge window is done.
diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts
On 06/10/2014 05:11 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
The XUSB pad controller found on NVIDIA Tegra SoCs provides several pads
that lanes can be assigned to in order to support a variety of interface
options: USB 2.0, USB 3.0, PCIe and SATA.
In addition to
On 06/12/2014 09:11 AM, Alban Bedel wrote:
Currently the Tamonten DTS define a fixed regulator for the 5V supply.
However this regulator is in fact on the base board. Fix this by
properly defining the regulators found on the base boards.
diff --git a/arch/arm/boot/dts/tegra20-medcom-wide.dts
On 06/11/2014 02:23 PM, Andrew Bresticker wrote:
> On Tue, Jun 10, 2014 at 4:11 AM, Thierry Reding
> wrote:
>> From: Thierry Reding
>>
>> The XUSB pad controller found on NVIDIA Tegra SoCs provides several pads
>> that lanes can be assigned to in order to support a variety of interface
>>
On 06/11/2014 10:19 AM, Peter De Schrijver wrote:
> On Wed, Jun 11, 2014 at 05:58:28PM +0200, Stephen Warren wrote:
>> On 06/11/2014 09:25 AM, Peter De Schrijver wrote:
>>> On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:
>>>> On 05/06/14 1
On 06/11/2014 09:25 AM, Peter De Schrijver wrote:
> On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:
>> On 05/06/14 16:09, Peter De Schrijver wrote:
>> ...
>>> +int tegra_fuse_readl(u32 offset, u32 *val)
>>> +{
>>> + if (!fuse_readl)
>>> + return -ENXIO;
>>> +
On 06/10/2014 05:48 PM, Brian Norris wrote:
> On Wed, Jun 11, 2014 at 01:34:39AM +0200, Thomas Gleixner wrote:
>> On Tue, 10 Jun 2014, Brian Norris wrote:
>>> Other random thought: it seems like any irqchip driver which does lazy IRQ
>>> masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the
On 06/10/2014 05:48 PM, Brian Norris wrote:
On Wed, Jun 11, 2014 at 01:34:39AM +0200, Thomas Gleixner wrote:
On Tue, 10 Jun 2014, Brian Norris wrote:
Other random thought: it seems like any irqchip driver which does lazy IRQ
masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core
On 06/11/2014 09:25 AM, Peter De Schrijver wrote:
On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:
On 05/06/14 16:09, Peter De Schrijver wrote:
...
+int tegra_fuse_readl(u32 offset, u32 *val)
+{
+ if (!fuse_readl)
+ return -ENXIO;
+
+ *val =
On 06/11/2014 10:19 AM, Peter De Schrijver wrote:
On Wed, Jun 11, 2014 at 05:58:28PM +0200, Stephen Warren wrote:
On 06/11/2014 09:25 AM, Peter De Schrijver wrote:
On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:
On 05/06/14 16:09, Peter De Schrijver wrote:
...
+int
On 06/11/2014 02:23 PM, Andrew Bresticker wrote:
On Tue, Jun 10, 2014 at 4:11 AM, Thierry Reding
thierry.red...@gmail.com wrote:
From: Thierry Reding tred...@nvidia.com
The XUSB pad controller found on NVIDIA Tegra SoCs provides several pads
that lanes can be assigned to in order to support
utine isn't called at all.
>*/
> clk_prepare_enable(pll_x_clk);
I would remove the word "so" in the added line; the function is not
called because we don't need to use an intermediate frequency, not
because we don't need to take a reference to pll_x. With that change,
Review
On 06/06/2014 12:27 AM, Mikko Perttunen wrote:
> The only compile-time dependencies here should be that:
> - patch 8 of 9 which contains the actual driver depends on patch 6 of 9
> (though only when building as a module) and the efuse series
> - patch 2 of 9 refers to the DT node called "padctl",
On 06/06/2014 01:35 AM, Peter De Schrijver wrote:
> On Fri, Jun 06, 2014 at 12:54:00AM +0200, Stephen Warren wrote:
...
>>> No. It's only used to populate /sys/devices/soc0/revision. I don't think
>>> that's particularly important.
>>
>> But it's a feature that
On 06/06/2014 01:35 AM, Peter De Schrijver wrote:
On Fri, Jun 06, 2014 at 12:54:00AM +0200, Stephen Warren wrote:
...
No. It's only used to populate /sys/devices/soc0/revision. I don't think
that's particularly important.
But it's a feature that works today. Why should we break it?
I don't
On 06/06/2014 12:27 AM, Mikko Perttunen wrote:
The only compile-time dependencies here should be that:
- patch 8 of 9 which contains the actual driver depends on patch 6 of 9
(though only when building as a module) and the efuse series
- patch 2 of 9 refers to the DT node called padctl, so it
is not
called because we don't need to use an intermediate frequency, not
because we don't need to take a reference to pll_x. With that change,
Reviewed-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
On 06/05/2014 04:08 PM, Thierry Reding wrote:
> On Thu, Jun 05, 2014 at 10:47:45AM -0600, Stephen Warren wrote:
>> On 06/04/2014 09:16 AM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> This patch adds the device tree binding documentation for the XUS
On 06/05/2014 04:13 PM, Peter De Schrijver wrote:
> On Thu, Jun 05, 2014 at 08:41:55PM +0200, Stephen Warren wrote:
>> On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
>>> Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
>>
>>> diff -
On 06/05/2014 04:09 PM, Peter De Schrijver wrote:
> On Thu, Jun 05, 2014 at 08:37:26PM +0200, Stephen Warren wrote:
>> On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
>>> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
>>>
>>&g
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
> Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> + apbmisc@7800 {
> + compatible = "nvidia,tegra114-apbmisc",
>
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
>
> Signed-off-by: Peter De Schrijver
> ---
> Documentation/ABI/testing/sysfs-driver-tegra-fuse | 11 +
> drivers/misc/fuse/Makefile|1 +
>
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
This series isn't bisectable; building at either patch 3 or patch 4 yields:
> In file included from arch/arm/mach-tegra/fuse.c:28:0:
> arch/arm/mach-tegra/fuse.h:40:5: error:
On 06/05/2014 11:57 AM, Stephen Warren wrote:
> On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
>> Export APB DMA readl and writel. These are needed because we can't access
>> the fuses directly on Tegra20 without potentially causing a system hang.
>> Also have the APB
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
> Export APB DMA readl and writel. These are needed because we can't access
> the fuses directly on Tegra20 without potentially causing a system hang.
> Also have the APB DMA readl and writel return an error in case of a read
> failure instead of
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> Hi,
>
> This series adds support for the onboard AHCI-compliant Serial ATA
> controller found on Tegra124 systems-on-chip. The controller is
> enabled on Jetson TK1. The series depends on Peter's efuse series
> and Thierry's yet to be submitted
On 06/04/2014 09:16 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> The XUSB pad controller found on NVIDIA Tegra SoCs provides several pads
> that lanes can be assigned to in order to support a variety of interface
> options: USB 2.0, USB 3.0, PCIe and SATA.
>
> In addition to the pin
On 06/04/2014 09:16 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> This patch adds the device tree binding documentation for the XUSB pad
> controller found on NVIDIA Tegra SoCs. It exposes both pinmuxing and PHY
> capabilities.
> diff --git
>
erent boards.
>
> This fragment is based on what's currently in tegra124-venice2.dts
This series looks fine to me. Given it touches both Tegra and Exynos,
should it be merged into a topic branch in arm-soc, so that it can be
pulled into both Tegra/Exynos trees to resolve any conflicts. So,
function.
> 3.Remove the disable ops in struct pinmux_ops
> 4.Remove all the disable ops users in current code base.
...
The overall concept, plus the bcm2835, and Tegra driver parts,
Acked-by: Stephen Warren
That said ...
> diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/p
.Remove the disable ops in struct pinmux_ops
4.Remove all the disable ops users in current code base.
...
The overall concept, plus the bcm2835, and Tegra driver parts,
Acked-by: Stephen Warren swar...@nvidia.com
That said ...
diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl
on what's currently in tegra124-venice2.dts
This series looks fine to me. Given it touches both Tegra and Exynos,
should it be merged into a topic branch in arm-soc, so that it can be
pulled into both Tegra/Exynos trees to resolve any conflicts. So,
Acked-by: Stephen Warren swar...@nvidia.com
On 06/04/2014 09:16 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This patch adds the device tree binding documentation for the XUSB pad
controller found on NVIDIA Tegra SoCs. It exposes both pinmuxing and PHY
capabilities.
diff --git
On 06/04/2014 09:16 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
The XUSB pad controller found on NVIDIA Tegra SoCs provides several pads
that lanes can be assigned to in order to support a variety of interface
options: USB 2.0, USB 3.0, PCIe and SATA.
In addition to
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
Hi,
This series adds support for the onboard AHCI-compliant Serial ATA
controller found on Tegra124 systems-on-chip. The controller is
enabled on Jetson TK1. The series depends on Peter's efuse series
and Thierry's yet to be submitted XUSB
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
Export APB DMA readl and writel. These are needed because we can't access
the fuses directly on Tegra20 without potentially causing a system hang.
Also have the APB DMA readl and writel return an error in case of a read
failure instead of just
On 06/05/2014 11:57 AM, Stephen Warren wrote:
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
Export APB DMA readl and writel. These are needed because we can't access
the fuses directly on Tegra20 without potentially causing a system hang.
Also have the APB DMA readl and writel return
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
This series isn't bisectable; building at either patch 3 or patch 4 yields:
In file included from arch/arm/mach-tegra/fuse.c:28:0:
arch/arm/mach-tegra/fuse.h:40:5: error:
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
Signed-off-by: Peter De Schrijver pdeschrij...@nvidia.com
---
Documentation/ABI/testing/sysfs-driver-tegra-fuse | 11 +
drivers/misc/fuse/Makefile|
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
+ apbmisc@7800 {
+ compatible = nvidia,tegra114-apbmisc,
On 06/05/2014 04:09 PM, Peter De Schrijver wrote:
On Thu, Jun 05, 2014 at 08:37:26PM +0200, Stephen Warren wrote:
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
Signed-off-by: Peter De Schrijver pdeschrij...@nvidia.com
On 06/05/2014 04:13 PM, Peter De Schrijver wrote:
On Thu, Jun 05, 2014 at 08:41:55PM +0200, Stephen Warren wrote:
On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
diff --git a/arch/arm/boot/dts/tegra114.dtsi
b/arch
On 06/05/2014 04:08 PM, Thierry Reding wrote:
On Thu, Jun 05, 2014 at 10:47:45AM -0600, Stephen Warren wrote:
On 06/04/2014 09:16 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This patch adds the device tree binding documentation for the XUSB pad
controller found
On 06/04/2014 01:17 PM, Vidya Sagar wrote:
> As per PCIe spec, fast back-to-back transactions feature
> is not applicable to PCIe devices. Hence, do not print
> that fast back-to-back trasactions are disabled when
> there is a PCIe device found on the bus
> @@ -298,6 +299,8 @@ void
On 06/04/2014 01:17 PM, Vidya Sagar wrote:
As per PCIe spec, fast back-to-back transactions feature
is not applicable to PCIe devices. Hence, do not print
that fast back-to-back trasactions are disabled when
there is a PCIe device found on the bus
@@ -298,6 +299,8 @@ void
On 06/03/2014 07:28 PM, FanWu wrote:
> On 06/04/2014 12:49 AM, Stephen Warren wrote:
>> On 06/03/2014 01:37 AM, f...@marvell.com wrote:
>>> From: Fan Wu
>>>
>>> What the patch did:
>>> 1.To call pinmux_disable_setting ahead of pinmux_enab
function.
> 3.Remove the disable ops in struct pinmux_ops
...
> Signed-off-by: Fan Wu
> Signed-off-by: Stephen Warren
As I mentioned in my previous email, I didn't sign this off. I made some
suggestions for a better alternative in that email.
If I *had* written that s-o-b, then it shoul
e point is that you can NEVER write S-o-b for someone else, only for
yourself. Given the small contribution from me in this patch, the
following would be better ways to credit me:
1) Not bother since it's a tiny comment
2) In patch description:
(includes comment fixes from Stephen Warren)
3) In pa
the small contribution from me in this patch, the
following would be better ways to credit me:
1) Not bother since it's a tiny comment
2) In patch description:
(includes comment fixes from Stephen Warren)
3) In patch description final paragraph, before your S-o-b:
Based-on-work-by: Stephen Warren
.Remove the disable ops in struct pinmux_ops
...
Signed-off-by: Fan Wu f...@marvell.com
Signed-off-by: Stephen Warren swar...@nvidia.com
As I mentioned in my previous email, I didn't sign this off. I made some
suggestions for a better alternative in that email.
If I *had* written that s-o-b
On 06/03/2014 07:28 PM, FanWu wrote:
On 06/04/2014 12:49 AM, Stephen Warren wrote:
On 06/03/2014 01:37 AM, f...@marvell.com wrote:
From: Fan Wu f...@marvell.com
What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in
each time of
calling
On 06/02/2014 02:18 PM, Marcel Ziswiler wrote:
> On 06/02/2014 06:26 PM, Stephen Warren wrote:
>>> +pwmleds {
>>> +compatible = "pwm-leds";
>>> +
>>> +pwm3 {
>>> +label = "PWM3";
>&g
On 06/02/2014 11:01 AM, Olof Johansson wrote:
> On Mon, Jun 2, 2014 at 2:43 AM, Marcel Ziswiler wrote:
>> The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
>> i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller,
>> SPI bus and PWM LEDs generically accessible
On 06/02/2014 04:06 AM, Viresh Kumar wrote:
> On 30 May 2014 21:56, Stephen Warren wrote:
>> ... [This patch causes issues on Tegra20] ...
>> I believe the issue is this:
...
> Okay, that was very helpful..
>
> What about this ? (Attached for testing) :
>
> Autho
On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
> This patch adds the device tree to support Toradex Apalis T30, a
> computer on module which can be used on different carrier boards.
>
> The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
> RAM, eMMC, an LM95245 temperature sensor
On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
> This patch adds the device tree to support Toradex Apalis T30, a
> computer on module which can be used on different carrier boards.
>
> The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
> RAM, eMMC, an LM95245 temperature sensor
On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
> The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
> i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller, I2C
> as well as SPI buses and PWM LEDs generically accessible from user
> space and an LM95245 temperature
On 06/02/2014 03:43 AM, Marcel Ziswiler wrote:
> The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
> i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller,
> SPI bus and PWM LEDs generically accessible from user space and an
> LM95245 temperature sensor chip. The
On 06/02/2014 03:43 AM, Marcel Ziswiler wrote:
The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller,
SPI bus and PWM LEDs generically accessible from user space and an
LM95245 temperature sensor chip. The
On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller, I2C
as well as SPI buses and PWM LEDs generically accessible from user
space and an LM95245 temperature
On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
This patch adds the device tree to support Toradex Apalis T30, a
computer on module which can be used on different carrier boards.
The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
RAM, eMMC, an LM95245 temperature sensor chip,
On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
This patch adds the device tree to support Toradex Apalis T30, a
computer on module which can be used on different carrier boards.
The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
RAM, eMMC, an LM95245 temperature sensor chip,
On 06/02/2014 04:06 AM, Viresh Kumar wrote:
On 30 May 2014 21:56, Stephen Warren swar...@wwwdotorg.org wrote:
... [This patch causes issues on Tegra20] ...
I believe the issue is this:
...
Okay, that was very helpful..
What about this ? (Attached for testing) :
Author: Viresh Kumar
On 06/02/2014 11:01 AM, Olof Johansson wrote:
On Mon, Jun 2, 2014 at 2:43 AM, Marcel Ziswiler mar...@ziswiler.com wrote:
The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller,
SPI bus and PWM LEDs generically
On 06/02/2014 02:18 PM, Marcel Ziswiler wrote:
On 06/02/2014 06:26 PM, Stephen Warren wrote:
+pwmleds {
+compatible = pwm-leds;
+
+pwm3 {
+label = PWM3;
+pwms = pwm 1 19600;
+max-brightness = 255;
+};
+pwm2
nction name and comment between v1 and v2 so that the return
> value signals the opposite thing.
> Step 2: Change the call sites to reflect the opposite return value.
> Step 3: ???
> Step 4: Make a complete fool of yourself.
Tested-by: Stephen Warren
This fix doesn't seem
On 05/29/2014 07:56 PM, Viresh Kumar wrote:
> On 29 May 2014 23:10, Stephen Warren wrote:
>> This patch breaks Tegra. The reason is below.
...
>>> +disable_pll_x:
>>> + clk_disable_unprepare(pll_x_clk);
>>
>> ... so this turns off pll_x even though we're
On 05/30/2014 02:23 AM, Peter De Schrijver wrote:
> On Thu, May 29, 2014 at 09:01:27PM +0200, Stephen Warren wrote:
>> On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
>>> This driver allows userspace to read the raw efuse data. Its userspace
>>> interface is modelled
On 05/30/2014 05:36 AM, Peter De Schrijver wrote:
> On Thu, May 29, 2014 at 09:04:33PM +0200, Stephen Warren wrote:
>> On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
>>> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
>>
>>> diff --git a/Docum
On 05/30/2014 05:36 AM, Peter De Schrijver wrote:
On Thu, May 29, 2014 at 09:04:33PM +0200, Stephen Warren wrote:
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
On 05/30/2014 02:23 AM, Peter De Schrijver wrote:
On Thu, May 29, 2014 at 09:01:27PM +0200, Stephen Warren wrote:
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
This driver allows userspace to read the raw efuse data. Its userspace
interface is modelled after the sunxi_sid driver which
On 05/29/2014 07:56 PM, Viresh Kumar wrote:
On 29 May 2014 23:10, Stephen Warren swar...@wwwdotorg.org wrote:
This patch breaks Tegra. The reason is below.
...
+disable_pll_x:
+ clk_disable_unprepare(pll_x_clk);
... so this turns off pll_x even though we're running from it.
Can you
-and-need_sched-contention-fix2
Step 1: Change function name and comment between v1 and v2 so that the return
value signals the opposite thing.
Step 2: Change the call sites to reflect the opposite return value.
Step 3: ???
Step 4: Make a complete fool of yourself.
Tested-by: Stephen Warren swar
On 05/28/2014 07:16 AM, Andrew Morton wrote:
> On Wed, 28 May 2014 15:54:32 +0300 Peter De Schrijver
> wrote:
>
>> This driver allows userspace to read the raw efuse data.
>
> The patchset uses an inexplicable mixture of "fuse" and "efuse".
> Given that the kernel already has a "fuse", it
ion.
...
This commit description is way too long for such a simple change. A much
shorter summary would be better.
> Signed-off-by: Fan Wu
> Signed-off-by: Stephen Warren
I'm pretty sure I never signed off on this patch. How come my s-o-b line
is there?
This patch still doesn't remove o
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
> The Tegra fuse code has moved to drivers/misc/fuse/tegra. Enable the
> building of that code, and disable the building of the old fuse code in
> arch/arm/mach-tegra/.
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
> Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
>
> Signed-off-by: Peter De Schrijver
> ---
> .../devicetree/bindings/fuse/fuse-tegra.txt| 30
>
>
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
> diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
> b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
> +Description: read-only access to the efuses on
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
> This driver allows userspace to read the raw efuse data. Its userspace
> interface is modelled after the sunxi_sid driver which provides similar
> functionality for some Allwinner SoCs. It has been tested on
> Tegra20 (ventana), Tegra30
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
> All fuse related functionality will move to a driver in the following patches.
> To prepare for this, export all the required functionality in a global header
> file and move all users of fuse.h to tegra-soc.h. While we're at it, remove
>
On 05/28/2014 10:51 AM, Peter De Schrijver wrote:
> This patch set introduces the 'regs' debugfs entry which shows the
> contents of all registers related to a clock.
Would it be better to create a regmap object for the entire clock module
register space, and then get all the debugfs stuff for
On 05/22/2014 10:05 PM, Viresh Kumar wrote:
> On 22 May 2014 22:09, Stephen Warren wrote:
>> I think the call to tegra_target_intermediate() is wrong here; shouldn't
>> the cpufreq core guarantee that tegra_target_intermediate() has always
>> been called before tegra_target(
On 05/21/2014 02:59 AM, Viresh Kumar wrote:
> Tegra had always been switching to intermediate frequency (pll_p_clk) since
> ever. CPUFreq core has better support for handling notifications for these
> frequencies and so we can adapt Tegra's driver to it.
>
> Also do a WARN() if clk_set_parent()
On 05/23/2014 02:36 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
>
> initrd= option to command line (in the DT).
>
> Therefore, to facilitate adding to the DT command line directly in the
> DTB, add some padding.
>
> Cc: Nicolas Pitre
> Cc: Stephen Warren
> Cc: Thomas Petazzoni
> Signed-off-by: Kevin Hilman
> ---
> I kinda p
).
Therefore, to facilitate adding to the DT command line directly in the
DTB, add some padding.
Cc: Nicolas Pitre n...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
I kinda
On 05/23/2014 02:36 PM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU
On 05/21/2014 02:59 AM, Viresh Kumar wrote:
Tegra had always been switching to intermediate frequency (pll_p_clk) since
ever. CPUFreq core has better support for handling notifications for these
frequencies and so we can adapt Tegra's driver to it.
Also do a WARN() if clk_set_parent() fails
On 05/22/2014 10:05 PM, Viresh Kumar wrote:
On 22 May 2014 22:09, Stephen Warren swar...@wwwdotorg.org wrote:
I think the call to tegra_target_intermediate() is wrong here; shouldn't
the cpufreq core guarantee that tegra_target_intermediate() has always
been called before tegra_target(), so
On 05/28/2014 10:51 AM, Peter De Schrijver wrote:
This patch set introduces the 'regs' debugfs entry which shows the
contents of all registers related to a clock.
Would it be better to create a regmap object for the entire clock module
register space, and then get all the debugfs stuff for
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
This driver allows userspace to read the raw efuse data. Its userspace
interface is modelled after the sunxi_sid driver which provides similar
functionality for some Allwinner SoCs. It has been tested on
Tegra20 (ventana), Tegra30
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
All fuse related functionality will move to a driver in the following patches.
To prepare for this, export all the required functionality in a global header
file and move all users of fuse.h to tegra-soc.h. While we're at it, remove
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
+Description: read-only access to the efuses on Tegra20,
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
Signed-off-by: Peter De Schrijver pdeschrij...@nvidia.com
---
.../devicetree/bindings/fuse/fuse-tegra.txt| 30
On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
The Tegra fuse code has moved to drivers/misc/fuse/tegra. Enable the
building of that code, and disable the building of the old fuse code in
arch/arm/mach-tegra/.
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index
.
...
This commit description is way too long for such a simple change. A much
shorter summary would be better.
Signed-off-by: Fan Wu f...@marvell.com
Signed-off-by: Stephen Warren swar...@nvidia.com
I'm pretty sure I never signed off on this patch. How come my s-o-b line
is there?
This patch still
On 05/28/2014 07:16 AM, Andrew Morton wrote:
On Wed, 28 May 2014 15:54:32 +0300 Peter De Schrijver
pdeschrij...@nvidia.com wrote:
This driver allows userspace to read the raw efuse data.
The patchset uses an inexplicable mixture of fuse and efuse.
Given that the kernel already has a
1201 - 1300 of 5773 matches
Mail list logo
