Hi Laurent,
21. 8. 13. 오후 9:16에 Laurent Pinchart 이(가) 쓴 글:
> Hi Inki,
>
> On Fri, Aug 13, 2021 at 03:50:56PM +0900, Inki Dae wrote:
>> 21. 7. 26. 오전 2:25에 Sam Ravnborg 이(가) 쓴 글:
>>> On Sun, Jul 04, 2021 at 02:32:19PM +0530, Jagan Teki wrote:
Exynos DSI driver is actually a Samsung MIPI DSIM
On 18-08-21, 08:21, Dmitry Osipenko wrote:
> Yes, GENPD will cache the perf state across suspend/resume and initially
> cached value is out of sync with h/w.
>
> Nothing else. But let me clarify it all again.
Thanks for your explanation.
> Initially the performance state of all GENPDs is 0 for
18.08.2021 07:53, Viresh Kumar пишет:
> On 18-08-21, 07:37, Dmitry Osipenko wrote:
>> This will set voltage level without having an actively used hardware.
>> Take a 3d driver for example, if you set the rate on probe and
>> rpm-resume will never be called, then the voltage will be set high,
>>
On 18-08-21, 07:37, Dmitry Osipenko wrote:
> This will set voltage level without having an actively used hardware.
> Take a 3d driver for example, if you set the rate on probe and
> rpm-resume will never be called, then the voltage will be set high,
> while hardware is kept suspended if userspace
Hi, Markus:
On Mon, 2021-08-16 at 21:25 +0200, Markus Schneider-Pargmann wrote:
> DP_INTF is similar to the actual dpi. They differ in some points
> regarding registers and what needs to be set but the function blocks
> itself are similar in design.
>
> Signed-off-by: Markus Schneider-Pargmann
Hi, Markus:
On Mon, 2021-08-16 at 21:25 +0200, Markus Schneider-Pargmann wrote:
> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>
> It supports both functional units on the mt8195, the embedded
> DisplayPort as well as the external DisplayPort units. It offers
>
18.08.2021 07:31, Viresh Kumar пишет:
> On 18-08-21, 07:12, Dmitry Osipenko wrote:
>> 18.08.2021 06:55, Viresh Kumar пишет:
>>> On 17-08-21, 18:49, Dmitry Osipenko wrote:
17.08.2021 10:55, Viresh Kumar пишет:
...
>> +int dev_pm_opp_sync(struct device *dev)
>> +{
>> +
On 18-08-21, 07:30, Dmitry Osipenko wrote:
> 18.08.2021 07:29, Dmitry Osipenko пишет:
> >> The first resume initializes the OPP state on sync, all further syncs on
> >> resume are no-ops.
> >>
> >
> > Notice that we use GENPD here. GENPD core takes care of storing PD's
> > performance state
On 18-08-21, 07:12, Dmitry Osipenko wrote:
> 18.08.2021 06:55, Viresh Kumar пишет:
> > On 17-08-21, 18:49, Dmitry Osipenko wrote:
> >> 17.08.2021 10:55, Viresh Kumar пишет:
> >> ...
> +int dev_pm_opp_sync(struct device *dev)
> +{
> +struct opp_table *opp_table;
> +
18.08.2021 07:29, Dmitry Osipenko пишет:
> 18.08.2021 07:12, Dmitry Osipenko пишет:
>> 18.08.2021 06:55, Viresh Kumar пишет:
>>> On 17-08-21, 18:49, Dmitry Osipenko wrote:
17.08.2021 10:55, Viresh Kumar пишет:
...
>> +int dev_pm_opp_sync(struct device *dev)
>> +{
>> +
18.08.2021 07:12, Dmitry Osipenko пишет:
> 18.08.2021 06:55, Viresh Kumar пишет:
>> On 17-08-21, 18:49, Dmitry Osipenko wrote:
>>> 17.08.2021 10:55, Viresh Kumar пишет:
>>> ...
> +int dev_pm_opp_sync(struct device *dev)
> +{
> + struct opp_table *opp_table;
> + struct dev_pm_opp
18.08.2021 06:55, Viresh Kumar пишет:
> On 17-08-21, 18:49, Dmitry Osipenko wrote:
>> 17.08.2021 10:55, Viresh Kumar пишет:
>> ...
+int dev_pm_opp_sync(struct device *dev)
+{
+ struct opp_table *opp_table;
+ struct dev_pm_opp *opp;
+ int ret = 0;
+
+ /*
On 17-08-21, 18:49, Dmitry Osipenko wrote:
> 17.08.2021 10:55, Viresh Kumar пишет:
> ...
> >> +int dev_pm_opp_sync(struct device *dev)
> >> +{
> >> + struct opp_table *opp_table;
> >> + struct dev_pm_opp *opp;
> >> + int ret = 0;
> >> +
> >> + /* Device may not have OPP table */
> >> +
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
Drop the wrapping structures and the enum used to index those
structures
in dpu_kms. Instead of them use IRQ indices and callback functions
directly.
Signed-off-by: Dmitry Baryshkov
Is this change really needed because I think the enum based
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
Get rid of dpu_encoder_helper_register_irq/unregister_irq helpers, call
dpu_core_register/unregister_callback directly, without surrounding
them
with helpers.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
Remove extra dpu_irq_* wrappers from dpu_kms.c, merge them directly
into
dpu_core_irq_* functions.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 12 -
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
DPU interrupts code allows multiple callbacks per interrut. In reality
/interrupt
none of the interrupts is shared between blocks (and will probably
never
be). Drop support for registering multiple callbacks per interrupt to
simplify interrupt
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
As dpu_core_irq was merged into dpu_hw_intr, merge data structures too,
removing the need for a separate data structure.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 51
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
We already clear the IRQ status register before processing IRQs, so do
not clear the register again. Especially do not clear the IRQ status
_after_ processing the IRQ as this way we can loose the event.
Signed-off-by: Dmitry Baryshkov
Reviewed-by:
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
With dpu_core_irq being the wrapper around dpu_hw_interrupts, there is
little sense in having them separate. Squash them together to remove
another layer of abstraction (hw_intr ops).
Signed-off-by: Dmitry Baryshkov
Overall, I think this is a
18.08.2021 05:04, Dmitry Osipenko пишет:
> 18.08.2021 04:37, Dmitry Osipenko пишет:
>> 18.08.2021 04:16, Rob Herring пишет:
>>> On Tue, Aug 17, 2021 at 04:27:29AM +0300, Dmitry Osipenko wrote:
Memory Client should be blocked before hardware reset is asserted in order
to prevent memory
18.08.2021 04:37, Dmitry Osipenko пишет:
> 18.08.2021 04:16, Rob Herring пишет:
>> On Tue, Aug 17, 2021 at 04:27:29AM +0300, Dmitry Osipenko wrote:
>>> Memory Client should be blocked before hardware reset is asserted in order
>>> to prevent memory corruption and hanging of memory controller.
>>>
On Fri, Feb 26, 2021 at 12:08 AM James Park wrote:
>
> On Thu, Feb 4, 2021 at 1:07 PM Emil Velikov wrote:
> >
> > Do send a patch, unless someone shouts against it, I'll be happy to
> > push it and churn the whole copy to drm/mesa game.
> >
> > Thanks
> > Emil
>
> Hi Emil,
>
> Were you still
18.08.2021 04:15, Rob Herring пишет:
>> + tegra-clocks:
>> +description: child nodes are the output clocks from the CAR
>> +type: object
>> +
>> +patternProperties:
>> + "^[a-z]+[0-9]+$":
>> +type: object
>> +properties:
>> + compatible:
>> +
18.08.2021 04:16, Rob Herring пишет:
> On Tue, Aug 17, 2021 at 04:27:29AM +0300, Dmitry Osipenko wrote:
>> Memory Client should be blocked before hardware reset is asserted in order
>> to prevent memory corruption and hanging of memory controller.
>>
>> Document Memory Client resets of Host1x,
On Tue, 17 Aug 2021 04:27:44 +0300, Dmitry Osipenko wrote:
> Document new OPP table and power domain properties of the video decoder
> hardware.
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../devicetree/bindings/media/nvidia,tegra-vde.yaml | 12
> 1 file changed, 12 insertions(+)
On Tue, 17 Aug 2021 04:27:43 +0300, Dmitry Osipenko wrote:
> Convert NVIDIA Tegra video decoder binding to schema.
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../bindings/media/nvidia,tegra-vde.txt | 64 ---
> .../bindings/media/nvidia,tegra-vde.yaml | 107 ++
On Tue, Aug 17, 2021 at 04:27:29AM +0300, Dmitry Osipenko wrote:
> Memory Client should be blocked before hardware reset is asserted in order
> to prevent memory corruption and hanging of memory controller.
>
> Document Memory Client resets of Host1x, GR2D and GR3D hardware units.
>
>
On Tue, Aug 17, 2021 at 04:27:26AM +0300, Dmitry Osipenko wrote:
> Document tegra-clocks sub-node which describes Tegra SoC clocks that
> require a higher voltage of the core power domain in order to operate
> properly on a higher clock rates. Each node contains a phandle to OPP
> table and power
Am 2021-08-17 um 8:01 p.m. schrieb Ralph Campbell:
> On 8/12/21 11:31 PM, Alex Sierra wrote:
>> From: Ralph Campbell
>>
>> ZONE_DEVICE struct pages have an extra reference count that
>> complicates the
>> code for put_page() and several places in the kernel that need to
>> check the
>>
On 8/9/2021 23:36, Daniel Vetter wrote:
On Mon, Aug 09, 2021 at 04:12:52PM -0700, John Harrison wrote:
On 8/6/2021 12:46, Daniel Vetter wrote:
Seen this fly by and figured I dropped a few thoughts in here. At the
likely cost of looking a bit out of whack :-)
On Fri, Aug 6, 2021 at 8:01 PM
On 8/9/2021 23:38, Daniel Vetter wrote:
On Wed, Jul 28, 2021 at 05:33:59PM -0700, Matthew Brost wrote:
Should fix below failures with GuC submission for the following tests:
gem_exec_balancer --r noheartbeat
gem_ctx_persistence --r heartbeat-close
Not going to fix:
gem_ctx_persistence --r
On 8/12/21 11:31 PM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration,
The kernel builds with -Werror=designated-init, and __designated_init
is used by CONFIG_GCC_PLUGIN_RANDSTRUCT for automatically selected (all
function pointer) structures. Include the field names in the init/exit
table. Avoids warnings like:
drivers/gpu/drm/i915/i915_module.c:59:4: error:
Cursors don't have a framebuffer so the fb comparisson was always
failing and atomic state was being committed without any plane state.
So here checking if objects match when checking cursors.
Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
Cc: Daniel Vetter
Cc: Rob Clark
Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
drivers know about DisplayPort over Type-C hotplug events.
Reviewed-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
Changes in v3:
- Only call drm_connector_oob_hotplug_event() on hpd status
Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
rather then having separate code-paths for this in various places
which call it.
Reviewed-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/usb/typec/altmodes/displayport.c | 35
On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
From: Heikki Krogerus
On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI
Add a new drm_connector_oob_hotplug_event() function and
oob_hotplug_event drm_connector_funcs member.
On some hardware a hotplug event notification may come from outside the
display driver / device. An example of this is some USB Type-C setups
where the hardware muxes the DisplayPort data and
Add a function to find a connector based on a fwnode.
This will be used by the new drm_connector_oob_hotplug_event()
function which is added by the next patch in this patch-set.
Changes in v2:
- Complete rewrite to use a global connector list in drm_connector.c
rather then using a
Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).
The adding of the fwnode pointer allows drivers to associate a fwnode
that represents a connector with that connector.
When the new fwnode pointer
Give connector sysfs devices there own device_type, this allows us to
check if a device passed to functions dealing with generic devices is
a drm_connector or not.
A check like this is necessary in the drm_connector_acpi_bus_match()
function added in the next patch in this series.
Tested-by:
Hi all,
Here is a rebased-resend of v4 of my patchset making DP over Type-C work on
devices where the Type-C controller does not drive the HPD pin on the GPU,
but instead we need to forward HPD events from the Type-C controller to
the DRM driver.
Changes in v4 resend:
- Rebase on top of latest
On Tue, Aug 17, 2021 at 10:41 PM Michal Wajdeczko
wrote:
> On 17.08.2021 19:34, Daniel Vetter wrote:
> > On Tue, Aug 17, 2021 at 07:27:18PM +0200, Michal Wajdeczko wrote:
> >> On 17.08.2021 19:20, Daniel Vetter wrote:
> >>> On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:
> On
On Wed, Aug 11, 2021 at 01:50:28PM +0300, Mikko Perttunen wrote:
> Add YAML device tree bindings for NVDEC, now in a more appropriate
> place compared to the old textual Host1x bindings.
>
> Signed-off-by: Mikko Perttunen
> ---
> v3:
> * Drop host1x bindings
> * Change read2 to read-1 in
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set
Panel is 800x1280, but mounted on a laptop form factor, sideways.
Reviewed-by: Hans de Goede
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
This patch series is for making the GPD Win Max display usable with
Linux.
The GPD Win Max is a small laptop, and its eDP panel does not send an
EDID over DPCD; the EDID is instead available in the intel opregion, in
mailbox #5 [1]
The first patch is based on Jani's patch series [2] adding
On 17.08.2021 19:34, Daniel Vetter wrote:
> On Tue, Aug 17, 2021 at 07:27:18PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 17.08.2021 19:20, Daniel Vetter wrote:
>>> On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:
On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:
It may have been, we're in the process of trying to change around how we
currently accept nouveau patches to stop this from happening in the future.
Ben, whenever you get a moment can you take a look at this?
On Mon, 2021-08-16 at 09:03 +0200, Salvatore Bonaccorso wrote:
> Hi,
>
> On Fri, Mar
On 17/08/2021 19:22, Thomas Zimmermann wrote:
> Hi
>
> Am 17.08.21 um 18:32 schrieb Colin King:
>> From: Colin Ian King
>>
>> The variable delta is not initialized and this will cause unexpected
>> behaviour with the comparison of tmpdelta < delta. Fix this by setting
>> it to 0x. This
On Tue, Aug 17, 2021 at 8:16 PM Thomas Zimmermann wrote:
>
> Initialize delta variable in PLL compute function for G200SE, rev 00 to
> the maximum value. Fixes uninitialized usage.
>
> smatch warnings:
> drivers/gpu/drm/mgag200/mgag200_pll.c:142
> mgag200_pixpll_compute_g200se_00() \
>
Hi Nikola,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.14-rc6 next-20210817]
[cannot apply to drm/drm-next]
[If your patch
Applied. Thanks!
Alex
On Tue, Aug 17, 2021 at 10:35 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a dev_err error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 2 +-
> 1 file changed, 1
Hi Nikola,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.14-rc6 next-20210817]
[cannot apply to drm/drm-next]
[If your patch
Hi Anitha,
On Tue, Aug 03, 2021 at 03:04:45PM -0700, Anitha Chrisanthus wrote:
> Use a different value for system clock offset in the
> ppl/llp ratio calculations for clocks higher than 500 Mhz.
>
> Fixes: 98521f4d4b4c ("drm/kmb: Mipi DSI part of the display driver")
> Signed-off-by: Anitha
On Mon, Aug 09, 2021 at 09:47:11PM +0300, Dmitry Baryshkov wrote:
> Add devicetree bindings for the Sharp LS060T1SX01 6.0" FullHD panel
> using NT35695 driver. This panel can be found i.e. in the Dragonboard
> Display Adapter bundle.
>
> Signed-off-by: Dmitry Baryshkov
> ---
>
On Tue, Aug 17, 2021 at 10:26:18AM -0500, Tom Lendacky wrote:
> >>/*
> >> - * If SME is active we need to be sure that kexec pages are
> >> - * not encrypted because when we boot to the new kernel the
> >> + * If host memory encryption is active we need to be sure that kexec
> >> + *
On Tue, Aug 17, 2021 at 09:46:58AM -0500, Tom Lendacky wrote:
> I'm ok with letting the TDX folks make changes to these calls to be SME or
> SEV specific, if necessary, later.
Yap, exactly. Let's add the specific stuff only when really needed.
Thx.
--
Regards/Gruss,
Boris.
On Tue, Aug 17, 2021 at 10:22:52AM -0500, Tom Lendacky wrote:
> I can change it to be an AMD/HYGON check... although, I'll have to check
> to see if any (very) early use of the function will work with that.
We can always change it later if really needed. It is just that I'm not
a fan of such
On Tue, Aug 17, 2021 at 11:39:29AM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:19AM -0700, Matthew Brost wrote:
> > A small race that could result in incorrect accounting of the number
> > of outstanding G2H. Basically prior to this patch we did not increment
> > the number of
Hi
Am 17.08.21 um 18:32 schrieb Colin King:
From: Colin Ian King
The variable delta is not initialized and this will cause unexpected
behaviour with the comparison of tmpdelta < delta. Fix this by setting
it to 0x. This matches the behaviour as in the similar function
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.13.6 |5.13.11
--- Comment #19
Initialize delta variable in PLL compute function for G200SE, rev 00 to
the maximum value. Fixes uninitialized usage.
smatch warnings:
drivers/gpu/drm/mgag200/mgag200_pll.c:142 mgag200_pixpll_compute_g200se_00() \
error: uninitialized symbol 'delta'.
Signed-off-by: Thomas Zimmermann
On Fri, Aug 13, 2021 at 11:48 AM Mark Yacoub wrote:
>
> Thanks for your review Michel!
> @MAINTAINER, could you please strip the Change-Id when applying.
> Thanks!
Applied to drm-misc-fixes with the Change-Id removed.
Thank you for your patch!
Sean
>
> On Fri, Aug 13, 2021 at 3:33 AM Michel
On 2021-06-28 12:19, Dmitry Baryshkov wrote:
Add support for alpha blending properties. Setup the plane blend state
according to those properties.
Signed-off-by: Dmitry Baryshkov
I think this has already been picked up by Rob but just had a couple of
comments
below.
Also, how has this
Hi Nikola,
thanks for the quick re-spin. There is still a few things that needs to
be addressed though. Sorry for not catching these the first time.
On Tue, Aug 17, 2021 at 06:36:05PM +0200, Nikola Pavlica wrote:
> The model and make of the LCD panel of the Vivax TPC-9150 is unknown,
> hence the
On Tue, Aug 17, 2021 at 07:27:18PM +0200, Michal Wajdeczko wrote:
>
>
> On 17.08.2021 19:20, Daniel Vetter wrote:
> > On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:
> >> On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:
> >>> On Mon, Aug 16, 2021 at 06:51:39AM -0700,
On 17.08.2021 19:20, Daniel Vetter wrote:
> On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:
>> On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:
>>> On Mon, Aug 16, 2021 at 06:51:39AM -0700, Matthew Brost wrote:
Add GuC kernel doc for all structures added thus
I'd really like this for Mesa so we can pull drm_fourcc.h into common
WSI code. Why has it stalled?
--Jason
On Tue, Dec 8, 2020 at 2:33 AM James Park wrote:
>
> I updated the patch earlier today incorporating the suggestions. I also had
> to bring back "#include " to drm.h because there's
On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:
> On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 06:51:39AM -0700, Matthew Brost wrote:
> > > Add GuC kernel doc for all structures added thus far for GuC submission
> > > and update the main
On Tue, Aug 17, 2021 at 07:13:33PM +0200, Daniel Vetter wrote:
> On Tue, Aug 17, 2021 at 08:26:28AM -0700, Matthew Brost wrote:
> > On Tue, Aug 17, 2021 at 12:27:29PM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 16, 2021 at 06:51:36AM -0700, Matthew Brost wrote:
> > > > Lock the xarray and take
On Tue, Aug 17, 2021 at 08:26:28AM -0700, Matthew Brost wrote:
> On Tue, Aug 17, 2021 at 12:27:29PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 06:51:36AM -0700, Matthew Brost wrote:
> > > Lock the xarray and take ref to the context if needed.
> > >
> > > v2:
> > > (Checkpatch)
> > >
On Tue, Aug 17, 2021 at 11:47:53AM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:25AM -0700, Matthew Brost wrote:
> > When unblocking a context, do not enable scheduling if the context is
> > banned, guc_id invalid, or not registered.
> >
> > Fixes: 62eaf0ae217d ("drm/i915/guc:
On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:39AM -0700, Matthew Brost wrote:
> > Add GuC kernel doc for all structures added thus far for GuC submission
> > and update the main GuC submission section with the new interface
> > details.
> >
> >
Apologies for the spammy emails, I didn't see Sam's comment on time.
On Tue, Aug 17, 2021 at 6:36 PM Nikola Pavlica
wrote:
> The model and make of the LCD panel of the Vivax TPC-9150 is unknown,
> hence the panel settings that were retrieved with a FEX dump are named
> after the device NOT the
The model and make of the LCD panel of the Vivax TPC-9150 is unknown,
hence the panel settings that were retrieved with a FEX dump are named
after the device NOT the actual panel.
The LCD in question is a 50 pin MISO TFT LCD panel of the resolution
1024x600 used by the aforementioned device.
From: Colin Ian King
The variable delta is not initialized and this will cause unexpected
behaviour with the comparison of tmpdelta < delta. Fix this by setting
it to 0x. This matches the behaviour as in the similar function
mgag200_pixpll_compute_g200se_04.
Addresses-Coverity:
On Tue, Aug 17, 2021 at 12:06:16PM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:31AM -0700, Matthew Brost wrote:
> > Error captures can now be done in a work queue processing G2H messages.
> > These messages need to be completely done being processed in the reset
> > path, to avoid
Daniel Vetter wrote:
> Also I just realized we've totally ignored endianess on these, which is
> not great, because strictly speaking all the drm_fourcc codes should be
> little endian. But I'm also not sure that's worth fixing ...
We discussed framebuffer endianess when introducing the driver,
The model and make of the LCD panel of the Vivax TPC-9150 is unknown,
hence the panel settings that were retrieved with a FEX dump are named
after the device NOT the actual panel.
The LCD in question is a 50 pin MISO TFT LCD panel of the resolution
1024x600 used by the aforementioned device.
17.08.2021 15:22, Mark Brown пишет:
> On Tue, Aug 17, 2021 at 04:27:42AM +0300, Dmitry Osipenko wrote:
>> The SPI on Tegra belongs to the core power domain and we're going to
>> enable GENPD support for the core domain. Now SPI driver must use OPP
>> API for driving the controller's clock rate
On Tue, Aug 17, 2021 at 5:13 PM Matthew Brost wrote:
> On Tue, Aug 17, 2021 at 11:21:27AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 06:51:23AM -0700, Matthew Brost wrote:
> > > Progagating errors to dependent fences is wrong, don't do it. Selftest
> > > in following patch exposes
17.08.2021 10:55, Viresh Kumar пишет:
...
>> +int dev_pm_opp_sync(struct device *dev)
>> +{
>> +struct opp_table *opp_table;
>> +struct dev_pm_opp *opp;
>> +int ret = 0;
>> +
>> +/* Device may not have OPP table */
>> +opp_table = _find_opp_table(dev);
>> +if
Hi Nikola,
see a few comments in the following.
On Tue, Aug 17, 2021 at 10:32:01AM +0200, Nikola Pavlica wrote:
> The model and make of the LCD panel of the Vivax TPC-9150 is unknown,
> hence the panel settings that were retrieved with a FEX dump are named
> after the device NOT the actual
Am 2021-08-17 um 1:50 a.m. schrieb Christoph Hellwig:
> On Mon, Aug 16, 2021 at 03:00:49PM -0400, Felix Kuehling wrote:
>> Am 2021-08-15 um 11:40 a.m. schrieb Christoph Hellwig:
>>> On Fri, Aug 13, 2021 at 01:31:45AM -0500, Alex Sierra wrote:
Add MEMORY_DEVICE_GENERIC case to
On Tue, Aug 17, 2021 at 12:15:21PM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:35AM -0700, Matthew Brost wrote:
> > Rework and simplify the locking with GuC subission. Drop
> > sched_state_no_lock and move all fields under the guc_state.sched_state
> > and protect all these fields
On Tue, Aug 17, 2021 at 12:27:29PM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:36AM -0700, Matthew Brost wrote:
> > Lock the xarray and take ref to the context if needed.
> >
> > v2:
> > (Checkpatch)
> > - Add new line after declaration
> >
> > Signed-off-by: Matthew Brost
>
On 8/17/21 5:24 AM, Borislav Petkov wrote:
> On Tue, Aug 17, 2021 at 12:22:33PM +0200, Borislav Petkov wrote:
>> This one wants to be part of the previous patch.
>
> ... and the three following patches too - the treewide patch does a
> single atomic :) replacement and that's it.
Ok, I'll squash
On 8/17/21 5:02 AM, Borislav Petkov wrote:
> On Fri, Aug 13, 2021 at 11:59:25AM -0500, Tom Lendacky wrote:
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 8e7b517ad738..66ff788b79c9 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++
On 8/15/21 9:39 AM, Borislav Petkov wrote:
> On Sun, Aug 15, 2021 at 08:53:31AM -0500, Tom Lendacky wrote:
>> It's not a cross-vendor thing as opposed to a KVM or other hypervisor
>> thing where the family doesn't have to be reported as AMD or HYGON.
>
> What would be the use case? A HV starts a
On Tue, Aug 17, 2021 at 11:21:27AM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:23AM -0700, Matthew Brost wrote:
> > Progagating errors to dependent fences is wrong, don't do it. Selftest
> > in following patch exposes this bug.
>
> Please explain what "this bug" is, it's hard to
On Tue, Aug 17, 2021 at 11:32:56AM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:22AM -0700, Matthew Brost wrote:
> > If the context is reset as a result of the request cancelation the
> > context reset G2H is received after schedule disable done G2H which is
> > likely the wrong
On 16/8/21 9:59 pm, Daniel Vetter wrote:
On Mon, Aug 16, 2021 at 12:31 PM Desmond Cheong Zhi Xi
wrote:
On 16/8/21 5:04 pm, Daniel Vetter wrote:
On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
wrote:
On 16/8/21 2:47 am, kernel test robot wrote:
Hi Desmond,
Thank you for the patch!
Greetings,
Original proposal:
https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html
Abstract: Add "preferred color format", "active color format", "active
bpc", and "active Broadcast RGB" drm properties,
to control color information send to the monitor.
It seems that the
On 8/17/21 4:00 AM, Borislav Petkov wrote:
> On Fri, Aug 13, 2021 at 11:59:24AM -0500, Tom Lendacky wrote:
>> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
>> index edc67ddf065d..5635ca9a1fbe 100644
>> --- a/arch/x86/mm/mem_encrypt.c
>> +++ b/arch/x86/mm/mem_encrypt.c
>> @@
On Tue, Aug 17, 2021 at 10:32:01AM +0200, Nikola Pavlica wrote:
> The model and make of the LCD panel of the Vivax TPC-9150 is unknown,
> hence the panel settings that were retrieved with a FEX dump are named
> after the device NOT the actual panel.
>
> The LCD in question is a 50 pin MISO TFT
From: Colin Ian King
There is a spelling mistake in a dev_err error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
On Tue, Aug 17, 2021 at 05:01:50AM +0300, Dmitry Osipenko wrote:
> Fix troubles introduced by recent commits.
>
> Dmitry Osipenko (3):
> drm/tegra: dc: Remove unused variables
> drm/tegra: uapi: Fix wrong mapping end address in case of disabled
> IOMMU
> gpu/host1x: fence: Make spinlock
1 - 100 of 174 matches
Mail list logo
