Am 10.06.22 um 00:34 schrieb Javier Martinez Canillas:
The commit eecb3e4e5d9d ("staging: olpc_dcon: add OLPC display controller
(DCON) support") added this driver in 2010, and has been in staging since
then. It was marked as broken at some point because it didn't even build
but that got
Hi all,
After merging the drm-misc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/firmware/efi/sysfb_efi.c:29:10: fatal error: asm/efi.h: No such file or
directory
29 | #include
| ^~~
Caused by commit
fa0e256450f2 ("fbdev: vesafb:
On Thu, 2022-06-09 at 09:47 +0200, Alexander Stein wrote:
> Am Donnerstag, 9. Juni 2022, 08:49:26 CEST schrieb Liu Ying:
> > This patch adds a helper to support LDB drm bridge drivers for
> > i.MX SoCs. Helper functions supported by this helper should
> > implement common logics for all LDB
Hi Lucas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on linus/master v5.19-rc1 next-20220609]
[cannot apply to tegra-drm/drm/tegra/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Hi Laurent,
On Thu, 2022-06-09 at 12:32 +0300, Laurent Pinchart wrote:
> Hi Liu,
>
> On Thu, Jun 09, 2022 at 02:49:17PM +0800, Liu Ying wrote:
> > Hi,
> >
> > This is the v8 series to add some DRM bridge drivers support
> > for i.MX8qm/qxp SoCs.
> >
> > The bridges may chain one by one to form
Hi Laurent,
On Thu, 2022-06-09 at 12:30 +0300, Laurent Pinchart wrote:
> Hi Liu,
>
> Thank you for the patch.
Thank you for the review.
>
> On Thu, Jun 09, 2022 at 02:49:23PM +0800, Liu Ying wrote:
> > This patch adds a drm bridge driver for i.MX8qm/qxp display pixel
> > link.
> > The pixel
Hi Laurent,
On Thu, 2022-06-09 at 11:24 +0300, Laurent Pinchart wrote:
> Hi Liu,
>
> Thank you for the patch.
Thank you for the review.
>
> On Thu, Jun 09, 2022 at 02:49:20PM +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp pixel combiner.
> >
> > Reviewed-by: Rob Herring
On Wed, Jun 08, 2022 at 12:24:04PM +0100, Matthew Auld wrote:
On Tue, 17 May 2022 at 19:32, Niranjana Vishwanathapura
wrote:
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
---
Hi Jason,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[cannot apply to drm-tip/drm-tip linus/master v5.19-rc1 next-20220609]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
include/uapi/linux/dma-buf.h
between commit:
7c3e9fcad9c7 ("dma-buf: fix use of DMA_BUF_SET_NAME_{A,B} in userspace")
from Linus' tree and commits:
20e10881a043 ("dma-buf: Add an API for exporting sync files
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately
There's no reason to require the primary plane to always be at the
bottom of the stack, as the VSP supports arbitrary ordering of planes,
and the KMS API doesn't have such a requirement either. Lift the
restriction.
As the primary plane can now be positioned arbitrarily, enable control
of its
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.
Employ a similar trick as __seqprop() by
The commit eecb3e4e5d9d ("staging: olpc_dcon: add OLPC display controller
(DCON) support") added this driver in 2010, and has been in staging since
then. It was marked as broken at some point because it didn't even build
but that got removed once the build issues were addressed.
But it seems that
Quoting Dmitry Baryshkov (2022-06-02 03:20:19)
> On Thu, 2 Jun 2022 at 01:07, Marijn Suijten
> wrote:
> > diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> > index 54942d758ee6..fabb98d0cdb2 100644
> > --- a/drivers/clk/clk-fixed-factor.c
> > +++
Hi,
On Tue, Jun 07, 2022 at 08:20:26PM +0200, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
Hi,
On Tue, Jun 07, 2022 at 08:20:25PM +0200, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
On Thu, 9 Jun 2022 15:41:02 -0600
Alex Williamson wrote:
> On Thu, 9 Jun 2022 11:13:22 +0200
> Thomas Zimmermann wrote:
> >
> > Please have a look at the attached patch. It moves the aperture helpers
> > to a location common to the various possible users (DRM, fbdev, vfio).
> > The DRM
On Thu, 9 Jun 2022 11:13:22 +0200
Thomas Zimmermann wrote:
>
> Please have a look at the attached patch. It moves the aperture helpers
> to a location common to the various possible users (DRM, fbdev, vfio).
> The DRM interfaces remain untouched for now. The patch should provide
> what you
Hi Peter,
Am 09.06.22 um 13:52 schrieb Peter Robinson:
As of Linux 5.18.0, module vc4 apparently isn't working on Raspberry Pi
3B any more.
If a monitor is attached to the device, the boot messages show up as
usual, but right when KMS starts, the screen turns black. Similarly, the
screen also
On Wed, 2022-06-08 at 10:53 +0300, Pekka Paalanen wrote:
> On Tue, 7 Jun 2022 17:50:24 +
> Zack Rusin wrote:
>
> > On Tue, 2022-06-07 at 11:07 +0300, Pekka Paalanen wrote:
> > > On Fri, 03 Jun 2022 14:14:59 +
> > > Simon Ser wrote:
> > >
> > > > Hi,
> > > >
> > > > Please, read this
On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:
On 09/06/2022 00:55, Jason Ekstrand wrote:
On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
wrote:
On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin wrote:
>
>
>On 07/06/2022
Hi Stephen, thanks!
On Thu, Jun 09, 2022 at 08:04:40PM +0200, Stephen Kitt wrote:
> Instead of checking the state of various backlight_properties fields
> against the memorised state in atmel_lcdfb_info.bl_power,
> atmel_bl_update_status() should retrieve the desired state using
>
On Thu, Jun 09, 2022 at 09:36:48AM +0100, Matthew Auld wrote:
On 08/06/2022 22:32, Niranjana Vishwanathapura wrote:
On Wed, Jun 08, 2022 at 10:12:05AM +0100, Matthew Auld wrote:
On 08/06/2022 08:17, Tvrtko Ursulin wrote:
On 07/06/2022 20:37, Niranjana Vishwanathapura wrote:
On Tue, Jun 07,
On 6/9/2022 11:42 PM, Rob Clark wrote:
On Thu, Jun 9, 2022 at 11:04 AM Akhil P Oommen wrote:
On 6/9/2022 10:17 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume().
Reviewed-by: Tony Krowiak
On 6/7/22 7:02 PM, Jason Gunthorpe wrote:
Instead of having drivers register the notifier with explicit code just
have them provide a dma_unmap callback op in their driver ops and rely on
the core code to wire it up.
Suggested-by: Christoph Hellwig
Reviewed-by:
On Wed, Jun 8, 2022 at 11:41 PM Krzysztof Kozlowski
wrote:
>
> On 08/06/2022 23:56, Prashant Malani wrote:
> > On Wed, Jun 8, 2022 at 10:08 AM Prashant Malani
> > wrote:
> >>
> >> Hi Krzysztof,
> >>
> >> Thank you for looking at the patch.
> >>
> >> On Jun 08 11:24, Krzysztof Kozlowski wrote:
>
From: Pin-Yen Lin
Add the callback function when the driver receives state
changes of the Type-C port. The callback function configures the
crosspoint switch of the anx7625 bridge chip, which can change the
output pins of the signals according to the port state.
Signed-off-by: Pin-Yen Lin
When the DT node has "switches" available, register a Type-C mode-switch
for each listed "switch". This allows the driver to receive state
information about what operating mode a Type-C port and its connected
peripherals are in, as well as status information (like VDOs) related to
that state.
The
Parse the "switches" node, if available, and count and store the number
of Type-C switches within it. Since we currently don't do anything with
this info, no functional changes are expected from this change.
This patch sets a foundation for the actual registering of Type-C
switches with the
Analogix 7625 can be used in systems to switch USB Type-C DisplayPort
alternate mode lane traffic between 2 Type-C ports.
Update the binding to accommodate this usage by introducing a switch
property.
Signed-off-by: Prashant Malani
---
Changes since v1:
- Introduced patternProperties for
Introduce a binding which represents a component that can control the
routing of USB Type-C data lines as well as address data line
orientation (based on CC lines' orientation).
Signed-off-by: Prashant Malani
---
Changes since v1:
- Removed "items" from compatible.
- Fixed indentation in
There are some drivers that can use the Type C mux API, but don't have
to. Introduce CONFIG guards for the mux functions so that drivers can
include the header file and not run into compilation errors on systems
which don't have CONFIG_TYPEC enabled. When CONFIG_TYPEC is not enabled,
the Type C
Loosen the typec_mux_match() requirements so that searches where an
alt mode is not specified, but the target mux device lists the
"mode-switch" property, return a success.
This is helpful in Type C port drivers which would like to get a pointer
to the mux switch associated with a Type C port,
Instead of checking the state of various backlight_properties fields
against the memorised state in atmel_lcdfb_info.bl_power,
atmel_bl_update_status() should retrieve the desired state using
backlight_get_brightness (which takes into account the power state,
blanking etc.). This means the
On Thu, Jun 9, 2022 at 11:04 AM Akhil P Oommen wrote:
>
> On 6/9/2022 10:17 PM, Douglas Anderson wrote:
> > >From testing on sc7180-trogdor devices, reading the GMU registers
> > needs the GMU clocks to be enabled. Those clocks get turned on in
> > a6xx_gmu_resume(). Confusingly enough, that
This series introduces a binding for Type-C data lane switches. These
control the routing and operating modes of USB Type-C data lanes based
on the PD messaging from the Type-C port driver regarding connected
peripherals.
The first patch introduces a change to the Type-C mux class mode-switch
On 6/9/2022 10:17 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct
Hi Sam, Daniel,
On Thu, 9 Jun 2022 19:30:57 +0200, Sam Ravnborg wrote:
> thanks for taking care of all these backlight simplifications - this
> really helps to make the code simpler and more readable.
You’re welcome! I noticed fb_blank was deprecated and near enough unused, and
started
From: Rob Clark
The DEFINE_DRM_GEM_FOPS() helper is a bit limiting if a driver wants to
provide additional file ops, like show_fdinfo().
v2: Split out DRM_GEM_FOPS instead of making DEFINE_DRM_GEM_FOPS
varardic
v3: nits
Signed-off-by: Rob Clark
Acked-by: Thomas Zimmermann
---
From: Rob Clark
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.
Example output:
# cat /proc/`pgrep glmark2`/fdinfo/6
pos:0
Hello Sam,
On 6/9/22 19:23, Sam Ravnborg wrote:
[snip]
>
> To repeat myself from irc.
> olpc_dcon is a staging driver and we should avoid inventing anything in
> core code for to make staging drivers works.
> Geert suggested EXPORT_SYMPBOL_NS_GPL() that could work and narrow it
> down to
Hi Stephen,
thanks for taking care of all these backlight simplifications - this
really helps to make the code simpler and more readable.
On Thu, Jun 09, 2022 at 10:54:12AM +0100, Daniel Thompson wrote:
> On Wed, Jun 08, 2022 at 10:56:23PM +0200, Stephen Kitt wrote:
> > Instead of checking the
Hi Javier.
On Thu, Jun 09, 2022 at 03:09:21PM +0200, Javier Martinez Canillas wrote:
> Hello Thomas,
>
> On 6/9/22 13:49, Thomas Zimmermann wrote:
> > Hi Javier
> >
> > Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
> >> From: Daniel Vetter
> >>
> >> Well except when the olpc dcon
Reorder scratch page allocation so that memory regions are available
to allocate the buffers
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gt_gmch.c | 20 ++--
drivers/gpu/drm/i915/gt/intel_gt_gmch.h | 6 ++
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
In commit 450cede7f380 ("drm/i915/gem: Fix the mman selftest") we fixed up
the mman selftest to allocate user buffers via smem only if we have lmem,
otherwise it uses internal buffers.
As the commit message asserts, we should only be using buffers that
userland should be able to create.
Internal
Create a kernel only internal memory region that uses ttm pool allocator to
allocate volatile system pages.
Refactor internal buffer backend to simply allocate from this new
region.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 187 +-
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.
Internal/volatile buffers should not be shmem backed.
If a volatile buffer is requested, allow ttm to use the pool allocator
to provide volatile pages as backing.
Fix i915_ttm_shrink to handle !is_shmem volatile buffers by purging.
Signed-off-by: Robert Beckett
---
Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt. The object only exists as a fake object pointing to ggtt
and gains no benefit in going via the internal backend.
Instead, create a dummy
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well
This series refactors i915's internal buffer backend to use ttm.
It uses ttm's pool allocator to allocate volatile pages in place of the
old code which rolled its own via alloc_pages.
This is continuing progress to align all backends on using ttm.
v2: - commit message improvements to add
Hi,
On Wed, Jun 8, 2022 at 9:13 AM Rob Clark wrote:
>
> From: Rob Clark
>
> I've seen a few crashes like:
>
> CPU: 0 PID: 216 Comm: A618-worker Tainted: GW 5.4.196 #7
> Hardware name: Google Wormdingler rev1+ INX panel board (DT)
> pstate: 20c9 (nzCv daif +PAN
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device".
Let's grab a
On Wed, 11 May 2022 13:03:36 +0100
Liviu Dudau wrote:
Hi Liviu,
> On Mon, May 09, 2022 at 02:49:01PM +0100, Andre Przywara wrote:
> > On Fri, 06 May 2022 17:39:53 -0500
> > Rob Herring wrote:
> >
> > > On Fri, 06 May 2022 15:05:32 +0100, Andre Przywara wrote:
> > > > The Arm Mali Display
As Liviu pointed out, the arm,malidp-arqos-high-level property
mentioned in the original .txt binding was a mistake, and
arm,malidp-arqos-value needs to take its place.
The binding commit ce6eb0253cba ("dt/bindings: display: Add optional
property node define for Mali DP500") mentions the right
On 6/9/2022 9:24 PM, Rob Clark wrote:
On Thu, Jun 9, 2022 at 7:34 AM Douglas Anderson wrote:
From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
On Thu, Jun 9, 2022 at 7:34 AM Douglas Anderson wrote:
>
> From testing on sc7180-trogdor devices, reading the GMU registers
> needs the GMU clocks to be enabled. Those clocks get turned on in
> a6xx_gmu_resume(). Confusingly enough, that function is called as a
> result of the runtime_pm of the
On 6/8/2022 9:43 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
CPU: 0 PID: 216 Comm: A618-worker Tainted: GW 5.4.196 #7
Hardware name: Google Wormdingler rev1+ INX panel board (DT)
pstate: 20c9 (nzCv daif +PAN +UAO)
pc :
On 6/9/2022 8:27 PM, Doug Anderson wrote:
Hi,
On Thu, Jun 9, 2022 at 7:16 AM Akhil P Oommen wrote:
On 6/9/2022 2:17 AM, Rob Clark wrote:
On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen wrote:
On 6/8/2022 3:00 AM, Rob Clark wrote:
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
On
On 6/9/2022 8:03 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
">" ??
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU
Hi,
Thanks
Acked-by: Raphael Gallais-Pou
Cheers,
Raphaël
On 6/3/22 15:43, Yannick Fertre wrote:
> Fix issues reported by checkpatch.pl:
> - Braces {} should be used on all arms
> - Blank lines
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/ltdc.c | 5 ++---
> 1 file
Hi,
Thanks
Acked-by: Raphael Gallais-Pou
Cheers,
Raphaël
On 6/3/22 15:42, Yannick Fertre wrote:
> Remove error message about scaling & replace it by a debug
> message to avoid too much error.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/ltdc.c | 3 ++-
> 1 file changed, 2
Hi,
On Thu, Jun 9, 2022 at 7:16 AM Akhil P Oommen wrote:
>
> On 6/9/2022 2:17 AM, Rob Clark wrote:
> > On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen
> > wrote:
> >> On 6/8/2022 3:00 AM, Rob Clark wrote:
> >>> On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen
> >>> wrote:
> On 9/27/2021
On 09/06/2022 00:55, Jason Ekstrand wrote:
On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
wrote:
On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin wrote:
>
>
>On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
>>On Tue, Jun 07, 2022 at 11:18:11AM -0700,
On Wed, Jun 08, 2022 at 11:50:31AM -0400, Eric Farman wrote:
> > --- a/drivers/s390/cio/vfio_ccw_private.h
> > +++ b/drivers/s390/cio/vfio_ccw_private.h
> > @@ -98,7 +98,6 @@ struct vfio_ccw_private {
> > struct completion *completion;
> > atomic_tavail;
> >
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device".
Let's grab a
Am 2022-06-09 um 03:18 schrieb Christian König:
Am 09.06.22 um 02:05 schrieb Felix Kuehling:
[SNIP]
+ *
+ * ret = drm_exec_lock(, boB, 1);
Where is drm_exec_lock? It's not in this patch.
I've renamed this function to drm_exec_prepare_obj() but forgot to
update the documentation.
On 6/7/22 20:23, Javier Martinez Canillas wrote:
> The patches in this series contain mostly changes suggested by Daniel Vetter
> Thomas Zimmermann. They aim to fix existing races between the Generic System
> Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.
>
> For
On 6/9/2022 2:17 AM, Rob Clark wrote:
On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen wrote:
On 6/8/2022 3:00 AM, Rob Clark wrote:
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
On Tue, 7 Jun 2022 19:08:48 +0800, GONG, Ruiqi wrote:
> Fix the `unused-but-set-variable` warning as how other iteration
> wrappers do.
>
>
Applied to drm/drm-misc (drm-misc-fixes).
Thanks!
Maxime
> Could you start a bisection maybe?
I for one am having two issues here.
The harmless one is that I'm lacking a cooler for the RPi and my cross
compiling skills have become a bit rusty.
Both could be fixed quickly, of course.
The not so harmless one is that kernel 5.18.x is completely
On Fri, Jun 03, 2022 at 07:56:16AM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 3, 2022 at 7:14 AM Maxime Ripard wrote:
> >
> > On Fri, Jun 03, 2022 at 01:19:16PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, 3 Jun 2022 at 11:21, Maxime Ripard wrote:
> > > >
> > > > On Tue, May 31, 2022 at
Hello Thomas,
On 6/9/22 13:49, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
>> From: Daniel Vetter
>>
>> Well except when the olpc dcon fbdev driver is enabled, that thing
>> digs around in there in rather unfixable ways.
>
> There is
> If I understand you properly, it results in a blank screen if the
> monitor is connected, but the system is still responsive?
Yes. Similar to (the other) Peter's findings, the system is fully
responsive, it's just that the monitor is displaying a black screen.
Meanwhile I stumbled upon another
> Which kernel config do you use (is it a defconfig)?
These are custom configs provided by the distribution, the origin of
which I do not know.
You can find them at [1] (5.17.0, used in 5.17.1 as well) and [2]
(5.18.0, modified in 5.18.1).
The difference between these files and their upstream
Mark obsolete GPIO properties as deprecated. They are not used by
existing device trees. While we are at it, also drop them from the
schema example.
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
Declare that 8x60 HDMI PHY uses the core-vdda regulator and slave_iface
clock (this is the same config as is used by the 8960).
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 12
1 file changed, 12 insertions(+)
diff --git
Since there is no more difference between the HDMI platform data
between MSM8974/APQ8084/MSM8994/MSM8996, merge these configs into a
single entry.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 27 +++
1 file changed, 3
The HDMI driver doesn't use the phy-names to identify the PHY. Different
Qualcomm platforms have used different names for the PHY. So, we are
deprecating phy-names propertty of the HDMI device and dropping them
from existing DTs.
Signed-off-by: Dmitry Baryshkov
---
MSM8660 requires the same set of clocks and regulators as MSM8960. Reuse
MSM8960's config for the MSM8660 (8x60).
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
The HDMI driver doesn't use the phy-names to identify the PHY. Different
Qualcomm platforms have used different names for the PHY. So, we are
deprecating phy-names propertty of the HDMI device and dropping them
from existing DTs.
Signed-off-by: Dmitry Baryshkov
---
With the last (and only) in-kernel user of hdmi-mux regulator, drop it
from the HDMI driver.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c
Several platform configs use empty 'none' regulator arrays. They are not
necessary, as the code will use corresponding _cnt field and skip the
array completely. Drop them now.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 5 -
1 file
DB820c makes use of core-vcc-supply and core-vdda-supply, however the
driver code doesn't support these regulators. Enable them for HDMI on
8996 platform.
Fixes: 0afbe59edd3f ("drm/msm/hdmi: Add basic HDMI support for msm8996")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c
The MSM HDMI driver has support for hpd_regs on 8x74/8084: supply
regulators that are to be enabled for HPD to work. Currently these
regulators contain the hpd_gdsc, which was replaced by the power-domains
support and hpd-5v/hpd-5v-en, which are not used by the chip itself.
They power up the ESD
The HDMI driver has code to configure extra GPIOs, which predates
pinctrl support. Nowadays all platforms should use pinctrl instead.
Neither of upstreamed Qualcomm platforms uses these properties, so it's
safe to drop them.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
The HDMI circuitry on the IFC6410 is not powered by the 3v3. Drop the
hdmi-mux-supply property.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
hdmi-mux-supply is not used by the SoC's HDMI block, it is thought to
power up the external logic. Thus it should not be a part of HDMI
bindings, but it should be declared at some other device in the DT (like
HDMI mux, bridge, etc). Mark it as deprecated.
Reviewed-by: Krzysztof Kozlowski
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- dropped qcom,tx-ddc-* from example, they were not documented
- make phy-names deprecated, drop it from the examples
PHY:
- moved into phy/
As agreed with David, this is a continuation of his work started at [1].
Changes since v2:
- Deprecated usage of phy-names for HDMI node, added two patches to
remove this property from DT files,
- Fixed the uninitialized variable access in hpd_gpio code.
Changes since v1:
- Dropped quotes in
On 08/06/2022 15:37, Krzysztof Kozlowski wrote:
On 08/06/2022 14:07, Dmitry Baryshkov wrote:
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- dropped qcom,tx-ddc-* from example, they were
On 09/06/2022 01:45, David Heidelberg wrote:
On 08/06/2022 14:37, Krzysztof Kozlowski wrote:
On 08/06/2022 14:07, Dmitry Baryshkov wrote:
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
-
> >>> As of Linux 5.18.0, module vc4 apparently isn't working on Raspberry Pi
> >>> 3B any more.
> >>>
> >>> If a monitor is attached to the device, the boot messages show up as
> >>> usual, but right when KMS starts, the screen turns black. Similarly, the
> >>> screen also turns black when the
Hi Javier
Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
From: Daniel Vetter
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
There is fb_client_register() to set up a 'client' on top of an fbdev.
The client would
> > > > > > As of Linux 5.18.0, module vc4 apparently isn't working on
> > > > > > Raspberry Pi
> > > > > > 3B any more.
> > > > > >
> > > > > > If a monitor is attached to the device, the boot messages show up as
> > > > > > usual, but right when KMS starts, the screen turns black.
> > > > > >
Conversion to use bulk regulator API omitted filling the pwr_regs with
proper regulator IDs. This was left unnoticed, since none of my testing
platforms has used the pwr_regs. Fix this by propagating regulator ids
properly.
Fixes: 31b3b1f5e352 ("drm/msm/hdmi: use bulk regulator API")
On 09/06/2022 04:22, cy_huang wrote:
> From: ChiYuan Huang
>
> Add 'richtek,bled-ocp-microamp' property to make it chooseable.
>
> The wrong backlight ocp level may affect the backlight channel output
> current smaller than configured.
>
> Signed-off-by: ChiYuan Huang
> ---
> Since v3:
> -
Hi Yunfei Dong,
On 5/26/22 11:57, Yunfei Dong wrote:
> Fix v4l2 capability bus_info value with correct chip name according to
> compatible.
>
> Signed-off-by: Yunfei Dong
> ---
> .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 23 ++-
> 1 file changed, 22 insertions(+), 1
1 - 100 of 153 matches
Mail list logo
