* Re: [PATCH] drm/tegra: Add zpos property for cursor planes
From: Dmitry Osipenko @ 2020-06-10 13:16 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Jon Hunter
In-Reply-To: <20200610113059.2164132-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
10.06.2020 14:30, Thierry Reding пишет:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> have a zpos property") a warning is emitted if there's a mix of planes
> with and without a zpos property.
>
> On Tegra, cursor planes are always composited on top of all other
> planes, which is why they never had a zpos property attached to them.
> However, since the composition order is fixed, this is trivial to
> remedy by simply attaching an immutable zpos property to them.
>
> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
What problem does it solve?
^ permalink raw reply
* Re: [RFC PATCH v1 05/18] i2c: tegra: Fix runtime resume to re-init VI I2C
From: Dmitry Osipenko @ 2020-06-10 13:14 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, frankc-DDmLM1+adcrQT0dZR+AlfA,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sakari.ailus-X3B1VOXEql0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
helen.koike-ZGY8ohtN/8qB+jHODAdFcQ
Cc: sboyd-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1591768960-31648-6-git-send-email-skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
10.06.2020 09:02, Sowjanya Komatineni пишет:
> VI I2C is on host1x bus and is part of VE power domain.
>
> During suspend/resume VE power domain goes through power off/on.
>
> So, controller reset followed by i2c re-initialization is required
> after the domain power up.
>
> This patch fixes it.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/i2c/busses/i2c-tegra.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index dba38a5..650240d 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -293,6 +293,8 @@ struct tegra_i2c_dev {
> bool is_curr_atomic_xfer;
> };
>
> +static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev, bool clk_reinit);
> +
> static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
> unsigned long reg)
> {
> @@ -679,8 +681,22 @@ static int __maybe_unused tegra_i2c_runtime_resume(struct device *dev)
> goto disable_slow_clk;
> }
>
> + /*
> + * VI I2C device is attached to VE power domain which goes through
> + * power ON/OFF during PM runtime resume/suspend. So, controller
> + * should go through reset and need to re-initialize after power
> + * domain ON.
> + */
> + if (i2c_dev->is_vi) {
> + ret = tegra_i2c_init(i2c_dev, true);
> + if (ret)
> + goto disable_div_clk;
> + }
> +
> return 0;
>
> +disable_div_clk:
> + clk_disable(i2c_dev->div_clk);
> disable_slow_clk:
> if (i2c_dev->slow_clk)
> clk_disable(i2c_dev->slow_clk);
>
The clk_disable() can cope with a NULL argument. Won't it be cleaner to
remove the conditions?
^ permalink raw reply
* Re: [PATCH v4 0/7] Support inhibiting input devices
From: Andrzej Pietrasiewicz @ 2020-06-10 13:12 UTC (permalink / raw)
To: Rafael J. Wysocki, Hans de Goede
Cc: Linux PM, ACPI Devel Maling List, Linux Kernel Mailing List,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux ARM, Linux Samsung SoC,
linux-input-u79uwXL29TY76Z2rM5mHXA, linux-tegra,
patches-yzvPICuk2AA4QjBA90+/kJqQE7yCjDx5,
ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Platform Driver,
Rafael J . Wysocki, Len Brown, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Kukjin Kim
In-Reply-To: <CAJZ5v0hB2ra2K=dd9ZjVyy1V2b1PmFHm79uDO2HtHU1D_4YUbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi All,
W dniu 10.06.2020 o 12:38, Rafael J. Wysocki pisze:
> On Wed, Jun 10, 2020 at 11:50 AM Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> Hi All,
>>
>> On 6/8/20 1:22 PM, Andrzej Pietrasiewicz wrote:
>>> This is a quick respin of v3, with just two small changes, please see
>>> the changelog below.
>>>
>>> Userspace might want to implement a policy to temporarily disregard input
>>> from certain devices.
>>>
>>> An example use case is a convertible laptop, whose keyboard can be folded
>>> under the screen to create tablet-like experience. The user then must hold
>>> the laptop in such a way that it is difficult to avoid pressing the keyboard
>>> keys. It is therefore desirable to temporarily disregard input from the
>>> keyboard, until it is folded back. This obviously is a policy which should
>>> be kept out of the kernel, but the kernel must provide suitable means to
>>> implement such a policy.
>>
>> First of all sorry to start a somewhat new discussion about this
>> while this patch set is also somewhat far along in the review process,
>> but I believe what I discuss below needs to be taken into account.
>>
>> Yesterday I have been looking into why an Asus T101HA would not stay
>> suspended when the LID is closed. The cause is that the USB HID multi-touch
>> touchpad in the base of the device starts sending events when the screen
>> gets close to the touchpad (so when the LID is fully closed) and these
>> events are causing a wakeup from suspend. HID multi-touch devices
>> do have a way to tell them to fully stop sending events, also disabling
>> the USB remote wakeup the device is doing. The question is when to tell
>> it to not send events though ...
>>
>> So now I've been thinking about how to fix this and I believe that there
>> is some interaction between this problem and this patch-set.
>>
>> The problem I'm seeing on the T101HA is about wakeups, so the question
>> which I want to discuss is:
>>
>> 1. How does inhibiting interact with enabling /
>> disabling the device as a wakeup source ?
>>
>> 2. Since we have now made inhibiting equal open/close how does open/close
>> interact with a device being a wakeup source ?
>>
>> And my own initial (to be discussed) answers to these questions:
>>
>> 1. It seems to me that when a device is inhibited it should not be a
>> wakeup source, so where possible a input-device-driver should disable
>> a device's wakeup capabilities on suspend if inhibited
>
> If "inhibit" means "do not generate any events going forward", then
> this must also cover wakeup events, so I agree.
I agree, too.
>
>> 2. This one is trickier I don't think we have really clearly specified
>> any behavior here. The default behavior of most drivers seems to be
>> using something like this in their suspend callback:
>>
>> if (device_may_wakeup(dev))
>> enable_irq_wake(data->irq);
>> else if (input->users)
>> foo_stop_receiving_events(data);
>>
>> Since this is what most drivers seem to do I believe we should keep
>> this as is and that we should just clearly document that if the
>> input_device has users (has been opened) or not does not matter
>> for its wakeup behavior.
>>
>> Combining these 2 answers leads to this new pseudo code template
>> for an input-device's suspend method:
>>
>> /*
>> * If inhibited we have already disabled events and
>> * we do NOT want to setup the device as wake source.
>> */
>> if (input->inhibited)
>> return 0;
Right, if a device is inhibited it shouldn't become a wakeup source,
because that would contradict the purpose of being inhibited.
>>
>> if (device_may_wakeup(dev))
>> enable_irq_wake(data->irq);
What would it mean to become a wakeup source if there are no users,
or nobody has ever opened the device? There are no interested
input handlers (users) so what's the point of becoming a wakeup
source? Why would the system need to wake up?
>> else if (input->users)
>> foo_stop_receiving_events(data);
>>
>> ###
>
> Sounds reasonable to me.
>
>> A different, but related issue is how to make devices actually use the
>> new inhibit support on the builtin keyboard + touchpad when say the lid
>> is closed. Arguably this is an userspace problem, but it is a tricky
>> one. Currently on most modern Linux distributions suspend-on-lid-close
>> is handled by systemd-logind and most modern desktop-environments are
>> happy to have logind handle this for them.
>>
>> But most knowledge about input devices and e.g. heurisitics to decide
>> if a touchpad is internal or external are part of libinput. Now we could
>> have libinput use the new inhibit support (1), but then when the lid
>> closes we get race between whatever process is using libinput trying
>> to inhibit the touchpad (which must be done before to suspend to disable
>> it as wakeup source) and logind trying to suspend the system.
>>
>> One solution here would be to move the setting of the inhibit sysfs
>> attr into logind, but that requires adding a whole bunch of extra
>> knowledge to logind which does not really belong there IMHO.
>>
>> I've been thinking a bit about this and to me it seems that the kernel
>> is in the ideal position to automatically inhibit some devices when
>> some EV_SW transitions from 0->1 (and uninhibit again on 1->0). The
>> issue here is to chose on which devices to enable this. I believe
>> that the auto inhibit on some switches mechanism is best done inside
>> the kernel (disabled by default) and then we can have a sysfs
>> attr called auto_inhibit_ev_sw_mask which can be set to e.g.
>> (1 << SW_LID) to make the kernel auto-inhibit the input-device whenever
>> the lid is closed, or to ((1 << SW_LID) | (1 << SW_TABLET_MODE)) to
>> inhibit both when the lid is closed or when switched to tablet mode.
>
> I agree that the kernel is the right place to handle this, but it
> requires some extra knowledge about dependencies between devices.
>
> It'd be kind of like power resources in ACPI, so for each state of a
> "master" device (in principle, there may be more states of it than
> just two) there would be a list of "dependent" intput devices that
> need to be inhibited when the "master" device goes into that state.
>
>> This could then be combined with a userspace utility run from an
>> udev rule which makes the actual decision what auto_inhibit_ev_sw_mask
>> should be set for a given input device.
>>
>> This will put the mechanism for what we want inside the kernel and
>> leaves the policy on which switches we want this for out of the
>> kernel.
>>
>> Note adding this new auto_inhibit_ev_sw_mask sysfs attr falls
>> somewhat outside the context of this patchset and could be done
>> as a follow up to this patch-set.
Yes, please ;)
But I do believe that we need to
>> figure out how (non ChromeOS) userspace can / will use the new inhibit
>> interface before merging it.
Of course.
Regards,
Andrzej
^ permalink raw reply
* Re: [PATCH] drm/tegra: Add zpos property for cursor planes
From: Ville Syrjälä @ 2020-06-10 12:10 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Jon Hunter
In-Reply-To: <20200610113059.2164132-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Jun 10, 2020 at 01:30:59PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> have a zpos property") a warning is emitted if there's a mix of planes
> with and without a zpos property.
>
> On Tegra, cursor planes are always composited on top of all other
> planes, which is why they never had a zpos property attached to them.
> However, since the composition order is fixed, this is trivial to
> remedy by simply attaching an immutable zpos property to them.
>
> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/gpu/drm/tegra/dc.c | 10 ++++++++--
> drivers/gpu/drm/tegra/hub.c | 2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 83f31c6e891c..e7a6eb952ece 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -787,7 +787,7 @@ static struct drm_plane *tegra_primary_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
> - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
> + drm_plane_create_zpos_property(&plane->base, 1 + plane->index, 1, 255);
>
> err = drm_plane_create_rotation_property(&plane->base,
> DRM_MODE_ROTATE_0,
> @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
> + drm_plane_create_zpos_immutable_property(&plane->base, 0);
zpos==0 means the plane is at the bottom of the pile. Doesn't seem to
agree what you say in the commit msg.
>
> return &plane->base;
> }
> @@ -1074,7 +1075,12 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
> - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
> +
> + if (!cursor)
> + drm_plane_create_zpos_property(&plane->base, 1 + plane->index,
> + 1, 255);
> + else
> + drm_plane_create_zpos_immutable_property(&plane->base, 0);
>
> err = drm_plane_create_rotation_property(&plane->base,
> DRM_MODE_ROTATE_0,
> diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
> index a2ef8f218d4e..697d75bbb9fa 100644
> --- a/drivers/gpu/drm/tegra/hub.c
> +++ b/drivers/gpu/drm/tegra/hub.c
> @@ -590,7 +590,7 @@ struct drm_plane *tegra_shared_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(p, &tegra_shared_plane_helper_funcs);
> - drm_plane_create_zpos_property(p, 0, 0, 255);
> + drm_plane_create_zpos_property(p, 1 + index, 1, 255);
>
> return p;
> }
> --
> 2.24.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH 5.7 00/24] 5.7.2-rc1 review
From: Greg Kroah-Hartman @ 2020-06-10 11:50 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <7208a2cc-c439-57bc-f154-a23e6ac683f5-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Wed, Jun 10, 2020 at 12:30:28PM +0100, Jon Hunter wrote:
>
> On 09/06/2020 18:45, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.7.2 release.
> > There are 24 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu, 11 Jun 2020 17:41:38 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.2-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.7.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.7:
> 11 builds: 11 pass, 0 fail
> 26 boots: 26 pass, 0 fail
> 50 tests: 50 pass, 0 fail
>
> Linux version: 5.7.2-rc1-g00f7cc67908b
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra210-p3450-0000,
> tegra30-cardhu-a04
Wonderful, thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply
* [PATCH] drm/tegra: Add zpos property for cursor planes
From: Thierry Reding @ 2020-06-10 11:30 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
have a zpos property") a warning is emitted if there's a mix of planes
with and without a zpos property.
On Tegra, cursor planes are always composited on top of all other
planes, which is why they never had a zpos property attached to them.
However, since the composition order is fixed, this is trivial to
remedy by simply attaching an immutable zpos property to them.
Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
drivers/gpu/drm/tegra/dc.c | 10 ++++++++--
drivers/gpu/drm/tegra/hub.c | 2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 83f31c6e891c..e7a6eb952ece 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -787,7 +787,7 @@ static struct drm_plane *tegra_primary_plane_create(struct drm_device *drm,
}
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
- drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+ drm_plane_create_zpos_property(&plane->base, 1 + plane->index, 1, 255);
err = drm_plane_create_rotation_property(&plane->base,
DRM_MODE_ROTATE_0,
@@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
}
drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
+ drm_plane_create_zpos_immutable_property(&plane->base, 0);
return &plane->base;
}
@@ -1074,7 +1075,12 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm,
}
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
- drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+
+ if (!cursor)
+ drm_plane_create_zpos_property(&plane->base, 1 + plane->index,
+ 1, 255);
+ else
+ drm_plane_create_zpos_immutable_property(&plane->base, 0);
err = drm_plane_create_rotation_property(&plane->base,
DRM_MODE_ROTATE_0,
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index a2ef8f218d4e..697d75bbb9fa 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -590,7 +590,7 @@ struct drm_plane *tegra_shared_plane_create(struct drm_device *drm,
}
drm_plane_helper_add(p, &tegra_shared_plane_helper_funcs);
- drm_plane_create_zpos_property(p, 0, 0, 255);
+ drm_plane_create_zpos_property(p, 1 + index, 1, 255);
return p;
}
--
2.24.1
^ permalink raw reply related
* Re: [PATCH 5.7 00/24] 5.7.2-rc1 review
From: Jon Hunter @ 2020-06-10 11:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200609174149.255223112-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 09/06/2020 18:45, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.7.2 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 11 Jun 2020 17:41:38 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.2-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.7.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.7:
11 builds: 11 pass, 0 fail
26 boots: 26 pass, 0 fail
50 tests: 50 pass, 0 fail
Linux version: 5.7.2-rc1-g00f7cc67908b
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 5.6 00/41] 5.6.18-rc1 review
From: Jon Hunter @ 2020-06-10 11:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200609174112.129412236-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 09/06/2020 18:45, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.6.18 release.
> There are 41 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 11 Jun 2020 17:40:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.18-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.6:
11 builds: 11 pass, 0 fail
26 boots: 26 pass, 0 fail
50 tests: 50 pass, 0 fail
Linux version: 5.6.18-rc1-g1bece508f6a9
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 5.4 00/34] 5.4.46-rc1 review
From: Jon Hunter @ 2020-06-10 11:29 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings, lkft-triage,
stable, linux-tegra
In-Reply-To: <20200609174052.628006868@linuxfoundation.org>
On 09/06/2020 18:44, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.46 release.
> There are 34 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 11 Jun 2020 17:40:27 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.46-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.4:
11 builds: 11 pass, 0 fail
26 boots: 26 pass, 0 fail
50 tests: 50 pass, 0 fail
Linux version: 5.4.46-rc1-g12a5ce113626
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4.19 00/25] 4.19.128-rc1 review
From: Jon Hunter @ 2020-06-10 11:29 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200609174048.576094775-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 09/06/2020 18:44, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.128 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 11 Jun 2020 17:40:24 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.128-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
36 tests: 36 pass, 0 fail
Linux version: 4.19.128-rc2-gf6c346f2d42d
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4.14 00/46] 4.14.184-rc2 review
From: Jon Hunter @ 2020-06-10 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200609190050.275446645-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 09/06/2020 20:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.184 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 11 Jun 2020 19:00:37 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.184-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
28 tests: 28 pass, 0 fail
Linux version: 4.14.184-rc2-g9817cdae1b62
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4.9 00/42] 4.9.227-rc2 review
From: Jon Hunter @ 2020-06-10 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, shuah-DgEjT+Ai2ygdnm+yROfE0A,
patches-ssFOTAMYnuFg9hUCZPvPmw,
ben.hutchings-4yDnlxn2s6sWdaTGBSpHTA,
lkft-triage-cunTk1MwBs8s++Sfvej+rw, stable-u79uwXL29TY76Z2rM5mHXA,
linux-tegra
In-Reply-To: <20200609190124.109610974-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 09/06/2020 20:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.227 release.
> There are 42 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 11 Jun 2020 19:01:14 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.227-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
28 tests: 28 pass, 0 fail
Linux version: 4.9.227-rc2-g2d9a8182e06a
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4.4 00/36] 4.4.227-rc2 review
From: Jon Hunter @ 2020-06-10 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings, lkft-triage,
stable, linux-tegra
In-Reply-To: <20200609190211.793882726@linuxfoundation.org>
On 09/06/2020 20:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.227 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 11 Jun 2020 19:02:00 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.227-rc2.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
23 tests: 23 pass, 0 fail
Linux version: 4.4.227-rc2-g61ef7e7aaf1d
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [RFC PATCH v1 10/18] dt-bindings: tegra: Document VI and CSI port nodes
From: Sakari Ailus @ 2020-06-10 11:23 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: thierry.reding, jonathanh, frankc, hverkuil, robh+dt, helen.koike,
digetx, sboyd, gregkh, linux-media, devicetree, linux-tegra,
linux-kernel, linux-i2c
In-Reply-To: <1591768960-31648-11-git-send-email-skomatineni@nvidia.com>
Hi Sowjanya,
Thanks for the patchset.
On Tue, Jun 09, 2020 at 11:02:32PM -0700, Sowjanya Komatineni wrote:
> This patch documents Tegra VI and CSI port and endpoint nodes along
> with the other required properties.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> ---
> .../display/tegra/nvidia,tegra20-host1x.txt | 87 ++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> index 4731921..f70a838 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> @@ -65,6 +65,48 @@ of the following host1x client modules:
> - power-domains: Must include sor powergate node as csicil is in
> SOR partition.
>
> + Optional properties for csi node:
What hardware does the csi node represent? A CSI-2 receiver? Something
else?
If you have two connections, you need two ports. The example isn't quite
clear on this; it would appear to represent a single physical interface.
> +
> + - channel nodes: Max upto 6 channels/streams are supported with each CSI
> + brick can as either x4 or x2 based on hw connectivity to sensor.
> +
> + Required properties:
> + - reg: channel/stream index
> + - nvidia,mipi-calibrate: Should contain a phandle and a specifier
> + specifying which pads are used by this CSI port and need to be
> + calibrated. See also ../display/tegra/nvidia,tegra114-mipi.txt.
> +
> + - port: CSI port node and its endpoint nodes as per device graph
> + bindings defined in Documentation/devicetree/bindings/graph.txt.
> + Required properties:
You have both properties and nodes here. Same for the above (port is a
node).
> + - reg: csi port index based on hw csi lanes connectivity to the
> + sensor.
> + - bus-width: number of lanes used by this port. Supported lanes
> + are 1/2/4.
bus-width belongs to the endpoint. Note that this is for parallel busses
only. If you need the number of lanes, the property is called data-lanes.
> + - endpoint@0: sink node
> + Required properties:
> + - reg: endpoint id. This is used to retrieve pad for creating
> + media link
> + - remote-endpoint: phandle to sensor endpoint
> + - endpoint@1: source node
> + - reg: endpoint id. This is used to retrieve pad for creating
> + media link
> + - remote-endpoint: phandle to vi port endpoint
> +
> + Optional properties for vi node:
> + - ports: Video port nodes and endpoint nodes as per device graph bindings
> + defined in Documentation/devicetree/bindings/graph.txt
> + Max 6 ports are supported and each port should have one endpoint node.
> +
> + Required properties:
> + - port: VI port node and its sink endpoint node
> + Required properties:
> + - reg: should match port index
> + - endpoint@0: sink node
> + Required properties:
> + - reg: endpoint id must be 0
> + - remote-endpoint: phandle to CSI endpoint node.
> +
> - epp: encoder pre-processor
>
> Required properties:
> @@ -340,6 +382,22 @@ Example:
>
> ranges = <0x0 0x0 0x54080000 0x2000>;
>
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + imx219_vi_in0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&imx219_csi_out0>;
> + };
> + };
> + };
> +
> csi@838 {
> compatible = "nvidia,tegra210-csi";
> reg = <0x838 0x1300>;
> @@ -362,6 +420,35 @@ Example:
> <&tegra_car TEGRA210_CLK_CSI_TPG>;
> clock-names = "csi", "cilab", "cilcd", "cile", "csi_tpg";
> power-domains = <&pd_sor>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 {
> + reg = <0>;
> + nvidia,mipi-calibrate = <&mipi 0x001>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + bus-width = <2>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + imx219_csi_in0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&imx219_out0>;
> + };
> +
> + imx219_csi_out0: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&imx219_vi_in0>;
> + };
> + };
> + };
> };
> };
>
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v4 0/7] Support inhibiting input devices
From: Rafael J. Wysocki @ 2020-06-10 10:38 UTC (permalink / raw)
To: Hans de Goede
Cc: Andrzej Pietrasiewicz, Linux PM, ACPI Devel Maling List,
Linux Kernel Mailing List, linux-iio, Linux ARM,
Linux Samsung SoC, linux-input, linux-tegra, patches,
ibm-acpi-devel, Platform Driver, Rafael J . Wysocki, Len Brown,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Kuk
In-Reply-To: <964ca07a-3da5-101f-7edf-64bdeec98a4b@redhat.com>
On Wed, Jun 10, 2020 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi All,
>
> On 6/8/20 1:22 PM, Andrzej Pietrasiewicz wrote:
> > This is a quick respin of v3, with just two small changes, please see
> > the changelog below.
> >
> > Userspace might want to implement a policy to temporarily disregard input
> > from certain devices.
> >
> > An example use case is a convertible laptop, whose keyboard can be folded
> > under the screen to create tablet-like experience. The user then must hold
> > the laptop in such a way that it is difficult to avoid pressing the keyboard
> > keys. It is therefore desirable to temporarily disregard input from the
> > keyboard, until it is folded back. This obviously is a policy which should
> > be kept out of the kernel, but the kernel must provide suitable means to
> > implement such a policy.
>
> First of all sorry to start a somewhat new discussion about this
> while this patch set is also somewhat far along in the review process,
> but I believe what I discuss below needs to be taken into account.
>
> Yesterday I have been looking into why an Asus T101HA would not stay
> suspended when the LID is closed. The cause is that the USB HID multi-touch
> touchpad in the base of the device starts sending events when the screen
> gets close to the touchpad (so when the LID is fully closed) and these
> events are causing a wakeup from suspend. HID multi-touch devices
> do have a way to tell them to fully stop sending events, also disabling
> the USB remote wakeup the device is doing. The question is when to tell
> it to not send events though ...
>
> So now I've been thinking about how to fix this and I believe that there
> is some interaction between this problem and this patch-set.
>
> The problem I'm seeing on the T101HA is about wakeups, so the question
> which I want to discuss is:
>
> 1. How does inhibiting interact with enabling /
> disabling the device as a wakeup source ?
>
> 2. Since we have now made inhibiting equal open/close how does open/close
> interact with a device being a wakeup source ?
>
> And my own initial (to be discussed) answers to these questions:
>
> 1. It seems to me that when a device is inhibited it should not be a
> wakeup source, so where possible a input-device-driver should disable
> a device's wakeup capabilities on suspend if inhibited
If "inhibit" means "do not generate any events going forward", then
this must also cover wakeup events, so I agree.
> 2. This one is trickier I don't think we have really clearly specified
> any behavior here. The default behavior of most drivers seems to be
> using something like this in their suspend callback:
>
> if (device_may_wakeup(dev))
> enable_irq_wake(data->irq);
> else if (input->users)
> foo_stop_receiving_events(data);
>
> Since this is what most drivers seem to do I believe we should keep
> this as is and that we should just clearly document that if the
> input_device has users (has been opened) or not does not matter
> for its wakeup behavior.
>
> Combining these 2 answers leads to this new pseudo code template
> for an input-device's suspend method:
>
> /*
> * If inhibited we have already disabled events and
> * we do NOT want to setup the device as wake source.
> */
> if (input->inhibited)
> return 0;
>
> if (device_may_wakeup(dev))
> enable_irq_wake(data->irq);
> else if (input->users)
> foo_stop_receiving_events(data);
>
> ###
Sounds reasonable to me.
> A different, but related issue is how to make devices actually use the
> new inhibit support on the builtin keyboard + touchpad when say the lid
> is closed. Arguably this is an userspace problem, but it is a tricky
> one. Currently on most modern Linux distributions suspend-on-lid-close
> is handled by systemd-logind and most modern desktop-environments are
> happy to have logind handle this for them.
>
> But most knowledge about input devices and e.g. heurisitics to decide
> if a touchpad is internal or external are part of libinput. Now we could
> have libinput use the new inhibit support (1), but then when the lid
> closes we get race between whatever process is using libinput trying
> to inhibit the touchpad (which must be done before to suspend to disable
> it as wakeup source) and logind trying to suspend the system.
>
> One solution here would be to move the setting of the inhibit sysfs
> attr into logind, but that requires adding a whole bunch of extra
> knowledge to logind which does not really belong there IMHO.
>
> I've been thinking a bit about this and to me it seems that the kernel
> is in the ideal position to automatically inhibit some devices when
> some EV_SW transitions from 0->1 (and uninhibit again on 1->0). The
> issue here is to chose on which devices to enable this. I believe
> that the auto inhibit on some switches mechanism is best done inside
> the kernel (disabled by default) and then we can have a sysfs
> attr called auto_inhibit_ev_sw_mask which can be set to e.g.
> (1 << SW_LID) to make the kernel auto-inhibit the input-device whenever
> the lid is closed, or to ((1 << SW_LID) | (1 << SW_TABLET_MODE)) to
> inhibit both when the lid is closed or when switched to tablet mode.
I agree that the kernel is the right place to handle this, but it
requires some extra knowledge about dependencies between devices.
It'd be kind of like power resources in ACPI, so for each state of a
"master" device (in principle, there may be more states of it than
just two) there would be a list of "dependent" intput devices that
need to be inhibited when the "master" device goes into that state.
> This could then be combined with a userspace utility run from an
> udev rule which makes the actual decision what auto_inhibit_ev_sw_mask
> should be set for a given input device.
>
> This will put the mechanism for what we want inside the kernel and
> leaves the policy on which switches we want this for out of the
> kernel.
>
> Note adding this new auto_inhibit_ev_sw_mask sysfs attr falls
> somewhat outside the context of this patchset and could be done
> as a follow up to this patch-set. But I do believe that we need to
> figure out how (non ChromeOS) userspace can / will use the new inhibit
> interface before merging it.
^ permalink raw reply
* Re: [PATCH v4 0/7] Support inhibiting input devices
From: Hans de Goede @ 2020-06-10 9:49 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
patches-yzvPICuk2AA4QjBA90+/kJqQE7yCjDx5,
ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA
Cc: Rafael J . Wysocki, Len Brown, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Kukjin Kim,
Krzysztof Kozlowski, Dmitry Torokhov, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Vladimir Zapolskiy, Sylvain Lemieux, Laxman Dewangan,
Thierry Reding, Jonathan Hunter, Barry
In-Reply-To: <20200608112211.12125-1-andrzej.p-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Hi All,
On 6/8/20 1:22 PM, Andrzej Pietrasiewicz wrote:
> This is a quick respin of v3, with just two small changes, please see
> the changelog below.
>
> Userspace might want to implement a policy to temporarily disregard input
> from certain devices.
>
> An example use case is a convertible laptop, whose keyboard can be folded
> under the screen to create tablet-like experience. The user then must hold
> the laptop in such a way that it is difficult to avoid pressing the keyboard
> keys. It is therefore desirable to temporarily disregard input from the
> keyboard, until it is folded back. This obviously is a policy which should
> be kept out of the kernel, but the kernel must provide suitable means to
> implement such a policy.
First of all sorry to start a somewhat new discussion about this
while this patch set is also somewhat far along in the review process,
but I believe what I discuss below needs to be taken into account.
Yesterday I have been looking into why an Asus T101HA would not stay
suspended when the LID is closed. The cause is that the USB HID multi-touch
touchpad in the base of the device starts sending events when the screen
gets close to the touchpad (so when the LID is fully closed) and these
events are causing a wakeup from suspend. HID multi-touch devices
do have a way to tell them to fully stop sending events, also disabling
the USB remote wakeup the device is doing. The question is when to tell
it to not send events though ...
So now I've been thinking about how to fix this and I believe that there
is some interaction between this problem and this patch-set.
The problem I'm seeing on the T101HA is about wakeups, so the question
which I want to discuss is:
1. How does inhibiting interact with enabling /
disabling the device as a wakeup source ?
2. Since we have now made inhibiting equal open/close how does open/close
interact with a device being a wakeup source ?
And my own initial (to be discussed) answers to these questions:
1. It seems to me that when a device is inhibited it should not be a
wakeup source, so where possible a input-device-driver should disable
a device's wakeup capabilities on suspend if inhibited
2. This one is trickier I don't think we have really clearly specified
any behavior here. The default behavior of most drivers seems to be
using something like this in their suspend callback:
if (device_may_wakeup(dev))
enable_irq_wake(data->irq);
else if (input->users)
foo_stop_receiving_events(data);
Since this is what most drivers seem to do I believe we should keep
this as is and that we should just clearly document that if the
input_device has users (has been opened) or not does not matter
for its wakeup behavior.
Combining these 2 answers leads to this new pseudo code template
for an input-device's suspend method:
/*
* If inhibited we have already disabled events and
* we do NOT want to setup the device as wake source.
*/
if (input->inhibited)
return 0;
if (device_may_wakeup(dev))
enable_irq_wake(data->irq);
else if (input->users)
foo_stop_receiving_events(data);
###
A different, but related issue is how to make devices actually use the
new inhibit support on the builtin keyboard + touchpad when say the lid
is closed. Arguably this is an userspace problem, but it is a tricky
one. Currently on most modern Linux distributions suspend-on-lid-close
is handled by systemd-logind and most modern desktop-environments are
happy to have logind handle this for them.
But most knowledge about input devices and e.g. heurisitics to decide
if a touchpad is internal or external are part of libinput. Now we could
have libinput use the new inhibit support (1), but then when the lid
closes we get race between whatever process is using libinput trying
to inhibit the touchpad (which must be done before to suspend to disable
it as wakeup source) and logind trying to suspend the system.
One solution here would be to move the setting of the inhibit sysfs
attr into logind, but that requires adding a whole bunch of extra
knowledge to logind which does not really belong there IMHO.
I've been thinking a bit about this and to me it seems that the kernel
is in the ideal position to automatically inhibit some devices when
some EV_SW transitions from 0->1 (and uninhibit again on 1->0). The
issue here is to chose on which devices to enable this. I believe
that the auto inhibit on some switches mechanism is best done inside
the kernel (disabled by default) and then we can have a sysfs
attr called auto_inhibit_ev_sw_mask which can be set to e.g.
(1 << SW_LID) to make the kernel auto-inhibit the input-device whenever
the lid is closed, or to ((1 << SW_LID) | (1 << SW_TABLET_MODE)) to
inhibit both when the lid is closed or when switched to tablet mode.
This could then be combined with a userspace utility run from an
udev rule which makes the actual decision what auto_inhibit_ev_sw_mask
should be set for a given input device.
This will put the mechanism for what we want inside the kernel and
leaves the policy on which switches we want this for out of the
kernel.
Note adding this new auto_inhibit_ev_sw_mask sysfs attr falls
somewhat outside the context of this patchset and could be done
as a follow up to this patch-set. But I do believe that we need to
figure out how (non ChromeOS) userspace can / will use the new inhibit
interface before merging it.
Regards,
Hans
1) There are issues here with libinput not running as root and this
being a root only sysfs interface but lets ignore those for now,
note that the auto_inhibit_ev_sw_mask also neatly solves this
problem
^ permalink raw reply
* Re: [PATCH] pinctrl: tegra: Use noirq suspend/resume callbacks
From: Linus Walleij @ 2020-06-10 8:47 UTC (permalink / raw)
To: Vidya Sagar
Cc: Thierry Reding, Jon Hunter, Dmitry Osipenko, Sowjanya Komatineni,
open list:GPIO SUBSYSTEM, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kthota-DDmLM1+adcrQT0dZR+AlfA, mmaddireddy-DDmLM1+adcrQT0dZR+AlfA,
sagar.tv-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20200604174935.26560-1-vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Jun 4, 2020 at 7:49 PM Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Use noirq suspend/resume callbacks as other drivers which implement
> noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
> configure the signals used by their respective devices in the noirq phase.
>
> Signed-off-by: Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [FIXED PATCH v4 5/7] iio: adc: exynos: Use input_device_enabled()
From: Andrzej Pietrasiewicz @ 2020-06-10 7:52 UTC (permalink / raw)
To: linux-pm, linux-acpi, linux-kernel, linux-iio, linux-arm-kernel,
linux-samsung-soc, linux-input, linux-tegra, patches,
ibm-acpi-devel, platform-driver-x86
Cc: Rafael J . Wysocki, Len Brown, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Kukjin Kim,
Krzysztof Kozlowski, Dmitry Torokhov, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Vladimir Zapolskiy, Sylvain Lemieux, Laxman Dewangan,
Thierry Reding, Jonathan Hunter, Barry
In-Reply-To: <20200610012801.GA11530@qmqm.qmqm.pl>
A new helper is available, so use it. Inspecting 'users' member of
input_dev requires taking device's mutex.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
---
drivers/iio/adc/exynos_adc.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 22131a677445..2761c3aea2c6 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -633,7 +633,9 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
bool pressed;
int ret;
- while (info->input->users) {
+ mutex_lock(&info->input->mutex);
+ while (input_device_enabled(info->input)) {
+ mutex_unlock(&info->input->mutex);
ret = exynos_read_s3c64xx_ts(dev, &x, &y);
if (ret == -ETIMEDOUT)
break;
@@ -651,7 +653,10 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
input_sync(info->input);
usleep_range(1000, 1100);
+
+ mutex_lock(&info->input->mutex);
}
+ mutex_unlock(&info->input->mutex);
writel(0, ADC_V1_CLRINTPNDNUP(info->regs));
--
2.17.1
^ permalink raw reply related
* [RFC PATCH v1 18/18] arm64: tegra: Enable Tegra VI CSI support for Jetson Nano
From: Sowjanya Komatineni @ 2020-06-10 6:02 UTC (permalink / raw)
To: skomatineni, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: digetx, sboyd, gregkh, linux-media, devicetree, linux-tegra,
linux-kernel, linux-i2c
In-Reply-To: <1591768960-31648-1-git-send-email-skomatineni@nvidia.com>
This patch enables VI and CSI in device tree for Jetson Nano.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
index 9bc52fd..eab5c5e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
@@ -64,6 +64,16 @@
status = "okay";
};
+ vi@54080000 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&vdd_sys_1v2>;
+
+ csi@838 {
+ status = "okay";
+ };
+ };
+
sor@54540000 {
status = "okay";
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v1 17/18] arm64: tegra: jetson-tx1: Add camera supplies
From: Sowjanya Komatineni @ 2020-06-10 6:02 UTC (permalink / raw)
To: skomatineni, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: digetx, sboyd, gregkh, linux-media, devicetree, linux-tegra,
linux-kernel, linux-i2c
In-Reply-To: <1591768960-31648-1-git-send-email-skomatineni@nvidia.com>
Jetson TX1 development board has a camera expansion connector which
has 2V8, 1V8 and 1V2 supplies to power up the camera sensor on the
supported camera modules.
Camera module designed as per Jetson TX1 camera expansion connector
may use these supplies for camera sensor avdd 2V8, digital core 1V8,
and digital interface 1V2 voltages.
These supplies are from fixed regulators on TX1 carrier board with
enable control signals from I2C GPIO expanders.
This patch adds these camera supplies to Jetson TX1 device tree to
allow using these when a camera module is used.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 41 ++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
index b57d837..5e24d7a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
@@ -1323,6 +1323,14 @@
#gpio-cells = <2>;
gpio-controller;
};
+
+ exp2: gpio@77 {
+ compatible = "ti,tca9539";
+ reg = <0x77>;
+
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
};
/* HDMI DDC */
@@ -1667,6 +1675,39 @@
enable-active-high;
vin-supply = <&vdd_5v0_sys>;
};
+
+ vdd_cam_1v2: regulator@12 {
+ compatible = "regulator-fixed";
+ reg = <12>;
+ regulator-name = "vdd-cam-1v2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ gpio = <&exp2 10 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
+
+ vdd_cam_2v8: regulator@13 {
+ compatible = "regulator-fixed";
+ reg = <13>;
+ regulator-name = "vdd-cam-2v8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ gpio = <&exp1 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
+
+ vdd_cam_1v8: regulator@14 {
+ compatible = "regulator-fixed";
+ reg = <14>;
+ regulator-name = "vdd-cam-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&exp2 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
};
gpio-keys {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v1 16/18] media: tegra-video: Compute settle times based on the clock rate
From: Sowjanya Komatineni @ 2020-06-10 6:02 UTC (permalink / raw)
To: skomatineni, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: digetx, sboyd, gregkh, linux-media, devicetree, linux-tegra,
linux-kernel, linux-i2c
In-Reply-To: <1591768960-31648-1-git-send-email-skomatineni@nvidia.com>
Settle time determines the number of cil clock cyles to wait after
LP00 when moving from LP to HS.
This patch computes T-CLK-SETTLE and T-HS-SETTLE times based on cil
clock rate and pixel rate from the sensor and programs them during
streaming.
T-CLK-SETTLE time is the interval during which receiver will ignore
any HS transitions on clock lane starting from the beginning of
T-CLK-PREPARE.
T-HS-SETTLE time is the interval during which recevier will ignore
any HS transitions on data lane starting from the beginning of
T-HS-PREPARE.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
drivers/staging/media/tegra-video/csi.c | 55 ++++++++++++++++++++++++++++
drivers/staging/media/tegra-video/csi.h | 5 +++
drivers/staging/media/tegra-video/tegra210.c | 17 ++++++++-
3 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/tegra-video/csi.c b/drivers/staging/media/tegra-video/csi.c
index 82e340a..0f4d815 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -16,6 +16,8 @@
#include "csi.h"
#include "video.h"
+#define MHZ 1000000
+
static inline struct tegra_csi *
host1x_client_to_csi(struct host1x_client *client)
{
@@ -232,6 +234,59 @@ static int tegra_csi_g_frame_interval(struct v4l2_subdev *subdev,
return 0;
}
+static unsigned int csi_get_pixel_rate(struct tegra_csi_channel *csi_chan)
+{
+ struct tegra_vi_channel *chan;
+ struct v4l2_subdev *src_subdev;
+ struct v4l2_ctrl *ctrl;
+
+ chan = v4l2_get_subdev_hostdata(&csi_chan->subdev);
+ src_subdev = tegra_channel_get_remote_subdev(chan, true);
+ ctrl = v4l2_ctrl_find(src_subdev->ctrl_handler, V4L2_CID_PIXEL_RATE);
+ if (ctrl)
+ return v4l2_ctrl_g_ctrl_int64(ctrl);
+
+ return 0;
+}
+
+void tegra_csi_calc_settle_time(struct tegra_csi_channel *csi_chan,
+ u8 *clk_settle_time,
+ u8 *ths_settle_time)
+{
+ struct tegra_csi *csi = csi_chan->csi;
+ unsigned int cil_clk_mhz;
+ unsigned int pix_clk_mhz;
+ int clk_idx = (csi_chan->csi_port_num >> 1) + 1;
+
+ cil_clk_mhz = clk_get_rate(csi->clks[clk_idx].clk) / MHZ;
+ pix_clk_mhz = csi_get_pixel_rate(csi_chan) / MHZ;
+
+ /*
+ * CLK Settle time is the interval during which HS receiver should
+ * ignore any clock lane HS transitions, starting from the beginning
+ * of T-CLK-PREPARE.
+ * Per DPHY specification, T-CLK-SETTLE should be between 95ns ~ 300ns
+ *
+ * 95ns < (clk-settle-programmed + 7) * lp clk period < 300ns
+ * midpoint = 197.5 ns
+ */
+ *clk_settle_time = ((95 + 300) * cil_clk_mhz - 14000) / 2000;
+
+ /*
+ * THS Settle time is the interval during which HS receiver should
+ * ignore any data lane HS transitions, starting from the beginning
+ * of THS-PREPARE.
+ *
+ * Per DPHY specification, T-HS-SETTLE should be between 85ns + 6UI
+ * and 145ns+10UI.
+ * 85ns + 6UI < (Ths-settle-prog + 5) * lp_clk_period < 145ns + 10UI
+ * midpoint = 115ns + 8UI
+ */
+ if (pix_clk_mhz)
+ *ths_settle_time = (115 * cil_clk_mhz + 8000 * cil_clk_mhz
+ / (2 * pix_clk_mhz) - 5000) / 1000;
+}
+
static int tegra_csi_s_stream(struct v4l2_subdev *subdev, int enable)
{
struct tegra_vi_channel *chan = v4l2_get_subdev_hostdata(subdev);
diff --git a/drivers/staging/media/tegra-video/csi.h b/drivers/staging/media/tegra-video/csi.h
index 0e5a537..a52c7da1 100644
--- a/drivers/staging/media/tegra-video/csi.h
+++ b/drivers/staging/media/tegra-video/csi.h
@@ -52,6 +52,7 @@ struct tegra_csi;
* @h_blank: horizontal blanking for TPG active format
* @v_blank: vertical blanking for TPG active format
* @mipi: mipi device for corresponding csi channel pads
+ * @pixel_rate: active pixel rate from the sensor on this channel
*/
struct tegra_csi_channel {
struct list_head list;
@@ -68,6 +69,7 @@ struct tegra_csi_channel {
unsigned int h_blank;
unsigned int v_blank;
struct tegra_mipi_device *mipi;
+ unsigned int pixel_rate;
};
/**
@@ -148,4 +150,7 @@ extern const struct tegra_csi_soc tegra210_csi_soc;
#endif
void tegra_csi_error_recover(struct v4l2_subdev *subdev);
+void tegra_csi_calc_settle_time(struct tegra_csi_channel *csi_chan,
+ u8 *clk_settle_time,
+ u8 *ths_settle_time);
#endif
diff --git a/drivers/staging/media/tegra-video/tegra210.c b/drivers/staging/media/tegra-video/tegra210.c
index 4f5080a..bcc0492 100644
--- a/drivers/staging/media/tegra-video/tegra210.c
+++ b/drivers/staging/media/tegra-video/tegra210.c
@@ -7,6 +7,7 @@
* This source file contains Tegra210 supported video formats,
* VI and CSI SoC specific data, operations and registers accessors.
*/
+#include <linux/bitfield.h>
#include <linux/clk.h>
#include <linux/clk/tegra.h>
#include <linux/delay.h>
@@ -98,6 +99,8 @@
#define BRICK_CLOCK_B_4X (0x2 << 16)
#define TEGRA_CSI_CIL_PAD_CONFIG1 0x004
#define TEGRA_CSI_CIL_PHY_CONTROL 0x008
+#define CLK_SETTLE_MASK GENMASK(13, 8)
+#define THS_SETTLE_MASK GENMASK(5, 0)
#define TEGRA_CSI_CIL_INTERRUPT_MASK 0x00c
#define TEGRA_CSI_CIL_STATUS 0x010
#define TEGRA_CSI_CILX_STATUS 0x014
@@ -770,8 +773,14 @@ static int tegra210_csi_start_streaming(struct tegra_csi_channel *csi_chan)
{
struct tegra_csi *csi = csi_chan->csi;
unsigned int portno = csi_chan->csi_port_num;
+ u8 clk_settle_time = 0;
+ u8 ths_settle_time = 10;
u32 val;
+ if (!csi_chan->pg_mode)
+ tegra_csi_calc_settle_time(csi_chan, &clk_settle_time,
+ &ths_settle_time);
+
csi_write(csi, portno, TEGRA_CSI_CLKEN_OVERRIDE, 0);
/* clean up status */
@@ -782,7 +791,9 @@ static int tegra210_csi_start_streaming(struct tegra_csi_channel *csi_chan)
/* CIL PHY registers setup */
cil_write(csi, portno, TEGRA_CSI_CIL_PAD_CONFIG0, 0x0);
- cil_write(csi, portno, TEGRA_CSI_CIL_PHY_CONTROL, 0xa);
+ cil_write(csi, portno, TEGRA_CSI_CIL_PHY_CONTROL,
+ FIELD_PREP(CLK_SETTLE_MASK, clk_settle_time) |
+ FIELD_PREP(THS_SETTLE_MASK, ths_settle_time));
/*
* The CSI unit provides for connection of up to six cameras in
@@ -801,7 +812,9 @@ static int tegra210_csi_start_streaming(struct tegra_csi_channel *csi_chan)
BRICK_CLOCK_A_4X);
cil_write(csi, portno + 1, TEGRA_CSI_CIL_PAD_CONFIG0, 0x0);
cil_write(csi, portno + 1, TEGRA_CSI_CIL_INTERRUPT_MASK, 0x0);
- cil_write(csi, portno + 1, TEGRA_CSI_CIL_PHY_CONTROL, 0xa);
+ cil_write(csi, portno + 1, TEGRA_CSI_CIL_PHY_CONTROL,
+ FIELD_PREP(CLK_SETTLE_MASK, clk_settle_time) |
+ FIELD_PREP(THS_SETTLE_MASK, ths_settle_time));
csi_write(csi, portno, TEGRA_CSI_PHY_CIL_COMMAND,
CSI_A_PHY_CIL_ENABLE | CSI_B_PHY_CIL_ENABLE);
} else {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v1 15/18] media: tegra-video: Add CSI MIPI pads calibration
From: Sowjanya Komatineni @ 2020-06-10 6:02 UTC (permalink / raw)
To: skomatineni, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: digetx, sboyd, gregkh, linux-media, devicetree, linux-tegra,
linux-kernel, linux-i2c
In-Reply-To: <1591768960-31648-1-git-send-email-skomatineni@nvidia.com>
CSI MIPI pads need to be enabled and calibrated for capturing from
the external sensor or transmitter.
MIPI CAL unit calibrates MIPI pads pull-up, pull-down and termination
impedances. Calibration is done by co-work of MIPI BIAS pad and MIPI
CAL control unit.
Triggering calibration start can happen any time after MIPI pads are
enabled but calibration results will be latched and applied to MIPI
pads by MIPI CAL unit only when the link is in LP11 state and then
calibration status register gets updated.
This patch enables CSI MIPI pads and calibrates them during streaming.
Tegra CSI receiver is able to catch the very first clock transition.
So, CSI receiver is always enabled prior to sensor streaming and
trigger of calibration start is done during CSI subdev streaming and
status of calibration is verified after sensor stream on.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
drivers/staging/media/tegra-video/csi.c | 44 +++++++++++++++++++++++++++++++--
drivers/staging/media/tegra-video/csi.h | 2 ++
drivers/staging/media/tegra-video/vi.c | 18 ++++++++++++++
3 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/tegra-video/csi.c b/drivers/staging/media/tegra-video/csi.c
index 14e9050..82e340a 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -249,15 +249,42 @@ static int tegra_csi_s_stream(struct v4l2_subdev *subdev, int enable)
return ret;
}
+ if (csi_chan->mipi) {
+ ret = tegra_mipi_enable(csi_chan->mipi);
+ if (ret < 0) {
+ dev_err(csi->dev,
+ "failed to enable MIPI pads: %d\n",
+ ret);
+ goto rpm_put;
+ }
+
+ /*
+ * CSI MIPI pads PULLUP, PULLDN and TERM impedances
+ * need to be calibrated after power on.
+ * So, trigger the calibration start here and results
+ * will be latched and applied to the pads when link is
+ * in LP11 state during start of sensor streaming.
+ */
+ tegra_mipi_calibrate(csi_chan->mipi);
+ }
+
ret = csi->ops->csi_start_streaming(csi_chan);
if (ret < 0)
- goto rpm_put;
+ goto disable_mipi;
return 0;
}
csi->ops->csi_stop_streaming(csi_chan);
+disable_mipi:
+ if (csi_chan->mipi) {
+ ret = tegra_mipi_disable(csi_chan->mipi);
+ if (ret < 0)
+ dev_err(csi->dev,
+ "failed to disable MIPI pads: %d\n", ret);
+ }
+
rpm_put:
pm_runtime_put(csi->dev);
return ret;
@@ -291,6 +318,7 @@ static int tegra_csi_channel_alloc(struct tegra_csi *csi,
unsigned int num_pads)
{
struct tegra_csi_channel *chan;
+ int ret = 0;
chan = kzalloc(sizeof(*chan), GFP_KERNEL);
if (!chan)
@@ -309,7 +337,16 @@ static int tegra_csi_channel_alloc(struct tegra_csi *csi,
chan->pads[0].flags = MEDIA_PAD_FL_SOURCE;
}
- return 0;
+ if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return 0;
+
+ chan->mipi = of_tegra_mipi_request(csi->dev, node);
+ if (IS_ERR(chan->mipi)) {
+ ret = PTR_ERR(chan->mipi);
+ dev_err(csi->dev, "failed to get mipi device: %d\n", ret);
+ }
+
+ return ret;
}
static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
@@ -473,6 +510,9 @@ static void tegra_csi_channels_cleanup(struct tegra_csi *csi)
struct tegra_csi_channel *chan, *tmp;
list_for_each_entry_safe(chan, tmp, &csi->csi_chans, list) {
+ if (chan->mipi)
+ tegra_mipi_free(chan->mipi);
+
subdev = &chan->subdev;
if (subdev->dev) {
if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
diff --git a/drivers/staging/media/tegra-video/csi.h b/drivers/staging/media/tegra-video/csi.h
index b7b754a..0e5a537 100644
--- a/drivers/staging/media/tegra-video/csi.h
+++ b/drivers/staging/media/tegra-video/csi.h
@@ -51,6 +51,7 @@ struct tegra_csi;
* @framerate: active framerate for TPG
* @h_blank: horizontal blanking for TPG active format
* @v_blank: vertical blanking for TPG active format
+ * @mipi: mipi device for corresponding csi channel pads
*/
struct tegra_csi_channel {
struct list_head list;
@@ -66,6 +67,7 @@ struct tegra_csi_channel {
unsigned int framerate;
unsigned int h_blank;
unsigned int v_blank;
+ struct tegra_mipi_device *mipi;
};
/**
diff --git a/drivers/staging/media/tegra-video/vi.c b/drivers/staging/media/tegra-video/vi.c
index 03def26..337a19f 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -187,6 +187,7 @@ tegra_channel_get_remote_subdev(struct tegra_vi_channel *chan, bool sensor)
int tegra_channel_set_stream(struct tegra_vi_channel *chan, bool on)
{
struct v4l2_subdev *subdev;
+ struct tegra_csi_channel *csi_chan;
int ret;
/* stream CSI */
@@ -198,11 +199,28 @@ int tegra_channel_set_stream(struct tegra_vi_channel *chan, bool on)
if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
return 0;
+ if (on)
+ csi_chan = v4l2_get_subdevdata(subdev);
+
subdev = tegra_channel_get_remote_subdev(chan, on);
ret = v4l2_subdev_call(subdev, video, s_stream, on);
if (on && ret < 0 && ret != -ENOIOCTLCMD)
return ret;
+ /*
+ * CSI subdev stream on triggers start of MIPI pads calibration.
+ * Calibration results are latched and applied to the pads when
+ * link is in LP11 state which will hapen during sensor streaming.
+ * So, wait for calibration to complete here.
+ */
+ if (on && csi_chan->mipi) {
+ ret = tegra_mipi_wait(csi_chan->mipi);
+ if (ret < 0)
+ dev_err(csi_chan->csi->dev,
+ "MIPI calibration failed: %d\n", ret);
+ return ret;
+ }
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v1 14/18] gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait
From: Sowjanya Komatineni @ 2020-06-10 6:02 UTC (permalink / raw)
To: skomatineni, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: digetx, sboyd, gregkh, linux-media, devicetree, linux-tegra,
linux-kernel, linux-i2c
In-Reply-To: <1591768960-31648-1-git-send-email-skomatineni@nvidia.com>
SW can trigger MIPI pads calibration any time after power on
but calibration results will be latched and applied to the pads
by MIPI CAL unit only when the link is in LP-11 state and then
status register will be updated.
For CSI, trigger of pads calibration happen during CSI stream
enable where CSI receiver is kept ready prior to sensor or CSI
transmitter stream start.
So, pads may not be in LP-11 at this time and waiting for the
calibration to be done immediate after calibration start will
result in timeout.
This patch splits tegra_mipi_calibrate() and tegra_mipi_wait()
so triggering for calibration and waiting for it to complete can
happen at different stages.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
drivers/gpu/drm/tegra/dsi.c | 7 ++++++-
drivers/gpu/host1x/mipi.c | 23 +++++++++++++++++------
include/linux/host1x.h | 1 +
3 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 38beab9..814363f 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -670,6 +670,7 @@ static int tegra_dsi_pad_enable(struct tegra_dsi *dsi)
static int tegra_dsi_pad_calibrate(struct tegra_dsi *dsi)
{
u32 value;
+ int ret;
/*
* XXX Is this still needed? The module reset is deasserted right
@@ -693,7 +694,11 @@ static int tegra_dsi_pad_calibrate(struct tegra_dsi *dsi)
DSI_PAD_PREEMP_PD(0x03) | DSI_PAD_PREEMP_PU(0x3);
tegra_dsi_writel(dsi, value, DSI_PAD_CONTROL_3);
- return tegra_mipi_calibrate(dsi->mipi);
+ ret = tegra_mipi_calibrate(dsi->mipi);
+ if (ret < 0)
+ return ret;
+
+ return tegra_mipi_wait(dsi->mipi);
}
static void tegra_dsi_set_timeout(struct tegra_dsi *dsi, unsigned long bclk,
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
index f51fe69..a01df6a 100644
--- a/drivers/gpu/host1x/mipi.c
+++ b/drivers/gpu/host1x/mipi.c
@@ -299,22 +299,35 @@ int tegra_mipi_disable(struct tegra_mipi_device *dev)
}
EXPORT_SYMBOL(tegra_mipi_disable);
-static int tegra_mipi_wait(struct tegra_mipi *mipi)
+int tegra_mipi_wait(struct tegra_mipi_device *device)
{
+ struct tegra_mipi *mipi = device->mipi;
unsigned long timeout = jiffies + msecs_to_jiffies(250);
u32 value;
+ int err;
+
+ err = clk_enable(device->mipi->clk);
+ if (err < 0)
+ return err;
+
+ mutex_lock(&device->mipi->lock);
while (time_before(jiffies, timeout)) {
value = tegra_mipi_readl(mipi, MIPI_CAL_STATUS);
if ((value & MIPI_CAL_STATUS_ACTIVE) == 0 &&
(value & MIPI_CAL_STATUS_DONE) != 0)
- return 0;
+ goto done;
usleep_range(10, 50);
}
- return -ETIMEDOUT;
+ err = -ETIMEDOUT;
+done:
+ mutex_unlock(&device->mipi->lock);
+ clk_disable(device->mipi->clk);
+ return err;
}
+EXPORT_SYMBOL(tegra_mipi_wait);
int tegra_mipi_calibrate(struct tegra_mipi_device *device)
{
@@ -380,12 +393,10 @@ int tegra_mipi_calibrate(struct tegra_mipi_device *device)
value |= MIPI_CAL_CTRL_START;
tegra_mipi_writel(device->mipi, value, MIPI_CAL_CTRL);
- err = tegra_mipi_wait(device->mipi);
-
mutex_unlock(&device->mipi->lock);
clk_disable(device->mipi->clk);
- return err;
+ return 0;
}
EXPORT_SYMBOL(tegra_mipi_calibrate);
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index a61ca52..dbad062 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -332,5 +332,6 @@ void tegra_mipi_free(struct tegra_mipi_device *device);
int tegra_mipi_enable(struct tegra_mipi_device *device);
int tegra_mipi_disable(struct tegra_mipi_device *device);
int tegra_mipi_calibrate(struct tegra_mipi_device *device);
+int tegra_mipi_wait(struct tegra_mipi_device *device);
#endif
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v1 13/18] gpu: host1x: mipi: Add of_tegra_mipi_request() API
From: Sowjanya Komatineni @ 2020-06-10 6:02 UTC (permalink / raw)
To: skomatineni-DDmLM1+adcrQT0dZR+AlfA,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, frankc-DDmLM1+adcrQT0dZR+AlfA,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sakari.ailus-X3B1VOXEql0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
helen.koike-ZGY8ohtN/8qB+jHODAdFcQ
Cc: digetx-Re5JQEeQqe8AvxtiuMwx3w, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1591768960-31648-1-git-send-email-skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
This patch adds an API of_tegra_mipi_request() to allow creating
mipi device for specific device node rather than a device so Tegra
CSI driver can use it for calibrating MIPI pads for each stream
independently.
Signed-off-by: Sowjanya Komatineni <skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
drivers/gpu/host1x/mipi.c | 10 ++++++++--
include/linux/host1x.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
index e00809d..f51fe69 100644
--- a/drivers/gpu/host1x/mipi.c
+++ b/drivers/gpu/host1x/mipi.c
@@ -206,9 +206,9 @@ static int tegra_mipi_power_down(struct tegra_mipi *mipi)
return 0;
}
-struct tegra_mipi_device *tegra_mipi_request(struct device *device)
+struct tegra_mipi_device *of_tegra_mipi_request(struct device *device,
+ struct device_node *np)
{
- struct device_node *np = device->of_node;
struct tegra_mipi_device *dev;
struct of_phandle_args args;
int err;
@@ -252,6 +252,12 @@ struct tegra_mipi_device *tegra_mipi_request(struct device *device)
of_node_put(args.np);
return ERR_PTR(err);
}
+EXPORT_SYMBOL(of_tegra_mipi_request);
+
+struct tegra_mipi_device *tegra_mipi_request(struct device *device)
+{
+ return of_tegra_mipi_request(device, device->of_node);
+}
EXPORT_SYMBOL(tegra_mipi_request);
void tegra_mipi_free(struct tegra_mipi_device *device)
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index c230b4e..a61ca52 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -325,6 +325,8 @@ int host1x_client_resume(struct host1x_client *client);
struct tegra_mipi_device;
+struct tegra_mipi_device *of_tegra_mipi_request(struct device *device,
+ struct device_node *np);
struct tegra_mipi_device *tegra_mipi_request(struct device *device);
void tegra_mipi_free(struct tegra_mipi_device *device);
int tegra_mipi_enable(struct tegra_mipi_device *device);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v1 12/18] media: tegra-video: Add support for selection ioctl ops
From: Sowjanya Komatineni @ 2020-06-10 6:02 UTC (permalink / raw)
To: skomatineni, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: digetx, sboyd, gregkh, linux-media, devicetree, linux-tegra,
linux-kernel, linux-i2c
In-Reply-To: <1591768960-31648-1-git-send-email-skomatineni@nvidia.com>
This patch adds selection v4l2 ioctl operations to allow configuring
a selection rectangle in the sensor through the Tegra video device
node.
Some sensor drivers supporting crop uses try_crop rectangle from
v4l2_subdev_pad_config during try format for computing binning.
So with selection ops support, this patch also updates try format
to use try crop rectangle either from subdev frame size enumeration
or from subdev crop boundary.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
drivers/staging/media/tegra-video/vi.c | 106 +++++++++++++++++++++++++++++++++
1 file changed, 106 insertions(+)
diff --git a/drivers/staging/media/tegra-video/vi.c b/drivers/staging/media/tegra-video/vi.c
index 6f320c1..03def26 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -427,6 +427,13 @@ static int __tegra_channel_try_format(struct tegra_vi_channel *chan,
struct v4l2_subdev *subdev;
struct v4l2_subdev_format fmt;
struct v4l2_subdev_pad_config *pad_cfg;
+ struct v4l2_subdev_frame_size_enum fse = {
+ .which = V4L2_SUBDEV_FORMAT_TRY,
+ };
+ struct v4l2_subdev_selection sdsel = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ .target = V4L2_SEL_TGT_CROP_BOUNDS,
+ };
int ret;
subdev = tegra_channel_get_remote_subdev(chan, true);
@@ -449,6 +456,24 @@ static int __tegra_channel_try_format(struct tegra_vi_channel *chan,
fmt.which = V4L2_SUBDEV_FORMAT_TRY;
fmt.pad = 0;
v4l2_fill_mbus_format(&fmt.format, pix, fmtinfo->code);
+
+ /*
+ * Attempt to obtain the format size from subdev.
+ * If not available, try to get crop boundary from subdev.
+ */
+ fse.code = fmtinfo->code;
+ ret = v4l2_subdev_call(subdev, pad, enum_frame_size, pad_cfg, &fse);
+ if (ret) {
+ ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, &sdsel);
+ if (ret)
+ return -EINVAL;
+ pad_cfg->try_crop.width = sdsel.r.width;
+ pad_cfg->try_crop.height = sdsel.r.height;
+ } else {
+ pad_cfg->try_crop.width = fse.max_width;
+ pad_cfg->try_crop.height = fse.max_height;
+ }
+
ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, &fmt);
if (ret < 0)
return ret;
@@ -540,6 +565,85 @@ static int tegra_channel_set_subdev_active_fmt(struct tegra_vi_channel *chan)
return 0;
}
+static int tegra_channel_g_selection(struct file *file, void *priv,
+ struct v4l2_selection *sel)
+{
+ struct tegra_vi_channel *chan = video_drvdata(file);
+ struct v4l2_subdev *subdev;
+ struct v4l2_subdev_format fmt = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ };
+ struct v4l2_subdev_selection sdsel = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ .target = sel->target,
+ };
+ int ret;
+
+ if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOTTY;
+
+ if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+ /*
+ * Try the get selection operation and fallback to get format if not
+ * implemented.
+ */
+ subdev = tegra_channel_get_remote_subdev(chan, true);
+ ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, &sdsel);
+ if (!ret)
+ sel->r = sdsel.r;
+ if (ret != -ENOIOCTLCMD)
+ return ret;
+
+ ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt);
+ if (ret < 0)
+ return ret;
+
+ sel->r.left = 0;
+ sel->r.top = 0;
+ sel->r.width = fmt.format.width;
+ sel->r.height = fmt.format.height;
+
+ return 0;
+}
+
+static int tegra_channel_s_selection(struct file *file, void *fh,
+ struct v4l2_selection *sel)
+{
+ struct tegra_vi_channel *chan = video_drvdata(file);
+ struct v4l2_subdev *subdev;
+ int ret;
+ struct v4l2_subdev_selection sdsel = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ .target = sel->target,
+ .flags = sel->flags,
+ .r = sel->r,
+ };
+
+ if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOTTY;
+
+ if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ if (vb2_is_busy(&chan->queue))
+ return -EBUSY;
+
+ subdev = tegra_channel_get_remote_subdev(chan, true);
+ ret = v4l2_subdev_call(subdev, pad, set_selection, NULL, &sdsel);
+ if (!ret) {
+ sel->r = sdsel.r;
+ /*
+ * Subdev active format resolution may have changed during
+ * set selection operation. So, update channel format to
+ * the sub-device active format.
+ */
+ return tegra_channel_set_subdev_active_fmt(chan);
+ }
+
+ return ret;
+}
+
static int tegra_channel_enum_input(struct file *file, void *fh,
struct v4l2_input *inp)
{
@@ -597,6 +701,8 @@ static const struct v4l2_ioctl_ops tegra_channel_ioctl_ops = {
.vidioc_streamoff = vb2_ioctl_streamoff,
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
+ .vidioc_g_selection = tegra_channel_g_selection,
+ .vidioc_s_selection = tegra_channel_s_selection,
};
/*
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox