On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
Add device-tree binding documentation for the XHCI controller present
on Tegra124 and later SoCs.
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
Add device-tree binding documentation for the XHCI controller present
on Tegra124 and later SoCs.
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
+
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
The Tegra XHCI controller communicates requests to the host through
a mailbox interface. Host drivers which can handle these requests,
such as the Tegra XUSB pad controller driver and upcoming Tegra XHCI
host controller driver, can send
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.
diff --git
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
Add support for the on-chip XHCI host controller present on Tegra SoCs.
The driver is currently very basic: it loads the controller with its
firmware, starts the controller, and is able to service messages sent
by the controller's firmware.
On 06/25/2014 04:37 PM, Andrew Bresticker wrote:
On Wed, Jun 25, 2014 at 2:42 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra XHCI
On 06/25/2014 05:01 PM, Andrew Bresticker wrote:
On Wed, Jun 25, 2014 at 2:52 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
Add device-tree binding documentation for the XHCI controller present
on Tegra124 and later SoCs.
diff --git
On 06/25/2014 05:02 PM, Andrew Bresticker wrote:
On Wed, Jun 25, 2014 at 2:54 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
Add device-tree binding documentation for the XHCI controller present
on Tegra124 and later SoCs.
diff --git
On 06/10/2014 09:15 AM, Frederic Weisbecker wrote:
> irq work currently only supports local callbacks. However its code
> is mostly ready to run remote callbacks and we have some potential user.
>
> The full nohz subsystem currently open codes its own remote irq work
> on top of the scheduler ipi
On 06/24/2014 02:33 PM, Stephen Warren wrote:
> On 06/10/2014 09:15 AM, Frederic Weisbecker wrote:
>> irq work currently only supports local callbacks. However its code
>> is mostly ready to run remote callbacks and we have some potential user.
>>
>> The full nohz sub
On 06/18/2014 08:23 AM, Mikko Perttunen wrote:
> This adds support for the integrated AHCI-compliant Serial ATA
> controller present on the NVIDIA Tegra124 system-on-chip.
At a quick glance, this looks fine to me now. I'll wait for an ack to
take this patch through the Tegra tree, for the reasons
On 06/18/2014 08:23 AM, Mikko Perttunen wrote:
> This adds two clocks, SATA and SATA_OOB, to the Tegra124 clock initialization
> table. The clocks are needed for working SATA support.
Acked-by: Stephen Warren
(When I wrote that for v1, it applied to both patches 4 and 5, not just
patch 4)
On 06/24/2014 11:27 AM, Rasmus Villemoes wrote:
> The header file include/linux/platform_data/tegra_emc.h does not seem
> to be used anywhere. It was orphaned by a7cbe92c "ARM: tegra: remove
> tegra EMC scaling driver". Remove it.
Acked-by: Stephen Warren
Perhaps this should
On 06/23/2014 11:44 PM, Alexandre Courbot wrote:
> On 06/24/2014 04:01 AM, Stephen Warren wrote:
>> On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
>>> Input had been disabled by mistake on these pins, leading to issues with
>>> SDIO devices like the Wifi module not be
On 06/23/2014 11:44 PM, Alexandre Courbot wrote:
On 06/24/2014 04:01 AM, Stephen Warren wrote:
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
Input had been disabled by mistake on these pins, leading to issues with
SDIO devices like the Wifi module not being probed or random errors
occuring
On 06/24/2014 11:27 AM, Rasmus Villemoes wrote:
The header file include/linux/platform_data/tegra_emc.h does not seem
to be used anywhere. It was orphaned by a7cbe92c ARM: tegra: remove
tegra EMC scaling driver. Remove it.
Acked-by: Stephen Warren swar...@nvidia.com
Perhaps this should go
On 06/18/2014 08:23 AM, Mikko Perttunen wrote:
This adds two clocks, SATA and SATA_OOB, to the Tegra124 clock initialization
table. The clocks are needed for working SATA support.
Acked-by: Stephen Warren swar...@nvidia.com
(When I wrote that for v1, it applied to both patches 4 and 5, not just
On 06/18/2014 08:23 AM, Mikko Perttunen wrote:
This adds support for the integrated AHCI-compliant Serial ATA
controller present on the NVIDIA Tegra124 system-on-chip.
At a quick glance, this looks fine to me now. I'll wait for an ack to
take this patch through the Tegra tree, for the reasons I
On 06/24/2014 02:33 PM, Stephen Warren wrote:
On 06/10/2014 09:15 AM, Frederic Weisbecker wrote:
irq work currently only supports local callbacks. However its code
is mostly ready to run remote callbacks and we have some potential user.
The full nohz subsystem currently open codes its own
On 06/10/2014 09:15 AM, Frederic Weisbecker wrote:
irq work currently only supports local callbacks. However its code
is mostly ready to run remote callbacks and we have some potential user.
The full nohz subsystem currently open codes its own remote irq work
on top of the scheduler ipi when
On 06/23/2014 02:20 PM, Stephen Warren wrote:
> On 06/23/2014 02:11 PM, Nishanth Menon wrote:
>> On Mon, Jun 23, 2014 at 2:50 PM, Stephen Warren
>> wrote:
>>> On 06/20/2014 11:26 AM, Nishanth Menon wrote:
>>>> We use regmap regulator ops to enable/disable an
From: Stephen Warren
When setting up .enable_reg for an SMPS regulator, presumably we should
call PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE, ...) rather than using
LDO_BASE. This change makes the LCD panel and HDMI work again on the
NVIDIA Dalmore board anyway.
Cc: Alex Courbot
Cc: Keerthy
Cc
On 06/23/2014 02:11 PM, Nishanth Menon wrote:
> On Mon, Jun 23, 2014 at 2:50 PM, Stephen Warren wrote:
>> On 06/20/2014 11:26 AM, Nishanth Menon wrote:
>>> We use regmap regulator ops to enable/disable and check if regulator
>>> is enabled for various SMPS. How
On 06/20/2014 11:26 AM, Nishanth Menon wrote:
> We use regmap regulator ops to enable/disable and check if regulator
> is enabled for various SMPS. However, these depend on valid
> enable_reg, enable_mask and enable_value in regulator descriptor.
>
> Currently we do not populate these for SMPS
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
> Input had been disabled by mistake on these pins, leading to issues with
> SDIO devices like the Wifi module not being probed or random errors
> occuring on the SD card.
I thought the host controller always drove the clock, so there should be
no
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
> Two small but important fixes to SHIELD's pinmux configuration.
> The use of invalid properties caused the pinmux to not be applied
> at all. Also the setting for sdmmc clock lines resulted in random
> errors or even the impossibility to probe
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
Two small but important fixes to SHIELD's pinmux configuration.
The use of invalid properties caused the pinmux to not be applied
at all. Also the setting for sdmmc clock lines resulted in random
errors or even the impossibility to probe
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
Input had been disabled by mistake on these pins, leading to issues with
SDIO devices like the Wifi module not being probed or random errors
occuring on the SD card.
I thought the host controller always drove the clock, so there should be
no
On 06/20/2014 11:26 AM, Nishanth Menon wrote:
We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.
Currently we do not populate these for SMPS other
On 06/23/2014 02:11 PM, Nishanth Menon wrote:
On Mon, Jun 23, 2014 at 2:50 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/20/2014 11:26 AM, Nishanth Menon wrote:
We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend
From: Stephen Warren swar...@nvidia.com
When setting up .enable_reg for an SMPS regulator, presumably we should
call PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE, ...) rather than using
LDO_BASE. This change makes the LCD panel and HDMI work again on the
NVIDIA Dalmore board anyway.
Cc: Alex Courbot gnu
On 06/23/2014 02:20 PM, Stephen Warren wrote:
On 06/23/2014 02:11 PM, Nishanth Menon wrote:
On Mon, Jun 23, 2014 at 2:50 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 06/20/2014 11:26 AM, Nishanth Menon wrote:
We use regmap regulator ops to enable/disable and check if regulator
On 06/19/2014 07:25 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.
I've applied the series to Tegra's for-3.17/dt
On 06/19/2014 02:02 AM, Peter De Schrijver wrote:
> On Wed, Jun 18, 2014 at 05:37:54PM +0200, Stephen Warren wrote:
>> On 06/18/2014 06:18 AM, Peter De Schrijver wrote:
>>> On Tue, Jun 17, 2014 at 11:51:20PM +0200, Thierry Reding wrote:
>>>> * PGP Signed by an unknow
On 06/19/2014 01:49 AM, Alexandre Courbot wrote:
> Remove the regulator-always-on property from some regulators that do not
> need it. On recent kernels fixed regulators which supply is always on
> fail registration.
That sounds like a bug in the regulator core, which should be fixed there.
On 06/19/2014 01:49 AM, Alexandre Courbot wrote:
Remove the regulator-always-on property from some regulators that do not
need it. On recent kernels fixed regulators which supply is always on
fail registration.
That sounds like a bug in the regulator core, which should be fixed there.
After
On 06/19/2014 02:02 AM, Peter De Schrijver wrote:
On Wed, Jun 18, 2014 at 05:37:54PM +0200, Stephen Warren wrote:
On 06/18/2014 06:18 AM, Peter De Schrijver wrote:
On Tue, Jun 17, 2014 at 11:51:20PM +0200, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jun 17, 2014 at 05:01
On 06/19/2014 07:25 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.
I've applied the series to Tegra's for-3.17/dt branch.
On 06/18/2014 05:14 PM, Thierry Reding wrote:
> On Wed, Jun 18, 2014 at 04:09:06PM -0600, Stephen Warren wrote:
>> On 06/18/2014 04:03 PM, Thierry Reding wrote:
...
>>> From what I remember, Mike was fairly strongly opposing the idea of
>>> virtual clocks, but what y
On 06/18/2014 04:19 PM, Stéphane Marchesin wrote:
> On Wed, Jun 18, 2014 at 3:00 PM, Thierry Reding
> wrote:
>> On Wed, Jun 18, 2014 at 07:23:47PM +0200, Tomeu Vizoso wrote:
>>> On 06/17/2014 06:15 PM, Stephen Warren wrote:
>>>> On 06/17/2014 06:16 AM, Tomeu Viz
On 06/18/2014 04:03 PM, Thierry Reding wrote:
> On Wed, Jun 18, 2014 at 11:46:49AM -0600, Stephen Warren wrote:
>> On 06/18/2014 11:23 AM, Tomeu Vizoso wrote:
>>> On 06/17/2014 06:15 PM, Stephen Warren wrote:
>>>> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>>
On 06/18/2014 01:33 PM, Luis R. Rodriguez wrote:
> On Wed, Jun 18, 2014 at 09:56:03AM -0600, Stephen Warren wrote:
>> On 06/18/2014 05:14 AM, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez"
>>>
>>> We have to consider alignment for the ri
On 06/18/2014 11:23 AM, Tomeu Vizoso wrote:
> On 06/17/2014 06:15 PM, Stephen Warren wrote:
>> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>>> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>>>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>>>&g
On 06/18/2014 05:14 AM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> We have to consider alignment for the ring buffer both for the
> default static size, and then also for when an dynamic allocation
> is made when the log_buf_len=n kernel parameter is passed to set
> the size
PM +0200, Thierry Reding wrote:
>>>>> Old Signed by an unknown key
>>>>
>>>> On Mon, Jun 16, 2014 at 04:01:02PM -0600, Stephen Warren wrote:
>>>>> On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
>>>>>> Thi
by an unknown key
On Mon, Jun 16, 2014 at 04:01:02PM -0600, Stephen Warren wrote:
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
This symbol needs to be exported to power on rails without using
tegra_powergate_sequence_power_up. tegra_powergate_sequence_power_up
cannot be used in situations where
On 06/18/2014 05:14 AM, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
We have to consider alignment for the ring buffer both for the
default static size, and then also for when an dynamic allocation
is made when the log_buf_len=n kernel parameter is passed to set
the size
On 06/18/2014 11:23 AM, Tomeu Vizoso wrote:
On 06/17/2014 06:15 PM, Stephen Warren wrote:
On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
On 06/16/2014 10:02 PM, Stephen Warren wrote:
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
+#ifdef CONFIG_TEGRA124_EMC
+int tegra124_emc_reserve_bandwidth
On 06/18/2014 01:33 PM, Luis R. Rodriguez wrote:
On Wed, Jun 18, 2014 at 09:56:03AM -0600, Stephen Warren wrote:
On 06/18/2014 05:14 AM, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
We have to consider alignment for the ring buffer both for the
default static size
On 06/18/2014 04:03 PM, Thierry Reding wrote:
On Wed, Jun 18, 2014 at 11:46:49AM -0600, Stephen Warren wrote:
On 06/18/2014 11:23 AM, Tomeu Vizoso wrote:
On 06/17/2014 06:15 PM, Stephen Warren wrote:
On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
On 06/16/2014 10:02 PM, Stephen Warren wrote
On 06/18/2014 04:19 PM, Stéphane Marchesin wrote:
On Wed, Jun 18, 2014 at 3:00 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Jun 18, 2014 at 07:23:47PM +0200, Tomeu Vizoso wrote:
On 06/17/2014 06:15 PM, Stephen Warren wrote:
On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
On 06/16
On 06/18/2014 05:14 PM, Thierry Reding wrote:
On Wed, Jun 18, 2014 at 04:09:06PM -0600, Stephen Warren wrote:
On 06/18/2014 04:03 PM, Thierry Reding wrote:
...
From what I remember, Mike was fairly strongly opposing the idea of
virtual clocks, but what you're proposing here sounds like
On 06/17/2014 11:36 AM, Mikko Perttunen wrote:
> On 06/17/2014 08:04 PM, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Tuesday, June 17, 2014 10:10:23 AM Stephen Warren wrote:
>>> On 06/17/2014 06:14 AM, Bartlomiej Zolnierkiewicz wrote:
>>
>&g
On 06/17/2014 10:14 AM, Tejun Heo wrote:
> On Tue, Jun 17, 2014 at 12:13:20PM -0400, Tejun Heo wrote:
>> On Tue, Jun 17, 2014 at 10:10:23AM -0600, Stephen Warren wrote:
>>>> sata_writel() and sata_read() static inlines don't seem to add any value.
>>
On 06/17/2014 02:53 AM, Paul Bolle wrote:
> Doug,
>
> On Fri, 2014-06-13 at 08:22 -0700, Doug Anderson wrote:
>> On Fri, Jun 13, 2014 at 1:08 AM, Paul Bolle wrote:
>>> On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote:
This is a config option on the ChromeOS EC
On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>> This binding looks quite anaemic vs.
>> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
>> would expect
On 06/17/2014 06:14 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, June 04, 2014 02:32:38 PM Mikko Perttunen wrote:
>> This adds support for the integrated AHCI-compliant Serial ATA
>> controller present on the NVIDIA Tegra124 system-on-chip.
>> +static inline void
On 06/17/2014 08:17 AM, Tuomas Tynkkynen wrote:
> The tegra_ehci_hcd structure is located in the private space allocated
> by the core USB code so it must not be accessed after the HCD is
> freed.
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
This seems to be a
On 06/17/2014 08:17 AM, Tuomas Tynkkynen wrote:
The tegra_ehci_hcd structure is located in the private space allocated
by the core USB code so it must not be accessed after the HCD is
freed.
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
This seems to be a
On 06/17/2014 06:14 AM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday, June 04, 2014 02:32:38 PM Mikko Perttunen wrote:
This adds support for the integrated AHCI-compliant Serial ATA
controller present on the NVIDIA Tegra124 system-on-chip.
+static inline void sata_writel(struct
On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
On 06/16/2014 10:02 PM, Stephen Warren wrote:
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
This binding looks quite anaemic vs.
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
would expect that this binding needs all the EMC
On 06/17/2014 02:53 AM, Paul Bolle wrote:
Doug,
On Fri, 2014-06-13 at 08:22 -0700, Doug Anderson wrote:
On Fri, Jun 13, 2014 at 1:08 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote:
This is a config option on the ChromeOS EC
On 06/17/2014 10:14 AM, Tejun Heo wrote:
On Tue, Jun 17, 2014 at 12:13:20PM -0400, Tejun Heo wrote:
On Tue, Jun 17, 2014 at 10:10:23AM -0600, Stephen Warren wrote:
sata_writel() and sata_read() static inlines don't seem to add any value.
Can they be removed?
Such functions are quite
On 06/17/2014 11:36 AM, Mikko Perttunen wrote:
On 06/17/2014 08:04 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Tuesday, June 17, 2014 10:10:23 AM Stephen Warren wrote:
On 06/17/2014 06:14 AM, Bartlomiej Zolnierkiewicz wrote:
[...]
+static struct platform_driver tegra_ahci_driver
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> This adds support for the integrated AHCI-compliant Serial ATA
> controller present on the NVIDIA Tegra124 system-on-chip.
> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> +static int tegra_ahci_controller_init(struct
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> The Tegra AHCI device requires four clocks, so increase the maximum
> amount of handled clocks from three to four.
Tejun,
The SATA driver in patch 8/9 in this series would usually be applied in
your ATA tree. However, it has a lot of compile-time
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> This symbol needs to be exported to power on rails without using
> tegra_powergate_sequence_power_up. tegra_powergate_sequence_power_up
> cannot be used in situations where the driver wants to handle clocking
> by itself.
Thierry, are you OK with
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> This enables the integrated SATA controller on the Tegra124 system-on-chip
> on the Jetson TK1 board and adds regulators for the onboard Molex connector
> commonly used to power SATA devices. The regulators are marked always-on
> since they can be
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
> This patch adds device tree binding documentation for the SATA
> controller found on NVIDIA Tegra SoCs.
Just one nit below:
> diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt
>
ndency in the clock
patches, so they can go through a different tree to the rest of the
series without issue. These 2 patches look fine to me, so consider them:
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
On 06/16/2014 07:30 AM, Rob Herring wrote:
> On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner wrote:
...
>> Rob Herring wrote:
>>> Don't you need need to keep the kernel from allocating this memory by
>>> using one of the reserved memory mechanisms? The recently added one
>>> should be able to
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
> Request it based solely on the current mode's refresh rate. More
> accurate requirements can be requested in future patches.
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> + bandwidth = mode->clock *
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
> Adds functionality for registering memory bandwidth needs and setting
> the EMC clock rate based on that.
>
> Also adds API for setting floor and ceiling frequency rates.
> diff --git
>
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.
>
> The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
> RAM, eMMC, an LM95245 temperature sensor
On 04/30/2014 11:44 AM, Doug Anderson wrote:
> This adds the EC i2c tunnel (and devices under it) to the
> tegra124-venice2 device tree.
I've applied this to Tegra's for-3.17/dt branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 06/09/2014 04:52 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
> buses and PWM LEDs generically accessible from user space and an
> LM95245 temperature sensor chip.
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
On 06/04/2014 04:20 PM, Doug Anderson wrote:
> All ChromeOS ARM devices that have the standard "CrOS EC" have the
> same keyboard mapping. It's silly to include this same definition
> everywhere. Let's create a "dtsi" fragment that we can include from
> many different boards.
>
> This fragment
On 06/04/2014 04:20 PM, Doug Anderson wrote:
All ChromeOS ARM devices that have the standard CrOS EC have the
same keyboard mapping. It's silly to include this same definition
everywhere. Let's create a dtsi fragment that we can include from
many different boards.
This fragment is based
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
On 06/09/2014 04:52 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
buses and PWM LEDs generically accessible from user space and an
LM95245 temperature sensor chip. The
On 04/30/2014 11:44 AM, Doug Anderson wrote:
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
I've applied this to Tegra's for-3.17/dt branch.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
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.
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/16/2014 07:35 AM, Tomeu Vizoso wrote:
Adds functionality for registering memory bandwidth needs and setting
the EMC clock rate based on that.
Also adds API for setting floor and ceiling frequency rates.
diff --git
a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra124-emc.txt
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
Request it based solely on the current mode's refresh rate. More
accurate requirements can be requested in future patches.
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
+ bandwidth = mode-clock * window.bits_per_pixel /
On 06/16/2014 07:30 AM, Rob Herring wrote:
On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner jwer...@chromium.org wrote:
...
Rob Herring wrote:
Don't you need need to keep the kernel from allocating this memory by
using one of the reserved memory mechanisms? The recently added one
should be able
in the clock
patches, so they can go through a different tree to the rest of the
series without issue. These 2 patches look fine to me, so consider them:
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
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
This patch adds device tree binding documentation for the SATA
controller found on NVIDIA Tegra SoCs.
Just one nit below:
diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt
b/Documentation/devicetree/bindings/ata/tegra-sata.txt
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
This enables the integrated SATA controller on the Tegra124 system-on-chip
on the Jetson TK1 board and adds regulators for the onboard Molex connector
commonly used to power SATA devices. The regulators are marked always-on
since they can be used
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
This symbol needs to be exported to power on rails without using
tegra_powergate_sequence_power_up. tegra_powergate_sequence_power_up
cannot be used in situations where the driver wants to handle clocking
by itself.
Thierry, are you OK with this
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
The Tegra AHCI device requires four clocks, so increase the maximum
amount of handled clocks from three to four.
Tejun,
The SATA driver in patch 8/9 in this series would usually be applied in
your ATA tree. However, it has a lot of compile-time
On 06/04/2014 05:32 AM, Mikko Perttunen wrote:
This adds support for the integrated AHCI-compliant Serial ATA
controller present on the NVIDIA Tegra124 system-on-chip.
diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
+static int tegra_ahci_controller_init(struct
On 06/13/2014 08:10 AM, Arnd Bergmann wrote:
> On Tuesday 10 June 2014, 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, PWM
>> LEDs generically accessible from user space and an
On 06/13/2014 08:10 AM, Arnd Bergmann wrote:
On Tuesday 10 June 2014, 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, PWM
LEDs generically accessible from user space and an
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
On 06/10/2014 05: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
> options: USB 2.0, USB 3.0, PCIe and SATA.
>
> In addition to the pin
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
later three can 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
I assume this will be applied directly to the arm-soc tree.
--
To unsubscribe from this list: se
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
On 06/11/2014 06:53 PM, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> 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 appropriate review
1101 - 1200 of 5773 matches
Mail list logo
