Hi
Am 12.02.24 um 05:28 schrieb Randy Dunlap:
Correct spellos/typos in comments.
Signed-off-by: Randy Dunlap
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
---
include/linux/iosys-map.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -- a/include/linux/iosys-m
Correct spellos/typos in comments.
Signed-off-by: Randy Dunlap
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
---
include/linux/iosys-map.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -- a/include/linux/iosys-map.h b/include/linux/iosys-map.h
--- a/include/linu
use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Tony-Lindgren/dt-bindings-display-bridge-tc358775-make-stby-gpio-optional/20240211-180213
base: git://anongit.freedesktop.org/drm/dr
Hi Krzysztof,
On 09/02/24 9:40 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 09/02/2024 17:05, Krzysztof Kozlowski wrote:
>> On 09/02/2024 16:02, dharm...@microchip.com wrote:
>>> On 09/02/24 7:50 pm, Dharma B
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 7edd06233958d9086a9e3eb723a8768d3c5a9ce1
commit: e154c4fc7bf2d5c3f86d07628ab1cb03e8085c25 [49/49] drm: remove
drm_debug_printer in favor of drm_dbg_printer
config: powerpc-randconfig-002-20240211
(https://download.01.org
Hello Angelo,
thank you for taking a look at these MT8192 issues before. The panel issue
reported in this thread is resolved on v6.8, possibly by the "drm for 6.8"
changes including "chromebook panel support" and we can thus "close" this
thread. Unfortunately, suspend [1] and sound still do not
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/tests/drm_mm_test.c: In function 'drm_test_mm_debug':
drivers/gpu/drm/tests/drm_mm_test.c:191:32: error: implicit declaration of
function 'drm_debug_printer'; did you mean 'd
Hi all,
On Tue, 6 Feb 2024 15:28:50 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> In function 'i915_ttm_placement_from_obj',
> inlined from 'i915_ttm_get_pages' at
> drivers/gpu/drm/i915/gem/i915_gem_ttm
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too small which can cause
some monitors to not
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
As noted by F
On Fri, 9 Feb 2024 16:08:29 +
Colin Ian King wrote:
> The pointer map is being initialized with a value that is never
> read, it is being re-assigned later on in a for-loop. The
> initialization is redundant and can be removed.
>
> Cleans up clang scan build warning:
> drivers/gpu/drm/i915/
On Sun, 11 Feb 2024 at 19:18, Abhinav Kumar wrote:
>
>
>
> On 2/10/2024 10:57 PM, Dmitry Baryshkov wrote:
> > On Sun, 11 Feb 2024 at 06:06, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/10/2024 1:46 PM, Dmitry Baryshkov wrote:
> >>> On Sat, 10 Feb 2024 at 20:50, Abhinav Kumar
> >>> wrote:
Hi Frank,
On Sun, Feb 11, 2024 at 04:09:16PM +0100, Frank Oltmanns wrote:
> Hi Ondřej,
>
> On 2024-02-05 at 17:02:00 +0100, Ondřej Jirman wrote:
> > On Mon, Feb 05, 2024 at 04:54:07PM +0100, Ondřej Jirman wrote:
> >> On Mon, Feb 05, 2024 at 04:22:23PM +0100, Frank Oltmanns wrote:
> >>
> >> [...]
On 1/18/24 19:39, Marek Vasut wrote:
In case the LCDIF is enabled in DT but unused, the clock used by the
LCDIF are not enabled. Those clock may even have a use count of 0 in
case there are no other users of those clock. This can happen e.g. in
case the LCDIF drives HDMI bridge which has no panel
In smu_baco_get_state() smu->ppt_funcs->baco_get_state is checked for NULL.
If it is NULL then the pointer is dereferenced.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 6c45e480fe23 ("drm/amd/powerplay: clear the swSMU code layer")
Signed-off-by: Daniil Dulov
---
dri
On 2/10/2024 10:57 PM, Dmitry Baryshkov wrote:
On Sun, 11 Feb 2024 at 06:06, Abhinav Kumar wrote:
On 2/10/2024 1:46 PM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 20:50, Abhinav Kumar wrote:
On 2/10/2024 10:14 AM, Abhinav Kumar wrote:
On 2/10/2024 2:09 AM, Dmitry Baryshkov wr
On 2024-02-08 at 20:05:08 +0100, Maxime Ripard wrote:
> [[PGP Signed Part:Undecided]]
> Hi Frank,
>
> On Mon, Feb 05, 2024 at 04:22:28PM +0100, Frank Oltmanns wrote:
>> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
>> The SOC requires pll-mipi to run at more than 500 MHz.
Hi Ondřej,
On 2024-02-05 at 17:02:00 +0100, Ondřej Jirman wrote:
> On Mon, Feb 05, 2024 at 04:54:07PM +0100, Ondřej Jirman wrote:
>> On Mon, Feb 05, 2024 at 04:22:23PM +0100, Frank Oltmanns wrote:
>> > On some pinephones the video output sometimes freezes (flips between two
>> > frames) [1]. It s
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
Signed-off-by:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the panel. If a user prefers to use the EDID from
the panel, offer a module parameter that would di
This series adds the ability to fetch the EDID through ACPI for laptop
panels. Drivers need to opt into the behavior.
In this series it's enabled by default for all eDP or LVDS panels with
AMDGPU and certain panels for Nouveau.
Mario Limonciello (3):
drm: Add support to get EDID from ACPI
drm
Rather than inventing a wrapper to acpi_video_get_edid() use the
one provided by drm. This fixes two problems:
1. A memory leak that the memory provided by the ACPI call was
never freed.
2. Validation of the BIOS provided blob.
Convert the usage in nouveau_connector_detect_lvds() to use
struct
On Sun, 11 Feb 2024 11:51:08 +0200, Tony Lindgren wrote:
> The tc358765 is similar to tc358775. The tc358765 just an earlier version
> of the hardware, and it's pin and register compatible with tc358775 for
> most part.
>
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check
This panel is found on Motorola mapphone tablets mz607 to mz609.
Acked-by: Conor Dooley
Signed-off-by: Tony Lindgren
---
No changes since v1
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindi
The BOE BP082WX1-100 is a 8.2" panel similar to the 10.1" panel
BP101WX1-100. Both panels use the same timings.
Acked-by: Conor Dooley
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Tony Lindgren
---
Changes since v1:
- Update viewport dimensions based on panelook values asa suggested
by Dmitr
The following trace occurs when using nouveau and unplugging a DP MST
adaptor:
divide error: [#1] PREEMPT SMP PTI
CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
The hs_rate and lp_rate may be used by the dsi host for timing
calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
tc358765 has maximurate of 800 Mbps per lane.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 13 +
1 file changed, 13 insertions(+)
The tc358775 bridge is pin compatible with earlier tc358765 according to
the tc358774xbg_datasheet_en_20190118.pdf documentation. Compared to the
tc358765, the tc358775 supports a STBY GPIO and higher data rates.
The tc358765 has a register bit for video event mode vs video pulse mode.
We must set
Set pre_enable_prev_first to ensure the previous bridge is enabled
first.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Michael Walle
Tested-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/br
Burst and low-power modes are supported both for tc358765 and tc358775.
Reviewed-by: Michael Walle
Tested-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
The current code assumes the data-lanes property is configured on the
DSI host side instead of the bridge side, and assumes DSI host endpoint 1.
Let's standardize on what the other bridge drivers are doing and parse the
data-lanes property for the bridge. Only if data-lanes property is not found,
From: Michael Walle
The stby pin is optional. It is only needed for power-up and down
sequencing. It is not needed, if the power rails cannot by dynamically
enabled.
Because the GPIO is now optional, remove the error message.
Signed-off-by: Michael Walle
Reviewed-by: Dmitry Baryshkov
Signed-o
From: Michael Walle
The bridge always uses 24bpp internally. Therefore, for jeida-18
mapping we need to discard the lowest two bits for each channel and thus
starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
lanes instead of three, with the forth pair transmitting the lowest tw
The tc358765 is similar to tc358775. The tc358765 just an earlier version
of the hardware, and it's pin and register compatible with tc358775 for
most part.
>From the binding point of view the only difference is that the tc358765
does not have stdby-gpios.
Signed-off-by: Tony Lindgren
---
.../b
The device uses a clock lane, and 1 to 4 DSI data lanes. Let's add the
data-lanes property starting at 1 similar to what the other bridge
bindings are doing.
Let's also drop the data-lanes properties in the example for the DSI host
controller to avoid confusion. The configuration of the DSI host d
From: Michael Walle
For a normal operation, the stby GPIO is not needed.
The reset pin is required because once the PPI (PHY protocol interface)
is started, it can only be stopped by asserting the reset pin.
Signed-off-by: Michael Walle
[t...@atomide.com: dropped regulator related changes]
Sig
Hi all,
Here are v3 patches to improve tc358775 driver and add support for
tc358765.
Regards,
Tony
Changes since v2:
- Only make stby-gpios optional for tc358775, and disallow them for
tc358765 as noted by Krzysztof
- Added additionalProperties: false for port-base as noted by Krzysztof
-
37 matches
Mail list logo
