With this series I get the kernel to output to the panel in 0.5s,
>> instead of 2.8s.
>>
>> Regards,
>>
>> Tomeu
>>
>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>
>> [1] https://lkml.org/lkml/2014/5/12/452
>>
>&
i.MX6UL can be powered off by programming SNVS.
When long press ON/OFF button(5 seconds),
PMIC_ON_REQ pin will be set to low and external
PMIC will be powered off.
And system can be powered on by long press ON/OFF
button again.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6ul-14x14-evk.
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> Signed-off-by: Zhou Wang
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8133cef..7cd8e47 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7854,6 +7854,13 @
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> This patch adds related DTS binding document for HiSilicon PCIe host driver.
>
> Signed-off-by: Zhou Wang
> ---
> .../devicetree/bindings/pci/hisilicon-pcie.txt | 46
> ++
> 1 file changed, 46 insertions(+
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> This patch adds PCIe host support for HiSilicon SoC Hip05.
>
> Signed-off-by: Zhou Wang
> ---
> drivers/pci/host/Kconfig | 8 ++
> drivers/pci/host/Makefile| 1 +
> drivers/pci/host/pcie-hisi.c | 254
> +++
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> move related operations to dw_pcie_host_init.
>
> In past, we use:
> pci_co
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> From: gabriele paoloni
>
> This patch is needed in order to unify the PCIe designware framework for ARM
> and
> ARM64 architectures. In the PCIe designware unification process we are calling
> pci_create_root_bus() passing a "sysd
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> From: gabriele paoloni
>
> Commit f4c55c5a3f7f "PCI: designware: Program ATU with untranslated
> address" added the calculation of PCI BUS addresses in designware,
> storing them in new fields added in "struct pcie_port". This
> ca
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> From: gabriele paoloni
>
> Commit f4c55c5a3f7f "PCI: designware: Program ATU with untranslated
> address" added the calculation of PCI BUS addresses in designware,
> storing them in new fields added in "struct pcie_port". This
> ca
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts
> use PCIe IP core from Synopsys, So this driver is base on designware PCIe
> driver.
>
> Hip05 is an ARMv8 architecture SoC. It should be able to use ARM
[+cc jingooh...@gmail.com]
On 2015/8/6 16:09, Zhou Wang wrote:
> This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts
> use PCIe IP core from Synopsys, So this driver is base on designware PCIe
> driver.
>
> Hip05 is an ARMv8 architecture SoC. It should be able to use ARM
On Thursday 06 August 2015 12:19 PM, Shawn Lin wrote:
> DesignWare MMC Controller's transfer mode should be decided
> at runtime instead of compile-time. So we remove this config
> option and read dw_mmc's register to select DMA master.
>
> Signed-off-by: Shawn Lin
Acked-by: Vineet Gupta
Thx,
-
On 2015/8/6 23:06, Jingoo Han wrote:
> On Thursday, August 06, 2015 10:53 PM, Gabriele Paoloni wrote:
>>
>> Hi all
>>
>> This patch has now been moved in "[PATCH v6 1/6] PCI: designware: move
>> calculation of bus addresses to
>> DRA7xx"
>
> To Zhou Wang,
>
> Please send your patches to 'jingooh
am4372-rtc string was already part of dts, introduced to identify
the rtc specific to am4372 family of SoCs. It was removed in one of the
previous patches. Adding back the same with appropriate documentation.
Signed-off-by: Keerthy
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 1 +
ar
On Sun, Aug 2, 2015 at 9:15 AM, Jonathan Cameron wrote:
> On 20/07/15 05:00, Matt Ranostay wrote:
>> APDS9960 is a combination of ALS, proximity, and gesture sensors.
>>
>> This patch adds support for these functions along with gain control,
>> integration time, and event thresholds.
>>
>> Signed-
Hi Dmitry,
Thanks for your explanation, I understand.
Reviewed-by: Scott Liu
Best Regards,
--
Scott
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: Friday, August 07, 2015 8:25 AM
> To: ELAN 劉嘉駿
> Cc: Dmitry Torokhov; linu
* Keerthy [150806 09:51]:
>
> Shall i re-do this patch without removing am4372-rtc? If you can drop this i
> can re-do without removing the original am4372 compatible.
OK please send a patch reverting the compatible change against the
current omap-for-v4.3/dt-v2 branch. Please also describe why
On Wed, 2015-08-05 at 10:44 +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 04, 2015 at 09:54:21PM +0800, Scott Shu wrote:
> > Add support for cpu enable-method "mediatek,mt6580-smp" for booting
> > secondary CPUs on MT6580.
>
> If you have CPU power domain support, and you power up and power
Hi Sascha,
On Thu, 2015-08-06 at 12:20 +0200, Sascha Hauer wrote:
> On Thu, Aug 06, 2015 at 05:13:21PM +0800, Daniel Kurtz wrote:
> > On Thu, Aug 6, 2015 at 5:00 PM, James Liao
> > wrote:
> > > Hi Sascha,
> > >
> > > On Thu, 2015-08-06 at 10:53 +0200, Sascha Hauer wrote:
> > >> On Thu, Aug 06, 2
On Thu, 2015-08-06 at 08:19 +0200, Sascha Hauer wrote:
> On Wed, Aug 05, 2015 at 06:47:03PM +0200, Matthias Brugger wrote:
> > On Tuesday, August 04, 2015 09:54:21 PM Scott Shu wrote:
> > > Add support for cpu enable-method "mediatek,mt6580-smp" for booting
> > > secondary CPUs on MT6580.
> > >
>
On Thu, 2015-08-06 at 12:03 +0200, Sascha Hauer wrote:
> On Thu, Aug 06, 2015 at 10:59:02AM +0800, Scott Shu wrote:
> > On Wed, 2015-08-05 at 10:50 +0200, Sascha Hauer wrote:
> > > don't do this then it indeed doesn't make much sense to put it into the
> > > same file.
> > >
> > > From what I see
On Thu, Aug 06, 2015 at 08:48:10AM -0500, Rob Herring wrote:
>On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
Thanks, Rob. All your comments will be covered in next revision.
Thanks,
Gavin
>> The PowerNV PCI hotplug driver is going to use the OF changeset
>> to manage the changed device sub-
On Wed, Aug 5, 2015 at 9:27 PM, Stephen Boyd wrote:
> On 07/28/2015 05:54 AM, Srinivas Kandagatla wrote:
>>
>> @@ -618,5 +633,77 @@
>> compatible = "qcom,tcsr-apq8064", "syscon";
>> reg = <0x1a40 0x100>;
>> };
>> +
>> +
Add support for the BCM7038-style PWM controller found in all BCM7xxx STB SoCs.
This controller has a hardcoded 2 channels per controller, and cascades a
variable frequency generator on top of a fixed frequency generator which offers
a range of a 148ns period all the way to ~622ms periods.
Signed-
Add a binding documentation for the Broadcom BCM7038 PWM controller found in
BCM7xxx chips.
Signed-off-by: Florian Fainelli
---
.../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/p
Hi,
This patch series add PWM support for the Broadcom BCM7xxx
chips which feature one or more PWM controllers capable of
output periods from 148ns to ~622ms using a combination of
variable and fixed frequency settings.
The controller does not support setting a polarity.
This is based on Thierry
On Thu, Aug 06, 2015 at 11:06:13PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 08/06/2015 03:47 AM, Simon Horman wrote:
>
> >>Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
> >>'renesas-devel-20150803-v4.2-rc5' tag. Here we add the GPIO device tree
> >>support
> >>f
On Thu, Aug 06, 2015 at 09:21:34AM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 2:47 AM, Simon Horman wrote:
> > On Tue, Aug 04, 2015 at 12:36:27AM +0300, Sergei Shtylyov wrote:
> >>Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
> >> 'renesas-devel-20150803
On Thu, Aug 06, 2015 at 09:17:38AM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 2:35 AM, Simon Horman wrote:
> > On Wed, Aug 05, 2015 at 10:58:04AM +0200, Geert Uytterhoeven wrote:
> >> This patch series add L1 and L2 cache descriptions to DT for r8a7740 and
> >> sh73a0, and migrates
Hi Scott,
On Thu, Aug 6, 2015 at 12:03 AM, ELAN 劉嘉駿 wrote:
> Hi Dmitry
>
> I am curious about how reset gpio works and I think the reset gpio
> at low level after elants_i2c_power_on(),
> So that the controller won't response anyway, please see below my
> question and correct me i
For BCM2836, we want to chain into this IRQ chip from the root
controller, and for chaining we need to do something else instead of
handle_IRQ() once we have decoded the IRQ.
Note that this changes the behavior a little bit: Previously for a
non-shortcut IRQ, we'd loop reading and handling the sec
This is a new per-cpu root interrupt controller on the Raspberry Pi 2,
which will chain to the bcm2835 interrupt controller for peripheral
interrupts.
Signed-off-by: Eric Anholt
Acked-by: Stephen Warren
---
.../interrupt-controller/brcm,bcm2836-l1-intc.txt | 37 ++
1 file c
The BCM2836 (Raspberry Pi 2) uses two levels of interrupt handling
with the CPU-local interrupts being the root, so we need to register
ours as chained off of the CPU's local interrupt.
Signed-off-by: Eric Anholt
Acked-by: Stephen Warren
---
v3: Use a separate compatible value to indicate that
https://github.com/anholt/linux/tree/bcm2836-irqchip
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This interrupt controller is the new root interrupt controller with
the timer, PMU events, and IPIs, and the bcm2835's interrupt
controller is chained off of it to handle the peripherals.
I wrote the interrupt chip support, while Andrea Merello wrote the IPI
code.
Signed-off-by: Eric Anholt
Sign
On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> >> On the whole following are my requirements:
> >> 1. to be able to communicate with non -flash
On Thu, Aug 6, 2015 at 9:11 AM, Tomeu Vizoso wrote:
> Delay matches of platform devices with OF nodes until late_initcall,
> when we are sure that all built-in drivers have been registered already.
> This is needed to prevent deferred probes because of some drivers not
> having registered yet.
>
>
rchives/dri-devel/2014-August/066527.html
>
> [1] https://lkml.org/lkml/2014/5/12/452
>
> [2] https://lkml.org/lkml/2015/6/17/305
>
> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>
> [4] https://lkml.org/lkml/2015/7/21/441a
>
> [5]
> http
Hello.
On 08/06/2015 03:47 AM, Simon Horman wrote:
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20150803-v4.2-rc5' tag. Here we add the GPIO device tree support
for the R8A7794 SoC.
[1/2] ARM: shmobile: r8a7794: add GPIO clocks
[2/2] ARM: shmobile
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Thursday, August 06, 2015 1:15 PM
> To: Yoder Stuart-B08248; Marc Zyngier; Will Deacon
> Cc: devicetree@vger.kernel.org; Lorenzo Pieralisi; a...@arndb.de;
> linux-ker...@vger.kernel.org;
> dda...@caviumnetwor
Hi Philipp,
Could you add Greg KH in the CC, for next merge window, we can request
Greg to take this driver via his tree.
Once the comments are fixed you can add my
Acked-by: Srinivas Kandagatla
On 06/08/15 17:28, Philipp Zabel wrote:
Hi Srinivas,
Am Donnerstag, den 06.08.2015, 17:20 +010
On 06/08/15 17:33, Philipp Zabel wrote:
Am Donnerstag, den 06.08.2015, 17:12 +0100 schrieb Srinivas Kandagatla:
On 04/08/15 14:02, Philipp Zabel wrote:
This patch documents the i.MX6 OCOTP device tree binding.
Signed-off-by: Philipp Zabel
---
.../devicetree/bindings/nvmem/imx-ocotp.txt
Hello Rob,
On 8/3/2015 10:13 AM, Rob Herring wrote:
On Mon, Aug 3, 2015 at 1:59 AM, Sagar Dharia wrote:
OF helper routine scans the SLIMbus DeviceTree, allocates resources,
and creates slim_devices according to the hierarchy.
Signed-off-by: Sagar Dharia
---
Documentation/devicetree/bindings
On 6 August 2015 at 18:14, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
> wrote:
>> On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
>>> On the whole following are my requirements:
>>> 1. to be able to communicate with non -flash SPI devices via c
On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> 1.Write to flash config register via config port to switch to QUAD MODE
> (or any mode that flash supports).
> 2. Populate QSPI_SPI_SETUP_REGx with flash read command, number of
> address bytes to use and dummy bytes required.
These thi
[...]
> > +PCI root complex
> > +
> > +
> > +Optional properties
> > +---
> > +
> > +- msi-map: Maps a Requester ID to an MSI controller and associated
> > + msi-specifier data. The property is an arbitrary number of tuples of
> > + (rid-base,msi-controller,msi-ba
On Wed, Aug 05, 2015 at 05:39:33PM +0100, Varun Sethi wrote:
> Hi Mark
> Thanks for the patch. Please find my comment inline.
>
> Regards
> Varun
>
> > -Original Message-
> > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > boun...@lists.linux-foundation.org] On Behalf Of
Hi Robert,
On Wed, Jul 29, 2015 at 1:52 PM, Robert Abel
wrote:
> On 30 Jun 2015 Grant Likely wroke
>> Looks good to me. I've made comments on patch 3. Also, you'll need to
>> include unittests before I can merge it.
>> [...]
>>> - Should the OF core handle this itself, by registering a notifie
On Thursday 06 August 2015 07:46 PM, Felipe Balbi wrote:
On Thu, Aug 06, 2015 at 06:55:57AM +0530, Keerthy wrote:
On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote:
On Wed, Aug 05, 2015 at 09:48:08PM +0530, Keerthy wrote:
On Wednesday 05 August 2015 09:44 PM, Felipe Balbi wrote:
On Thu, Aug 06, 2015 at 02:51:29PM +0100, Russell King - ARM Linux wrote:
> The M25P80 driver just appends additional bytes to the message to
> achieve this:
>
> struct m25p *flash = nor->priv;
> unsigned int dummy = nor->read_dummy;
>
> /* convert the dummy cycles to the
Am Donnerstag, den 06.08.2015, 17:12 +0100 schrieb Srinivas Kandagatla:
>
> On 04/08/15 14:02, Philipp Zabel wrote:
> > This patch documents the i.MX6 OCOTP device tree binding.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > .../devicetree/bindings/nvmem/imx-ocotp.txt | 20
> > +
Hi Srinivas,
Am Donnerstag, den 06.08.2015, 17:20 +0100 schrieb Srinivas Kandagatla:
> Few Nits..
>
> On 04/08/15 14:02, Philipp Zabel wrote:
> > +#include
> May be you can drop this?
Yes, that's a left-over and can be removed.
> BTW, who is taking care of the gated peripheral clock controlled
Few Nits..
On 04/08/15 14:02, Philipp Zabel wrote:
This driver handles the i.MX On-Chip OTP Controller found in
i.MX6Q/D, i.MX6S/DL, i.MX6SL, and i.MX6SX SoCs. Currently it
just returns the values stored in the shadow registers.
Signed-off-by: Philipp Zabel
---
This patch is based on the v9 "A
Hi Sudeep,
On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla wrote:
> On 05/08/15 11:44, Geert Uytterhoeven wrote:
>> On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla
>> wrote:
>>> On 05/08/15 09:58, Geert Uytterhoeven wrote:
Add the missing L2 cache-controller node. This will allow migration to
>
On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
wrote:
> On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
>> On the whole following are my requirements:
>> 1. to be able to communicate with non -flash SPI devices via config port
>> ( this functionality is supported by current dr
On 04/08/15 14:02, Philipp Zabel wrote:
This patch documents the i.MX6 OCOTP device tree binding.
Signed-off-by: Philipp Zabel
---
.../devicetree/bindings/nvmem/imx-ocotp.txt | 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/
On Thu, Aug 06, 2015 at 01:42:32PM +0200, Michal Suchanek wrote:
> On 6 August 2015 at 13:23, Mark Brown wrote:
> > Sure, but at the end of the day it's just emitting standard SPI messages
> > which don't know anything about flash. If those messages are a sensible
> > interface here then why bot
Add iio_hwmon node to expose the temperature channel on Vybrid
as hardware monitor device using the iio_hwmon driver.
Signed-off-by: Sanchayan Maity
---
arch/arm/boot/dts/vfxxx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dt
On Wednesday, July 22, 2015 9:45 AM, Bjorn Andersson wrote:
>
> The Qualcomm PM8941 WLED block is used for backlight and should therefor
> be in the backlight framework and not in the LED framework. This moves
> the driver and adapts to the backlight api instead.
>
> Acked-by: Jacek Anaszewski
>
On Thursday, August 06, 2015 10:53 PM, Gabriele Paoloni wrote:
>
> Hi all
>
> This patch has now been moved in "[PATCH v6 1/6] PCI: designware: move
> calculation of bus addresses to
> DRA7xx"
To Zhou Wang,
Please send your patches to 'jingooh...@gmail.com', instead of
'jg1@samsung.com'.
Walks the OF tree up and finds the closest ancestor that has a platform
device associated with it, probing it if isn't bound to a driver yet.
The above should ensure that the dependency represented by the passed OF
node is available, because probing a platform device should cause its
descendants t
Delay matches of platform devices with OF nodes until late_initcall,
when we are sure that all built-in drivers have been registered already.
This is needed to prevent deferred probes because of some drivers not
having registered yet.
The reason why only platform devices are delayed is that some o
When looking up a pin controller through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: T
...by moving the locking of regulator_list_mutex into
regulator_dev_lookup(), where it is iterated over.
The regulator device lock gets acquired before returning, and the caller
is responsible for releasing it after it's done with the regulator
device.
In _regulator_get() the regulator_list_mutex
When looking up a gpiochip through its firmware node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: T
When looking up a regulator through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu
When looking up a backlight device through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by:
When looking up a clock through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizo
When looking up a dpaux device through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tom
When looking up an i2c adapter or device through its OF node, probe it
if it hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-o
When looking up a phy through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
When looking up a pin controller through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: T
When looking up a PWM chip through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu V
When looking up a component through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu
When looking up a power supply through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tom
When looking up a phy provider through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tom
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> This changes of_fdt_unflatten_tree() so that it returns the allocated
> memory chunk for unflattened device-tree, which can be released once
> it's obsoleted.
>
> Signed-off-by: Gavin Shan
Acked-by: Rob Herring
> ---
> drivers/of/fdt.c
When looking up a panel through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizo
/21/441a
[5]
https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v5
[6]
http://kernelci.org/boot/all/job/collabora/kernel/v4.2-rc5-6548-g632b98c83840/
[7] http://kernelci.org/boot/all/job/next/kernel/next-20150806/
Changes in v3:
- Only delay platform devices with OF nodes
When looking up a DMA controller through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: T
On Thu, Aug 06, 2015 at 06:55:57AM +0530, Keerthy wrote:
>
>
> On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote:
> >On Wed, Aug 05, 2015 at 09:48:08PM +0530, Keerthy wrote:
> >>
> >>
> >>On Wednesday 05 August 2015 09:44 PM, Felipe Balbi wrote:
> >>>On Wed, Aug 05, 2015 at 09:21:05PM +053
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> unflatten_dt_node() is called recursively to unflatten FDT nodes
> with the assumption that FDT blob has only one root node, which
> isn't true when the FDT blob represents device sub-tree. This
> improves the function to supporting device sub-t
On Wed, 2015-08-05 at 18:47 +0200, Matthias Brugger wrote:
> On Tuesday, August 04, 2015 09:54:21 PM Scott Shu wrote:
> > Add support for cpu enable-method "mediatek,mt6580-smp" for booting
> > secondary CPUs on MT6580.
> >
> > Signed-off-by: Scott Shu
> > ---
> > arch/arm/mach-mediatek/platsmp.
Hi all
This patch has now been moved in "[PATCH v6 1/6] PCI: designware: move
calculation of bus addresses to DRA7xx"
commit "f4c55c5a3f7f (PCI: designware: Program ATU with untranslated address)"
has been reverted in
"[PATCH v6 3/6] PCI: designware: Add ARM64 support"
Gab
> -Original Mes
On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> On the whole following are my requirements:
> 1. to be able to communicate with non -flash SPI devices via config port
> ( this functionality is supported by current driver, I dont want to
> break it). Or pump any spi_message on to SPI bu
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> The PowerNV PCI hotplug driver is going to use the OF changeset
> to manage the changed device sub-tree, which requires those OF
> changeset functions are exported.
>
> Signed-off-by: Gavin Shan
> ---
> drivers/of/dynamic.c | 65
> ++
On 14 July 2015 at 10:29, Tomeu Vizoso wrote:
> If the gpio DT node has the gpio-ranges property, the range will be
> added by the gpio core and doesn't need to be added by the pinctrl
> driver.
>
> By having the gpio-ranges property, we have an explicit dependency from
> the gpio node to the pinc
Hi,
On Wed, Aug 05, 2015 at 11:14:45AM -0500, Felipe Balbi wrote:
> for them. Sure, it wasn't documented, but that's a problem of commit
> 73456012734b80442b33916406cfd13bf1b73acb (ARM: dts: AM4372: add few
> nodes) which, essentially, added that compatible flag without
> documenting it.
It was
On Thu, Aug 06, 2015 at 02:45:15PM +0800, Shawn Lin wrote:
> arch/mips/configs/pistachio_defconfig | 1 -
Acked-by: Ralf Baechle
Ralf
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
On 08/06/2015 03:52 PM, Russell King - ARM Linux wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>> Disclaimer: I am not familiar with the hardware for which this patch
>> adds support.
>>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is bas
I am Mrs. Gu Kailai and i intend to make a DONATION. please send your reply to
my personal email for more details via : w...@langsonenergy.com
===
The information in this email is confidential, and is intended solely for the
addressee(s).
On 6 August 2015 at 13:23, Mark Brown wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is basically supposed to implement m25p80.c in hardware when this flag
>> is set.
>
> But what in concrete t
On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
> However, I am familiar m25p80.c and as I understand it the controller
> is basically supposed to implement m25p80.c in hardware when this flag
> is set.
But what in concrete terms is that supposed to mean? It's currently
just an
From: Ezequiel Garcia
This commit introduces a new config, so the user can choose to enable
the General Purpose Timer based clocksource. This option is required
to have CPUFreq support.
Signed-off-by: Ezequiel Garcia
---
No changes from v4 just reposting 7/7.
arch/mips/Kconfig | 1
From: Ezequiel Garcia
The Pistachio SoC provides four general purpose timers, and allow
to implement a clocksource driver.
This driver can be used as a replacement for the MIPS GIC and MIPS R4K
clocksources and sched clocks, which are clocked from the CPU clock.
Given the general purpose timers
On 6 August 2015 at 12:22, Russell King - ARM Linux
wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>> Disclaimer: I am not familiar with the hardware for which this patch
>> adds support.
>>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is b
On Thu, Aug 06, 2015 at 11:22:25AM +0100, Russell King - ARM Linux wrote:
> If that's the case, then maybe you should consider whether using the SPI
> bus infrastructure is really the best way forward. Would it make more
> sense instead to adopt a different software structure, something more
> hi
Signed-off-by: Alexander Couzens
---
arch/mips/ath79/irq.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/mips/ath79/irq.c b/arch/mips/ath79/irq.c
index afb0096..dc76fa1 100644
--- a/arch/mips/ath79/irq.c
+++ b/arch/mips/ath79/irq.c
@@ -303,13 +303,20 @@ s
The ar7240 misc irq chip use ack handler instead of ack_mask handler.
All new ath79 SoCs use the ar7240 misc irq chip
Signed-off-by: Alexander Couzens
---
.../interrupt-controller/qca,ath79-misc-intc.txt | 18 +-
arch/mips/ath79/irq.c | 9 +
Initial version of DTSI for ProXstream2 and PH1-LD6b and DTS for
PH1-LD6b reference board.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 105 +++
arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi| 67 +++
1 - 100 of 159 matches
Mail list logo
