On 6 June 2016 at 12:13, Lin Huang wrote:
> on rk3399 platform, there is dfi conroller can monitor
> ddr load, base on this result, we can do ddr freqency
> scaling.
Hi Lin,
isn't the DDRMON in this SoC capable of raising interrupts when the
programmed utilization thresholds have been trespassed
so the current
testsuite still passes.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 +-
drivers/gpu/drm/i915/i915_dma.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 21 --
drivers/gpu/drm/i915/i915_irq.c | 39 +--
drivers/gpu/drm/i915/intel_displa
vers can now provide
frame CRCs by implementing the set_crc_source callback in
drm_crtc_funcs.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_crtc.c | 28 ++-
drivers/gpu/drm/drm_debugfs.c | 506 -
drivers/gpu/drm/drm_internal.h | 10 +
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/Makefile | 2
for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.
Thanks,
Tomeu
Tomeu Vizoso (3):
drm/i915/debugfs: Move out pipe CRC code
drm: Add API for capturing frame CRCs
drm/i915
They are deprecated and by moving their implementations to bind/unbind
we can call drm_connector_register_all instead of open-coding it.
Signed-off-by: Tomeu Vizoso
Cc: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 87 ++---
1 file changed, 30
ation
this bridge has.
Signed-off-by: Tomeu Vizoso
Cc: Caesar Wang
Cc: Douglas Anderson
Cc: Heiko Stuebner
Cc: Yakir Yang
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analog
This driver was still using the old legacy helpers and that caused a few
NULL dereferences when trying to call empty callbacks.
Signed-off-by: Tomeu Vizoso
Cc: Caesar Wang
Cc: Douglas Anderson
Cc: Heiko Stuebner
Cc: Yakir Yang
---
Hi,
these two patches apply on top of Daniel Vetter&#
Regardless of the status of the bridge, we want to receive HPD events.
Only disable it when suspending.
Signed-off-by: Tomeu Vizoso
Cc: Caesar Wang
Cc: Douglas Anderson
Cc: Heiko Stuebner
Cc: Javier Martinez Canillas
Cc: Yakir Yang
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 7
On 2 June 2016 at 08:25, Mark yao wrote:
> On 2016å¹´06æ02æ¥ 13:57, Tomeu Vizoso wrote:
>>
>> On 25 May 2016 at 03:33, Mark yao wrote:
>>>
>>> On 2016å¹´05æ25æ¥ 09:06, Mark yao wrote:
>>>
>>> On 2016å¹´05æ24æ¥ 18:11, Tomeu Vizoso wro
On 25 May 2016 at 03:33, Mark yao wrote:
> On 2016å¹´05æ25æ¥ 09:06, Mark yao wrote:
>
> On 2016å¹´05æ24æ¥ 18:11, Tomeu Vizoso wrote:
>
> Hi Tomeu
>>
>> Sorry for reply late.
>> I don't agree the changes:
>>
>> - if (!state->enable)
>&g
On 23 May 2016 at 08:32, Mark yao wrote:
> On 2016å¹´05æ05æ¥ 17:34, Tomeu Vizoso wrote:
>>
>> On 20 April 2016 at 16:23, Tomeu Vizoso
>> wrote:
>>>
>>> On 11 April 2016 at 03:15, Mark yao wrote:
>>>>
>>>> On 2016å¹´04æ08æ¥
nt field as
suggested by Daniel Stone.
v5: Only block if there's outstanding work if it's a blocking call.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 25 ++---
drivers/gpu/drm/rockchi
nt field as
suggested by Daniel Stone.
v5: Only block if there's outstanding work if it's a blocking call.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 25 ++---
drivers/gpu/drm/rockchi
On 20 April 2016 at 16:23, Tomeu Vizoso wrote:
> On 11 April 2016 at 03:15, Mark yao wrote:
>> On 2016å¹´04æ08æ¥ 18:54, Tomeu Vizoso wrote:
>>>
>>> On 8 April 2016 at 03:07, Mark yao wrote:
>>>>
>>>> On 2016å¹´04æ06æ¥ 18:14, Tomeu Vizoso
On 11 April 2016 at 03:15, Mark yao wrote:
> On 2016å¹´04æ08æ¥ 18:54, Tomeu Vizoso wrote:
>>
>> On 8 April 2016 at 03:07, Mark yao wrote:
>>>
>>> On 2016å¹´04æ06æ¥ 18:14, Tomeu Vizoso wrote:
>>>
>>> When a plane is being disabled but it&#
nt field as
suggested by Daniel Stone.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 19 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
3 files changed, 25 insertions(+), 1 deletion(-
On 8 April 2016 at 03:07, Mark yao wrote:
> On 2016å¹´04æ06æ¥ 18:14, Tomeu Vizoso wrote:
>
> When a plane is being disabled but it's still enabled, do check if the
> previous update has been completed by reading yrgb_mst back.
>
> Otherwise, pending pageflips would rema
When a VOP is disabled, it will stop raising interrupts. If we had a
pending pageflip when the VOP is disabled, userspace won't get that
event until the corresponding CRTC is enabled again.
So let's wait for any pending events that may be right before disabling
a CRTC.
Signed-off
When a plane is being disabled but it's still enabled, do check if the
previous update has been completed by reading yrgb_mst back.
Otherwise, pending pageflips would remain pending after a CRTC is
disabled.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.
On 4 April 2016 at 17:44, Daniel Stone wrote:
> Hi Tomeu,
>
> On 4 April 2016 at 14:55, Tomeu Vizoso wrote:
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> index 3b8f652698f8..8305bbd2a4d7 100644
>&g
#x27;s a sizeable delay when the worker
finishes, which introduces a race in which the client has already
received the last flip event but the next page flip ioctl will still
return -EBUSY because work_busy returns outdated information.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/
On 04/01/2016 01:26 PM, Mark yao wrote:
> On 2016å¹´03æ31æ¥ 16:08, Tomeu Vizoso wrote:
>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>> updated is requested and there is an earlier updated pending".
>>
>> v2: Use the status o
As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
updated is requested and there is an earlier updated pending".
v2: Use the status of the workqueue instead of vop->event, and don't add
a superfluous wait on the workqueue.
Signed-off-by: Tomeu Vizoso
--
On 31 March 2016 at 03:25, Mark yao wrote:
> On 2016å¹´03æ30æ¥ 21:48, Tomeu Vizoso wrote:
>>
>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>> updated is requested and there is an earlier updated pending".
>>
>> Also wa
As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
updated is requested and there is an earlier updated pending".
Also wait for the pending event to complete when a sync update is
requested.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_
On 19 January 2016 at 17:12, John Harrison wrote:
> On 19/01/2016 15:23, Gustavo Padovan wrote:
>>
>> Hi Daniel,
>>
>> 2016-01-19 Daniel Vetter :
>>
>>> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
From: Gustavo Padovan
This patch series de-stage the sync f
get a
valid framebuffer address before it's enabled again.
Signed-off-by: Tomeu Vizoso
Link:
http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw at
mail.gmail.com
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++
1 file changed, 15 insertions(+)
On 19 March 2016 at 02:15, Mark yao wrote:
> On 2016å¹´03æ18æ¥ 19:22, Tomeu Vizoso wrote:
>>
>> When the VOP is re-enabled, it will start scanning right away the
>> framebuffers that were configured from the last time, even if those have
>> been destroyed alrea
to them, but before the VOP is awaken from standby.
Signed-off-by: Tomeu Vizoso
Link:
http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw at
mail.gmail.com
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +
1 file changed, 13 insertions(+)
diff --git a
So that when DRM_IOCTL_MODE_SETCRTC is called without a FB nor mode, the
CRTC gets disabled.
Signed-off-by: Tomeu Vizoso
Link:
http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw at
mail.gmail.com
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ---
1 file changed
On 16 March 2016 at 16:23, Tomeu Vizoso wrote:
> On 15 March 2016 at 02:30, Mark yao wrote:
>> On 2016å¹´03æ14æ¥ 21:35, Tomeu Vizoso wrote:
>>>
>>> On 2 December 2014 at 10:15, Mark Yao wrote:
>>>>
>>>> diff --git a/drivers/gpu/drm/rockchip
On 15 March 2016 at 02:30, Mark yao wrote:
> On 2016å¹´03æ14æ¥ 21:35, Tomeu Vizoso wrote:
>>
>> On 2 December 2014 at 10:15, Mark Yao wrote:
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> b/drivers/gpu/drm/rockchip/rockchip_dr
On 2 December 2014 at 10:15, Mark Yao wrote:
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> new file mode 100644
> index 000..e7ca25b
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -0,0 +1,1455 @@
...
> +s
that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Ulf Hansson
---
Changes in v12:
- Include linux/pm_domain.h in vga_switcheroo.c for dev_pm_domain_set()
Changes in v11:
- Move calls to dev_pm_domain_set() out
a
no_pm_callbacks flag at the times when that could change.
Tomeu Vizoso (4):
device core: add device_is_bound()
PM / Domains: add setter for dev.pm_domain
PM / sleep: Go direct_complete if driver has no callbacks
USB / PM: Allow USB devices to remain runtime-suspended when sl
On 10 November 2015 at 10:33, Daniel Kurtz wrote:
[snip]
>
> The problem appears to be that:
> * On boot, platform_drv_probe() calls dev_pm_domain_attach() before
> drv->probe(); thus, it calls dev_pm_domain_attach() while the device
> is unbound.
>
> * However, for a platform_device, the reboo
that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Ulf Hansson
---
Changes in v11:
- Move calls to dev_pm_domain_set() out from &dev->power.lock as that
isn't needed for dev->pm_domain.
Changes in
m_callbacks to power/main.c as it
doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.
Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
no_pm_callbacks flag at the times when that could change.
Tomeu Vizoso (4):
devi
On 26 October 2015 at 11:51, Michael Turquette
wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so fo
On 25 October 2015 at 16:18, Rafael J. Wysocki wrote:
> On Wednesday, October 21, 2015 05:34:12 PM Tomeu Vizoso wrote:
>> Adds a function that sets the pointer to dev_pm_domain in struct device
>> and that warns if the device has already finished probing. The reason
>> why we
On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But
On 22 October 2015 at 02:54, Rafael J. Wysocki wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 201
d wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused. If I understood correc
that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Ulf Hansson
---
Changes in v9:
- Add docs noting the need for the device lock to be held before calling
dev_pm_domain_set()
Changes in v8:
- Add
n v5:
- Check for all dev_pm_ops instances associated to a device, updating a
no_pm_callbacks flag at the times when that could change.
Tomeu Vizoso (4):
device core: add device_is_bound()
PM / Domains: add setter for dev.pm_domain
PM / sleep: Go direct_complete if driver has no callbacks
US
On 20 October 2015 at 18:04, Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restric
On 19 October 2015 at 16:30, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> &
On 19 October 2015 at 15:18, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that&
On 18 October 2015 at 21:53, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > I can't see adding calls like this a
(2015-10-15 13:25:47 +0200)
Tomeu Vizoso (20):
driver core: handle -EPROBE_DEFER from bus_type.match()
ARM: amba: Move reading of periphid to amba_match()
of/platform: Point to struct device from device node
of
://git.collabora.co.uk/git/user/tomeu/linux.git
on-demand-probes-for-next
for you to fetch changes up to 587402133fe433759d2d535e5d92ead87fd7f615:
of/platform: Defer probes of registered devices (2015-10-14 10:08:23 +0200)
Tomeu Vizoso (20
that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
---
Changes in v9:
- Add docs noting the need for the device lock to be held before calling
dev_pm_domain_set()
Changes in v8:
- Add dev_pm_domain_set() and update code to
backs flag at the times when that could change.
Tomeu Vizoso (4):
device core: add device_is_bound()
PM / Domains: add setter for dev.pm_domain
PM / sleep: Go direct_complete if driver has no callbacks
USB / PM: Allow USB devices to remain runtime-suspended when sleeping
arch/a
that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
---
Changes in v8:
- Add dev_pm_domain_set() and update code to use it
arch/arm/mach-omap2/omap_device.c | 7 ---
drivers/acpi/acpi_lpss.c | 5 +++--
drivers
Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
no_pm_callbacks flag at the times when that could change.
Tomeu Vizoso (4):
device core: add device_is_bound()
PM / Domains: add setter for dev.pm_domain
PM / sleep: Go direct_complete if driver has no callbac
On 9 September 2015 at 03:33, Rob Herring wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso >> collabora.com> wrote:
>>>> Hello,
>>>&g
On 7 September 2015 at 22:50, Rob Herring wrote:
> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso
> wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer
>> than expected to be ready during boot (Stéphane Marchesin reported
ff-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/tegra/dpaux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 224a7dc8e4ed..96a2eec7e020 100644
--- a/drivers/gpu/drm/
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:
add OF-only API for
now. I think this same scheme could be used for machines with ACPI,
but I haven't been able to find one that had to defer its probes because
of the device probe order.
- Avoid unlocking the regulator device's mutex if we don't have a device
Changes in v2:
- A
On 30 July 2015 at 05:06, Rob Herring wrote:
> On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
> wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer
>> than expected to be ready during boot (Stéphane Marchesin reported what
>
d-off-by: Tomeu Vizoso
---
Changes in v2: None
drivers/gpu/drm/tegra/dpaux.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 07b26972f487..9a793158a571 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/
ff-by: Tomeu Vizoso
---
Changes in v2: None
drivers/gpu/drm/drm_panel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e037b7..374a964c3842 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -80,6
o the mechanism for probing devices on
demand is independent of the firmware format.
- Acquire regulator device lock before returning from regulator_dev_lookup()
Tomeu Vizoso (22):
platform: delay device-driver matches until late_initcall
of/platform: Set fwnode field for new devices
device
On 14 July 2015 at 13:07, Mark Brown wrote:
> On Tue, Jul 14, 2015 at 09:34:22AM +0200, Tomeu Vizoso wrote:
>> On 13 July 2015 at 17:42, Mark Brown wrote:
>
>> > No, I'm looking at how we already have all the "did all my dependencies
>> > appear" lo
On 13 July 2015 at 17:42, Mark Brown wrote:
> On Mon, Jul 13, 2015 at 02:10:45PM +0200, Tomeu Vizoso wrote:
>> On 1 July 2015 at 19:38, Mark Brown wrote:
>> > On Wed, Jul 01, 2015 at 11:41:06AM +0200, Tomeu Vizoso wrote:
>
>> >> +static void tegra_max98090_get_
On 1 July 2015 at 19:38, Mark Brown wrote:
> On Wed, Jul 01, 2015 at 11:41:06AM +0200, Tomeu Vizoso wrote:
>
>> +static void tegra_max98090_get_dependencies(struct fwnode_handle *fwnode,
>> + struct list_head *deps)
>> +{
>&g
On 2 July 2015 at 02:02, Rafael J. Wysocki wrote:
> On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
>> Adds API that allows callers to find out what other firmware nodes a
>> node depends on.
>>
>> Implementors of bindings documentation can register c
On 2 July 2015 at 01:29, Rafael J. Wysocki wrote:
> On Wednesday, July 01, 2015 11:40:56 AM Tomeu Vizoso wrote:
>> Delay matches of platform devices until late_initcall, when we are sure
>> that all built-in drivers have been registered already. This is needed
>> to pr
usage.
Signed-off-by: Tomeu Vizoso
tegra, kernel, usb
---
Changes in v2:
- Allocate the list of dependencies and pass it to the function that
fills it.
drivers/base/dd.c | 139 ++
1 file changed, 139 insertions(+)
diff --git a/drivers/base/d
So others can find out what dependencies a nvidia,tegra-audio-max98090
device has, as specified in
bindings/sound/nvidia,tegra-audio-max98090.txt.
Signed-off-by: Tomeu Vizoso
---
Changes in v2: None
sound/soc/tegra/tegra_max98090.c | 42 +++-
1 file changed
So others can find out what depends on pwm controllers, as specified
in bindings/pwm/pwm.txt.
Signed-off-by: Tomeu Vizoso
---
Changes in v2: None
drivers/pwm/core.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index
So others can find out what depends on regulators, as specified
in bindings/regulator/regulator.txt.
Signed-off-by: Tomeu Vizoso
---
Changes in v2: None
drivers/regulator/core.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers
So others can find out whether a firmware node depends on a phy as
specified in bindings/usb/nvidia,tegra20-ehci.txt.
Signed-off-by: Tomeu Vizoso
---
Changes in v2: None
drivers/usb/host/ehci-tegra.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/host/ehci
So others can find out what depends on backlight devices, as specified
in bindings/video/backlight/backlight.txt.
Signed-off-by: Tomeu Vizoso
---
Changes in v2: None
drivers/video/backlight/backlight.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/video
Add a small note that makes explicit that properties named 'backlight'
contain phandles to backlight nodes.
This is needed so that we can automatically extract dependencies on
backlight devices by assuming that a property with that name contains a
phandle to such a device.
Signed-off
So others can find out dependencies of host1x clients, as specified in
bindings/gpu/nvidia,tegra20-host1x.txt.
Signed-off-by: Tomeu Vizoso
---
Changes in v2: None
drivers/gpu/host1x/dev.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/host1x/dev.c
So the GPIO subsystem can be queried about the dependencies of nodes
that consume GPIOs, as specified in bindings/gpio/gpio.txt.
Signed-off-by: Tomeu Vizoso
---
Changes in v2: None
drivers/gpio/gpiolib.c | 54 ++
1 file changed, 54 insertions
To avoid duplicating code in upcoming patches that will check for
postfixes in strings, add strends().
Signed-off-by: Tomeu Vizoso
---
Changes in v2:
- Move strends to string.h
include/linux/string.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/string.h b
when a device node is going to be
probed without all its dependencies fulfilled.
Signed-off-by: Tomeu Vizoso
---
Changes in v2:
- Allow bindings implementations register a function instead of using
class callbacks, as not only subsystems implement firmware bindings.
drivers/base/property.c
revent any deferred probes once
devices are probed in dependency order.
Signed-off-by: Tomeu Vizoso
---
Changes in v2:
- Instead of delaying all probes until late_initcall, only delay matches
of platform devices that have a firmware node attached.
drivers/base/prope
perty to hold a phandle to the backlight device.
- Allocate the list of dependencies and pass it to the function that
fills it.
Tomeu Vizoso (12):
device: property: delay device-driver matches
device: property: find dependencies of a firmware node
string: Introduce strends()
gpio: register de
On 22 June 2015 at 14:02, Daniel Vetter wrote:
> We should never nest these since in theory kms drivers should know
> when a pipe is on/off and call the corresponding enable/disable
> functions for the vblank helper code only once. But for historical
> reasons (the shared-with-ums version of this
On 28 May 2015 at 06:33, Rob Herring wrote:
> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
> wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer than
>> expected to be ready during boot (Stéphane Marchesin reported what is
On 06/11/2015 12:17 PM, Alexander Holler wrote:
> Am 11.06.2015 um 10:12 schrieb Linus Walleij:
>> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
>> wrote:
>>> Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>>
i2c host comes out, probes the regulator driver, regulator driver
probes a
On 06/11/2015 10:15 AM, Linus Walleij wrote:
> On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso
> wrote:
>> On 10 June 2015 at 09:30, Linus Walleij wrote:
>
>>> regulator_get(...) -> not available, so:
>>> - identify target regulator provider - this will
On 10 June 2015 at 09:30, Linus Walleij wrote:
> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
> wrote:
>> On 2 June 2015 at 10:48, Linus Walleij wrote:
>
>>> This is what systemd is doing in userspace for starting services:
>>> ask for your dependencies
On 3 June 2015 at 21:57, Grygorii.Strashko at linaro.org
wrote:
> Hi Tomeu,
>
> On 05/28/2015 07:33 AM, Rob Herring wrote:
>> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso > collabora.com> wrote:
>>> I have a problem with the panel on my Tegra Chromebook taking
On 2 June 2015 at 10:48, Linus Walleij wrote:
> On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
> wrote:
>
>> have looked into ordered probing as a
>> better way of solving this than moving nodes around in the DT or playing with
>> initcall levels.
>>
>> Whil
When looking up a dpaux device through its DT node, ensure that the
corresponding device has been registered.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/tegra/dpaux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index
When looking up a panel through its DT node, ensure that the
corresponding device has been registered.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_panel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e
Tomeu
[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
[1] https://lkml.org/lkml/2014/5/12/452
Tomeu Vizoso (21):
regulator: core: Reduce critical area in _regulator_get
ARM: tegra: Add gpio-ranges property
ARM: tegra: Register drivers before devices
ARM: EXYNOS: Regi
As there isn't a way for the firmware on the Nyan chromebooks to hand
over the display to the kernel, and the kernel isn't redoing the whole
configuration at present.
With this patch, the SOR is brought to a known state and we get correct
display on every boot.
Signed-off-by: To
As there isn't a way for the firmware on the Nyan chromebooks to hand
over the display to the kernel, and the kernel isn't redoing the whole
configuration at present.
With this patch, the SOR is brought to a known state and we get correct
display on every boot.
Signed-off-by: To
As there isn't a way for the firmware on the Nyan chromebooks to hand
over the display to the kernel.
Signed-off-by: Tomeu Vizoso
Acked-by: Stephen Warren
Reviewed-by: Alexandre Courbot
---
drivers/gpu/drm/tegra/sor.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/dr
From: Stéphane Marchesin
This panel is used by the Nyan Blaze board and supported by the simple-panel
driver.
Signed-off-by: Stéphane Marchesin
[tomeu.vizoso at collabora.com: add device tree binding document]
Signed-off-by: Tomeu Vizoso
Acked-by: Stephen Warren
Reviewed-by: Alexandre
Stéphane Marchesin (1):
drm/panel: add support for Samsung LTN140AT29 panel
Tomeu Vizoso (10):
ARM: tegra: Change model of sound card in Nyan Big
ARM: tegra: Move out nyan-generic parts out from the nyan-big DT
ARM: tegra: Add DTS for the nyan-blaze board
ARM: tegra: Add node for trackp
On 2 March 2015 at 09:41, Alexandre Courbot wrote:
> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
> wrote:
>> As there isn't a way for the firmware on the Nyan chromebooks to hand
>> over the display to the kernel.
>
> Could this have a side-effect on models for whi
As there isn't a way for the firmware on the Nyan chromebooks to hand
over the display to the kernel.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/tegra/sor.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
301 - 400 of 416 matches
Mail list logo
