On Fri, Nov 12, 2021 at 02:28:30PM +0530, Jagan Teki wrote:
> On Fri, Nov 12, 2021 at 2:12 PM Michael Tretter wrote:
> > On Thu, 11 Nov 2021 13:21:03 -0800, Tim Harvey wrote:
> > > On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki
> > > wrote:
> > > > On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki
> > > >
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is ready,
then all the iommu consumers always are after the smi driver.
Whe
The platform device is created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
When entering our probe, all the devices should be already created.
if it is null, means NODEV. Currently we don't get the fail case.
It's a
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_init) from []
(of_iommu_xlate+0x7c/0x12c)
[] (of_iommu_xlate) from []
(of_iommu_c
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need this property.
And IOMMU also know which larb this consumer conne
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
When the consumer works, it should
On Tue, Nov 09, 2021 at 05:39:02PM +0300, Dmitry Osipenko wrote:
> 09.11.2021 17:17, Dmitry Osipenko пишет:
> > 09.11.2021 17:08, Dmitry Osipenko пишет:
> >>> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
> >>> +{
> >>> + struct drm_device *drm = dev_get_drvdata(&dev->dev);
> >> And
On Fri, Nov 05, 2021 at 09:59:24AM +0100, Thierry Reding wrote:
> On Fri, Oct 08, 2021 at 10:23:34PM +0200, Thierry Reding wrote:
> > Hi Dave, Daniel,
> >
> > The following changes since commit c3dbfb9c49eef7d07904e5fd5e158dd6688bbab3:
> >
> > gpu: host1x: Plug potential memory leak (2021-09-16
On Fri, 12 Nov 2021, Pekka Paalanen wrote:
> On Fri, 12 Nov 2021 11:09:13 +0100
> Thomas Zimmermann wrote:
>
>> Hi
>>
>> Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
>> > Hello Pekka,
>> >
>> > On 11/12/21 09:56, Pekka Paalanen wrote:
>> >
>> > [snip]
>> >
>> >>
>> >> Hi,
>> >>
>>
On 11/12/21 11:22, Pekka Paalanen wrote:
[snip]
>>>
As this is just returning bool without changing anything, the usual
word to use is "is". Since this function is also used at most once per
driver, which is rarely, it could have a long and descriptive name.
For exampl
On Fri, 12 Nov 2021 11:09:13 +0100
Thomas Zimmermann wrote:
> Hi
>
> Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
> > Hello Pekka,
> >
> > On 11/12/21 09:56, Pekka Paalanen wrote:
> >
> > [snip]
> >
> >>
> >> Hi,
> >>
> >> these ideas make sense to me, so FWIW,
> >>
> >> Acked-by:
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #18 from Lang Yu (lang...@amd.com) ---
Hi all,
I reproduced the issue. Thanks for Erhard F.'s work!
The problem is the pinned BO of last call to
amdgpu_display_crtc_page_flip_target() was not unpinned properly.
int amdgpu_display_
Hi
Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
Hello Pekka,
On 11/12/21 09:56, Pekka Paalanen wrote:
[snip]
Hi,
these ideas make sense to me, so FWIW,
Acked-by: Pekka Paalanen
Thanks.
There is one nitpick I'd like to ask about:
+bool drm_get_modeset(void)
+{
+ return
Hello Pekka,
On 11/12/21 09:56, Pekka Paalanen wrote:
[snip]
>
> Hi,
>
> these ideas make sense to me, so FWIW,
>
> Acked-by: Pekka Paalanen
>
Thanks.
> There is one nitpick I'd like to ask about:
>
> +bool drm_get_modeset(void)
> +{
> + return !drm_nomodeset;
> +}
> +EXPORT_SYMBOL(drm_ge
On Thu, 11 Nov 2021, Matt Roper wrote:
> This workaround is documented a bit strangely in the bspec; it's listed
> as an A0 workaround, but the description clarifies that the workaround
> is implicitly handled by the hardware and what the driver really needs
> to do is program a chicken bit to ree
On Wed, 10 Nov 2021 21:19:53 -0800 Joe Perches wrote:
> On Wed, 2021-11-10 at 17:39 -0800, Jakub Kicinski wrote:
> > On Wed, 10 Nov 2021 12:09:06 -0800 Srivatsa S. Bhat wrote:
> > > DRM DRIVER FOR VMWARE VIRTUAL GPU
> > > -M: "VMware Graphics"
> > > M: Zack Rusin
> > > +R: V
On 11/11/21 10:03 AM, Ajay Garg wrote:
> Hi Jens.
>
> Same issue at my side.
>
> Have posted a patch at
> https://lore.kernel.org/linux-mm/camzfgtup6dkt4owzlhl8whqnnxabfvw5c6aqoghzy3bbm_k...@mail.gmail.com/T/#m2189d135b9293de9b4a11362f0179c17b254d5ab
>
> Will be great to hear back if it fixes th
On 11.11.21 10:20, Javier Martinez Canillas wrote:
> The efifb and simplefb drivers just render to a pre-allocated frame buffer
> and rely on the display hardware being initialized before the kernel boots.
>
> But if another driver already probed correctly and registered a fbdev, the
> generic dri
On 11.11.21 11:00, Daniel Vetter wrote:
> On Thu, Nov 11, 2021 at 10:58:14AM +0100, Thorsten Leemhuis wrote:
>> On 11.11.21 10:20, Javier Martinez Canillas wrote:
>>> The efifb and simplefb drivers just render to a pre-allocated frame buffer
>>> and rely on the display hardware being initialized be
Hi,
I tested Linux mainline kernel 5.15 (aarch64) with enabled VC4 on RPi 4B. I
notice UI freezes a while (about 10 seconds) some times.
The kernel shows the error message during the time:
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [
Hi,
Running -git as of a day or two ago on my laptop, and I've hit this resume
crash a few times:
OOM killer enabled.
Restarting tasks ... done.
thermal thermal_zone7: failed to read out thermal zone (-61)
xfs filesystem being remounted at
/run/systemd/unit-root/var/cache/private/fwupdmgr suppor
Hi Jens.
Same issue at my side.
Have posted a patch at
https://lore.kernel.org/linux-mm/camzfgtup6dkt4owzlhl8whqnnxabfvw5c6aqoghzy3bbm_k...@mail.gmail.com/T/#m2189d135b9293de9b4a11362f0179c17b254d5ab
Will be great to hear back if it fixes things at your side too.
Thanks and Regards,
Ajay
On T
Hi Jernej,
On 10/11/2021 20:20, Jernej Škrabec wrote:
> Hi Neil,
>
> sorry for late response.
>
> Dne petek, 29. oktober 2021 ob 15:59:47 CET je Neil Armstrong napisal(a):
>> The current ELD handling takes the internal connector ELD buffer and
>> shares it to the I2S and AHB sub-driver.
>>
>> Bu
On Fri, Nov 12, 2021 at 2:12 PM Michael Tretter
wrote:
>
> On Thu, 11 Nov 2021 13:21:03 -0800, Tim Harvey wrote:
> > On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki
> > wrote:
> > > On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki
> > > wrote:
> > > > On Wed, Nov 10, 2021 at 2:24 AM Tim Harvey
> > > >
On Mon, 8 Nov 2021 15:17:13 +0100
Thomas Zimmermann wrote:
> Hi
>
> Am 08.11.21 um 15:06 schrieb Javier Martinez Canillas:
> > There is a lot of historical baggage on this parameter. It is defined in
> > the vgacon driver as nomodeset, but its set function is called text_mode()
> > and the value
On Thu, 11 Nov 2021 13:21:03 -0800, Tim Harvey wrote:
> On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki wrote:
> > On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki
> > wrote:
> > > On Wed, Nov 10, 2021 at 2:24 AM Tim Harvey wrote:
> > > > On Tue, Nov 9, 2021 at 12:39 PM Marek Vasut wrote:
> > > > > On 1
On Thu, 11 Nov 2021 21:58:35 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Friday, November 12, 2021 2:41 AM
> > To: Shankar, Uma ; Ville Syrjälä
> >
> > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > ppaala...@gmail.com
101 - 127 of 127 matches
Mail list logo
