ux-arm-kernel/CAPY8ntBua=wpvuj+sm0wgcul0ft56ueho8yzutmb8z54x_a...@mail.gmail.com/T/
[3] https://lore.kernel.org/lkml/cover.1706948717.git.andrea.po...@suse.com/T/
[4]
https://lore.kernel.org/linux-iommu/20220610080802.11147-1-sergey.se...@baikalelectronics.ru/
Dave Stevenson (7):
ARM: dts: bcm283x:
The code handling DMA mapping is currently incorrect and
needs a sequence of fixups.
Move the mapping out into a separate function and structure
to allow for those fixes to be applied more cleanly.
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 46
From: Phil Elwell
Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
sound/soc/bcm/bcm2835-i2s.c | 18 --
1
In order to use the dma_map_resource for mappings, add the
dma-ranges to the relevant DT files.
Signed-off-by: Dave Stevenson
---
arch/arm/boot/dts/broadcom/bcm2711.dtsi | 12 ++--
arch/arm/boot/dts/broadcom/bcm2835.dtsi | 3 ++-
arch/arm/boot/dts/broadcom/bcm2836.dtsi | 3 ++-
arch
From: Phil Elwell
Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
drivers/mmc/host/bcm2835.c | 17 +++--
1
Now that all DMA clients are passing in CPU addresses, drop
the workaround that would accept those and not try mapping
them.
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma
bcm2835-dma has been (incorrectly) expecting dma addresses to be
passed in, not CPU physical addresses.
In order to fix this up, add temporary handling of clients still
passing in dma addresses until they are fixed up.
This will be reverted once all clients have been fixed.
Signed-off-by: Dave
.
The "ranges" property has always been defined correctly, so
abuse that in the event that dma-ranges are missing.
There appears to be no easy route to access "ranges", so
duplicate the functions for handling "dma-ranges" here to
keep the hack contained.
Signed-off-by
There is a need to account for dma-ranges and iommus in the
dma mapping process, and the public API for handling that is
dma_map_resource.
Add support for mapping addresses to the DMA driver.
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 46
-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index 9d74fe97452e..528c4593b45a 100644
--- a/drivers/dma/bcm2835-dma.c
From: Phil Elwell
Slave addresses for DMA are meant to be supplied as physical addresses
(contrary to what struct snd_dmaengine_dai_dma_data does).
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ---
1 file changed, 4 insertions
From: Phil Elwell
Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.
Signed-off-by: Phil Elwell
Signed-off-by: Dave Stevenson
---
drivers/spi/spi-bcm2835.c | 23
From: Stefan Wahren
In preparation to support more platforms pass the dma_chan to the
generic functions. This provides access to the DMA device and possible
platform specific data.
Signed-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 24
From: Stefan Wahren
The parameters info and finalextrainfo are platform specific. So drop
them by generating them within bcm2835_dma_create_cb_chain().
Signed-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 83 +++
1
-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index ef452ebb3c15..d6c5a2762a46 100644
--- a/drivers/dma/bcm
From: Stefan Wahren
Similar to the info generation, generate the final extra info with a
separate function. This is necessary to introduce other platforms
with different info bits.
Signed-off-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 34
-by: Stefan Wahren
Signed-off-by: Dave Stevenson
---
drivers/dma/bcm2835-dma.c | 50 +--
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index 528c4593b45a..7cef7ff89575 100644
--- a/drivers/dma
fic bus address from the passed memory resource for the case
of the directly mapped DMA.
Fixes: 25f1e1887088 ("dma: Take into account dma_pfn_offset")
Signed-off-by: Serge Semin
Signed-off-by: Dave Stevenson
---
kernel/dma/direct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Now the driver looks for the common dma-channel-mask property
rather than the vendor-specific brcm,dma-channel-mask, update
the dt files to follow suit.
Signed-off-by: Dave Stevenson
---
arch/arm/boot/dts/broadcom/bcm2711.dtsi| 2 +-
arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 2
> On Fri, 16 Feb 2024 18:48:55 +
> > > Dave Stevenson wrote:
> > >
> > > > From: Nick Hollinghurst
> > > >
> > > > Add this as a value for enum_drm_connector_tv_mode, represented
> > > > by the string "Mono",
Hi Maxime
On Tue, 20 Feb 2024 at 16:10, Maxime Ripard wrote:
>
> The EDID firmware loading mechanism introduced a few built-in EDIDs that
> could be forced on any connector, bypassing the EDIDs it exposes.
>
> While convenient, this limited set of EDIDs doesn't take into account
> the connector
All the handling for the properties was present, but they
were never attached to the connector to allow userspace
to change them.
Add them to the connector.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_vec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vc4
The VEC supports not producing colour bursts for monochrome output.
It also has an option for disabling the chroma input to remove
chroma from the signal.
Now that there is a DRM_MODE_TV_MODE_MONOCHROME defined, plumb
this in.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_vec.c
ew tv_mode value
which comprises both 525-line and 625-line formats.
Signed-off-by: Nick Hollinghurst
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/drm_connector.c| 7 +++
drivers/gpu/drm/drm_modes.c| 5 -
drivers/gpu/drm/drm_probe_helper.c | 5 +++--
include/drm/drm_c
-line and the French
819-line mono modes as well.
If "TV mode" does dictate the timing as well as the colour encoding, then we
need to add PAL-60, and 2 modes for mono (extending to 4 for 405 and 819 line
modes later). If not, we ought to update the description.
Thoughts?
Thanks
D
Hi Maxime
On Thu, 1 Feb 2024 at 12:51, Maxime Ripard wrote:
>
> On Thu, Dec 14, 2023 at 03:10:43PM +, Dave Stevenson wrote:
> > > +static bool
> > > +sink_supports_format_bpc(const struct drm_connector *connector,
> > > +co
Hi Joerg
On Fri, 26 Jan 2024 at 10:45, Albert, Joerg (TT-U)
wrote:
> Hi,
>
>
>
> I’m pretty new to DRM/DRI and wonder if there is a way to have a stable
> identification of connectors across changes in the Linux kernel and/or in
> the devicetree?
>
>
>
> Our hardware contains an iMX8QM with two
Hi Maxime
On Fri, 12 Jan 2024 at 13:59, Maxime Ripard wrote:
>
> Hi Dave,
>
> On Thu, Dec 14, 2023 at 02:43:37PM +, Dave Stevenson wrote:
> > On Thu, 7 Dec 2023 at 15:50, Maxime Ripard wrote:
> > >
> > > The i915 driver has a property to force the RGB ra
Hi
On Tue, 9 Jan 2024 at 11:19, wrote:
>
> Hi,
>
> On 09/01/2024 08:09, Shengyang Chen wrote:
> > This patchset adds waveshare 7inch touchscreen panel support
> > for the StarFive JH7110 SoC.
>
> Could you precise which SKU you're referring to ? is it 19885 =>
>
On Wed, 3 Jan 2024 at 14:02, Dave Stevenson
wrote:
>
> Hi Maxime
>
> On Wed, 3 Jan 2024 at 13:33, Maxime Ripard wrote:
> >
> > Hi Dave,
> >
> > Happy new year :)
>
> And to you.
>
> > On Tue, Jan 02, 2024 at 03:12:26PM +, Dave Stevenson wro
Hi Maxime
On Wed, 3 Jan 2024 at 13:33, Maxime Ripard wrote:
>
> Hi Dave,
>
> Happy new year :)
And to you.
> On Tue, Jan 02, 2024 at 03:12:26PM +, Dave Stevenson wrote:
> > Hi Maxime
> >
> > On Mon, 14 Nov 2022 at 13:00, Maxime Ripard wrote:
>
Hi Maxime
On Mon, 14 Nov 2022 at 13:00, Maxime Ripard wrote:
>
> The current construction of the named mode parsing doesn't allow to extend
> it easily. Let's move it to a separate function so we can add more
> parameters and modes.
>
> In order for the tests to still pass, some extra checks are
On Tue, 2 Jan 2024 at 10:03, Maxime Ripard wrote:
>
> Hi,
>
> On Wed, Dec 27, 2023 at 04:19:19PM +0100, AL13N wrote:
> > I have a RPI4B with upstream kernel 6.1 64bit and there is no /dev/video10
> > present. I thought if I waited a bit more, it would appear in the kernel,
> > but that was folly
Hi Maxime
On Thu, 7 Dec 2023 at 15:50, Maxime Ripard wrote:
>
> Now that we have all the infrastructure needed, we can add some code
> that will, for a given connector state and mode, compute the best output
> format and bpc.
>
> The algorithm is the same one than the one already found in i915
MDS character rate is reachable for them or not.
>
> This will then be useful to figure out the best format and bpc count for
> a given mode.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 9 +++
> drivers/gpu/drm
we need to repeat pixels or not, the bpc count and the format, we can
> now derive it from the HDMI connector state that stores all those infos
> and remove the duplication from drivers.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/drm_
ORSPACE_YUV422 && bpc != 12)
> + return 0;
> +
> + if (fmt == HDMI_COLORSPACE_YUV420)
> + clock = clock / 2;
> +
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> + clock = clock * 2;
> +
> + if (fmt == HDM
On Thu, 7 Dec 2023 at 15:50, Maxime Ripard wrote:
>
> Just like BPC, we'll add support for automatic selection of the output
> format for HDMI connectors.
>
> Let's add the needed defaults and fields for now.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
On Thu, 7 Dec 2023 at 15:50, Maxime Ripard wrote:
>
> We'll add automatic selection of the output BPC in a following patch,
> but let's add it to the HDMI connector state already.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers
t we're also adding unit tests wouldn't be amiss.
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/drm_atomic.c | 4 +-
> drivers/gpu/drm/drm_atomic_state_helper.c | 44 +++
> .../gpu/drm/tests/drm_atomic_
ave such a significant proportion of the patch being kunit tests
when there was no reference to such in the commit text was slightly
unexpected.
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> Documentation/gpu/kms-properties.csv | 1 -
> drivers/gpu
o HDMI controllers,
> that will eventually store everything we need.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 35
> +++
> include/drm/drm_atomic_state_helper.h | 4
> incl
drm_connector_state structures, which will allow to
> abstract away the duplicated logic. This infrastructure comes with a few
> requirements though, and thus we need a new initialization function.
>
> Hopefully, this will make drivers simpler to handle, and their behaviour
> more c
of
> our state so the pointers are probably equal in all relevant cases, but
> it's still fragile so let's fix this properly.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +++-
> 1 file changed, 11 inse
Hi Keith
On Wed, 6 Dec 2023 at 08:55, Keith Zhao wrote:
>
>
>
> On 2023/11/25 0:04, Dave Stevenson wrote:
> > On Fri, 24 Nov 2023 at 15:00, Stefan Wahren wrote:
> >>
> >> Hi Shengyang,
> >>
> >> [fix address of Emma]
> >
> > No
Hi Dario
On Tue, 5 Dec 2023 at 10:54, Dario Binacchi
wrote:
>
> The patch fixes the code for finding the next bridge with the
> "pre_enable_prev_first" flag set to false. In case this condition is
> not verified, i. e. there is no subsequent bridge with the flag set to
> false, the whole bridge
On Fri, 24 Nov 2023 at 15:00, Stefan Wahren wrote:
>
> Hi Shengyang,
>
> [fix address of Emma]
Not merged to master yet, but Emma has stepped back from maintenance.
https://lists.freedesktop.org/archives/dri-devel/2023-October/428829.html
Dropped from the cc.
> Am 24.11.23 um 11:44 schrieb
Hi Simon
On Thu, 9 Nov 2023 at 17:46, Simon Ser wrote:
>
> On Thursday, November 9th, 2023 at 16:42, Dave Stevenson
> wrote:
>
> > > > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > > > not precise enough. Som
Hi Simon and Maxime
On Thu, 9 Nov 2023 at 09:12, Maxime Ripard wrote:
>
> Hi Simon,
>
> On Thu, Nov 09, 2023 at 07:45:58AM +, Simon Ser wrote:
> > User-space sometimes needs to allocate scanout-capable memory for
> > GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> > is
Hi Dario
Thanks for the patch.
On Mon, 23 Oct 2023 at 09:59, Dario Binacchi
wrote:
>
> Replace 'pack' with 'back'.
>
> Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
> Signed-off-by: Dario Binacchi
Reviewed-by: Dave Stevenson
> ---
>
>
Hi Thomas
Thanks for the response.
On Thu, 12 Oct 2023 at 08:03, Thomas Zimmermann wrote:
>
> Hi Dave
>
> Am 11.10.23 um 17:52 schrieb Dave Stevenson:
> > Hi Thomas (and everyone else)
> >
> > Maxime has suggested you're the person for DRM framebuffer emula
Hi Thomas (and everyone else)
Maxime has suggested you're the person for DRM framebuffer emulation.
I'm getting some unexpected behaviour when there are multiple DRM
drivers in play. In this case it happens to be vc4 and the tiny
hx8357d SPI display driver, but this affects most of the tiny DRM
Hi Neil
On Mon, 28 Aug 2023 at 09:49, wrote:
>
> Hi Jessica,
>
> On 25/08/2023 20:37, Jessica Zhang wrote:
> >
> >
> > On 8/21/2023 3:01 AM, neil.armstr...@linaro.org wrote:
> >> Hi Maxime,
> >>
> >> On 21/08/2023 10:17, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> On Fri, Aug 18, 2023 at
Hi Marek & Mimoja
On Sat, 26 Aug 2023 at 22:02, Marek Vasut wrote:
>
> On 8/26/23 20:33, Mimoja wrote:
>
> Hi,
>
> +CC Dave , he might be able to help with the last part.
>
> > I appreciate you taking the time to respond!
> >
> > On 26.08.23 17:18, Marek Vasut wrote:
> >> On 8/26/23 11:55,
Hi Dmitry
On Fri, 18 Aug 2023 at 11:27, Dmitry Baryshkov
wrote:
>
> On 18/08/2023 11:25, neil.armstr...@linaro.org wrote:
> > Hi Dmitry,
> >
> > On 17/08/2023 20:35, Dmitry Baryshkov wrote:
> >> On 16/08/2023 10:51, neil.armstr...@linaro.org wrote:
> >>> Hi Abhinav,
> >>>
> >>> On 14/08/2023
Hi Maxime
On Mon, 14 Aug 2023 at 14:56, Maxime Ripard wrote:
>
> Infoframes in KMS is usually handled by a bunch of low-level helpers
> that require quite some boilerplate for drivers. This leads to
> discrepancies with how drivers generate them, and which are actually
> sent.
>
> Now that we
On Wed, 2 Aug 2023 at 18:26, Chris Morgan wrote:
>
> * Spam *
> On Mon, Jul 31, 2023 at 07:03:07PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Jul 31, 2023 at 11:33:22AM -0500, Chris Morgan wrote:
> > > In my case a few different panel drivers disable the regulators in the
> > >
bridge init order with an example on the
> bridge operations helpers.
>
> Signed-off-by: Jagan Teki
Reviewed-by: Dave Stevenson
> ---
> Changes for v2:
> - add missing dri-devel in CC
> - prefix @ for bridge helper names
>
> drivers/gpu/drm/drm_bridge.c | 14 ++
>
dge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1,
> > Panel.
> >
> > This patch fixes this by assigning next with previou bridge only if the
> > bridge doesn't enable pre_enable_prev_first flag and the next further
> > assign it to limit. This way we can find the bridge th
Hi Frieder
On Mon, 10 Jul 2023 at 08:46, Frieder Schrempf
wrote:
>
> On 07.07.23 21:00, Vladimir Lypak wrote:
> > [Sie erhalten nicht häufig E-Mails von vladimir.ly...@gmail.com. Weitere
> > Informationen, warum dies wichtig ist, finden Sie unter
> >
Hi Paulo
On Tue, 16 May 2023 at 14:09, Paulo Pavačić wrote:
>
> Add dt-bindings documentation for panel-mipi-dsi-bringup which currently
> supports fannal,c3004 panel. Also added fannal to vendor-prefixes.
>
> v2 changelog:
> - revised driver title, now describes purpose
> - revised
returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Thanks for the patch - looks good.
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/g
Hi Mark (and Dmitry)
On Fri, 21 Apr 2023 at 18:07, Dmitry Baryshkov
wrote:
>
> On 21/04/2023 19:27, Mark Yacoub wrote:
> > From: Mark Yacoub
>
> Nit: is there a reason for this header? My first impression is that it
> matches your outgoing name & email address and as such is not necessary.
>
>
Hi Jagan
On Thu, 30 Mar 2023 at 07:56, Jagan Teki wrote:
>
> On Wed, Mar 29, 2023 at 10:16 PM Maxime Ripard wrote:
> >
> > On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote:
> > > On Wed, 29 Mar 2023 at 14:19, Jagan Teki
> > > wrote:
> &
Hi Maxime
On Wed, 29 Mar 2023 at 17:46, Maxime Ripard wrote:
>
> On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote:
> > On Wed, 29 Mar 2023 at 14:19, Jagan Teki wrote:
> > >
> > > DSI sink devices typically send the MIPI-DCS commands to the DSI host
Hi Jagan
On Wed, 29 Mar 2023 at 14:19, Jagan Teki wrote:
>
> DSI sink devices typically send the MIPI-DCS commands to the DSI host
> via general MIPI_DSI_DCS read and write API.
>
> The classical DSI sequence mentioned that the DSI host receives MIPI-DCS
> commands from the DSI sink first in
On Fri, 10 Mar 2023 at 12:59, AL13N wrote:
>
>
> I donno if this is related or not, but since 6.1 has v3d, i'm assuming
> the opengl compositor will be faster and not draw too much cpu?
>
> I did try youtube video, but that on 1080p fullscreen, takes all the CPU
> and seems to have dropped frames
On Fri, 10 Mar 2023 at 09:10, AL13N wrote:
>
> Dave Stevenson schreef op 2023-03-09 13:59:
> > On Wed, 8 Mar 2023 at 22:46, AL13N wrote:
> >>
> >> AL13N schreef op 2023-03-08 22:16:
> >> > Maxime Ripard schreef op 2023-03-08 13:35:
> >> >&g
On Wed, 8 Mar 2023 at 22:46, AL13N wrote:
>
> AL13N schreef op 2023-03-08 22:16:
> > Maxime Ripard schreef op 2023-03-08 13:35:
> >> Hi,
> >>
> >> On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
> >>> On Tue, 7 Mar 2023 at 16:25
On Thu, 9 Mar 2023 at 11:26, AL13N wrote:
>
> Dave Stevenson schreef op 2023-03-07 18:10:
> > Hi Maarten
> >
> > On Tue, 7 Mar 2023 at 16:25, AL13N wrote:
> >>
> >> AL13N schreef op 2023-03-06 17:34:
> >> > Hi,
> >> >
> >
Hi Maarten
On Tue, 7 Mar 2023 at 16:25, AL13N wrote:
>
> AL13N schreef op 2023-03-06 17:34:
> > Hi,
> >
> > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
> > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
> > plymouth), the cause of no X is that EDID gives
On Tue, 28 Feb 2023 at 11:45, Ville Syrjälä
wrote:
>
> On Tue, Feb 28, 2023 at 11:37:38AM +, Dave Stevenson wrote:
> > Hi Pekka
> >
> > On Tue, 28 Feb 2023 at 10:12, Pekka Paalanen wrote:
> > >
> > > On Tue, 28 Feb 2023 09:53:47 +
> &
Hi Pekka
On Tue, 28 Feb 2023 at 10:12, Pekka Paalanen wrote:
>
> On Tue, 28 Feb 2023 09:53:47 +
> Simon Ser wrote:
>
> > On Tuesday, February 28th, 2023 at 09:46, Pekka Paalanen
> > wrote:
> >
> > > can these be negative as well, to achieve overscan and not just
> > > underscan? Did I get
is certainly matches my understanding of the properties. Thanks.
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/drm_connector.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_c
On Mon, 20 Feb 2023 at 15:57, Simon Ser wrote:
>
> On Monday, February 20th, 2023 at 16:49, Dave Stevenson
> wrote:
>
> > > + * User-space sets _prime_handle.fd with a DMA-BUF file descriptor to
> > > + * import, and gets back a GEM handle in _prime_handle.handle.
Hi Simon
On Thu, 16 Feb 2023 at 13:09, Simon Ser wrote:
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> ---
> include/uapi/drm/drm.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/include/uapi/drm/drm.h
Hi Hans
On Sat, 18 Feb 2023 at 11:33, Hans Verkuil wrote:
>
> Hi Maxime, Dave,
>
> On 26/01/2023 14:46, Maxime Ripard wrote:
> > From: Dave Stevenson
> >
> > Copy Intel's "Broadcast RGB" property semantics to add manual override
> > of the
his flag does mean that the DSI host doesn't need to
power up and down for each host_transfer request from
tc358762_pre_enable/tc358762_init, so on that basis I'm good with it.
Reviewed-by: Dave Stevenson
> Cc: Dave Stevenson
> Cc: Dmitry Baryshkov
> Cc: Abhinav Kumar
> Signed-off-b
Hi Jagan
On Fri, 20 Jan 2023 at 19:10, Jagan Teki wrote:
>
> Hi Dave,
>
> On Sat, Jan 21, 2023 at 12:26 AM Dave Stevenson
> wrote:
> >
> > Hi Jagan
> >
> > Responding due to Marek's comment on the "Add Samsung MIPI DSIM
> > bridge&quo
series.
>
> Hm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .
>
> Can you send a subsequent patch to convert the DSIM_* m
Hi Jagan
Responding due to Marek's comment on the "Add Samsung MIPI DSIM
bridge" series, although I know very little about the Exynos
specifics, and may well be missing context of what you're trying to
achieve.
On Mon, 12 Dec 2022 at 18:29, Jagan Teki wrote:
>
> Restore the proper bridge chain
Hi Stephen
On Fri, 13 Jan 2023 at 21:12, Stephen Boyd wrote:
>
> Quoting Dave Stevenson (2023-01-13 08:27:29)
> > Hi Stephen
> >
> > On Fri, 6 Jan 2023 at 03:01, Stephen Boyd wrote:
> > >
> > > The unprepare sequence has started to fail after moving
Hi Stephen
On Fri, 6 Jan 2023 at 03:01, Stephen Boyd wrote:
>
> The unprepare sequence has started to fail after moving to panel bridge
> code in the msm drm driver (commit 007ac0262b0d ("drm/msm/dsi: switch to
> DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs:
>
>
Hi Thomas
Thanks for the review
On Wed, 11 Jan 2023 at 15:03, Thomas Zimmermann wrote:
>
> Hi
>
> Am 07.12.22 um 17:07 schrieb Maxime Ripard:
> > From: Dave Stevenson
> >
> > The CSC matrices were stored as separate matrix for each colorspace, and
> > if we
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hvs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 3582ede1a0aa..5fadbf219542 100644
> -
dd.
Fixes: 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel")
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/bridge/panel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 03c3274dc3d9.
Commit f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort
driver") added usage of the drm_bridge_chain_ functions which are
to be deprecated.
Replace with the drm_atomic_bridge_chain_ variants using the
current state.
Signed-off-by: Dave Stevenson
---
drivers/gpu/dr
-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Daniel Vetter
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/drm_bridge.c | 110
requested pre_enable_prev_first.
eg:
- Panel
- Bridge 1
- Bridge 2 pre_enable_prev_first
- Bridge 3
- Bridge 4 pre_enable_prev_first
- Bridge 5 pre_enable_prev_first
- Bridge 6
- Encoder
Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3,
Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder.
Signed-of
The exact behaviour of DSI host controllers is not specified,
therefore define it.
Signed-off-by: Dave Stevenson
Reviewed-by: Laurent Pinchart
---
Documentation/gpu/drm-kms-helpers.rst | 7 +
drivers/gpu/drm/drm_bridge.c | 39 +++
2 files changed, 46
Mapping to the drm_bridge flag pre_enable_prev_first,
add a new flag prepare_prev_first to drm_panel to allow
the panel driver to request that the upstream bridge should
be pre_enabled before the panel prepare.
Signed-off-by: Dave Stevenson
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm
state operations in drm_bridge_funcs (Laurent)
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Jitao Shi
Cc: Philip Chen
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Reviewed-by: Laurent Pinchart
Signed-off-by: Dave Stevenson
sn65dsi83
My branches are going to be out of date by now - sorry.
Dave Stevenson (4):
drm/mediatek: dp: Replace usage of drm_bridge_chain_ functions
drm/bridge: Introduce pre_enable_prev_first to alter bridge init order
drm/panel: Add prepare_prev_first flag to drm_panel
drm/bridge: Document t
Hi Frieder
On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
wrote:
>
> On 02.12.22 15:55, Dave Stevenson wrote:
> > Hi Marek
> >
> > On Fri, 2 Dec 2022 at 12:21, Marek Vasut wrote:
> >>
> >> On 12/2/22 11:52, Marek Szyprowski wrote:
> >>> Hi,
&
Hi Marek
On Fri, 2 Dec 2022 at 12:21, Marek Vasut wrote:
>
> On 12/2/22 11:52, Marek Szyprowski wrote:
> > Hi,
> >
> > Sorry for delay, I was on a sick leave last 2 weeks.
> >
> > On 28.11.2022 15:43, Jagan Teki wrote:
> >> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut wrote:
> >>> On 11/23/22
Pinchart
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/bridge/parade-ps8640.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index f74090a9cc9e..4b361d7d5e44 100644
The exact behaviour of DSI host controllers is not specified,
therefore define it.
Signed-off-by: Dave Stevenson
Reviewed-by: Laurent Pinchart
---
Documentation/gpu/drm-kms-helpers.rst | 7 +
drivers/gpu/drm/drm_bridge.c | 39 +++
2 files changed, 46
Mapping to the drm_bridge flag pre_enable_prev_first,
add a new flag prepare_prev_first to drm_panel to allow
the panel driver to request that the upstream bridge should
be pre_enabled before the panel prepare.
Signed-off-by: Dave Stevenson
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm
-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Daniel Vetter
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/drm_bridge.c | 110
requested pre_enable_prev_first.
eg:
- Panel
- Bridge 1
- Bridge 2 pre_enable_prev_first
- Bridge 3
- Bridge 4 pre_enable_prev_first
- Bridge 5 pre_enable_prev_first
- Bridge 6
- Encoder
Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3,
Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder.
Signed-of
1 - 100 of 381 matches
Mail list logo
