On Tue, Dec 13, 2022 at 9:11 PM Marek Szyprowski
wrote:
>
> On 13.12.2022 16:15, Jagan Teki wrote:
> > On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
> > wrote:
> >> On 13.12.2022 15:18, Jagan Teki wrote:
> >>> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
> >>> wrote:
> On 13.12.2022
On Mon, Dec 12, 2022 at 06:17:01PM +, Matthew Auld wrote:
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Properly build the sg table for persistent mapping which can
be partial map of the underlying object. Ensure the sg pages
are properly set for page backed regions. The dump capture
Hi all,
Friendly ping on this patch.
Regards,
Pin-yen
On Wed, Nov 9, 2022 at 5:52 PM Pin-yen Lin wrote:
>
> Add a pair of pm_runtime_get_if_in_use and pm_runtime_put_sync in the
> interrupt handler to make sure the bridge won't be powered off during
> the interrupt handlings. Also remove the ir
Friendly ping.
Pin-yen
Pin-yen
On Mon, Nov 21, 2022 at 1:39 PM Pin-yen Lin wrote:
>
> Hi all,
> Friendly ping on this patch.
>
> Regards,
> Pin-yen
>
> On Thu, Nov 3, 2022 at 5:13 PM allen wrote:
> >
> > From: allen chen
> >
> > Add driver to read data-lanes and link-frequencies from dt prop
https://bugzilla.kernel.org/show_bug.cgi?id=216805
--- Comment #2 from kolAflash (kolafl...@kolahilft.de) ---
Finished the git bisect and created a new bug report here:
https://gitlab.freedesktop.org/drm/amd/-/issues/2297
--
You may reply to this email to add a comment.
You are receiving this m
Add the check for the return value of dma_alloc_coherent in order to
avoid NULL pointer dereference.
This flaw was found using an experimental static analysis tool we are
developing, APP-Miner, which has not been disclosed.
The allyesconfig build using GCC 9.3.0 shows no new warning. As we
don't
The function engine_init_common() has changed to static and we don't need
doc comment in the static function. No functional modification involved.
drivers/gpu/drm/i915/gt/intel_engine_cs.c:1306: warning: expecting prototype
for intel_engines_init_common(). Prototype was for engine_init_common() i
On Tue, 13 Dec 2022 11:57:07 +0800 Jiapeng Chong wrote:
> These functions are defined in the ksz884x.c file, but not called
> elsewhere, so delete these unused functions.
>
> drivers/net/ethernet/micrel/ksz884x.c:2212:20: warning: unused function
> 'port_cfg_force_flow_ctrl'.
>
> Link: https://b
https://bugzilla.kernel.org/show_bug.cgi?id=216805
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
On 14.12.2022 00:22, Marijn Suijten wrote:
> According to downstream /and the comment copied from it/ this comparison
> should be the other way around. In other words, when the panel driver
> requests to use more slices per packet than what could be sent over this
> interface, it is bumped down
Programming of the ENABLE_PREFETCH_INTO_IC bit originally showed up in
both the general DG2 tuning guide (applicable to all DG2
variants/steppings) and under Wa_22012654132 (applicable only to
specific steppings). It has now been removed from the tuning guide, and
the guidance is to only program i
On 13 December 2022 23:44:04 EET, Kuogee Hsieh wrote:
>Move data-lanes property from mdss_dp node to dp_out endpoint. Also
>add link-frequencies property into dp_out endpoint as well. The last
>frequency specified at link-frequencies will be the max link rate
>supported by DP.
>
>Changes in v5:
In the event that the topology requests resources that have not been
created by the system (because they are typically not represented in
dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC
blocks) remain NULL but will still be returned out of
dpu_rm_get_assigned_resources, where th
According to downstream /and the comment copied from it/ this comparison
should be the other way around. In other words, when the panel driver
requests to use more slices per packet than what could be sent over this
interface, it is bumped down to only use a single slice per packet (and
strangely
These blocks on CTL V1 support setting a PINGPONG idx to send pixel
output to.
Signed-off-by: Marijn Suijten
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 23 ++-
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
This preliminary Display Stream Compression support package for
(initially tested on) sm8[12]50 is based on comparing DSC behaviour
between downstream and mainline. Some new callbacks are added (for
binding blocks on active CTLs), logic bugs are corrected, zeroed struct
members are now assigned pr
All V1 CTL blocks (active CTLs) explicitly bind the pixel output from a
DSC block to a PINGPONG block by setting the PINGPONG idx in a DSC
hardware register.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|
According to downstream the value to use for WORD_COUNT is
bytes_per_pkt, which denotes the number of bytes in a packet based on
how many slices have been configured by the panel driver times the
width of a slice times the number of bytes per pixel.
The DSC panels seen thus far use one byte per pi
Active CTLs have to configure what DSC block(s) have to be enabled, and
what DSC block(s) have to be flushed; this value was initialized to zero
resulting in the necessary register writes to never happen (or would
write zero otherwise). This seems to have gotten lost in the DSC v4->v5
series while
Quoting Kuogee Hsieh (2022-12-13 13:44:07)
> Add capability to parser and retrieve max DP link supported rate from
to parse
> link-frequencies property of dp_out endpoint.
>
> Changes in v6:
> -- second patch after split parser patch into two patches
>
> Changes in v7:
> -- without checking cnt a
On 11/14/2022 5:49 PM, Yang Li wrote:
Make the description of @init to @p in dpu_encoder_phys_wb_init()
and remove @wb_roi in dpu_encoder_phys_wb_setup_fb() to clear the below
warnings:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:139: warning: Excess
function parameter 'wb_roi' descr
Quoting Kuogee Hsieh (2022-12-13 13:44:06)
> Add capability to parser data-lanes as property of dp_out endpoint.
> Also retain the original capability to parser data-lanes as property
> of mdss_dp node to handle legacy case.
>
> Changes in v6:
> -- first patch after split parser patch into two
>
>
Quoting Kuogee Hsieh (2022-12-13 13:44:05)
> Add both data-lanes and link-frequencies property into endpoint
Why do we care? Please tell us why it's important.
>
> Changes in v7:
> -- split yaml out of dtsi patch
> -- link-frequencies from link rate to symbol rate
> -- deprecation of old data-lan
By default, HBR2 (5.4G) is the max link link be supported. This patch uses the
actual limit specified by DT and removes the artificial limitation to 5.4 Gbps.
Supporting HBR3 is a consequence of that.
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Changes in v9:
--
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add &dp_out
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item t
Add DP both data-lanes and link-frequencies property to dp_out endpoint and
support
functions to DP driver.
Kuogee Hsieh (5):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
dt-bindings: msm/dp: add data-lanes and link-frequencies property
drm/msm/dp: parser da
On 12/13/2022 2:11 PM, Dmitry Baryshkov wrote:
On 13 December 2022 23:53:48 EET, Abhinav Kumar
wrote:
On 12/1/2022 11:54 AM, Dmitry Baryshkov wrote:
On 30/11/2022 22:09, Adam Skladowski wrote:
Follow other YAMLs and replace mdss name into display-subystem.
Signed-off-by: Adam Skladow
On 13 December 2022 23:53:48 EET, Abhinav Kumar
wrote:
>
>
>On 12/1/2022 11:54 AM, Dmitry Baryshkov wrote:
>> On 30/11/2022 22:09, Adam Skladowski wrote:
>>> Follow other YAMLs and replace mdss name into display-subystem.
>>>
>>> Signed-off-by: Adam Skladowski
>>
>> Reviewed-by: Dmitry Bary
On 13 December 2022 23:44:07 EET, Kuogee Hsieh wrote:
>Add capability to parser and retrieve max DP link supported rate from
>link-frequencies property of dp_out endpoint.
>
>Changes in v6:
>-- second patch after split parser patch into two patches
>
>Changes in v7:
>-- without checking cnt aga
On 13 December 2022 23:44:08 EET, Kuogee Hsieh wrote:
>By default, HBR2 (5.4G) is the max link link be supported. This patch uses the
>actual limit specified by DT and removes the artificial limitation to 5.4 Gbps.
>Supporting HBR3 is a consequence of that.
>
>Changes in v2:
>-- add max link ra
On 13 December 2022 23:44:05 EET, Kuogee Hsieh wrote:
>Add both data-lanes and link-frequencies property into endpoint
>
>Changes in v7:
>-- split yaml out of dtsi patch
>-- link-frequencies from link rate to symbol rate
>-- deprecation of old data-lanes property
>
>Changes in v8:
>-- correct B
Hi all,
Today's linux-next merge of the drm-misc-fixes tree got a conflict in:
drivers/dma-buf/dma-buf.c
between commit:
28743e25fa1c ("dma-buf: Remove obsoleted internal lock")
from Linus' tree and commit:
f728a5ea27c9 ("dma-buf: fix dma_buf_export init order v2")
from the drm-misc-fi
On 12/1/2022 11:54 AM, Dmitry Baryshkov wrote:
On 30/11/2022 22:09, Adam Skladowski wrote:
Follow other YAMLs and replace mdss name into display-subystem.
Signed-off-by: Adam Skladowski
Reviewed-by: Dmitry Baryshkov
Going to add two fixes tags here as we are touching two chipsets:
Fix
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Changes in v9:
--
By default, HBR2 (5.4G) is the max link link be supported. This patch uses the
actual limit specified by DT and removes the artificial limitation to 5.4 Gbps.
Supporting HBR3 is a consequence of that.
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add &dp_out
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item t
Add DP both data-lanes and link-frequencies property to dp_out endpoint and
support
functions to DP driver.
Kuogee Hsieh (5):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
dt-bindings: msm/dp: add data-lanes and link-frequencies property
drm/msm/dp: parser da
On 11/18/2022 9:55 PM, Hui Tang wrote:
Because of the possilble failure of devm_kzalloc(), dpu_wb_conn might
be NULL and will cause null pointer derefrence later.
derefrence --> dereference
Therefore, it might be better to check it and directly return -ENOMEM.
Fixes: 77b001acdcfe ("drm/msm
On 12/6/2022 12:02 AM, Jiasheng Jiang wrote:
As kzalloc may fail and return NULL pointer,
it should be better to check pstates
in order to avoid the NULL pointer dereference.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Jiasheng Jiang
Once again, your lines are wr
https://bugzilla.kernel.org/show_bug.cgi?id=216805
kolAflash (kolafl...@kolahilft.de) changed:
What|Removed |Added
Hardware|All |AMD
--
You may repl
https://bugzilla.kernel.org/show_bug.cgi?id=216806
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=216806
Bug ID: 216806
Summary: [Raven Ridge] console disappears after framebuffer
device loads
Product: Drivers
Version: 2.5
Kernel Version: 6.0.8
Hardware: AMD
The pull request you sent on Tue, 13 Dec 2022 12:56:25 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-12-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a594533df0f6ca391da003f43d53b336a2d23ffa
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Mon, Dec 12, 2022 at 6:56 PM Dave Airlie wrote:
>
> There are a bunch of conflicts, one in amdgpu is a bit nasty, I've
> cc'ed Christian/Alex to make sure they know to check whatever
> resolution you find. The one I have is what we have in drm-tip tree.
Hmm. My merge resolution is slightly dif
Drivers only emulate XRGB framebuffers. Remove all conversion
helpers that do not use XRGB as their source format. Also remove
some special cases for alpha formats in the blit helper.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 75 --
Add dedicated helper to convert from XRGB to ARGB. Sets
all alpha bits to make pixels fully opaque.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 53 +++-
.../gpu/drm/tests/drm_format_helper_test.c| 63 +++
include/dr
Fix the color-format selection of the single-probe helper. Go
through all user-specified values and test each for compatibility
with the driver. If none is supported, use the driver-provided
default. This guarantees that the console is always available in
any color format at least.
Until now, the
The DRM helper drm_fb_build_fourcc_list() creates a list of color
formats for primary planes of the generic drivers. Simplify the helper:
- It used to mix and filter native and emulated formats as provided
by the driver. Now the only emulated format is XRGB, which is
required as fallbac
Split the single-probe helper's implementation into multiple
functions and get locking and overallocation out of the way of
the surface setup. Simplifies later changes to the setup code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 116
Add conversion from XRGB to XRGB1555, ARGB1555 and RGBA5551, which
are the formats currently supported by the simplefb infrastructure. The
new helpers allow the output of XRGB framebuffers to firmware
scanout buffers in one of the 15-bit formats.
Signed-off-by: Thomas Zimmermann
---
driv
Upcoming changes to the format conversion will mostly blit from
XRGB to some other format. So put the source format in blit's
outer branches to make the code more readable. For cases where
a format only changes its endianness, such as XRGB565, introduce
dedicated branches that handle this for a
Fix the selection of the fbdev emulation's color format and make
XRGB the only emulated color format. Resolves the blank screen
in cases where video= specifies an unsupported color format. Also
resolves the issues around current format-conversion helpers.
DRM drivers usually pick a default for
Add dedicated helper to convert from XRGB to ARGB2101010. Sets
all alpha bits to make pixels fully opaque.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 58 -
.../gpu/drm/tests/drm_format_helper_test.c| 63 +++
includ
Select color format for EFI/VESA firmware scanout buffer from the
number of bits per pixel and the position of the individual color
components. Fixes the selected format for the buffer in several odd
cases. For example, XRGB1555 has been reported as ARGB1555 because
of the different use of depth an
On 13/12/2022 18:31, Abhinav Kumar wrote:
>
>
> On 12/13/2022 5:13 AM, Krzysztof Kozlowski wrote:
>> On 13/12/2022 00:41, Abhinav Kumar wrote:
>
> besides, i think i have to sent the whole series patches include this
> one to address your new comments on other patch.
>
> is th
Am 13.12.22 um 18:09 schrieb Daniel Vetter:
On Sat, Dec 10, 2022 at 08:43:47AM +0530, Sumit Semwal wrote:
Hi Christian,
On Fri, 9 Dec 2022 at 12:45, Christian König
wrote:
The init order and resulting error handling in dma_buf_export
was pretty messy.
Subordinate objects like the file and th
On 12/13/2022 5:13 AM, Krzysztof Kozlowski wrote:
On 13/12/2022 00:41, Abhinav Kumar wrote:
besides, i think i have to sent the whole series patches include this
one to address your new comments on other patch.
is this correct?
No. Please fix your system first, validate your patches and s
On 12/12/22 19:21, Harry Wentland wrote:
> This will let us pass kms_hdr.bpc_switch.
>
> I don't see any good reasons why we still need to
> limit bpc to 8 bpc and doing so is problematic when
> we enable HDR.
>
> If I remember correctly there might have been some
> displays out there where the a
We have more handhelds in the One XPLAYER lineup now that needs support added
to the orientation-quirks.
By adding more native resolution checks and the one unique BIOS variant
available we add support to most devices.
Signed-off-by: Matthew Anderson
---
.../gpu/drm/drm_panel_orientation_quirk
On Sat, Dec 10, 2022 at 08:43:47AM +0530, Sumit Semwal wrote:
> Hi Christian,
>
> On Fri, 9 Dec 2022 at 12:45, Christian König
> wrote:
> >
> > The init order and resulting error handling in dma_buf_export
> > was pretty messy.
> >
> > Subordinate objects like the file and the sysfs kernel object
On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
The KernelCI bisection bot found regressions in at least two KMS tests
in the Renesas tree on rk3399-gru-kevin just after the Renesas tree
merged up mainline:
igt-kms-rockchip.kms_vblank.pipe-A-wait-forked
igt-kms-rockchip.kms_v
On Tue, 13 Dec 2022 at 20:33, Robert Foss wrote:
>
> This fixes PLL being unable to lock, and is derived from an equivalent
> downstream commit.
>
> Available LT9611 documentation does not list this register, neither does
> LT9611UXC (which is a different chip).
>
> This commit has been confirmed
On 12/13/22 05:39, Pekka Paalanen wrote:
> On Mon, 12 Dec 2022 13:21:25 -0500
> Harry Wentland wrote:
>
>> This allows us to use strongly typed arguments.
>>
>> Signed-off-by: Harry Wentland
>> Cc: Pekka Paalanen
>> Cc: Sebastian Wick
>> Cc: vitaly.pros...@amd.com
>> Cc: Uma Shankar
>> Cc:
On 12/13/22 05:34, Pekka Paalanen wrote:
> Sorry, hand slipped on keyboard and sent out a draft of this email too
> early.
>
>
> On Mon, 12 Dec 2022 13:21:27 -0500
> Harry Wentland wrote:
>
>> Drivers might not support all colorspaces defined in
>> dp_colorspaces and hdmi_colorspaces. This r
On Tue, Dec 13, 2022 at 02:23:32PM +, Jiaxin Yu (俞家鑫) wrote:
> On Mon, 2022-12-05 at 12:07 +, Mark Brown wrote:
> > On Mon, Dec 05, 2022 at 09:34:17AM +, Jiaxin Yu (俞家鑫) wrote:
> > No, I mean that if you want to control the enable and disable of the
> > output path you should implement
On 12/13/22 05:23, Pekka Paalanen wrote:
> On Mon, 12 Dec 2022 13:21:27 -0500
> Harry Wentland wrote:
>
>> Drivers might not support all colorspaces defined in
>> dp_colorspaces and hdmi_colorspaces. This results in
>> undefined behavior when userspace is setting an
>> unsupported colorspace.
On Tue, Dec 13, 2022 at 07:10:14AM -0800, Bjorn Andersson wrote:
> On Fri, Dec 09, 2022 at 11:35:23AM +0100, Johan Hovold wrote:
> > > + edp_reg_en: edp-reg-en-state {
> > > + pins = "gpio25";
> > > + function = "gpio";
> > > + output-enable;
> >
> > 'output-enable' is no
On Tue, 15 Nov 2022 at 12:27, Pin-yen Lin wrote:
>
> Add caching when EDID is read, and invalidate the cache until the
> bridge detects HPD low or sink count changes on HPD_IRQ.
>
> It takes 1.2s for IT6505 bridge to read a 3-block EDID, and skipping
> one EDID read would be a notable difference o
On 13.12.2022 16:15, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
> wrote:
>> On 13.12.2022 15:18, Jagan Teki wrote:
>>> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
>>> wrote:
On 13.12.2022 13:20, Marek Szyprowski wrote:
> On 13.12.2022 11:40, Jagan Teki wrot
On 13.12.2022 16:23, Doug Anderson wrote:
> Hi,
>
> On Mon, Dec 12, 2022 at 4:24 PM Konrad Dybcio
> wrote:
>>
>> Add support for matching QFPROM fuse values to get the correct speed bin
>> on A650 (SM8250) GPUs.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> drivers/gpu/drm/msm/adreno/a6xx_gp
Hi,
On Mon, Dec 12, 2022 at 4:24 PM Konrad Dybcio wrote:
>
> Add support for matching QFPROM fuse values to get the correct speed bin
> on A650 (SM8250) GPUs.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 17 +
> 1 file changed, 17 insertions(+
On 13/12/2022 14:52, Andrzej Hajda wrote:
On 13.12.2022 13:39, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew,
the
code become a bit unsightly. Consolidate by storing the required
values at
engine init time in the engine its
On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
wrote:
>
> On 13.12.2022 15:18, Jagan Teki wrote:
> > On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
> > wrote:
> >> On 13.12.2022 13:20, Marek Szyprowski wrote:
> >>> On 13.12.2022 11:40, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 2:28 PM
On Fri, Dec 09, 2022 at 11:35:23AM +0100, Johan Hovold wrote:
> On Wed, Dec 07, 2022 at 02:00:11PM -0800, Bjorn Andersson wrote:
> > From: Bjorn Andersson
> >
> > The SC8280XP CRD has a EDP display on MDSS0 DP3, enable relevant nodes
> > and link it together with the backlight control.
> >
> > S
This fixes PLL being unable to lock, and is derived from an equivalent
downstream commit.
Available LT9611 documentation does not list this register, neither does
LT9611UXC (which is a different chip).
This commit has been confirmed to fix HDMI output on DragonBoard 845c.
Suggested-by: Amit Pund
On 13.12.2022 15:18, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
> wrote:
>> On 13.12.2022 13:20, Marek Szyprowski wrote:
>>> On 13.12.2022 11:40, Jagan Teki wrote:
On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
wrote:
> On 12.12.2022 16:33, Jagan Teki wro
On 13.12.2022 13:39, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of inv
On Tue, Dec 13, 2022 at 08:21:16PM +0800, Jiasheng Jiang wrote:
> Add the check for the return value of dma_alloc_coherent
> in order to avoid NULL pointer dereference.
>
> Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver")
> Signed-off-by: Jiasheng Jiang
Again, please prove that
On Tue, Dec 13, 2022 at 08:15:20PM +0800, Jiasheng Jiang wrote:
> Thanks, I found my mistake and I will submit a v2.
>
> > And how did you find this potential problem? What tool did you use and
> > why did you not follow the documentation for properly describing the
> > tool?
>
> I used a tool I
On Tue, Dec 13, 2022 at 07:46:32AM -0600, Rob Herring wrote:
>
> On Tue, 13 Dec 2022 09:10:34 +0100, Christophe Branchereau wrote:
> > Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> > 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> > interface.
> >
> >
On Mon, 12 Dec 2022 10:33:12 +0100, Konrad Dybcio wrote:
> Add bindings for the display hardware on SM8150.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm8150-dpu.yaml | 92 +
> .../display/msm/qcom,sm8150-mdss.yaml | 330 ++
> 2 files ch
On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
wrote:
>
> On 13.12.2022 13:20, Marek Szyprowski wrote:
> > On 13.12.2022 11:40, Jagan Teki wrote:
> >> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
> >> wrote:
> >>> On 12.12.2022 16:33, Jagan Teki wrote:
> >>>
> >>> On Mon, Dec 12, 2022 at 8:
On 13.12.2022 13:00, Nirmoy Das wrote:
Use MI_USE_GGTT instead of hardcoded value.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherenc
On 13.12.2022 13:20, Marek Szyprowski wrote:
> On 13.12.2022 11:40, Jagan Teki wrote:
>> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>> wrote:
>>> On 12.12.2022 16:33, Jagan Teki wrote:
>>>
>>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>>> wrote:
>>>
>>> On 12.12.2022 09:43, Marek Szy
On Tue, 13 Dec 2022 09:10:34 +0100, Christophe Branchereau wrote:
> Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Christophe Branchereau
> Signed-off-by: Paul Cercueil
> -
On Tue, 2022-12-13 at 13:50 +0800, Jiapeng Chong wrote:
> No functional modification involved.
>
> drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:112: warning:
> expecting prototype for intel_guc_hwconfig_init(). Prototype was for
> guc_hwconfig_init() instead.
Thank you for the patch and for a
On Tue, Dec 13, 2022 at 5:50 PM Marek Szyprowski
wrote:
>
> Hi,
>
> On 13.12.2022 11:40, Jagan Teki wrote:
> > On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
> > wrote:
> >> On 12.12.2022 16:33, Jagan Teki wrote:
> >>
> >> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
> >> wrote:
> >>
> >>
On 12/13/22 14:26, Jagan Teki wrote:
On Tue, Dec 13, 2022 at 6:51 PM Marek Vasut wrote:
On 12/13/22 14:18, Jagan Teki wrote:
On Tue, Dec 13, 2022 at 6:44 PM Marek Vasut wrote:
On 12/13/22 11:53, Jagan Teki wrote:
Hi Fabio,
Hi,
On Tue, Dec 13, 2022 at 4:17 PM Fabio Estevam wrote:
Hi
On Tue, Dec 13, 2022 at 6:51 PM Marek Vasut wrote:
>
> On 12/13/22 14:18, Jagan Teki wrote:
> > On Tue, Dec 13, 2022 at 6:44 PM Marek Vasut wrote:
> >>
> >> On 12/13/22 11:53, Jagan Teki wrote:
> >>> Hi Fabio,
> >>
> >> Hi,
> >>
> >>> On Tue, Dec 13, 2022 at 4:17 PM Fabio Estevam wrote:
>
>
On 12/13/22 14:18, Jagan Teki wrote:
On Tue, Dec 13, 2022 at 6:44 PM Marek Vasut wrote:
On 12/13/22 11:53, Jagan Teki wrote:
Hi Fabio,
Hi,
On Tue, Dec 13, 2022 at 4:17 PM Fabio Estevam wrote:
Hi Jagan,
On Tue, Dec 13, 2022 at 7:40 AM Jagan Teki wrote:
https://gitlab.com/openedev/ke
On Tue, 2022-12-13 at 00:08 +0100, Andi Shyti wrote:
> Hi Rodrigo,
>
> On Mon, Dec 12, 2022 at 11:55:10AM -0500, Rodrigo Vivi wrote:
> > On Mon, Dec 12, 2022 at 05:13:38PM +0100, Andi Shyti wrote:
> > > From: Chris Wilson
> > >
> > > After applying an engine reset, on some platforms like
> > > J
On Tue, Dec 13, 2022 at 6:44 PM Marek Vasut wrote:
>
> On 12/13/22 11:53, Jagan Teki wrote:
> > Hi Fabio,
>
> Hi,
>
> > On Tue, Dec 13, 2022 at 4:17 PM Fabio Estevam wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Tue, Dec 13, 2022 at 7:40 AM Jagan Teki
> >> wrote:
> >>
> >>> https://gitlab.com/openede
On 12/13/22 11:53, Jagan Teki wrote:
Hi Fabio,
Hi,
On Tue, Dec 13, 2022 at 4:17 PM Fabio Estevam wrote:
Hi Jagan,
On Tue, Dec 13, 2022 at 7:40 AM Jagan Teki wrote:
https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
Please preserve the authorship of the patches.
This one is
On 13/12/2022 00:41, Abhinav Kumar wrote:
>>>
>>> besides, i think i have to sent the whole series patches include this
>>> one to address your new comments on other patch.
>>>
>>> is this correct?
>>
>> No. Please fix your system first, validate your patches and send them
>> afterwards. You can no
1 - 100 of 135 matches
Mail list logo
