We have merged such DRM definition dependencies previously through a topic
branch in order to avoid redefining inside the driver.
But yes guarding this with ifdef is good.
Reviewed-by: Manasi Navare
Manasi
-Original Message-
From: Zuo, Jerry
Sent: Tuesday, September 28, 2021 11:11
Lack of documentation inside Linux here is a bit annoying, but do I
understand it correctly, that the main (and probably only) difference
is that kvcalloc checks whether the multiplication overflows and
returns NULL in this case?
On Wed, Sep 29, 2021 at 12:21 AM Gustavo A. R. Silva
wrote:
>
>
On Wed, Sep 29, 2021 at 5:36 AM Brian Norris wrote:
>
> Since commit 43c2de1002d2, we perform most HW configuration in the
> bind() function. This configuration may be lost on suspend/resume, so we
> need to call it again. That may lead to errors like this after system
> suspend/resume:
>
>
On Wed, Sep 29, 2021 at 5:36 AM Brian Norris wrote:
>
> In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should
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.
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 []
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 the property.
And IOMMU also know which larb this consumer
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
On Tue, Sep 28, 2021 at 04:33:24PM -0700, John Harrison wrote:
> On 9/28/2021 15:33, Matthew Brost wrote:
> > On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
> > > On 8/20/2021 15:44, Matthew Brost wrote:
> > > > For some users of multi-lrc, e.g. split frame, it isn't safe to
Hi, Nancy:
Nancy.Lin 於 2021年9月6日 週一 下午3:15寫道：
>
> MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
> The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
> only one drm driver register as the drm device.
> Each drm driver binds its own component. The first bind drm
On 9/28/2021 15:33, Matthew Brost wrote:
On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
On 8/20/2021 15:44, Matthew Brost wrote:
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between
https://bugzilla.kernel.org/show_bug.cgi?id=211875
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Sep 28, 2021 at 03:20:42PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
> > mid BB. To safely enable preemption at the BB boundary, a handshake
> > between to parent and child is needed.
If drm_modeset_lock() returns -EDEADLK, the caller is supposed to drop
all currently held locks using drm_modeset_backoff(). Failing to do so
will result in warnings and backtraces on the paths trying to lock a
contended lock. Add support for optionally printing the backtrace on the
path that hit
Another round of removing redundant minItems/maxItems from new schema in
the recent merge window.
If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
same size as the list is redundant and can be dropped. Note that is DT
schema specific behavior and not standard
Use 2-factor argument form kvcalloc() instead of kvzalloc().
Link: https://github.com/KSPP/linux/issues/162
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
On 8/20/2021 15:44, Matthew Brost wrote:
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb
On Tue, Sep 28, 2021 at 02:01:57PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> Yes. But, since the check is related to TDX, I just want to confirm whether
> you are fine with naming the function as intel_*().
Why is this such a big of a deal?!
There's amd_cc_platform_has() and
Fix some error handling here noticed in review of other changes.
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
driver")
Signed-off-by: Brian Norris
Reported-by: Chen-Yu Tsai
Reviewed-by: Chen-Yu Tsai
---
Changes in v3:
- Add Fixes, Reviewed-by
Changes in v2:
-
Our probe() function never enabled this clock, so we shouldn't disable
it if we fail to probe the bridge.
Noted by inspection.
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
driver")
Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
---
(no changes since v1)
In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
didn't move the runtime PM management. Therefore, depending on initial
boot state, runtime-PM workqueue delays, and other timing factors, we
may disable our power domain in between the hardware configuration
(bind()) and when
Since commit 43c2de1002d2, we perform most HW configuration in the
bind() function. This configuration may be lost on suspend/resume, so we
need to call it again. That may lead to errors like this after system
suspend/resume:
dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
The Rockchip DSI driver has had a number of bugs over time and has
usually only worked by chance. A number of users have noticed that
things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all
lane config except LCDC mux to bind()"), although it was fixing several
real issues of its
On 2021-09-28 11:02, Sean Paul wrote:
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org
wrote:
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> helpers.
>
> Cc: Stephen Boyd
> Signed-off-by:
Hi Sean
On 2021-09-28 10:33, Sean Paul wrote:
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org
wrote:
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> This patch expands upon the HDCP helper library to manage HDCP
> enable, disable, and check.
>
> Previous to this
On 2021-09-28 11:06, Sean Paul wrote:
On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org
wrote:
Hi Sean
On 2021-09-15 13:38, Sean Paul wrote:
> From: Sean Paul
>
> Hello again,
> This is the second version of the HDCP helper patchset. See version 1
> here:
On Tue, Sep 28, 2021 at 8:36 PM Jason Gunthorpe wrote:
>
> On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> > From: Tomer Tayar
> >
> > Implement the calls to the dma-buf kernel api to create a dma-buf
> > object backed by FD.
> >
> > We block the option to mmap the DMA-BUF object
On Mon, Sep 27, 2021 at 9:16 PM Chen-Yu Tsai wrote:
>
> On Tue, Sep 28, 2021 at 2:00 AM Brian Norris wrote:
> >
> > Fix some error handling here noticed in review of other changes.
> >
> > Reported-by: Chen-Yu Tsai
> > Signed-off-by: Brian Norris
>
> Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi:
On Tue, 2021-09-28 at 13:00 -0700, Doug Anderson wrote:
> Hi,
>
>
> I'm not sure I understand the comment above. You say "enabled/disabled
> via PWM" and that doesn't make sense w/ my mental model. Normally I
> think of a PWM allowing you to adjust the brightness and there being a
> separate
On 9/28/21 1:58 PM, Borislav Petkov wrote:
On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote:
Just read it. If you want to use cpuid_has_tdx_guest() directly in
cc_platform_has(), then you want to rename intel_cc_platform_has() to
tdx_cc_platform_has()?
Why?
You
On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> Just read it. If you want to use cpuid_has_tdx_guest() directly in
> cc_platform_has(), then you want to rename intel_cc_platform_has() to
> tdx_cc_platform_has()?
Why?
You simply do:
if
Hi,
Sorry, I missed this email.
W dniu 23.09.2021 o 00:32, Laurent Pinchart pisze:
> Hi Andrzej,
>
> On Wed, Sep 22, 2021 at 04:29:39AM +0300, Laurent Pinchart wrote:
>> On Tue, Sep 21, 2021 at 09:42:11PM +0200, Andrzej Hajda wrote:
>>> W dniu 23.06.2021 o 15:56, Laurent Pinchart pisze:
On 9/28/21 1:31 PM, Borislav Petkov wrote:
On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote:
Intel CC support patch is not included in this series. You want me
to address the issue raised by Joerg before merging it?
Did you not see my email to you today:
On 8/20/2021 15:44, Matthew Brost wrote:
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 180 ++
Thanks for the patch. Looks good.
Acked-by: Anitha Chrisanthus
> -Original Message-
> From: Nathan Chancellor
> Sent: Tuesday, September 28, 2021 12:24 PM
> To: Chrisanthus, Anitha ; Dea, Edmund J
>
> Cc: Geert Uytterhoeven ; Nick Desaulniers
> ; dri-devel@lists.freedesktop.org; linux-
Quoting Kuogee Hsieh (2021-09-28 09:11:12)
> Only signal audio when disconnected detected at dp_pm_resume since
> connected status will be signaled to audio at next plugin handler.
Please add more details. This says what the patch does but it would be
better if it included why it is important.
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from
On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> Intel CC support patch is not included in this series. You want me
> to address the issue raised by Joerg before merging it?
Did you not see my email to you today:
https://lkml.kernel.org/r/yvl4zughfsh1q...@zn.tnic
?
Hi,
On Mon, Sep 27, 2021 at 1:12 PM Lyude Paul wrote:
>
> @@ -3305,11 +3313,10 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
> * @bl: Backlight capability info from drm_edp_backlight_init()
> *
> * This function handles disabling DPCD backlight controls on a panel over
> AUX. Note that some
clang with W=1 warns:
drivers/gpu/drm/kmb/kmb_dsi.c:812:2: error: unused function
'set_test_mode_src_osc_freq_target_low_bits' [-Werror,-Wunused-function]
set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi *kmb_dsi,
^
drivers/gpu/drm/kmb/kmb_dsi.c:824:2: error: unused
On 9/28/21 12:10 PM, Borislav Petkov wrote:
From: Borislav Petkov
Hi all,
here's v4 of the cc_platform_has() patchset with feedback incorporated.
I'm going to route this through tip if there are no objections.
Intel CC support patch is not included in this series. You want me
to address
On Tue, Sep 28, 2021 at 8:13 PM Jason Gunthorpe wrote:
>
> On Sun, Sep 12, 2021 at 07:53:08PM +0300, Oded Gabbay wrote:
> > /* HL_MEM_OP_* */
> > __u32 op;
> > - /* HL_MEM_* flags */
> > + /* HL_MEM_* flags.
> > + * For the HL_MEM_OP_EXPORT_DMABUF_FD opcode, this field
From: Tom Lendacky
Replace uses of sev_es_active() with the more generic cc_platform_has()
using CC_ATTR_GUEST_STATE_ENCRYPT. If future support is added for other
memory encyrption techonologies, the use of CC_ATTR_GUEST_STATE_ENCRYPT
can be updated, as required.
Signed-off-by: Tom Lendacky
From: Tom Lendacky
Replace uses of sev_active() with the more generic cc_platform_has()
using CC_ATTR_GUEST_MEM_ENCRYPT. If future support is added for other
memory encryption technologies, the use of CC_ATTR_GUEST_MEM_ENCRYPT
can be updated, as required.
Signed-off-by: Tom Lendacky
From: Tom Lendacky
Replace uses of sme_active() with the more generic cc_platform_has()
using CC_ATTR_HOST_MEM_ENCRYPT. If future support is added for other
memory encryption technologies, the use of CC_ATTR_HOST_MEM_ENCRYPT
can be updated, as required.
This also replaces two usages of
From: Tom Lendacky
Replace uses of mem_encrypt_active() with calls to cc_platform_has() with
the CC_ATTR_MEM_ENCRYPT attribute.
Remove the implementation of mem_encrypt_active() across all arches.
For s390, since the default implementation of the cc_platform_has()
matches the s390
From: Tom Lendacky
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
attribute.
Signed-off-by: Tom Lendacky
Signed-off-by:
From: Tom Lendacky
Introduce an x86 version of the cc_platform_has() function. This will be
used to replace vendor specific calls like sme_active(), sev_active(),
etc.
Signed-off-by: Tom Lendacky
Signed-off-by: Borislav Petkov
---
arch/x86/Kconfig | 1 +
From: Tom Lendacky
In preparation for other uses of the cc_platform_has() function
besides AMD's memory encryption support, selectively build the
AMD memory encryption architecture override functions only when
CONFIG_AMD_MEM_ENCRYPT=y. These functions are:
- early_memremap_pgprot_adjust()
-
From: Borislav Petkov
Hi all,
here's v4 of the cc_platform_has() patchset with feedback incorporated.
I'm going to route this through tip if there are no objections.
Thx.
Tom Lendacky (8):
x86/ioremap: Selectively build arch override encryption functions
arch/cc: Introduce a function to
From: Tom Lendacky
In preparation for other confidential computing technologies, introduce
a generic helper function, cc_platform_has(), that can be used to
check for specific active confidential computing attributes, like
memory encryption. This is intended to eliminate having to add multiple
On 9/28/21 11:13 AM, Maxime Ripard wrote:
If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in
and drivers using that function will fail to build.
Add an inline stub so that we can still build-test those cases.
Reported-by: Randy Dunlap
Signed-off-by: Maxime Ripard
If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in
and drivers using that function will fail to build.
Add an inline stub so that we can still build-test those cases.
Reported-by: Randy Dunlap
Signed-off-by: Maxime Ripard
---
include/drm/drm_bridge.h | 13 -
1
On Tue, Sep 21, 2021 at 07:30:29PM -0700, abhin...@codeaurora.org wrote:
> Hi Sean
>
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > Hello again,
> > This is the second version of the HDCP helper patchset. See version 1
> > here:
On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> > helpers.
> >
> > Cc: Stephen Boyd
> > Signed-off-by: Sean Paul
> > Link:
>
[AMD Official Use Only]
> -Original Message-
> From: Harry Wentland
> Sent: September 28, 2021 1:08 PM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org; Zuo, Jerry
> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
> nat...@kernel.org; intel-...@lists.freedesktop.org; dri-
>
On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> From: Tomer Tayar
>
> Implement the calls to the dma-buf kernel api to create a dma-buf
> object backed by FD.
>
> We block the option to mmap the DMA-BUF object because we don't support
> DIRECT_IO and implicit P2P.
This
On Tue, Sep 21, 2021 at 04:34:59PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-15 13:38, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch expands upon the HDCP helper library to manage HDCP
> > enable, disable, and check.
> >
> > Previous to this patch, the majority of the state
On 2021-08-27 10:14, Bjorn Andersson wrote:
On Fri 27 Aug 00:20 CDT 2021, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-08-25 16:42:31)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
> index 2c7de43f655a..4a6132c18e57 100644
> ---
On Sun, Sep 12, 2021 at 07:53:08PM +0300, Oded Gabbay wrote:
> /* HL_MEM_OP_* */
> __u32 op;
> - /* HL_MEM_* flags */
> + /* HL_MEM_* flags.
> + * For the HL_MEM_OP_EXPORT_DMABUF_FD opcode, this field holds the
> + * DMA-BUF file/FD flags.
> + */
> __u32
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from
On Sat 25 Sep 16:25 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Fri, Sep 24, 2021 at 05:04:41PM -0500, Bjorn Andersson wrote:
> > On Fri 24 Sep 02:54 CDT 2021, Uwe Kleine-K?nig wrote:
> > > > +static int ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
> > > > +
On 28/09/2021 19:28, Rob Clark wrote:
From: Rob Clark
These aren't used. And if we add use for them later, we should probably
do something a bit more structured than string parsing.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
W dniu 23.09.2021 o 02:29, Laurent Pinchart pisze:
> Hi Maxime,
>
> Thank you for the patch.
>
> I know this has already been merged, but I have a question.
>
> On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
>> Display drivers so far need to have a lot of boilerplate to first
>>
From: Rob Clark
These aren't used. And if we add use for them later, we should probably
do something a bit more structured than string parsing.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 8
Only signal audio when disconnected detected at dp_pm_resume since
connected status will be signaled to audio at next plugin handler.
Fixes: 078867ce04ed ("drm/msm/dp: signal audio plugged change at dp_pm_resume")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10
On 9/28/21 12:23 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20210927:
on x86_64:
ERROR: modpost: "devm_drm_of_get_bridge" [drivers/gpu/drm/vc4/vc4.ko] undefined!
Full randconfig file is attached.
--
~Randy
config-r5051.gz
Description: application/gzip
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
>
> On 9/27/2021 8:59 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > I've seen a few crashes like:
> >
> > Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
> > Modules linked in: snd_seq_dummy snd_seq
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 299007
--> https://bugzilla.kernel.org/attachment.cgi?id=299007=edit
final bisect.log
--
You may reply to this email to add a comment.
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
CC|
On 2021-09-27 15:23, Fangzhi Zuo wrote:
> Include FEC, DSC, Link Training related headers.
>
> Change since v2
> - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT
>
> Signed-off-by: Fangzhi Zuo
Reviewed-by: Harry Wentland
Harry
> ---
> This patch is based on top of the other
On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> Yes. I was thinking of the possibility of putting off some work later so
> that we don't need to make a lot of changes. GVT-g needs to take a
> snapshot of GPU registers as the initial virtual states for other vGPUs,
> which
On 9/28/21 2:00 PM, Luis Chamberlain wrote:
> On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
>> Hey guys:
>>
>> After some investigation, I found the root cause this problem ("i915"
>> module loading will be stuck with Christoph's refactor patches), which
>> can be reproduced by
From: Arnd Bergmann
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m
are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency
does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This
can however result in a build failure when cfb_fillrect()
On 9/27/2021 8:59 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun
nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
Hi Nikolaus & Paul,
Le lun., sept. 27 2021 at 18:44:24 +0200, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780
HDMI support. This requires a new driver, plus device tree and
configuration
modifications.
On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
> Hey guys:
>
> After some investigation, I found the root cause this problem ("i915"
> module loading will be stuck with Christoph's refactor patches), which
> can be reproduced by building both i915 and kvmgt as kernel module and
>
Hi Neil,
> Am 28.09.2021 um 15:02 schrieb Neil Armstrong :
>
> On 27/09/2021 18:44, H. Nikolaus Schaller wrote:
>> From: Paul Boddie
>>
>> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
>> HDMI support. This requires a new driver, plus device tree and
On 9/28/21 2:50 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:
aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4):
From: Vladimir Lypak
MDP version v1.16 is almost identical to v1.15 with most significant
difference being presence of second DSI interface. MDP v1.16 is found on
SoCs such as MSM8x53, SDM450, SDM632 (All with Adreno 506).
Signed-off-by: Vladimir Lypak
Signed-off-by: Sireesh Kodali
---
From: Vladimir Lypak
Add phy configuration for 14nm dsi phy found on MSM8953 SoC. Only
difference from existing configurations are io_start addresses.
Signed-off-by: Vladimir Lypak
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sireesh Kodali
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |
SoCs based on the MSM8953 platform use the 14nm DSI PHY driver
Signed-off-by: Sireesh Kodali
---
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
This patch series adds support for the MDP and DSI PHY as found on the
MSM8953 platform (APQ8053, SDM450, SDA450, SDM625, SDM626). All the SoCs
on this platform use the adreno 506 GPU.
Changes since v2:
- Changed dt-bindings to use enum instead of oneOf
Changes since v1:
- Split the dsi phy doc
https://bugzilla.kernel.org/show_bug.cgi?id=212425
Grzegorz Kowal (custos.men...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 27/09/2021 18:44, H. Nikolaus Schaller wrote:
> From: Paul Boddie
>
> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
> HDMI support. This requires a new driver, plus device tree and configuration
> modifications.
>
> Signed-off-by: Paul Boddie
> Signed-off-by:
On 9/28/21 2:16 PM, Guido Günther wrote:
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm:
Hi,
On Tue, Sep 28, 2021 at 11:27:49AM +0200, Lucas Stach wrote:
> Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
> > Hi,
> > On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> > > On 9/28/21 10:55 AM, Guido Günther wrote:
> > > > If a bridge doesn't do any bus
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8
1 file changed, 8 insertions(+)
diff --git
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
1 file changed, 9 insertions(+)
diff --git
1 - 100 of 162 matches
Mail list logo
