On Tue, Dec 13, 2022 at 04:40:27PM +0530, Rijo Thomas wrote:
> For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
> ring buffer address sent by host to ASP must be a real physical
> address and the pages must be physically contiguous.
>
> In a virtualized environment though,
Smatch report warning as follows:
Line 53679: drivers/gpu/drm/amd/display/dc/core/dc_stream.c:402
dc_stream_set_cursor_position() warn: variable dereferenced before
check 'stream'
The value of 'dc' has been assigned after check whether 'stream' is
NULL. Fix it by remove redundant assignment.
On Fri, Dec 16, 2022 at 11:41:30AM +0100, Krzysztof Kozlowski wrote:
> On 14/12/2022 12:59, Uwe Kleine-König wrote:
> > Modify the existing (fb-like) binding to support the drm-like binding in
> > parallel.
>
> Aren't you now adding two compatibles to the same hardware, just for two
> Linux
Remove the unused 'reset' interface which was supposed to help to ensure
that cx gdsc has collapsed during gpu recovery. This is was not enabled
so far due to missing gpucc driver support. Similar functionality using
genpd framework will be implemented in the upcoming patch.
Signed-off-by: Akhil
When a device has multiple power domains, dev->power_domain is left
empty during probe. That didn't cause any issue so far because we are
freeloading on smmu driver's vote on cx gdsc. Instead of that, create
a device_link between cx genpd device and gmu device to keep a vote from
gpu driver.
Add support for the newly added 'synced_poweroff' genpd flag. This allows
some clients (like adreno gpu driver) to request gdsc driver to ensure
a votable gdsc (like gpucc cx gdsc) has collapsed at hardware.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/clk/qcom/gdsc.c | 11
As per the recommended recovery sequence of adreno gpu, cx gdsc should
collapse at hardware before it is turned back ON. This helps to clear
out the stale states in hardware before it is reinitialized. Use the
genpd notifier along with the newly introduced
dev_pm_genpd_synced_poweroff() api to
This is a rework of [1] using genpd instead of 'reset' framework.
As per the recommended reset sequence of Adreno gpu, we should ensure that
gpucc-cx-gdsc has collapsed at hardware to reset gpu's internal hardware states.
Because this gdsc is implemented as 'votable', gdsc driver doesn't poll
Le jeudi 15 décembre 2022 à 11:55 +0100, Robert Foss a écrit :
> On Wed, 14 Dec 2022 at 13:58, Paul Cercueil
> wrote:
> >
> > Add a new ite,it6610 compatible string to the IT66121 binding
> > documentation, since the two chips are very similar.
> >
> > Signed-off-by: Paul Cercueil
> > ---
> >
On 23/08/2022 03:16, Andrew Davis wrote:
We have no segment size limitations. Set to unlimited.
Signed-off-by: Andrew Davis
---
drivers/gpu/drm/tidss/tidss_dispc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
On 16/12/2022 12:38, Uwe Kleine-König wrote:
> On Fri, Dec 16, 2022 at 11:41:30AM +0100, Krzysztof Kozlowski wrote:
>> On 14/12/2022 12:59, Uwe Kleine-König wrote:
>>> Modify the existing (fb-like) binding to support the drm-like binding in
>>> parallel.
>>
>> Aren't you now adding two compatibles
https://bugzilla.kernel.org/show_bug.cgi?id=216119
--- Comment #50 from Harald Judt (h.j...@gmx.at) ---
On the other hand, I have not experienced any problems with vt-switching so far
_before_ hibernate/resume.
--
You may reply to this email to add a comment.
You are receiving this mail
On 12/15/22 10:07, Michel Dänzer wrote:
> On 12/14/22 16:46, Alex Deucher wrote:
>> On Wed, Dec 14, 2022 at 4:01 AM Pekka Paalanen wrote:
>>> On Tue, 13 Dec 2022 18:20:59 +0100
>>> Michel Dänzer wrote:
On 12/12/22 19:21, Harry Wentland wrote:
> This will let us pass kms_hdr.bpc_switch.
From: Ulf Hansson
Some genpd providers doesn't ensure that it has turned off at hardware.
This is fine until the consumer really requires during some special
scenarios that the power domain collapse at hardware before it is
turned ON again.
An example is the reset sequence of Adreno GPU which
On 16/12/2022 11:46, Paul Cercueil wrote:
>>> properties:
>>> compatible:
>>> - const: ite,it66121
>>> + enum:
>>> + - ite,it66121
>>> + - ite,it6610
These should be ordered alphabetically. What's with the tendency of
adding always to the end?
>>>
>>> reg:
>>>
On 14/12/2022 12:41, Christophe Branchereau wrote:
> From: Paul Cercueil
>
> 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: Paul Cercueil
> Signed-off-by: Christophe
On 14/12/2022 12:59, Uwe Kleine-König wrote:
> Modify the existing (fb-like) binding to support the drm-like binding in
> parallel.
Aren't you now adding two compatibles to the same hardware, just for two
Linux drivers? One hardware should have one compatible, regardless of
Linux display
On Fr, 2022-12-16 at 15:51 +0530, Akhil P Oommen wrote:
> Remove the unused 'reset' interface which was supposed to help to ensure
> that cx gdsc has collapsed during gpu recovery. This is was not enabled
> so far due to missing gpucc driver support. Similar functionality using
> genpd framework
On 02/12/2022 02:18, Randolph Sapp wrote:
There was a long-standing bug from a typo that created 2 ARGB1555 and
ABGR1555 pixel format entries. Weston 10 has a sanity check that alerted
me to this issue.
According to the Supported Pixel Data formats table we have the later
entries should have
On 14/10/2022 05:48, Yuan Can wrote:
After commit 64ff18911878, struct csc_coef_rgb2yuv is not used any more
and can be removed as well.
Fixes: 64ff18911878 ("drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for
planes")
Signed-off-by: Yuan Can
---
changes in v2:
- adjust commit msg
On 06/12/2022 03:00, nathan.lu wrote:
From: Nathan Lu
modify VDOSYS0 display device tree Documentations for MT8188.
Signed-off-by: Nathan Lu
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
Hi
Am 16.12.22 um 04:05 schrieb Ma Jun:
Add the missing declaration of struct drm_atomic_state to fix the
compile error below:
error: 'struct drm_atomic_state' declared inside parameter
list will not be visible outside of this definition or declaration [-Werror]
Signed-off-by: Ma Jun
Hi Marek,
Am Freitag, 16. Dezember 2022, 13:58:13 CET schrieb Marek Vasut:
> On 12/16/22 13:41, Alexander Stein wrote:
> > Hi,
>
> Hi,
>
> > thanks for the new update.
> >
> > Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb Jagan Teki:
> >> This series supports common bridge support for
On Fri, Dec 16, 2022 at 3:03 PM Tetsuo Handa
wrote:
>
> On 2022/12/15 18:36, Geert Uytterhoeven wrote:
> > The next line is:
> >
> > scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
> >
> > So how can this turn out to be uninitialized later below?
> >
> >
On Thu, 15 Dec 2022 12:52:09 -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Add documentation for Samsung AMS495QA01 panel (with Magnachip
> D53E6EA8966 controller IC).
>
> Signed-off-by: Chris Morgan
> Signed-off-by: Maya Matuszczyk
> ---
> .../display/panel/samsung,ams495qa01.yaml
On Wed, Nov 09, 2022 at 03:03:14PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2022 at 07:38:23PM +0100, Stanislaw Gruszka wrote:
> > If drm_sysfs_minor_alloc() fail in drm_minor_alloc() we can end up
> > freeing invalid minor->kdev pointer and drm_minor_alloc_release()
> > will crash like
https://bugzilla.kernel.org/show_bug.cgi?id=216814
Bug ID: 216814
Summary: amdgpu: CTM support has disappeared (vega)
Product: Drivers
Version: 2.5
Kernel Version: 6.0
Hardware: AMD
OS: Linux
Tree: Mainline
Hi,
thanks for the new update.
Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb Jagan Teki:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
>
> Patch
On 2022/12/15 18:36, Geert Uytterhoeven wrote:
> The next line is:
>
> scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
>
> So how can this turn out to be uninitialized later below?
>
> scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
>
> What am I
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP.
Simplify display info update by merging ELD handling as well as clearing
of the data in update_display_info().
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff
The original goal with drm_edid_connector_update() was to have a single
call for updating the connector and adding probed modes, in this order,
but that turned out to be problematic. Drivers that need to update the
connector in the .detect() callback would end up updating the probed
modes as well.
Rename the local variable to info for consistency.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
The BPC quirks are closer to home in update_display_info().
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
Realize that drm_edid_connector_update() and
_drm_connector_update_edid_property() are now the same thing. Drop the
latter.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
By moving update_display_info() out of _drm_edid_connector_update() we
make the function purely about adding modes. Rename accordingly.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 -
1 file changed, 12 insertions(+),
It's a bit confusing to have two cached EDIDs in struct intel_connector
with slightly different purposes. Make the distinction a bit clearer by
moving the EDID cached for eDP and LVDS panels at connector init time to
struct intel_panel, and name it fixed_edid. That's what it is, a fixed
EDID for
The DEFINE_DEBUGFS_ATTRIBUTE macro has implementation for protecting the
read/write file operations from removal race conditions. This further
enables using debugfs_create_file_unsafe() function since there is no need
for a proxy file operations struct for protection. Hence replace the
Quoting Akhil P Oommen (2022-12-15 07:10:58)
> Add support for the newly added 'synced_poweroff' genpd flag. This allows
> some clients (like adreno gpu driver) to request gdsc driver to ensure
> a votable gdsc (like gpucc cx gdsc) has collapsed at hardware.
>
> Signed-off-by: Akhil P Oommen
>
Am Freitag, dem 16.12.2022 um 13:03 +0100 schrieb Uwe Kleine-König:
> On Fri, Nov 25, 2022 at 12:25:19PM +0100, Lucas Stach wrote:
> > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > index b644deffe948..909622864716 100644
> > --- a/drivers/gpu/drm/imx/Makefile
> > +++
On Fri, 16 Dec 2022, Imre Deak wrote:
> On Wed, Dec 14, 2022 at 04:41:42PM -0500, Lyude Paul wrote:
>> For the whole series:
>>
>> Reviewed-by: Lyude Paul
>
> Thanks for the review, pushed it to drm-misc-next.
Hmm, with the drm-misc *not* cherry-picking patches from drm-misc-next
to
On Fri, Dec 16, 2022 at 06:10:39PM +0200, Jani Nikula wrote:
> On Fri, 16 Dec 2022, Imre Deak wrote:
> > On Wed, Dec 14, 2022 at 04:41:42PM -0500, Lyude Paul wrote:
> >> For the whole series:
> >>
> >> Reviewed-by: Lyude Paul
> >
> > Thanks for the review, pushed it to drm-misc-next.
>
> Hmm,
On Fri, Nov 25, 2022 at 12:25:19PM +0100, Lucas Stach wrote:
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> index b644deffe948..909622864716 100644
> --- a/drivers/gpu/drm/imx/Makefile
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -1,12 +1,4 @@
> [...]
>
On 16/12/2022 13:21, Paul Cercueil wrote:
> Hi Krzysztof,
>
> Le vendredi 16 décembre 2022 à 12:21 +0100, Krzysztof Kozlowski a
> écrit :
>> On 16/12/2022 11:46, Paul Cercueil wrote:
>>
> properties:
> compatible:
> - const: ite,it66121
> + enum:
> + -
Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().
v2: Rebase
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 ---
On 12/16/22 13:41, Alexander Stein wrote:
Hi,
Hi,
thanks for the new update.
Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb Jagan Teki:
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
The final bridge supports both the
On Wed, Dec 14, 2022 at 04:41:42PM -0500, Lyude Paul wrote:
> For the whole series:
>
> Reviewed-by: Lyude Paul
Thanks for the review, pushed it to drm-misc-next.
> Thanks!
>
> On Wed, 2022-12-14 at 20:42 +0200, Imre Deak wrote:
> > If the sink gets disconnected during receiving a
On Fri, Dec 16, 2022, 12:21 Krzysztof Kozlowski <
krzysztof.kozlow...@linaro.org> wrote:
> On 16/12/2022 11:46, Paul Cercueil wrote:
>
> >>> properties:
> >>>compatible:
> >>> -const: ite,it66121
> >>> +enum:
> >>> + - ite,it66121
> >>> + - ite,it6610
>
> These should be
Simplify validation and use by converting to drm_edid.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++-
drivers/gpu/drm/i915/display/intel_opregion.c | 29 +++
On 11/28/22 19:16, Thomas Zimmermann wrote:
> Hi
>
> Am 12.09.22 um 11:15 schrieb Uwe Kleine-König:
>> While working on a drm driver that doesn't need the i2c algobit stuff I
>> noticed that DRM selects this code even tough only 8 drivers actually use
>> it. While also only some drivers use i2c,
Hi Arnd,
On Thu, Dec 15, 2022 at 6:05 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The dsi_irq_stats structure is a little too big to fit on the
> stack of a 32-bit task, depending on the specific gcc options:
>
> fbdev/omap2/omapfb/dss/dsi.c: In function 'dsi_dump_dsidev_irqs':
>
Change struct fb_ops.release and its implementations to not return
a value. Returing an error is not necessary and callers of the
function ignore it. It is also good practice to make clean-up code
unable ot fail, as such failure cannot be handled.
In several places drivers tested for the
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/hgafb.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
index
Hi,
Does anyone know if the Crystalfontz CFAF240320X0-020T display is
supported in Linux?
https://www.crystalfontz.com/product/cfaf240320x0020t-2inch-240x320-color-tft
It uses a Sitronix ST7789V controller.
For the ST7789V, there is a drm driver:
drivers/gpu/drm/panel/panel-sitronix-st7789v.c
Remove the return type from struct fb_ops.fb_release. It is never
handled, it is never locked at. Originaly done for further updates
under DRM, but the majority of changes is within fbdev drivers.
Also fix trailing whitespaces before modifying hgafb.c.
Thomas Zimmermann (2):
fbdev/hgafb:
Hi Krzysztof,
Le vendredi 16 décembre 2022 à 12:21 +0100, Krzysztof Kozlowski a
écrit :
> On 16/12/2022 11:46, Paul Cercueil wrote:
>
> > > > properties:
> > > > compatible:
> > > > - const: ite,it66121
> > > > + enum:
> > > > + - ite,it66121
> > > > + - ite,it6610
>
> These
Den 16.12.2022 12.54, skrev Fabio Estevam:
> Hi,
>
> Does anyone know if the Crystalfontz CFAF240320X0-020T display is
> supported in Linux?
>
> https://www.crystalfontz.com/product/cfaf240320x0020t-2inch-240x320-color-tft
>
> It uses a Sitronix ST7789V controller.
>
> For the ST7789V,
Applied patches 2,3,4,5
The rest will go through the DRM driver tree.
Thanks!
On 06/12/2022 03:00, nathan.lu wrote:
From: Nathan Lu
This patch is to add first version mt8188 vdosys0 driver
Modify and add new files include:
1. bindings documents
2. mtk mmsys
3. mtk mutex
4. mtk drm driver
On 06/12/2022 03:00, nathan.lu wrote:
From: Nathan Lu
add driver data of mt8188 vdosys0 to mediatek-drm and the sub driver.
Signed-off-by: amy zhang
Signed-off-by: Nathan Lu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
On Thu, Dec 15, 2022, at 18:56, Michel Dänzer wrote:
> On 12/15/22 17:37, Arnd Bergmann wrote:
/amd/display/dc/core/dc_link_dp.c
>> index af9411ee3c74..95dbfa4e996a 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> @@
Now that quirks are stored in display info, we can just look them up
using the connector instead of having to pass them around.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 34 +++---
1 file changed, 15 insertions(+),
Although the quirks are internal to EDID parsing, it'll be helpful to
store them in display info to avoid having to pass them around.
This will also help separate adding probed modes (which needs the
quirks) from updating display info.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
The drm_edid handling still needed some plumbing in drm_edid.c before we
could convert i915 over to use it. Specifically
drm_edid_connector_update() needed to be split to two, with separate
drm_edid_connector_add_modes(). This is better explained in patch 7
commit message.
With that in patches
On 2022-12-16 17:08, Sean Anderson wrote:
On 11/3/22 14:22, Sean Anderson wrote:
This series adds a new function component_match_add_of to simplify the
common case of calling component_match_add_release with
component_release_of and component_compare_of. There is already
On Fr, 2022-11-25 at 12:25 +0100, Lucas Stach wrote:
> The IPUv3 and DCSS driver are two totally separate DRM drivers. Having
> one of them live in the drivers/gpu/drm/imx toplevel directory and the
> other one in the dcss/ subdirectory is confusing. Move the IPUv3 driver
> into its own
On Fr, 2022-12-16 at 18:50 +0100, Uwe Kleine-König wrote:
> Hello,
>
> Changes since v2:
>
> - added allOf as Krzysztof requested
> - reworked driver based on Philipp's comments
> (improved error handling, different selects, moved driver to a
> subdirectory,
> header sorting, drm_err
On Mi, 2022-07-20 at 23:22 +0800, Liang He wrote:
> In ipu_add_client_devices(), we need to call of_node_put() for
> reference returned by of_graph_get_port_by_id() in fail path.
>
> Fixes: 17e052175039 ("gpu: ipu-v3: Do not bail out on missing optional port
> nodes")
> Signed-off-by: Liang He
On Thu, Dec 15, 2022 at 2:46 PM Christophe JAILLET
wrote:
>
> Le 15/12/2022 à 17:36, Arnd Bergmann a écrit :
> > From: Arnd Bergmann
> >
> > The activity_monitor_external[] array is too big to fit on the
> > kernel stack, resulting in this warning with clang:
> >
> >
On 12/15/2022 6:16 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-12-15 13:12:49)
On 15/12/2022 02:38, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-12-14 14:56:23)
Once link training start, then there are no any interactions between
controller and phy during link training session.
On 12/12/2022 17:52, Umesh Nerlige Ramappa wrote:
On Tue, Nov 29, 2022 at 01:12:52PM -0800, john.c.harri...@intel.com
wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context
On Thu, Dec 15, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The check_reserve_boundaries function uses a lot of kernel stack,
> and it gets inlined by clang, which makes __drm_test_mm_reserve
> use even more of it, to the point of hitting the warning limit:
>
>
From: Rob Clark
Relying on an unreturned handle to hold a reference to an object we
dereference is not safe. Userspace can guess the handle and race us
by closing the handle from another thread. The _create_with_handle()
that returns an object ptr is pretty much a pattern to avoid. And
From: Rob Clark
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference. For that reason, dropping
the handle's reference must be done *after* we are done
On 12/13/2022 3:22 PM, 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 to
On Fri, Dec 16, 2022 at 4:20 PM Rob Clark wrote:
>
> On Fri, Dec 16, 2022 at 3:59 PM Chia-I Wu wrote:
> >
> > On Fri, Dec 16, 2022 at 3:34 PM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > Relying on an unreturned handle to hold a reference to an object we
> > > dereference is not
On 12/14/2022 5:08 PM, Dmitry Baryshkov wrote:
On 14/12/2022 21:30, Marijn Suijten wrote:
On 2022-12-14 20:43:29, Dmitry Baryshkov wrote:
On 14/12/2022 01:22, Marijn Suijten wrote:
Active CTLs have to configure what DSC block(s) have to be enabled, and
what DSC block(s) have to be flushed;
On 12/13/2022 3:22 PM, Marijn Suijten wrote:
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
On Fri, Dec 16, 2022 at 3:34 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Relying on an unreturned handle to hold a reference to an object we
> dereference is not safe. Userspace can guess the handle and race us
> by closing the handle from another thread. The _create_with_handle()
> that
On Fri, Dec 16, 2022 at 3:59 PM Chia-I Wu wrote:
>
> On Fri, Dec 16, 2022 at 3:34 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Relying on an unreturned handle to hold a reference to an object we
> > dereference is not safe. Userspace can guess the handle and race us
> > by closing the
By default, HBR2 (5.4G) is the max link rate 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
To increase the flexibility of supporting different DP main link configuration
at different platform, add both data-lanes and link-frequencies property
into endpoint so that different platform can specify its own main link
combination of both data lanes and max supported link rate.
Changes in v7:
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:
-- separate parser link-frequencies out of data-lanes
Changes in v10:
-- add dp_parser_link_frequencies()
Changes in
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 _out
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
On Fri, Dec 16, 2022 at 06:50:04PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> Changes since v2:
>
> - added allOf as Krzysztof requested
> - reworked driver based on Philipp's comments
>(improved error handling, different selects, moved driver to a
> subdirectory,
>header sorting,
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine
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: parse
On Fri, Dec 16, 2022 at 3:33 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Userspace can guess the handle value and try to race GEM object creation
> with handle close, resulting in a use-after-free if we dereference the
> object after dropping the handle's reference. For that reason, dropping
>
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine
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 _out
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
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
To increase the flexibility of supporting different DP main link configuration
at different platform, add both data-lanes and link-frequencies property
into endpoint so that different platform can specify its own main link
combination of both data lanes and max supported link rate.
Changes in v7:
Krzysztof, there is a bunch of DTS code below. If you can comment on it
(and on my understanding of the existing schemas) that would be great.
On 16/12/2022 04:16, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-12-15 13:12:49)
On 15/12/2022 02:38, Stephen Boyd wrote:
Quoting Kuogee Hsieh
Ast hardware scans out the primary plane from video memory, which
is in I/O-memory space. Hence init the damage handler's iosys_map
pointer as I/O memory.
Not all platforms support accessing I/O memory as system memory,
although it's usually not a problem in ast's x86-based systems.
The error
On 12/13/2022 3:22 PM, Marijn Suijten wrote:
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
Reviewed-by: Abhinav Kumar
---
As per the downstream driver, gx gbif halt is required only during
recovery sequence. So lets avoid it during regular rpm suspend.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 15 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 +++
1 - 100 of 127 matches
Mail list logo
