From: "Steven Rostedt (Google)"
Before a timer is released, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-..
From: "Steven Rostedt (Google)"
Before a timer is released, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko
Back in April, I posted an RFC patch set to help mitigate a common issue
where a timer gets armed just before it is freed, and when the timer
goes off, it crashes in the timer code without any evidence of who the
culprit was. I got side tracked and never finished up on that patch set.
Since this
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ur
On Wed, Nov 02, 2022 at 12:21:08PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
If a context has already been registered prior to first submission
then context init code was not being called. The noticeable effect of
that was the scheduling priority was left at zero (meaning supe
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead
Looks like that we're accidentally dropping a pretty important return code
here. For some reason, we just return -EINVAL if we fail to get the MST
topology state. This is wrong: error codes are important and should never
be squashed without being handled, which here seems to have the potential
to c
It appears that amdgpu makes the mistake of completely ignoring the return
values from the DP MST helpers, and instead just returns a simple
true/false. In this case, it seems to have come back to bite us because as
a result of simply returning false from
compute_mst_dsc_configs_for_state(), amdgpu
On Fri, Nov 04, 2022 at 01:40:53AM -0400, Steven Rostedt wrote:
>
> Back in April, I posted an RFC patch set to help mitigate a common issue
> where a timer gets armed just before it is freed, and when the timer
> goes off, it crashes in the timer code without any evidence of who the
> culprit was
From: antoniospg
Summary:
* Add support to turn on/off backlight when changing values in bl_power
file. This is achieved by using function backlight_get_brightness()
in nva3_set_intensity to get current brightness.
Test plan:
* Turn off:
echo 1 > /sys/class/backlight/nv_backlight/bl_power
From: antoniospg
Summary:
* Add support to turn on/off backlight when changing values in bl_power
file. This is achieved by using function backlight_get_brightness()
in nva3_set_intensity to get current brightness.
Test plan:
* Turn off:
echo 1 > /sys/class/backlight/nv_backlight/bl_power
The pull request you sent on Fri, 4 Nov 2022 13:21:02 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-11-04-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fde25beb382b7dd6f2eab8022ab017cbdfaa3ff6
Thank you!
--
Deet-doot-dot, I am a bot.
https://
Hi Dave, Daniel,
New stuff for 6.2.
The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:
Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-next-6.2-2022-11-04
for you to fe
On 11/4/22 23:37, Robin Murphy wrote:
> On 2022-11-04 20:11, Dmitry Osipenko wrote:
>> On 8/23/22 01:01, Robin Murphy wrote:
>>> Convert to io-pgtable's bulk {map,unmap}_pages() APIs, to help the old
>>> single-page interfaces eventually go away. Unmapping heap BOs still
>>> wants to be done a page
On Fri, Nov 04, 2022 at 04:38:34PM -0400, Steven Rostedt wrote:
> On Fri, 4 Nov 2022 15:42:09 -0400
> Steven Rostedt wrote:
>
[ ... ]
>
> > drivers/clocksource/timer-fttmr010.c: fttmr010->timer_shutdown(evt);
> > drivers/clocksource/timer-fttmr010.c: fttmr010->timer_shutdown(evt);
> > driver
On Fri, Nov 04, 2022 at 03:42:09PM -0400, Steven Rostedt wrote:
> On Fri, 4 Nov 2022 12:22:32 -0700
> Guenter Roeck wrote:
>
> > Unfortunately the renaming caused some symbol conflicts.
> >
> > Global definition: timer_shutdown
> >
> > File Line
> > 0 time.c93 static i
On 2022-11-04 15:41, coverity-bot wrote:
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20221104 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email becaus
On Fri, 4 Nov 2022 15:42:09 -0400
Steven Rostedt wrote:
> $ git grep '\btimer_shutdown'
> arch/arm/mach-spear/time.c:static inline void timer_shutdown(struct
> clock_event_device *evt)
> arch/arm/mach-spear/time.c: timer_shutdown(evt);
> arch/arm/mach-spear/time.c: timer_shutdown(evt);
>
On 2022-11-04 20:11, Dmitry Osipenko wrote:
On 8/23/22 01:01, Robin Murphy wrote:
Convert to io-pgtable's bulk {map,unmap}_pages() APIs, to help the old
single-page interfaces eventually go away. Unmapping heap BOs still
wants to be done a page at a time, but everything else can get the full
ben
On 8/23/22 01:01, Robin Murphy wrote:
> Convert to io-pgtable's bulk {map,unmap}_pages() APIs, to help the old
> single-page interfaces eventually go away. Unmapping heap BOs still
> wants to be done a page at a time, but everything else can get the full
> benefit of the more efficient interface.
>
On Tue, Nov 01, 2022 at 08:21:20AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, October 26, 2022 2:51 AM
> >
> > +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> > +{
> > + u32 ioas_id;
> > + u32 device_id;
> > + int ret;
> > +
> > +
On Fri, Nov 4, 2022 at 12:42 PM Steven Rostedt wrote:
>
> Linus, should I also add any patches that has already been acked by the
> respective maintainer?
No, I'd prefer to keep only the ones that are 100% unambiguously not
changing any semantics.
Linus
On Thu, Nov 03, 2022 at 04:38:16AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, November 1, 2022 8:26 PM
> > And this:
> >
> > /*
> > * If the device does not have
> > IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
> > * any domain later attached to it will also no
On Fri, 4 Nov 2022 12:22:32 -0700
Guenter Roeck wrote:
> Unfortunately the renaming caused some symbol conflicts.
>
> Global definition: timer_shutdown
>
> File Line
> 0 time.c93 static inline void timer_shutdown(struct
> clock_event_device *evt)
> 1 arm_arch_timer.c
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20221104 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email because you were associated with the identified
lin
On Fri, Nov 04, 2022 at 01:40:53AM -0400, Steven Rostedt wrote:
>
> Back in April, I posted an RFC patch set to help mitigate a common issue
> where a timer gets armed just before it is freed, and when the timer
> goes off, it crashes in the timer code without any evidence of who the
> culprit was
On Fri, Nov 4, 2022 at 12:50 AM Mauro Carvalho Chehab
wrote:
>
> On Thu, 3 Nov 2022 15:43:26 -0700
> Daniel Latypov wrote:
>
> > On Thu, Nov 3, 2022 at 8:23 AM Mauro Carvalho Chehab
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm facing a couple of issues when testing KUnit with the i915 driver.
> >
On 10/31/2022 8:36 PM, Badal Nilawar wrote:
From: Vinay Belgaumkar
By defaut idle mesaging is disabled for GSC CS so to unblock RC6
entry on media tile idle messaging need to be enabled.
C6 entry instead of RC6. Also *needs*.
Bspec: 71496
Cc: Daniele Ceraolo Spurio
Signed-off-by: Vinay B
On Fri, 4 Nov 2022 08:48:28 +
Tvrtko Ursulin wrote:
> If it stays all DRM drivers in one patch then I guess it needs to go via
> drm-misc, which for i915 would be okay I think in this case since patch
> is extremely unlikely to clash with anything. Or split it up per driver
> and then we c
On 11/4/2022 11:53, Ceraolo Spurio, Daniele wrote:
On 11/2/2022 12:21 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If a context has already been registered prior to first submission
then context init code was not being called. The noticeable effect of
that was the scheduling priori
On Fri, 4 Nov 2022 08:15:53 +0100
Christian König wrote:
> > index fb6e0a6ae2c9..5d3e7b503501 100644
> > --- a/drivers/dma-buf/st-dma-fence.c
> > +++ b/drivers/dma-buf/st-dma-fence.c
> > @@ -412,7 +412,7 @@ static int test_wait_timeout(void *arg)
> >
> > err = 0;
> > err_free:
> > - de
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 0cdb3579f1ee4c1e55acf8dfb0697b660067b1f8 Add linux-next specific
files for 20221104
Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
On 11/2/2022 12:21 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If a context has already been registered prior to first submission
then context init code was not being called. The noticeable effect of
that was the scheduling priority was left at zero (meaning super high
priority)
On Fri, Nov 4, 2022 at 6:05 AM Hanjun Guo wrote:
>
> VBIOSImageOffset in struct UEFI_ACPI_VFCT is ULONG (unsigned long),
> but it will be assigned to "unsigned offset", so use unsigned long
> instead of unsigned for the offset, to avoid possible overflow.
ULONG in atombios is 32 bits so an int sh
On Wed, Oct 26, 2022 at 05:34:27PM +0200, Danilo Krummrich wrote:
> Hi,
Hi Danilo,
>
> This patch series converts the driver to use drm managed resources to prevent
> potential use-after-free issues on driver unbind/rebind and to get rid of the
> usage of deprecated APIs.
>
> Changes in v2:
>
On Fri, 04 Nov 2022 16:03:19 +0300, Dmitry Baryshkov wrote:
> Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
> SM8450 platform.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/qcom,sm8450-dpu.yaml | 132 +++
> .../display/msm/qcom,sm8450-mdss.
On Fri, Nov 04, 2022 at 12:15:59AM +0530, Badal Nilawar wrote:
> This workaround is added for Media tile of MTL A step. It is to help
> pcode workaround which handles the hardware issue seen during package C2/C3
> transitions due to RC6 entry/exit transitions on Media tile. As a part of
> workaro
On 11/4/2022 03:01, Tvrtko Ursulin wrote:
On 03/11/2022 19:16, John Harrison wrote:
On 11/3/2022 02:38, Tvrtko Ursulin wrote:
On 03/11/2022 09:18, Tvrtko Ursulin wrote:
On 03/11/2022 01:33, John Harrison wrote:
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On 11/4/22 04:16, Dmitry Torokhov wrote:
This series converts various OMAPFB drivers to use the newer gpiod API
that respects line polarity specified in DTS.
Unfortunately existing DTS files specify incorrect (active high) polarity
for reset lines. As discussed in [1] we will not try to correct
On Wed, Nov 02, 2022 at 10:10:47AM -0700, Daniele Ceraolo Spurio wrote:
> There is no userspace user for this CS yet, we only need it for internal
> kernel ops (e.g. HuC, PXP), so don't expose it.
>
> v2: even if it's not exposed, rename the engine so it is easier to
> identify in the debug logs (
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
Use the new GT oriented output message helpers where possible.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 25 +++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 9 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 50 --
dr
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
On 11/4/22 8:17 AM, Maxime Ripard wrote:
The Davinci DA8xxx cfgchip "clk48" clock implements a mux with a
set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most
On 11/4/22 8:18 AM, Maxime Ripard wrote:
The TI DA8xx USB0 clk48 clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely can
On 11/4/22 8:17 AM, Maxime Ripard wrote:
The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most like
On Thu, Nov 3, 2022 at 10:48 PM Steven Rostedt wrote:
>
> Ideally, I would have the first patch go into this rc cycle, which is mostly
> non functional as it will allow the other patches to come in via the
> respective
> subsystems in the next merge window.
Ack.
I also wonder if we could do the
Hi Matthew, Rafael,
On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 10/27/22 11:52, Matthew Garrett wrote:
>>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote:
>>>
The *only* behavior which actually is new i
On 11/4/22 11:05 AM, Dawei Li wrote:
Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create
Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create device_create
list_add
On 04/11/2022 15:48, Krzysztof Kozlowski wrote:
On 04/11/2022 11:46, Jon Hunter wrote:
On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
On 04/11/2022 11:33, Jon Hunter wrote:
Hi Thierry, Krzysztof,
On 24/10/2022 14:15, Thierry Reding wrote:
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko P
On Fri, Nov 04, 2022 at 04:51:23PM +0100, Maxime Ripard wrote:
> Just filling determine_rate if it's missing with
> __clk_mux_determine_rate will possibly pick different parents, and I'm
> fairly certain that this have never been tested on most platforms, and
> will be completely broken. And I don
From: Rob Clark
Minimize interactive latency by boosting frequency when userspace is
waiting on the GPU to finish.
Signed-off-by: Rob Clark
---
I did contemplate also boosting on dma_fence_wait(), but (a) that would
require some extra plumbing thru gpu-sched, (b) that only captures a
sub-set of
Hi Mark,
On Fri, Nov 04, 2022 at 03:44:53PM +, Mark Brown wrote:
> On Fri, Nov 04, 2022 at 02:18:00PM +0100, Maxime Ripard wrote:
>
> > So, the set_parent hook is effectively unused, possibly because of an
> > oversight. However, it could also be an explicit decision by the
> > original autho
On 04/11/2022 11:46, Jon Hunter wrote:
>
> On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
>> On 04/11/2022 11:33, Jon Hunter wrote:
>>> Hi Thierry, Krzysztof,
>>>
>>> On 24/10/2022 14:15, Thierry Reding wrote:
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
> From: Mikko
On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
On 04/11/2022 11:33, Jon Hunter wrote:
Hi Thierry, Krzysztof,
On 24/10/2022 14:15, Thierry Reding wrote:
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
From: Mikko Perttunen
On Tegra234 NVDEC firmware is loaded from a secur
On Fri, Nov 04, 2022 at 02:18:00PM +0100, Maxime Ripard wrote:
> So, the set_parent hook is effectively unused, possibly because of an
> oversight. However, it could also be an explicit decision by the
> original author to avoid any reparenting but through an explicit call to
> clk_set_parent().
On 04/11/2022 11:33, Jon Hunter wrote:
> Hi Thierry, Krzysztof,
>
> On 24/10/2022 14:15, Thierry Reding wrote:
>> On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
>>> From: Mikko Perttunen
>>>
>>> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
>>> has been l
Hi Thierry, Krzysztof,
On 24/10/2022 14:15, Thierry Reding wrote:
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
From: Mikko Perttunen
On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
has been loaded by a bootloader. When booting NVDEC, we need to tell i
On 04-11-22, 16:13, Dmitry Baryshkov wrote:
> Enable MDSS/DPU/DSI0 on SM8450-HDK device. Note, there is no panel
> configuration (yet).
>
> Signed-off-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git
From: Rob Clark
If the hangcheck timer expires, check if the fw's position in the
cmdstream has advanced (changed) since last timer expiration, and
allow it up to three additional "extensions" to it's alotted time.
The intention is to continue to catch "shader stuck in a loop" type
hangs quickly,
From: Rob Clark
The _HI reg is always following the _LO reg, so no need to pass these
offsets seprately.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/a5xx_gpu.c |
From: Rob Clark
Try to detect when submit jobs are making forward progress and give them
a bit more time.
Rob Clark (2):
drm/msm/adreno: Simplify read64/write64 helpers
drm/msm: Hangcheck progress detection
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 3 +-
drivers/gpu/drm/msm/adreno/a5x
Am 04.11.22 um 15:58 schrieb Rob Clark:
On Wed, Nov 2, 2022 at 5:21 AM Christian König
wrote:
Hi Lucas,
Am 02.11.22 um 12:39 schrieb Lucas Stach:
Hi Christian,
going to reply in more detail when I have some more time, so just some
quick thoughts for now.
Am Mittwoch, dem 02.11.2022 um 12:18
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +, Paul Cercueil wrote:
> Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard a
> écrit :
> > The Ingenic CGU clocks implements a mux with a set_parent hook, but
> > doesn't provide a determine_rate implementation.
> >
> > This is a bit odd, since
On Wed, Nov 2, 2022 at 5:21 AM Christian König
wrote:
>
> Hi Lucas,
>
> Am 02.11.22 um 12:39 schrieb Lucas Stach:
> > Hi Christian,
> >
> > going to reply in more detail when I have some more time, so just some
> > quick thoughts for now.
> >
> > Am Mittwoch, dem 02.11.2022 um 12:18 +0100 schrieb
On Fri, Nov 04, 2022 at 10:57:28AM +, Nancy Lin (林欣螢) wrote:
> Dear Nicolas,
>
> Thanks for the review.
>
> On Thu, 2022-11-03 at 17:28 -0400, Nícolas F. R. A. Prado wrote:
> > On Thu, Nov 03, 2022 at 11:26:09AM +0800, Nancy.Lin wrote:
> > > Add drm ovl_adaptor sub driver. Bring up ovl_adapto
Am 04.11.22 um 14:38 schrieb Nicolas Dufresne:
Le vendredi 04 novembre 2022 à 10:03 +0100, Christian König a écrit :
Am 03.11.22 um 23:16 schrieb Nicolas Dufresne:
[SNIP]
Was there APIs suggested to actually make it manageable by userland to allocate
from the GPU? Yes, this what Linux Device A
On Fri, Nov 04, 2022 at 05:31:24PM +0530, Deepak R Varma wrote:
> On Mon, Oct 31, 2022 at 01:05:32PM +0100, Julia Lawall wrote:
> >
> >
> > I took a look, but it's pretty complex. You could take the code and
> > reorganize it so that it is more readable, and then take the definition of
> > the ARR
Hi Maxime,
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard
a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name
implies,
change the parent of a clock.
The determine_rate hook allows to select the proper parent and its rate
for a given clock configuration. On another hand, set_parent is there to
change the parent of a mux.
Some clocks provide a set_parent hook but don't implement
determine_rate. In such a case, set_parent is pretty much useless s
The tlv320aic32x4 divider clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The tlv320aic32x4 PLL clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a cal
On 04/11/2022 09:13, Dmitry Baryshkov wrote:
> From: Vinod Koul
>
> Add the HDMI display nodes and link it to DSI. Also enable missing dispcc
> nodes
>
> Signed-off-by: Vinod Koul
> Signed-off-by: Dmitry Baryshkov
Thank you for your patch. There is something to discuss/improve.
> +&dispcc {
Move the stuff associated with the mdev parent (and thus the
subchannel struct) into its own struct, and leave the rest in
the existing private structure.
The subchannel will point to the parent, and the parent will point
to the private, for the areas where one or both are needed. Further
separati
With the "mess" sorted out, we should be able to inline the
vfio_free_device call introduced by commit cb9ff3f3b84c
("vfio: Add helpers for unifying vfio_device life cycle")
and remove them from driver release callbacks.
Signed-off-by: Eric Farman
Reviewed-by: Jason Gunthorpe
Reviewed-by: Kevin
Now that we have a reasonable separation of structs that follow
the subchannel and mdev lifecycles, there's no reason we can't
call the official vfio_alloc_device routine for our private data,
and behave like everyone else.
Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
Acked-by: Alex Willia
These places all rely on the ability to jump from a private
struct back to the subchannel struct. Rather than keeping a
copy in our back pocket, let's use the relationship provided
by the vfio_device embedded within the private.
Signed-off-by: Eric Farman
Reviewed-by: Matthew Rosato
---
drivers
There's enough separation between the parent and private structs now,
that it is fine to remove the release completion hack.
Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
Reviewed-by: Matthew Rosato
---
drivers/s390/cio/vfio_ccw_ops.c | 14 +-
drivers/s390/cio/vfio_ccw_pri
Now that the mdev parent data is split out into its own struct,
it is safe to move the remaining private data to follow the
mdev probe/remove lifecycle. The mdev parent data will remain
where it is, and follow the subchannel and the css driver
interfaces.
Signed-off-by: Eric Farman
Reviewed-by: M
Hi Alex,
Here's the (last?) update to the vfio-ccw lifecycle changes that I've sent
recently, and were previously discussed at various points [1][2].
Patches 1-5 rework the behavior of the vfio-ccw driver's private struct.
In summary, the mdev pieces are split out of vfio_ccw_private and into a
n
There's already a device initialization callback that is used to
initialize the release completion workaround that was introduced
by commit ebb72b765fb49 ("vfio/ccw: Use the new device life cycle
helpers").
Move the other elements of the vfio_ccw_private struct that
require distinct initialization
On 04/11/2022 09:13, Dmitry Baryshkov wrote:
> From: Vinod Koul
>
> Add the LT9611uxc DSI-HDMI bridge and supplies
>
> Signed-off-by: Vinod Koul
> Signed-off-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 61 +
> 1 file changed, 61 insertions(+)
On 04/11/2022 14:13, Dmitry Baryshkov wrote:
From: Vinod Koul
Add the HDMI display nodes and link it to DSI. Also enable missing dispcc
nodes
Signed-off-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 45 +
1 file chan
On 04/11/2022 14:13, Dmitry Baryshkov wrote:
From: Vinod Koul
Add the LT9611uxc DSI-HDMI bridge and supplies
Signed-off-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 61 +
1 file changed, 61 insertions(+)
diff --git
On 04/11/2022 09:13, Dmitry Baryshkov wrote:
> Add devices tree nodes describing display hardware on SM8450:
> - Display Clock Controller
> - MDSS
> - MDP
> - two DSI controllers and DSI PHYs
>
> This does not provide support for DP controllers present on SM8450.
>
> Signed-off-by: Dmitry Baryshk
On 04/11/2022 14:13, Dmitry Baryshkov wrote:
Enable MDSS/DPU/DSI0 on SM8450-HDK device. Note, there is no panel
configuration (yet).
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm6
On 04/11/2022 14:13, Dmitry Baryshkov wrote:
Add devices tree nodes describing display hardware on SM8450:
- Display Clock Controller
- MDSS
- MDP
- two DSI controllers and DSI PHYs
This does not provide support for DP controllers present on SM8450.
Signed-off-by: Dmitry Baryshkov
---
arch
Create a common "framework" that can be used to add support for
different hdmi IPs within the mediatek range of products.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c| 620 ++---
driv
Add dt-binding documentation of dpi for MediaTek MT8195 SoC.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Guillaume Ranquet
---
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/med
Add basic support for the mediatek hdmi phy on MT8195 SoC
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 543 +
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.h | 109 ++
drivers/phy/
Add HDMI audio support for v2
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 1 +
drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c | 2 +-
drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 213 +
drivers/gpu/drm/mediatek/mtk_hdmi_v2.h |
Add the DPI1 hdmi path support in mtk dpi driver
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 143 ++--
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 5 ++
2 files changed, 141 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm
Some phys, such as mt8195, needs to have a configure callback defined.
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 12
drivers/phy/mediatek/phy-mtk-hdmi.h | 1 +
2 files changed, 13 insertions(+)
diff --git a
Add a flag to indicate support for frame colorimetry.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 11 +++
drivers/gpu/drm/mediatek/mtk_hdmi_common.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_common.c
b
Adds hdmi and hdmi-ddc support for v2 IP.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/Makefile |2 +
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 14 +
drivers/gpu/drm/mediatek/mtk_hdmi_common.h |1 +
drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c | 367
Make cec device optional in order to support newer versions of the
hdmi IP which doesn't require it
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi.c| 8 +++--
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 54 --
drivers/gpu/drm/mediatek
To prepare support for newer chips that need to share their address
range with a dedicated ddc driver, use a regmap.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 43 +++--
1 file changed, 13 insertions(+), 30 deletions(-)
diff --git
Add mt8195 SoC bindings for hdmi and hdmi-ddc
On mt8195 the ddc i2c controller is part of the hdmi IP block and thus has no
specific register range, power domain or interrupt, making it simpler
than its the legacy "mediatek,hdmi-ddc" binding.
Signed-off-by: Guillaume Ranquet
---
.../bindings/di
Add a compatible for the HDMI PHY on MT8195
Acked-by: Krzysztof Kozlowski
Signed-off-by: Guillaume Ranquet
---
Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
b/Documen
1 - 100 of 226 matches
Mail list logo
