On 05/10/2014 06:00 AM, Vivek Gautam wrote:
Using devm_ioremap_resource() API should actually be preferred over
devm_ioremap(), since the former request the mem region first and then
gives back the ioremap'ed memory pointer.
devm_ioremap_resource() calls request_mem_region(), therby preventing
On 05/07/2014 04:37 PM, Christopher Freeman wrote:
On Wed, May 07, 2014 at 09:37:25AM -0700, Stephen Warren wrote:
On 05/06/2014 03:22 PM, Christopher Freeman wrote:
Get word-level granularity from hardware for calculating
the transfer count remaining.
diff --git a/drivers/dma/tegra20-apb
On 05/07/2014 02:02 AM, FanWu wrote:
...
I think the glitch you mentioned is indeed a problem for the vendors who
define the pinctrl-single,function-off which will be activated when
disabling setting.
pinctrl-single,function-off is one specific driver's way of
configuring what happens when a
On 05/09/2014 08:20 AM, Andreas Färber wrote:
> Am 08.05.2014 01:40, schrieb Alex Courbot:
>> On 05/08/2014 12:57 AM, Stephen Warren wrote:
>>> On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
>>>> Console rotation is needed for devices like Tegra Note 7 and NVID
On 05/09/2014 08:20 AM, Andreas Färber wrote:
Am 08.05.2014 01:40, schrieb Alex Courbot:
On 05/08/2014 12:57 AM, Stephen Warren wrote:
On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
Console rotation is needed for devices like Tegra Note 7 and NVIDIA
SHIELD to get the boot console
On 05/07/2014 05:40 PM, Alex Courbot wrote:
> On 05/08/2014 12:57 AM, Stephen Warren wrote:
>> On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
>>> Console rotation is needed for devices like Tegra Note 7 and NVIDIA
>>> SHIELD to get the boot console in the expec
On 05/06/2014 03:22 PM, Christopher Freeman wrote:
> bytes_transferred will overflow during long audio playbacks. Since
> the driver only ever consults this value modulo bytes_requested, store the
> value modulo bytes_requested.
The audio driver may only interpret the value modulo
On 05/06/2014 03:22 PM, Christopher Freeman wrote:
> Get word-level granularity from hardware for calculating
> the transfer count remaining.
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> +static int tegra_dma_wcount_in_bytes(struct dma_chan *dc)
A lot of the
On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
> Console rotation is needed for devices like Tegra Note 7 and NVIDIA
> SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update multi_v7_defconfig, and send
On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
Console rotation is needed for devices like Tegra Note 7 and NVIDIA
SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you please also update multi_v7_defconfig, and send
On 05/06/2014 03:22 PM, Christopher Freeman wrote:
Get word-level granularity from hardware for calculating
the transfer count remaining.
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
+static int tegra_dma_wcount_in_bytes(struct dma_chan *dc)
A lot of the code
On 05/06/2014 03:22 PM, Christopher Freeman wrote:
bytes_transferred will overflow during long audio playbacks. Since
the driver only ever consults this value modulo bytes_requested, store the
value modulo bytes_requested.
The audio driver may only interpret the value modulo bytes_requested,
On 05/07/2014 05:40 PM, Alex Courbot wrote:
On 05/08/2014 12:57 AM, Stephen Warren wrote:
On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
Console rotation is needed for devices like Tegra Note 7 and NVIDIA
SHIELD to get the boot console in the expected orientation.
I've squashed
On 05/02/2014 01:59 AM, Alexandre Courbot wrote:
> Tegra Note 7 is a consumer tablet embedding a Tegra 4 SoC with 1GB RAM
> and a 720p panel.
>
> The following hardware is enabled by this device tree: UART, eMMC, USB
> (needs external power), PMIC, backlight, DSI panel, keys.
>
> SD card, HDMI,
On 05/02/2014 01:59 AM, Alexandre Courbot wrote:
Tegra Note 7 is a consumer tablet embedding a Tegra 4 SoC with 1GB RAM
and a 720p panel.
The following hardware is enabled by this device tree: UART, eMMC, USB
(needs external power), PMIC, backlight, DSI panel, keys.
SD card, HDMI,
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'll happily take this into the Tegra tree once the patch containing the
binding it uses is applied.
--
To unsubscribe from this list: send the line
ok 11 (and perhaps could even be used to access
> tps65090 on the HP Chromebook 11 instead of using a special driver,
> but I haven't researched that enough).
The binding looks reasonable to me, so that part,
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsub
Add a check for NULL like the rest of the code
> does.
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
Ple
On 05/01/2014 01:10 AM, Alexandre Courbot wrote:
> Tegra Note 7 is a consumer tablet embedding a Tegra 4 SoC with 1GB RAM
> and a 720p panel.
>
> The following features are enabled by this device tree: UART, eMMC, USB
> (needs external power), PMIC, backlight, DSI panel, keys.
>
> SD card, HDMI,
On 05/01/2014 12:26 AM, Brian Norris wrote:
> This defconfig contains the CONFIG_M25P80 symbol, which is now
> dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy
> the new dependency.
Squashed into Tegra's for-3.16/defconfig branch.
--
To unsubscribe from this list: send the
On 05/01/2014 12:07 AM, Brian Norris wrote:
> On Tue, Apr 29, 2014 at 01:42:50PM -0600, Stephen Warren wrote:
>> I guess you could also just see if arm-soc (a...@kernel.org) will take
>> this patch, and deal with any merge conflicts that arise when they merge
>> all the sub-a
On 05/01/2014 12:07 AM, Brian Norris wrote:
On Tue, Apr 29, 2014 at 01:42:50PM -0600, Stephen Warren wrote:
I guess you could also just see if arm-soc (a...@kernel.org) will take
this patch, and deal with any merge conflicts that arise when they merge
all the sub-arch defconfig changes. I CC'd
On 05/01/2014 12:26 AM, Brian Norris wrote:
This defconfig contains the CONFIG_M25P80 symbol, which is now
dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy
the new dependency.
Squashed into Tegra's for-3.16/defconfig branch.
--
To unsubscribe from this list: send the
On 05/01/2014 01:10 AM, Alexandre Courbot wrote:
Tegra Note 7 is a consumer tablet embedding a Tegra 4 SoC with 1GB RAM
and a 720p panel.
The following features are enabled by this device tree: UART, eMMC, USB
(needs external power), PMIC, backlight, DSI panel, keys.
SD card, HDMI,
for NULL like the rest of the code
does.
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
a special driver,
but I haven't researched that enough).
The binding looks reasonable to me, so that part,
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
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'll happily take this into the Tegra tree once the patch containing the
binding it uses is applied.
--
To unsubscribe from this list: send the line unsubscribe
On 04/29/2014 01:06 PM, Brian Norris wrote:
> Hi Stephen,
>
> On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
>> On 04/17/2014 01:21 AM, Brian Norris wrote:
>>> These defconfigs contain the CONFIG_M25P80 symbol, which is now
>>> depende
On 04/29/2014 01:06 PM, Brian Norris wrote:
Hi Stephen,
On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:
On 04/17/2014 01:21 AM, Brian Norris wrote:
These defconfigs contain the CONFIG_M25P80 symbol, which is now
dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR
On 04/23/2014 10:46 AM, Tomasz Figa wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
On 04/28/2014 05:18 AM, Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
...
>> A lot of drivers probably only support one
>> master, so they can just set #iommu-cells=<0>, others might require
>> IDs that do not fit into one cell.
>
> You mean "#iommu-cells
On 04/28/2014 05:18 AM, Thierry Reding wrote:
On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
...
A lot of drivers probably only support one
master, so they can just set #iommu-cells=0, others might require
IDs that do not fit into one cell.
You mean #iommu-cells = 1 for
On 04/23/2014 10:46 AM, Tomasz Figa wrote:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
On 04/17/2014 01:21 AM, Brian Norris wrote:
> These defconfigs contain the CONFIG_M25P80 symbol, which is now
> dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
> relevant defconfigs.
>
> At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
I hadn't realized that
On 04/24/2014 12:22 PM, Thierry Reding wrote:
...
> The downside of not allowing the gpiod API to support the -gpio suffix
> is that we'll never be able to convert drivers that use such a binding
> and will forever have a hodgepodge of GPIO APIs that we need to support.
Perhaps rather than making
On 04/24/2014 12:22 PM, Thierry Reding wrote:
...
The downside of not allowing the gpiod API to support the -gpio suffix
is that we'll never be able to convert drivers that use such a binding
and will forever have a hodgepodge of GPIO APIs that we need to support.
Perhaps rather than making
On 04/17/2014 01:21 AM, Brian Norris wrote:
These defconfigs contain the CONFIG_M25P80 symbol, which is now
dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
relevant defconfigs.
At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
I hadn't realized that the
On 04/23/2014 06:32 AM, Lee Jones wrote:
> On Tue, 22 Apr 2014, Doug Anderson wrote:
>
>> This series adds the most critical cros_ec changes for newer boards
>> using cros_ec. Specifically:
>> * Fixes timing/locking issues with the previously upstreamed (but
>> never used upstream) cros_ec_spi
On 04/23/2014 06:32 AM, Lee Jones wrote:
On Tue, 22 Apr 2014, Doug Anderson wrote:
This series adds the most critical cros_ec changes for newer boards
using cros_ec. Specifically:
* Fixes timing/locking issues with the previously upstreamed (but
never used upstream) cros_ec_spi driver.
On 04/21/2014 01:35 PM, Doug Anderson wrote:
> Stephen,
>
> On Mon, Apr 21, 2014 at 11:18 AM, Stephen Warren
> wrote:
>> On 04/17/2014 11:59 AM, Doug Anderson wrote:
>>> This adds the EC i2c tunnel (and devices under it) to the
>>> tegra124-venice2 device t
ces change RX interrupt trigger from userland.
Reviewed-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 04/17/2014 11:59 AM, Doug Anderson wrote:
> This adds the EC i2c tunnel (and devices under it) to the
> tegra124-venice2 device tree.
The series,
Tested-by: Stephen Warren
I can apply this one patch once the other patches in the series are
acked or applied (in order to make sure
On 04/17/2014 12:36 PM, Doug Anderson wrote:
> On ARM Chromebooks we have a few devices that are accessed by both the
> AP (the main "Application Processor") and the EC (the Embedded
> Controller). These are:
> * The battery (sbs-battery).
> * The power management unit tps65090.
...
> On the
On 04/17/2014 12:36 PM, Doug Anderson wrote:
On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main Application Processor) and the EC (the Embedded
Controller). These are:
* The battery (sbs-battery).
* The power management unit tps65090.
...
On the Samsung ARM
On 04/17/2014 11:59 AM, Doug Anderson wrote:
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
The series,
Tested-by: Stephen Warren swar...@nvidia.com
I can apply this one patch once the other patches in the series are
acked or applied (in order to make
-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 at http://www.tux.org/lkml/
On 04/21/2014 01:35 PM, Doug Anderson wrote:
Stephen,
On Mon, Apr 21, 2014 at 11:18 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 04/17/2014 11:59 AM, Doug Anderson wrote:
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
diff --git a/arch/arm
On 04/16/2014 05:08 PM, Andrew Bresticker wrote:
> VDDIO_SDMMC3 is the VQMMC (I/O) supply, not the VMMC (core) supply,
> for the SD slot on Venice2.
I've applied this (one patch) to Tegra's for-3.16/dt branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 04/15/2014 08:08 PM, Yoshihiro YUNOMAE wrote:
> Hi Stephen,
>
> Thank you for your review.
>
> (2014/04/16 2:39), Stephen Warren wrote:
>> On 04/15/2014 02:06 AM, Yoshihiro YUNOMAE wrote:
>>> /* I found a bug in V5, so I resend this as V5.1. Please do not
>>
ting the GPIO value.
Reviewed-by: Stephen Warren
Tested-by: Stephen Warren
(not with a 'scope or anything, but an affected system boots in a stable
fashion with this applied)
Should this be CC: stable?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
On 04/15/2014 06:29 PM, Andrew Bresticker wrote:
>> sdhci@0,700b0600 {
>> status = "okay";
>> bus-width = <8>;
>> + vqmmc-supply = <_1v8>;
>
> It turns out this bit isn't needed as the initialization failures are
> instead due to +3V3_RUN
On 04/15/2014 06:29 PM, Andrew Bresticker wrote:
sdhci@0,700b0600 {
status = okay;
bus-width = 8;
+ vqmmc-supply = vddio_1v8;
It turns out this bit isn't needed as the initialization failures are
instead due to +3V3_RUN toggling, which
Warren swar...@nvidia.com
Tested-by: Stephen Warren swar...@nvidia.com
(not with a 'scope or anything, but an affected system boots in a stable
fashion with this applied)
Should this be CC: stable?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On 04/15/2014 08:08 PM, Yoshihiro YUNOMAE wrote:
Hi Stephen,
Thank you for your review.
(2014/04/16 2:39), Stephen Warren wrote:
On 04/15/2014 02:06 AM, Yoshihiro YUNOMAE wrote:
/* I found a bug in V5, so I resend this as V5.1. Please do not
review V5. */
Add tunable RX interrupt
On 04/16/2014 05:08 PM, Andrew Bresticker wrote:
VDDIO_SDMMC3 is the VQMMC (I/O) supply, not the VMMC (core) supply,
for the SD slot on Venice2.
I've applied this (one patch) to Tegra's for-3.16/dt branch.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On 04/15/2014 12:41 AM, Chen-Yu Tsai wrote:
> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> +Optional properties:
> +- clocks : phandle to clock to enable/disable
Oh, and can't we use clock-names
On 04/15/2014 12:41 AM, Chen-Yu Tsai wrote:
Patch description?
> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> +Required properties:
> +- gpios : At most two GPIO phandles
> +- gpio-names :
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
> VDDIO_SDMMC3 is the VQMMC supply, not the VMMC supply, for the SD
> slot. Add 1.8V_VDDIO as the VQMMC supply for the eMMC.
Is there documentation re: what vmmc-supply and vqmmc-supply actually
refer to? I looked a long while ago and couldn't
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
> If regulator_get_optional() returns EPROBE_DEFER, it indicates
> that the regulator may show up later (e.g. the DT property is
> present but the corresponding regulator may not have probed).
> Instead of continuing without the regulator, return
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
> Tegra SDHCI controllers, by default, report a base clock frequency
> of 208Mhz in SDHCI_CAPABILTIES which may or may not be equal to the
> actual base clock frequency.
Some explanation of why this "may or may not be equal to the actual base
clock
On 04/15/2014 02:06 AM, Yoshihiro YUNOMAE wrote:
> /* I found a bug in V5, so I resend this as V5.1. Please do not review V5. */
>
> Add tunable RX interrupt trigger I/F of FIFO buffers.
> Serial devices are used as not only message communication devices but control
> or sending communication
On 04/15/2014 02:06 AM, Yoshihiro YUNOMAE wrote:
/* I found a bug in V5, so I resend this as V5.1. Please do not review V5. */
Add tunable RX interrupt trigger I/F of FIFO buffers.
Serial devices are used as not only message communication devices but control
or sending communication devices.
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
Tegra SDHCI controllers, by default, report a base clock frequency
of 208Mhz in SDHCI_CAPABILTIES which may or may not be equal to the
actual base clock frequency.
Some explanation of why this may or may not be equal to the actual base
clock
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
If regulator_get_optional() returns EPROBE_DEFER, it indicates
that the regulator may show up later (e.g. the DT property is
present but the corresponding regulator may not have probed).
Instead of continuing without the regulator, return
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
VDDIO_SDMMC3 is the VQMMC supply, not the VMMC supply, for the SD
slot. Add 1.8V_VDDIO as the VQMMC supply for the eMMC.
Is there documentation re: what vmmc-supply and vqmmc-supply actually
refer to? I looked a long while ago and couldn't find
On 04/15/2014 12:41 AM, Chen-Yu Tsai wrote:
Patch description?
diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
+Required properties:
+- gpios : At most two GPIO phandles
+- gpio-names : Shall be
On 04/15/2014 12:41 AM, Chen-Yu Tsai wrote:
diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
+Optional properties:
+- clocks : phandle to clock to enable/disable
Oh, and can't we use clock-names
On 04/14/2014 04:31 AM, Bart Tanghe wrote:
> Is it the responsibility of the pwm driver to handle the pinmux of the
> io pins? Or is the end user, or a parent driver responsible to handle this?
> Idem for the clock?
The pinmux driver is responsible for writing to the pinmux registers.
This can be
On 04/14/2014 04:31 AM, Bart Tanghe wrote:
Is it the responsibility of the pwm driver to handle the pinmux of the
io pins? Or is the end user, or a parent driver responsible to handle this?
Idem for the clock?
The pinmux driver is responsible for writing to the pinmux registers.
This can be
4, 2014 at 4:51 AM, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> Implement the new DT property ti,irq-externally-inverted, and add an
>> equivalent platform data field to match. This allows the driver to
>> correctly automatically configure the IRQ output polari
, Stephen Warren swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com
Implement the new DT property ti,irq-externally-inverted, and add an
equivalent platform data field to match. This allows the driver to
correctly automatically configure the IRQ output polarity when the board
or SoC
On 04/09/2014 04:01 AM, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Apr 08, 2014 at 10:37:55AM +0200, Johannes Berg wrote:
>> On Tue, 2014-04-01 at 17:02 +0300, Heikki Krogerus wrote:
>>> I hope this one is OK with everyone.
>>
>> It's fine with me. Are you expecting me to pick up any of these
On 04/09/2014 04:01 AM, Heikki Krogerus wrote:
Hi,
On Tue, Apr 08, 2014 at 10:37:55AM +0200, Johannes Berg wrote:
On Tue, 2014-04-01 at 17:02 +0300, Heikki Krogerus wrote:
I hope this one is OK with everyone.
It's fine with me. Are you expecting me to pick up any of these patches,
or do
On 04/08/2014 05:02 PM, Tim Kryger wrote:
> On Thu, Apr 3, 2014 at 6:44 AM, Bart Tanghe wrote:
>> need some recommendation
>> the memory mapped io registers of the bcm2835 pwm hardware are spreaded
>> over the memory mapped io
>> gpio config 0x2024 - clk config 0x201010A0 - pwm configuration
On 04/08/2014 05:02 PM, Tim Kryger wrote:
On Thu, Apr 3, 2014 at 6:44 AM, Bart Tanghe bart.tan...@thomasmore.be wrote:
need some recommendation
the memory mapped io registers of the bcm2835 pwm hardware are spreaded
over the memory mapped io
gpio config 0x2024 - clk config 0x201010A0 -
the register. This lead to a situation where the PLLE
> programming would only work if the register hadn't been touched before.
The series,
Acked-by: Stephen Warren
(I might have squashed patches 1 and 2 together, but no matter)
I expect these patches should be CC: stable when applied?
--
To u
. This lead to a situation where the PLLE
programming would only work if the register hadn't been touched before.
The series,
Acked-by: Stephen Warren swar...@nvidia.com
(I might have squashed patches 1 and 2 together, but no matter)
I expect these patches should be CC: stable when applied
On 04/01/2014 02:35 PM, ste...@agner.ch wrote:
> From: Stefan Agner
>
> By using the SD/MMC host device ID as a starting point for block
> device numbering, one can reliably predict the first block device
> name (at least for the first controller).
That's not true. There's no guarantee that a
On 04/01/2014 02:35 PM, ste...@agner.ch wrote:
From: Stefan Agner ste...@agner.ch
By using the SD/MMC host device ID as a starting point for block
device numbering, one can reliably predict the first block device
name (at least for the first controller).
That's not true. There's no
On 03/31/2014 08:45 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> PLLE has M, N and P divider shift and width parameters that differ from
> the defaults. Furthermore, when clearing the M, N and P divider fields
> the corresponding masks were never shifted, thereby clearing only the
>
On 03/31/2014 08:45 AM, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
PLLE has M, N and P divider shift and width parameters that differ from
the defaults. Furthermore, when clearing the M, N and P divider fields
the corresponding masks were never shifted, thereby clearing
On 03/25/2014 08:29 PM, Alexandre Courbot wrote:
> CONFIG_FHANDLE is required by systemd >= 210 to spawn a serial TTY.
The series,
Acked-by: Stephen Warren
Patch 1/2,
Tested-by: Stephen Warren
(although not with the new systemd version that requires the change, but
rather for regre
On 03/25/2014 08:29 PM, Alexandre Courbot wrote:
CONFIG_FHANDLE is required by systemd = 210 to spawn a serial TTY.
The series,
Acked-by: Stephen Warren swar...@nvidia.com
Patch 1/2,
Tested-by: Stephen Warren swar...@nvidia.com
(although not with the new systemd version that requires the change
On 03/20/2014 05:48 AM, Mark Brown wrote:
> On Wed, Mar 19, 2014 at 04:44:00PM -0700, Arun Shamanna Lakshmi wrote:
>
> Don't top post and fix your mailer to word wrap within paragraphs, your
> mail is very hard to read.
>
>> If each bit of a 32 bit register maps to an input of a mux, then with
On 03/20/2014 05:48 AM, Mark Brown wrote:
On Wed, Mar 19, 2014 at 04:44:00PM -0700, Arun Shamanna Lakshmi wrote:
Don't top post and fix your mailer to word wrap within paragraphs, your
mail is very hard to read.
If each bit of a 32 bit register maps to an input of a mux, then with
the
On 03/19/2014 04:15 AM, Yoshihiro YUNOMAE wrote:
> Add tunable RX interrupt trigger I/F of FIFO buffers.
> Serial devices are used as not only message communication devices but control
> or sending communication devices. For the latter uses, normally small data
> will be exchanged, so user
On 03/18/2014 03:52 PM, Pantelis Antoniou wrote:
> Make of_find_node_by_path() handle aliases as prefixes.
>
> Originally by David Daney , but
> reworked according to remark by Grant Likely.
>
> Handles all cases without allocating memory as requested by
> Grant Likely
Why not just introduce a
On 03/19/2014 11:04 AM, Lee Jones wrote:
>>>>> From: Stephen Warren
>>>>>
>>>>> The FUSE7_REG register is not currently marked readable. This causes
>>>>> as3722_sd0_is_low_voltage() to emit an error during boot, and assume
>>>&
On 03/04/2014 06:55 PM, Lee Jones wrote:
>> From: Stephen Warren
>>
>> The FUSE7_REG register is not currently marked readable. This causes
>> as3722_sd0_is_low_voltage() to emit an error during boot, and assume
>> the range of the SD0 regulator:
>>
>> a
On 03/04/2014 06:55 PM, Lee Jones wrote:
From: Stephen Warren swar...@nvidia.com
The FUSE7_REG register is not currently marked readable. This causes
as3722_sd0_is_low_voltage() to emit an error during boot, and assume
the range of the SD0 regulator:
as3722-regulator as3722-regulator: Reg
On 03/19/2014 11:04 AM, Lee Jones wrote:
From: Stephen Warren swar...@nvidia.com
The FUSE7_REG register is not currently marked readable. This causes
as3722_sd0_is_low_voltage() to emit an error during boot, and assume
the range of the SD0 regulator:
as3722-regulator as3722-regulator: Reg
On 03/18/2014 03:52 PM, Pantelis Antoniou wrote:
Make of_find_node_by_path() handle aliases as prefixes.
Originally by David Daney dda...@caviumnetworks.com, but
reworked according to remark by Grant Likely.
Handles all cases without allocating memory as requested by
Grant Likely
On 03/19/2014 04:15 AM, Yoshihiro YUNOMAE wrote:
Add tunable RX interrupt trigger I/F of FIFO buffers.
Serial devices are used as not only message communication devices but control
or sending communication devices. For the latter uses, normally small data
will be exchanged, so user
On 03/06/2014 08:45 PM, Wei Ni wrote:
> On 03/07/2014 01:59 AM, Stephen Warren wrote:
>> On 03/04/2014 04:31 AM, Wei Ni wrote:
>>> Add dt node to describe the thermal zone for the nct1008.
>>
>>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
>>>
On 03/06/2014 08:43 PM, Chen-Yu Tsai wrote:
> On Fri, Mar 7, 2014 at 11:41 AM, Linus Walleij
> wrote:
>> On Wed, Mar 5, 2014 at 10:59 AM, Stephen Warren
>> wrote:
>>> On 03/04/2014 07:37 PM, Linus Walleij wrote:
>>>> On Wed, Mar 5, 2014 at 10:18 AM, Step
On 03/04/2014 04:31 AM, Wei Ni wrote:
> Add dt node to describe the thermal zone for the nct1008.
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
> b/arch/arm/boot/dts/tegra114-dalmore.dts
> + thermal-zones {
> + nct1008-local {
> +
Commit 4e5e4705bf69 "thermal: introduce device tree parser" introduced
the text below into Documentation/devicetree/bindings/thermal/thermal.txt:
> * The thermal-zones node
>
> The "thermal-zones" node is a container for all thermal zone nodes. It shall
> contain only sub-nodes describing
Commit 4e5e4705bf69 thermal: introduce device tree parser introduced
the text below into Documentation/devicetree/bindings/thermal/thermal.txt:
* The thermal-zones node
The thermal-zones node is a container for all thermal zone nodes. It shall
contain only sub-nodes describing thermal zones
On 03/04/2014 04:31 AM, Wei Ni wrote:
Add dt node to describe the thermal zone for the nct1008.
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
+ thermal-zones {
+ nct1008-local {
+ polling-delay-passive =
On 03/06/2014 08:43 PM, Chen-Yu Tsai wrote:
On Fri, Mar 7, 2014 at 11:41 AM, Linus Walleij linus.wall...@linaro.org
wrote:
On Wed, Mar 5, 2014 at 10:59 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 03/04/2014 07:37 PM, Linus Walleij wrote:
On Wed, Mar 5, 2014 at 10:18 AM, Stephen
1401 - 1500 of 5773 matches
Mail list logo
