On 09/09/2014 09:28 AM, Marcel Ziswiler wrote:
Integrate Freescale SGTL5000 analogue audio codec support.
Patches 2 and 3 look OK. I'll hold off applying them until patch 1 is
applied, just to make sure that the new DT binding there is accepted
before I apply patches using it. If you could
On 09/09/2014 09:28 AM, Marcel Ziswiler wrote:
This binding and driver describe/support playback to headphones, and
capture from line-in and microphone.
This driver is useful for the Toradex Apalis T30 and Colibri T30 modules.
Reviewed-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe
On 09/10/2014 08:33 AM, nick.d...@itdev.co.uk wrote:
From: Stephen Warren swar...@wwwdotorg.org
[reworked after comments by Dmitry Torokhov. Move free of input device into
separate function. Only call in paths that require it.]
Signed-off-by: Nick Dyer nick.d...@itdev.co.uk
I re-tested
On 09/10/2014 02:54 PM, Marcel Ziswiler wrote:
Integrate Freescale SGTL5000 analogue audio codec support.
Signed-off-by: Marcel Ziswiler mar...@ziswiler.com
Reviewed-by: Stephen Warren swar...@nvidia.com
No, definitely not; this patch has significant semantic changes since I
reviewed
trieve all the information I mentioned above.
Any other option has too many holes or special cases that aren't covered.
What is your opinion?
Cheers,
Mikko
On 08/21/2014 08:54 PM, Stephen Warren wrote:
On 08/21/2014 10:53 AM, Thierry Reding wrote:
On Thu, Aug 21, 2014 at 09:38:29AM -0600, Stephen Wa
/linux-arm-kernel/2014-July/268653.html
This patch moves clk_prepare/unprepare and clk_set_rate calls to
the probe function, leaving only clk_enable/disable to be
done on each transfer. This solves the locking issue.
Reviewed-by: Stephen Warren
--
To unsubscribe from this list: send the line
://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/268653.html
This patch moves clk_prepare/unprepare and clk_set_rate calls to
the probe function, leaving only clk_enable/disable to be
done on each transfer. This solves the locking issue.
Reviewed-by: Stephen Warren swar...@nvidia.com
the information I mentioned above.
Any other option has too many holes or special cases that aren't covered.
What is your opinion?
Cheers,
Mikko
On 08/21/2014 08:54 PM, Stephen Warren wrote:
On 08/21/2014 10:53 AM, Thierry Reding wrote:
On Thu, Aug 21, 2014 at 09:38:29AM -0600, Stephen Warren wrote
On 08/25/2014 11:29 AM, Stephen Warren wrote:
On 07/29/2014 10:21 AM, Stephen Warren wrote:
On 07/29/2014 08:25 AM, Thierry Reding wrote:
From: Thierry Reding
This will allow the Kconfig option to be shared among 32-bit and 64-bit
ARM.
This seems fine to me. I'd expect to apply it for 3.18
ou should still call
clk_prepare_enable() here (and clk_disable_unprepare() in .remove()) to
make sure the driver is more portable.
The frequency can be minimized by a clock_divider ( the pwm clock is default
disabled). this has to be done by
a clock driver, as mentioned in a previous comment by Stephe
On 08/25/2014 11:29 AM, Stephen Warren wrote:
On 07/29/2014 10:21 AM, Stephen Warren wrote:
On 07/29/2014 08:25 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This will allow the Kconfig option to be shared among 32-bit and 64-bit
ARM.
This seems fine to me. I'd expect
still call
clk_prepare_enable() here (and clk_disable_unprepare() in .remove()) to
make sure the driver is more portable.
The frequency can be minimized by a clock_divider ( the pwm clock is default
disabled). this has to be done by
a clock driver, as mentioned in a previous comment by Stephen
On 09/02/2014 03:34 PM, 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. The
On 09/02/2014 03:34 PM, Andrew Bresticker wrote:
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
The series,
Reviewed-by: Stephen Warren
I'd like Thierry to review at least the XUSB
er .enable() is a bad name as it seems to imply that a
muxing can also be disabled. Rename the callback to .set_mux()
and also take this opportunity to clean out any remaining
mentions of .disable() from the documentation.
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line &q
() is a bad name as it seems to imply that a
muxing can also be disabled. Rename the callback to .set_mux()
and also take this opportunity to clean out any remaining
mentions of .disable() from the documentation.
Acked-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list: send
On 09/02/2014 03:34 PM, Andrew Bresticker wrote:
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
The series,
Reviewed-by: Stephen Warren swar...@nvidia.com
I'd like Thierry to review
On 09/02/2014 03:34 PM, 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. The
From: Stephen Warren
dump_vma() was written to access fields within vma->vm_page_prot. However,
pgprot_t is sometimes a scalar and sometimes a struct (At least on ARM;
see arch/arm/include/asm/pgtable-2level-types.h). use macro pgprot_val()
to get the value, so the code is imm
On 07/29/2014 01:26 PM, Stephen Warren wrote:
On 07/29/2014 11:06 AM, Nick Dyer wrote:
On 29/07/14 17:16, Stephen Warren wrote:
...
I also found that removing the module (even without attempting a FW
update) yields:
After attempted FW update via sysfs:
root@localhost:~# rmmod
On 09/02/2014 05:56 AM, Wolfram Sang wrote:
On Fri, Aug 15, 2014 at 10:18:15AM -0600, Stephen Warren wrote:
On 08/15/2014 03:47 AM, Mikko Perttunen wrote:
Currently the i2c-tegra bus driver prepares, enables
and set_rates its clocks separately for each transfer.
This causes locking problems
On 08/31/2014 08:28 PM, Sahara wrote:
On Fri, 29 Aug 2014, Stephen Warren wrote:
On 08/28/2014 11:28 PM, Sahara wrote:
On Wed, 27 Aug 2014, Thierry Reding wrote:
On Thu, Aug 14, 2014 at 07:13:36PM +0900, kpark3...@gmail.com wrote:
From: Sahara
Although there are many obs_kernel_param
On 08/31/2014 08:28 PM, Sahara wrote:
On Fri, 29 Aug 2014, Stephen Warren wrote:
On 08/28/2014 11:28 PM, Sahara wrote:
On Wed, 27 Aug 2014, Thierry Reding wrote:
On Thu, Aug 14, 2014 at 07:13:36PM +0900, kpark3...@gmail.com wrote:
From: Sahara keun-o.p...@windriver.com
Although
On 09/02/2014 05:56 AM, Wolfram Sang wrote:
On Fri, Aug 15, 2014 at 10:18:15AM -0600, Stephen Warren wrote:
On 08/15/2014 03:47 AM, Mikko Perttunen wrote:
Currently the i2c-tegra bus driver prepares, enables
and set_rates its clocks separately for each transfer.
This causes locking problems
On 07/29/2014 01:26 PM, Stephen Warren wrote:
On 07/29/2014 11:06 AM, Nick Dyer wrote:
On 29/07/14 17:16, Stephen Warren wrote:
...
I also found that removing the module (even without attempting a FW
update) yields:
After attempted FW update via sysfs:
root@localhost:~# rmmod
From: Stephen Warren swar...@nvidia.com
dump_vma() was written to access fields within vma-vm_page_prot. However,
pgprot_t is sometimes a scalar and sometimes a struct (At least on ARM;
see arch/arm/include/asm/pgtable-2level-types.h). use macro pgprot_val()
to get the value, so the code
On 08/28/2014 11:28 PM, Sahara wrote:
On Wed, 27 Aug 2014, Thierry Reding wrote:
On Thu, Aug 14, 2014 at 07:13:36PM +0900, kpark3...@gmail.com wrote:
From: Sahara
Although there are many obs_kernel_param and its names are
earlyprintk and also EARLY_PRINTK is also enabled, we could not
see
On 08/28/2014 11:28 PM, Sahara wrote:
On Wed, 27 Aug 2014, Thierry Reding wrote:
On Thu, Aug 14, 2014 at 07:13:36PM +0900, kpark3...@gmail.com wrote:
From: Sahara keun-o.p...@windriver.com
Although there are many obs_kernel_param and its names are
earlyprintk and also EARLY_PRINTK is also
On 08/28/2014 05:54 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.
Applied to Tegra's for-3.18/soc branch.
--
To unsubscribe from this
On 08/28/2014 05:54 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.
Applied to Tegra's for-3.18/soc branch.
--
To unsubscribe from this
On 08/27/2014 03:56 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 11:19 AM, Stephen Warren wrote:
On 08/27/2014 12:13 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 10:50 AM, Stephen Warren
wrote:
On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12
On 08/27/2014 12:13 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 10:50 AM, Stephen Warren wrote:
On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:01 PM, Stephen Warren
wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
+static int
On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:01 PM, Stephen Warren wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only
On 08/27/2014 10:36 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:12 PM, Stephen Warren wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
- #phy-cells: Should be 1. The specifier is the index of the PHY to
reference.
See for the list of valid
values.
+- mboxes: Must
lines of code (despite the still-present
one-comment-per-line over-documentation), and 30 bytes of code on ARM
V7.
For the mailing list record only (since it's been applied),
Reviewed-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On 08/27/2014 10:30 AM, Alexander Holler wrote:
Am 27.08.2014 18:22, schrieb Stephen Warren:
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
It's not just optimisation but an important feature for new arm64 SoCs.
Given some Tegra discussions recently, in many cases the machine_desc
use on arm
On 08/27/2014 01:32 AM, Tomeu Vizoso wrote:
On 08/26/2014 07:17 PM, Stephen Warren wrote:
On 08/26/2014 07:12 AM, Tomeu Vizoso wrote:
Sets the EMC clock rate based on the bandwidth requirements
registered by
memory clients through the PM_QOS_MEMORY_BANDWIDTH class.
Note: this is just
On 08/27/2014 12:51 AM, Mikko Perttunen wrote:
This enables AHCI_TEGRA by default. This driver is required
for Serial ATA support on Tegra124-based boards.
Reviewed-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
On Wed, Aug 27, 2014 at 11:34:32AM +0100, Grant Likely wrote:
On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland wrote:
On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote:
Am 26.08.2014 10:49, schrieb Thierry Reding:
On Tue, Aug 26,
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
On Wed, Aug 27, 2014 at 11:34:32AM +0100, Grant Likely wrote:
On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland mark.rutl...@arm.com wrote:
On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote:
Am 26.08.2014 10:49, schrieb Thierry
On 08/27/2014 12:51 AM, Mikko Perttunen wrote:
This enables AHCI_TEGRA by default. This driver is required
for Serial ATA support on Tegra124-based boards.
Reviewed-by: Stephen Warren swar...@nvidia.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 08/27/2014 01:32 AM, Tomeu Vizoso wrote:
On 08/26/2014 07:17 PM, Stephen Warren wrote:
On 08/26/2014 07:12 AM, Tomeu Vizoso wrote:
Sets the EMC clock rate based on the bandwidth requirements
registered by
memory clients through the PM_QOS_MEMORY_BANDWIDTH class.
Note: this is just
On 08/27/2014 10:30 AM, Alexander Holler wrote:
Am 27.08.2014 18:22, schrieb Stephen Warren:
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
It's not just optimisation but an important feature for new arm64 SoCs.
Given some Tegra discussions recently, in many cases the machine_desc
use on arm
-comment-per-line over-documentation), and 30 bytes of code on ARM
V7.
For the mailing list record only (since it's been applied),
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...@vger.kernel.org
On 08/27/2014 10:36 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:12 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
- #phy-cells: Should be 1. The specifier is the index of the PHY to
reference.
See dt-bindings/pinctrl/pinctrl
On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:01 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While
On 08/27/2014 12:13 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 10:50 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
On Mon, Aug 25, 2014 at 12:01 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 08/18/2014 11:08 AM, Andrew
On 08/27/2014 03:56 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 11:19 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/27/2014 12:13 PM, Andrew Bresticker wrote:
On Wed, Aug 27, 2014 at 10:50 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 08/27/2014 11:38 AM, Andrew
On 07/16/2014 02:54 AM, Mikko Perttunen wrote:
This adds ATA, SATA_AHCI and AHCI_TEGRA support to tegra_defconfig
so that the SATA support will be automatically enabled.
I've applied this to Tegra's for-3.18/dt branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 08/26/2014 07:12 AM, Tomeu Vizoso wrote:
Sets the EMC clock rate based on the bandwidth requirements registered by
memory clients through the PM_QOS_MEMORY_BANDWIDTH class.
Note: this is just an example and not a proper driver for a external memory
controller. Its only purpose is to
reporting.
The series,
Tested-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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 08/26/2014 06:17 AM, Eduardo Valentin wrote:
On Tue, Aug 26, 2014 at 10:27:43AM +0800, Wei Ni wrote:
On 08/25/2014 08:23 PM, Mikko Perttunen wrote:
FWIW, please fix the authorship information for next version.
Sorry, I didn't get your point, did you mean I should remove the line
"From:
On 08/26/2014 06:17 AM, Eduardo Valentin wrote:
On Tue, Aug 26, 2014 at 10:27:43AM +0800, Wei Ni wrote:
On 08/25/2014 08:23 PM, Mikko Perttunen wrote:
FWIW, please fix the authorship information for next version.
Sorry, I didn't get your point, did you mean I should remove the line
From:
for
consistent error reporting.
The series,
Tested-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://vger.kernel.org/majordomo-info.html
Please read the FAQ
On 08/26/2014 07:12 AM, Tomeu Vizoso wrote:
Sets the EMC clock rate based on the bandwidth requirements registered by
memory clients through the PM_QOS_MEMORY_BANDWIDTH class.
Note: this is just an example and not a proper driver for a external memory
controller. Its only purpose is to
On 07/16/2014 02:54 AM, Mikko Perttunen wrote:
This adds ATA, SATA_AHCI and AHCI_TEGRA support to tegra_defconfig
so that the SATA support will be automatically enabled.
I've applied this to Tegra's for-3.18/dt branch.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On 08/18/2014 11:08 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. The
On 08/18/2014 11:08 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 08/18/2014 11:08 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.
The xHCI controller will also send messages
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
Add new bindings used for USB support by the Tegra XUSB pad controller.
This includes additional PHY types, USB-specific pinconfig properties, etc.
I'll mainly defer to Thierry for this patch, since he's the expert on
this HW module.
diff
On 08/25/2014 12:48 PM, Stephen Warren wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
diff --git
a/Documentation/devicetree
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only a single
communication channel, messages sent by the controller can be divided
into two groups: those intended for
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
diff --git
a/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
On 08/19/2014 03:06 AM, Tomeu Vizoso wrote:
On 19 August 2014 11:03, Pavel Machek wrote:
On Tue 2014-08-19 10:38:43, Tomeu Vizoso wrote:
Sets the EMC clock rate based on the bandwidth requirements registered by
memory clients through the PM_QOS_MEMORY_BANDWIDTH class.
Note: this is just an
On 08/07/2014 05:01 PM, Tuomas Tynkkynen wrote:
Some mach-specific drivers that don't require their own node in the device tree
(for example drivers/soc/*, cpufreq, cpuidle etc.) want to match on the device
tree root compatible property instead. Instead of open-coding (and forgetting
to call
On 07/11/2014 08:18 AM, Mikko Perttunen wrote:
Hi everyone,
this series adds support for the EMC (external memory controller) clock
in the Tegra124 system-on-chip. The series has been tested on Jetson TK1.
The first two patches remove the old "emc_mux" and "emc" clocks from the
clock tree and
On 07/11/2014 08:18 AM, Mikko Perttunen wrote:
Add these clocks to the binding header so that EMC timings that have
them as parent can refer to the clocks.
Peter, I assume this patch (and patch 4/8 too) will be needed by any EMC
driver, whether it's part of this series or Tomeu Vizoso's work.
On 07/29/2014 10:21 AM, Stephen Warren wrote:
On 07/29/2014 08:25 AM, Thierry Reding wrote:
From: Thierry Reding
This will allow the Kconfig option to be shared among 32-bit and 64-bit
ARM.
This seems fine to me. I'd expect to apply it for 3.18, provided I get
an ack from Russell as drivers
On 07/16/2014 02:54 AM, Mikko Perttunen wrote:
This adds the integrated AHCI-compliant Serial ATA controller present
in Tegra124 systems-on-chip to the Tegra124 device tree.
I have applied patches 2 and 3 to Tegra's for-3.18/dt branch. I fixed
the DT node sort order when doing so.
I can't
On 07/16/2014 02:54 AM, Mikko Perttunen wrote:
This adds the integrated AHCI-compliant Serial ATA controller present
in Tegra124 systems-on-chip to the Tegra124 device tree.
I have applied patches 2 and 3 to Tegra's for-3.18/dt branch. I fixed
the DT node sort order when doing so.
I can't
On 07/29/2014 10:21 AM, Stephen Warren wrote:
On 07/29/2014 08:25 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This will allow the Kconfig option to be shared among 32-bit and 64-bit
ARM.
This seems fine to me. I'd expect to apply it for 3.18, provided I get
an ack from
On 07/11/2014 08:18 AM, Mikko Perttunen wrote:
Add these clocks to the binding header so that EMC timings that have
them as parent can refer to the clocks.
Peter, I assume this patch (and patch 4/8 too) will be needed by any EMC
driver, whether it's part of this series or Tomeu Vizoso's work.
On 08/07/2014 05:01 PM, Tuomas Tynkkynen wrote:
Some mach-specific drivers that don't require their own node in the device tree
(for example drivers/soc/*, cpufreq, cpuidle etc.) want to match on the device
tree root compatible property instead. Instead of open-coding (and forgetting
to call
On 07/11/2014 08:18 AM, Mikko Perttunen wrote:
Hi everyone,
this series adds support for the EMC (external memory controller) clock
in the Tegra124 system-on-chip. The series has been tested on Jetson TK1.
The first two patches remove the old emc_mux and emc clocks from the
clock tree and the
On 08/19/2014 03:06 AM, Tomeu Vizoso wrote:
On 19 August 2014 11:03, Pavel Machek pa...@ucw.cz wrote:
On Tue 2014-08-19 10:38:43, Tomeu Vizoso wrote:
Sets the EMC clock rate based on the bandwidth requirements registered by
memory clients through the PM_QOS_MEMORY_BANDWIDTH class.
Note: this
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
diff --git
a/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only a single
communication channel, messages sent by the controller can be divided
into two groups: those intended for
On 08/25/2014 12:48 PM, Stephen Warren wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
diff --git
a/Documentation/devicetree
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
Add new bindings used for USB support by the Tegra XUSB pad controller.
This includes additional PHY types, USB-specific pinconfig properties, etc.
I'll mainly defer to Thierry for this patch, since he's the expert on
this HW module.
diff
On 08/18/2014 11:08 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.
The xHCI controller will also send messages
On 08/18/2014 11:08 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 08/18/2014 11:08 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. The
On 08/22/2014 09:06 AM, Marcel Ziswiler wrote:
Working on Gigabit/PCIe support in U-Boot for Apalis T30 I realised
that the current device tree source includes for our modules only
happen to work due to referencing the on-carrier 5v0 supply from USB
which is not at all available on-module. The
On 08/22/2014 09:06 AM, Marcel Ziswiler wrote:
Working on Gigabit/PCIe support in U-Boot for Apalis T30 I realised
that the current device tree source includes for our modules only
happen to work due to referencing the on-carrier 5v0 supply from USB
which is not at all available on-module. The
On 08/21/2014 01:08 PM, Felipe Balbi wrote:
Currently, ahci_tegra doesn't build because it includes a file that
doesn't exist.
The problem is that first commit 306a7f9 (ARM: tegra: Move includes to
include/soc/tegra) renamed include/linux/tegra-powergate.h to
include/soc/tegra/powergate.h.
On 08/21/2014 10:53 AM, Thierry Reding wrote:
On Thu, Aug 21, 2014 at 09:38:29AM -0600, Stephen Warren wrote:
On 08/21/2014 12:58 AM, Thierry Reding wrote:
On Wed, Aug 20, 2014 at 02:16:49PM -0600, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Hardware-triggered
On 08/21/2014 10:04 AM, Eduardo Valentin wrote:
Stephen,
On Wed, Aug 20, 2014 at 01:44:00PM -0600, Stephen Warren wrote:
On 08/06/2014 04:25 AM, Mikko Perttunen wrote:
This adds critical trip points to the Jetson TK1 device tree.
The device will do a controlled shutdown when either the CPU
On 08/21/2014 01:05 AM, Thierry Reding wrote:
On Wed, Aug 20, 2014 at 02:19:35PM -0600, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Sometimes, hardware blocks want to issue requests to devices
connected to I2C buses by itself. In such case, the bus the
target device
On 08/21/2014 07:11 AM, Mikko Perttunen wrote:
On 20/08/14 23:25, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
This adds a device tree controlled option to enable PMC-based
thermal reset in overheating situations. Thermtrip is supported on
Tegra30, Tegra114 and Tegra124
On 08/21/2014 12:58 AM, Thierry Reding wrote:
On Wed, Aug 20, 2014 at 02:16:49PM -0600, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Hardware-triggered thermal reset requires configuring the I2C
reset procedure. This configuration is read from the device tree,
so
On 08/21/2014 12:58 AM, Thierry Reding wrote:
On Wed, Aug 20, 2014 at 02:16:49PM -0600, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Hardware-triggered thermal reset requires configuring the I2C
reset procedure. This configuration is read from the device tree,
so
On 08/21/2014 07:11 AM, Mikko Perttunen wrote:
On 20/08/14 23:25, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
This adds a device tree controlled option to enable PMC-based
thermal reset in overheating situations. Thermtrip is supported on
Tegra30, Tegra114 and Tegra124
On 08/21/2014 01:05 AM, Thierry Reding wrote:
On Wed, Aug 20, 2014 at 02:19:35PM -0600, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Sometimes, hardware blocks want to issue requests to devices
connected to I2C buses by itself. In such case, the bus the
target device
On 08/21/2014 10:04 AM, Eduardo Valentin wrote:
Stephen,
On Wed, Aug 20, 2014 at 01:44:00PM -0600, Stephen Warren wrote:
On 08/06/2014 04:25 AM, Mikko Perttunen wrote:
This adds critical trip points to the Jetson TK1 device tree.
The device will do a controlled shutdown when either the CPU
On 08/21/2014 10:53 AM, Thierry Reding wrote:
On Thu, Aug 21, 2014 at 09:38:29AM -0600, Stephen Warren wrote:
On 08/21/2014 12:58 AM, Thierry Reding wrote:
On Wed, Aug 20, 2014 at 02:16:49PM -0600, Stephen Warren wrote:
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Hardware-triggered
On 08/21/2014 01:08 PM, Felipe Balbi wrote:
Currently, ahci_tegra doesn't build because it includes a file that
doesn't exist.
The problem is that first commit 306a7f9 (ARM: tegra: Move includes to
include/soc/tegra) renamed include/linux/tegra-powergate.h to
include/soc/tegra/powergate.h.
On 08/20/2014 02:02 PM, Andreas Färber wrote:
Hi Javier,
Am 20.08.2014 17:39, schrieb Javier Martinez Canillas:
As you already know when you apply a patch with git am, everything
that is between a line with 3 dashes line (---) and the actual diff is
omitted since that is where the generated
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
This adds a device tree controlled option to enable PMC-based
thermal reset in overheating situations. Thermtrip is supported on
Tegra30, Tegra114 and Tegra124. The thermal reset only works when
the thermal sensors are calibrated, so a soctherm
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Hardware-triggered thermal reset requires configuring the I2C
reset procedure. This configuration is read from the device tree,
so document the relevant properties in the binding documentation.
diff --git
On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
Sometimes, hardware blocks want to issue requests to devices
connected to I2C buses by itself. In such case, the bus the
target device resides on must be configured into a register.
For this purpose, each I2C controller has a defined ID known
by the
801 - 900 of 5773 matches
Mail list logo
