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
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
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
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(),
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
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.
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
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
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);
> >
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
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 because you
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
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
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
lines
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
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
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
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
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:
> > -
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
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
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 +++
>
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
>
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
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 --
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
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
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
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
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
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
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
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
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:
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
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
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
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
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 +-
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
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
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
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
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
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
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
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
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.
> + {
> +
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
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
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
---
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 +-
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:
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
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
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
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
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
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
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
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
---
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 ++---
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
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 ++
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
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
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
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 --
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
---
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
and the dpi/drm_drv adjustments to
support hdmi.
Based on next-20221104
test branch with dts and various "in flight" patches available here:
https://gitlab.com/granquet/linux/-/tree/granquet/linux-next_HDMI
I haven't updated the vdosys/mmsys/ethdr and mutex patches in a while
in that test
On 04/11/2022 14:13, Dmitry Baryshkov wrote:
Add another power saving state used on SM8450. Unfortunately adding it
in proper place causes renumbering of all the opp states in sm8450.dtsi
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Konrad Dybcio
Konrad
On 04/11/2022 14:03, Dmitry Baryshkov wrote:
Add support for the MDSS block on SM8450 platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Konrad Dybcio
Konrad
drivers/gpu/drm/msm/msm_mdss.c | 5 +
1 file changed, 5
On 04/11/2022 14:03, Dmitry Baryshkov wrote:
Add definitions for the display hardware used on Qualcomm SM8450
platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Konrad Dybcio
Konrad
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
1 - 100 of 237 matches
Mail list logo
