absence of winsrv support in QEMU (Dave Airlie)
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 39 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 165 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 66
o the host part of a resource, so the extra copy in
TRANSFER_TO_HOST isn't needed.
Have pushed the QEMU counterpart to this branch, though it isn't as
polished atm:
https://gitlab.collabora.com/tomeu/qemu/commits/winsrv-wip
Thanks,
Tomeu
Tomeu Vizoso (2):
drm/virtio: Add window serve
When retrieving queued messages from the compositor in the host for
clients in the guest, handle buffers that may be passed.
These buffers should have been mapped to the guest's address space, for
example via the KVM_SET_USER_MEMORY_REGION ioctl.
Signed-off-by: Tomeu Vizoso
---
driver
On 1 February 2018 at 17:36, Gerd Hoffmann wrote:
Hi,
Sorry for joining the party late. Had a broken finger and was
offline for a bunch of weeks (and a buif backlog afterwards ...).
Hi, no problem, hope it's fine now.
This is to allow clients running within VMs to be able to
communicate wit
On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
Hi,
Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar functionality in
virtio-gpu.
The reason for abandoning that approach was the type of objects that
could be shared via virtio
On 02/05/2018 05:03 PM, Gerd Hoffmann wrote:
On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
Hi,
Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar function
On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote:
On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
Creation of shareable buffer by guest
-
1. Client requests virtio driver to create a buffer suitable for sharing
with host (DRM_VIRTGP
On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
Hi,
Hmm? I'm assuming the wayland client (in the guest) talks to the
wayland proxy, using the wayland protocol, like it would talk to a
wayland display server. Buffers must be passed from client to
server/proxy somehow, probably using fd passing
Hi Gerd and Stefan,
can we reach agreement on whether vsock should be involved in this?
Thanks,
Tomeu
On 02/07/2018 10:49 AM, Tomeu Vizoso wrote:
On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
Hi,
Hmm? I'm assuming the wayland client (in the guest) talks to the
wayland proxy, usin
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
Hi,
can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol. Use a wayland protocol extension to
reference the buffers in stdvg
On 02/12/2018 03:27 PM, Gerd Hoffmann wrote:
On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
Hi,
can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and
On 11/27/2017 11:59 AM, Stefan Hajnoczi wrote:
On Thu, Nov 23, 2017 at 09:17:02AM +0100, Tomeu Vizoso wrote:
On 11/22/2017 04:47 PM, Stefan Hajnoczi wrote:
On Wed, Nov 22, 2017 at 10:54 AM, Stefan Hajnoczi wrote:
I wonder if it would be cleaner to extend virtio-gpu for this use case
instead
If the wait timeouts, the caps are probably invalid and we shouldn't be
passing them to userspace.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/v
tested with Wayland clients that make use of wl_shm to
pass buffers to the compositor, but is expected to work similarly for X
clients that make use of MIT-SHM with FD passing.
Signed-off-by: Tomeu Vizoso
Cc: Zach Reizner
---
Hi,
this work is based on the virtio_wl driver in the ChromeOS kernel
: Tomeu Vizoso
Cc: Zach Reizner
---
Hi,
this work is based on the virtio_wl driver in the ChromeOS kernel by
Zach Reizner, currently at:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
There's two features missing in this patch
On 26 December 2017 at 19:19, Matt Roper wrote:
> On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote:
>> On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote:
>> > I forgot to include this brief information about this patch series.
>> >
>> > This patch series contains the impleme
On 28 December 2017 at 12:53, Tomeu Vizoso wrote:
> This is to allow clients running within VMs to be able to communicate
> with a compositor in the host. Clients will use the communication
> protocol that the compositor supports, and virtio-gpu will assist with
> making buffers avail
On 01/12/2018 05:11 AM, Dave Airlie wrote:
this work is based on the virtio_wl driver in the ChromeOS kernel by
Zach Reizner, currently at:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
There's two features missing in this patch when
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
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 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
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
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
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
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 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
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_
These ones will be needed to make use fo the NN and TP units in the NPUs
based on Vivante IP.
Signed-off-by: Tomeu Vizoso
Acked-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 12
drivers/gpu/drm
On Thu, Jun 13, 2024 at 11:38 PM Sebastian Reichel
wrote:
>
> Hi,
>
> On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
> > On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
> > > On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
> > > wrote:
&
On Fri, Jun 14, 2024 at 2:07 PM Robin Murphy wrote:
>
> On 2024-06-13 10:38 pm, Sebastian Reichel wrote:
> > Hi,
> >
> > On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
> >> On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso
> >> wrote:
>
/mesa/mesa/-/merge_requests/29698
Signed-off-by: Tomeu Vizoso
---
Tomeu Vizoso (9):
iommu/rockchip: Add compatible for rockchip,rk3588-iommu
iommu/rockchip: Attach multiple power domains
dt-bindings: mailbox: rockchip,rknn: Add bindings
arm64: dts: rockchip: Add nodes for
So far, seems to be fully compatible with the one in the RK3568.
The bindings already had this compatible, but the driver didn't
advertise it.
Signed-off-by: Tomeu Vizoso
---
drivers/iommu/rockchip-iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/rockchip-iomm
the DT.
This is needed by the IOMMU used by the NPU in the RK3588.
Signed-off-by: Tomeu Vizoso
---
drivers/iommu/rockchip-iommu.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index
Add the bindings for the Neural Processing Unit IP from Rockchip.
Signed-off-by: Tomeu Vizoso
---
.../devicetree/bindings/npu/rockchip,rknn.yaml | 123 +
1 file changed, 123 insertions(+)
diff --git a/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml
b
Enable the nodes added in a previous commit to the rk3588s device tree.
Signed-off-by: Tomeu Vizoso
---
arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
b/arch/arm64/boot/dts
See Chapter 36 "RKNN" from the RK3588 TRM (Part 1).
This is a derivative of NVIDIA's NVDLA, but with its own front-end
processor.
Mostly taken from downstream.
Signed-off-by: Tomeu Vizoso
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 53 +++
1 f
This uses the SHMEM DRM helpers and we map right away to the CPU and NPU
sides, as all buffers are expected to be accessed from both.
Signed-off-by: Tomeu Vizoso
---
drivers/accel/rocket/Makefile | 3 +-
drivers/accel/rocket/rocket_drv.c | 7 +++-
drivers/accel/rocket/rocket_gem.c | 68
Using the DRM GPU scheduler infrastructure, with a scheduler for each
core.
Userspace can decide for a series of tasks to be executed sequentially
in the same core, so SRAM locality can be taken advantage of.
The job submission code was intially based on Panfrost.
Signed-off-by: Tomeu Vizoso
same IOCTLs from the Etnaviv driver.
Signed-off-by: Tomeu Vizoso
---
drivers/accel/rocket/rocket_drv.c | 2 ++
drivers/accel/rocket/rocket_gem.c | 68 +++
drivers/accel/rocket/rocket_gem.h | 7 +++-
include/uapi/drm/rocket_accel.h | 20 +++-
4
On Mon, May 20, 2024 at 1:19 PM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 20 May 2024 at 08:39, Tomeu Vizoso wrote:
> > On Fri, May 10, 2024 at 10:34 AM Lucas Stach wrote:
> > > Am Mittwoch, dem 24.04.2024 um 08:37 +0200 schrieb Tomeu Vizoso:
> > > > If w
On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
wrote:
>
> Hi,
>
> On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
> > IOMMUs with multiple base addresses can also have multiple power
> > domains.
> >
> > The base framework only takes ca
On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
>
> On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
> wrote:
> >
> > Hi,
> >
> > On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
> > > IOMMUs with multiple base addresses
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers
.
Also, I have left the connector back pointer in the AUX structure, as on
IRC nor danvet nor me could find a good reason to change it.
Thanks,
Tomeu
Tomeu Vizoso (4):
drm/bridge: analogix_dp: set connector to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: a
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files
5: Move back to make the retry explicitly once
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_dp_helper.c | 124
include/drm/drm_dp_helper.h | 7 +++
2 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/
elated nodes
1206d41 ARM: dts: exynos4412-odroid: enable hdmi support
Tested-by: Tomeu Vizoso
I also needed these two patches from Daniel Drake:
64489ec ARM: dts: Enable PMIC interrupts on ODROID
ef009d7 ARM: dts: ODROID i2c improvements
HDMI worked just fine in the testing I did, I hav
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
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
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
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
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
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
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 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
://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
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
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/
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 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
>
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
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 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 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 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 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 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
From: Stéphane Marchesin
This panel is used by the Nyan Blaze board and supported by the simple-panel
driver.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel
50128.
http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=nyan-v3
Regards,
Tomeu
Stéphane Marchesin (1):
drm/panel: add support for Samsung LTN140AT29 panel
Tomeu Vizoso (9):
ARM: tegra: Set the sound card model that alsaucm expects
ARM: tegra: Move out nyan-generic parts out fro
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
---
.../bindings/panel/samsung,ltn140at29-301.txt
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
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
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
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
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
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 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
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 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 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 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
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
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 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
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 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 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 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
(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
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 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
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 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
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
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
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
301 - 400 of 518 matches
Mail list logo
