ports with two
distinct audio cards. This is reflected in their names, making them
different from previous RPi versions. With this, ALSA ultimately misses
the board's configuration on RPi4.
In order to avoid this, set "card->driver_name" to "vc4-hdmi"
unanimously.
S
rrors by returning EPROBE_DEFER in this situation.
>
> Signed-off-by: Stefan Wahren
> ---
Seems reasonable to me:
Tested-by: Nicolas Saenz Julienne
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
On Wed, 2021-01-13 at 20:08 +0100, Stefan Wahren wrote:
> This converts the v3d bindings to yaml format.
>
> Signed-off-by: Stefan Wahren
> ---
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
>
> Changes in V4:
> - define order for required reg-names
> - adapt
Hi Stefan, Maxime,
On Mon, 2021-01-18 at 12:28 +0100, Stefan Wahren wrote:
> Hi,
>
> Am 15.01.21 um 19:39 schrieb Mark Brown:
> > On Fri, Jan 15, 2021 at 07:14:37PM +0100, Maxime Ripard wrote:
> > > On Wed, Jan 13, 2021 at 11:42:23AM +, Mark Brown wrote:
> > > > On Wed, Jan 13, 2021 at 10:19:
Hi,
On Mon, 2021-01-11 at 15:22 +0100, Maxime Ripard wrote:
> Hi,
>
> Here's a series introducing the CEC support for the BCM2711 found on the
> RaspberryPi4.
>
> The BCM2711 HDMI controller uses a similar layout for the CEC registers, the
> main difference being that the interrupt handling part
On Mon, 2021-01-11 at 15:23 +0100, Maxime Ripard wrote:
> The CEC and hotplug interrupts go through an interrupt controller shared
> between the two HDMI controllers.
>
> Let's add that interrupt controller and the interrupts for both HDMI
> controllers
>
> Reviewed-by: Florian Fainelli
> Signed
ome cases as it applies to all entries. 'contains' is the correct schema
> to use in the case of multiple entries.
>
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: Eric Anholt
> Cc: Nicolas Saenz Julienne
> Cc: F
gular operation with V3D on BCM2711 (Raspberry
Pi 4), get rid of the PM code. PM will be reinstated once we figure out
the underlying issues.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +-
drivers/gpu/drm/v3d/v3d_drv.c | 11 ---
Add compatible string and Kconfig options for bcm2711.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/Kconfig | 2 +-
drivers/gpu/drm/v3d/v3d_drv.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
really
provide an exact explanation on what changed HW wise.
Ultimately, I need confirmation from the Broadcom folks that they are alright
with patch #7.
With all this, I get a more or less stable experience using mesa 20.3.4 and
X11/Gnome.
Regards,
Nicolas
---
Nicolas Saenz Julienne (11)
ges since v1:
- Use 'reg-names'
- Correct ASB names
- Add missing binding patch for V3D
- Address Stefan's comments
Nicolas Saenz Julienne (16):
dt-bindings: soc: bcm: bcm2835-pm: Convert bindings to DT schema
dt-bindings: soc: bcm: bcm2835-pm: Introduce reg-names
dt-binding
BCM2711, Raspberry Pi 4's SoC, contains a V3D core. So add its specific
compatible to the bindings.
Signed-off-by: Nicolas Saenz Julienne
---
Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu
Add compatible string and Kconfig options for bcm2711.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/Kconfig | 2 +-
drivers/gpu/drm/v3d/v3d_drv.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
regular operation with V3D on BCM2711 (Raspberry
Pi 4), get rid of the PM code. PM will be reinstated once we figure out
the underlying issues.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +-
drivers/gpu/drm/v3d/v3d_drv.c | 11 ---
On Wed, 2021-02-10 at 10:49 -0800, Florian Fainelli wrote:
> On 2/10/21 7:49 AM, Dave Stevenson wrote:
> > Hi Marc.
> >
> > On Wed, 10 Feb 2021 at 15:30, Marc Zyngier wrote:
> > >
> > > Hi Maxime,
> > >
> > > On 2021-02-10 14:40, Maxime Ripard wrote:
> > > > Hi Dave,
> > > >
> > > > On Tue, Fe
hich will mean that HDMI I2C will be
> polled, like it was before.
>
> Reported-by: Dave Stevenson
> Signed-off-by: Florian Fainelli
Acked-by: Nicolas Saenz Julienne
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
__
e or less stable experience using mesa 20.3.4 and
X11/Gnome.
Regards,
Nicolas
---
Changes since v2:
- Correct ASB names
- Address dt-binding comments
Changes since v1:
- Use 'reg-names'
- Correct ASB names
- Add missing binding patch for V3D
- Address Stefan's comments
Nico
BCM2711, Raspberry Pi 4's SoC, contains a V3D core. So add its specific
compatible to the bindings.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Document
regular operation with V3D on BCM2711 (Raspberry
Pi 4), get rid of the PM code. PM will be reinstated once we figure out
the underlying issues.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +-
drivers/gpu/drm/v3d/v3d_drv.c | 11 ---
Add compatible string and Kconfig options for bcm2711.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/Kconfig | 2 +-
drivers/gpu/drm/v3d/v3d_drv.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
On Thu, 2020-12-03 at 14:25 +0100, Maxime Ripard wrote:
> That pointer isn't used anywhere, so there's no point in keeping it.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Nicolas Saenz Julienne
> drivers/gpu/drm/vc4/vc4_drv.h | 1 -
> drivers/gpu/drm/vc4/
ned-off-by: Maxime Ripard
>
> Wouldn't this deserve a "Fixes: ..." and "Cc: sta...@vger.kernel.org"
> tag, as this bug is present in all stable releases since this driver was
> introduced? I think it would be really helpful to have it backported.
Agree, this would be nice
such case.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 04936cd6db8c..32da45821d3a 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
> crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
> maneuvers.
>
> Signed-off-by: Maxime Ripard
>
> ---
>
> Changes from v1:
> - Changed the
d complaint
> when we do that kind of access.
>
> Let's make sure we have the HDMI controller properly powered while
> disabling it.
>
> Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time")
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Nicolas Saenz Julienne
Tested-by: Nicolas Saenz Julienne
Regards,
Nicolas
off-by: Arnd Bergmann
> ---
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
Hi Maxime,
On Wed, 2021-11-17 at 15:50 +0100, Maxime Ripard wrote:
> Hi,
>
> The VC4 driver has had limited support to disable the HDMI controllers and
> pixelvalves at boot if the firmware has enabled them.
>
> However, this proved to be limited, and a bit unreliable so a new firmware
> command
Hi Maxime,
On Fri, 2021-12-03 at 14:51 +0100, Maxime Ripard wrote:
> Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
> been made, simplefb has been unregistered and the KMS driver is entirely
> in charge of the display.
>
> Thus, we can notify the firmware it can free whateve
On Thu, 2020-12-03 at 14:25 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> Updates the compatible string for DSI1 on BCM2711 to
> differentiate it from BCM2835.
>
> Signed-off-by: Dave Stevenson
> Signed-off-by: Maxime Ripard
> ---
Applied for-next,
Thanks!
signature.asc
Descripti
>
> Signed-off-by: Phil Elwell
> Signed-off-by: Stefan Wahren
> ---
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@
and writing the
> result back. There are some important control bits in that register,
> including MMU_ENABLE, so a safer approach is to simply write back the
> value just read unaltered.
>
> Signed-off-by: Phil Elwell
> Signed-off-by: Stefan Wahren
> ---
Reviewed-by: Nicol
@Maxime it seems you forgot to CC me on the series :)
On Mon, 2021-01-11 at 08:54 -0800, Florian Fainelli wrote:
>
> On 1/11/2021 6:22 AM, Maxime Ripard wrote:
> > The BCM2711 has a number of instances of interrupt controllers handled
> > by the driver behind the BRCMSTB_L2_IRQ Kconfig option (ir
This patch exposes backlight control into userspace by creating a
backlight device instead of directly accessing the PWM registers.
The backlight driver can't go on a separate file as it shares the I2C
bus & address with the panel.
Signed-off-by: Nicolas Saenz Julienne
---
v1 ->
On Thu, 2018-12-20 at 18:36 +, Gordon Hollingworth wrote:
> Assuming this is using the firmware interface then yes it's fine. If
> it is using the i2c directly then it's possible to clash with the GPU
> driving the camera
Well we're already in such a situation without this patch, as the panel
On Wed, 2019-07-10 at 16:31 +0800, Phil Reid wrote:
> G'day Nishad,
>
> I'm just wondering if the commit
> c440eee1a7a1d0f "Staging: fbtft: Switch to the gpio descriptor interface"
> was tested on anything.
>
> I've had to apply the following patch to get my display functioning again.
>
> in par
On Wed, 2019-07-10 at 17:27 +0800, Phil Reid wrote:
> On 10/07/2019 17:05, Nicolas Saenz Julienne wrote:
> > On Wed, 2019-07-10 at 16:31 +0800, Phil Reid wrote:
> > > G'day Nishad,
> > >
> > > I'm just wondering if the commit
> > > c440eee
We actually want to set the gpio pin if it's avilable, not the other way
around.
Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface")
Signed-off-by: Nicolas Saenz Julienne
---
drivers/staging/fbtft/fbtft-bus.c | 2 +-
1 file changed, 1 insertion
ptor
> Staging: fbtft: Fix reset assertion when using gpio descriptor
>
> drivers/staging/fbtft/fbtft-core.c | 43 ++---
> -
> 1 file changed, 20 insertions(+), 23 deletions(-)
>
You can add my:
Reviewed-by: Nicolas Saenz Julienne
Tested-by:
this version is indeed more complete.
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ace")
> > Tested-by: Jan Sebastian Götte
> > Reviewed-by: Nicolas Saenz Julienne
> > Signed-off-by: Jan Sebastian Götte
> > ---
>
> Can this go on top of Phil's patches? Or does it replace it?
This is needed on to
as the
> driver's PM ops were not hooked-up.
>
> So, in order to support regular operation with V3D on BCM2711 (Raspberry
> Pi 4), get rid of the PM code. PM will be reinstated once we figure out
> the underlying issues.
>
> Signed-off-by: Nicolas Saenz Julienne
> Si
Hi Peter,
On Wed, 2019-12-18 at 08:43 +, Peter Robinson wrote:
> On arm64 the config ARCH_BCM doesn't exist so to be able to
> build for platforms such as the Raspberry Pi 4 we need to add
> ARCH_BCM2835 similar to what has been done on vc4.
>
> Signed-off-by: Peter Robinson
> ---
v3d's ups
Hi Florian,
On Wed, 2019-12-18 at 09:39 -0800, Florian Fainelli wrote:
> On 12/18/19 6:39 AM, Nicolas Saenz Julienne wrote:
> > Hi Peter,
> >
> > On Wed, 2019-12-18 at 08:43 +, Peter Robinson wrote:
> > > On arm64 the config ARCH_BCM doesn't exist so to b
On Mon, 2019-10-14 at 16:28 +0800, Shawn Guo wrote:
> On Tue, Sep 24, 2019 at 08:12:38PM +0200, Nicolas Saenz Julienne wrote:
> > qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
> > which acts a bus in this regard. So far it maked all devices as
> &g
Hi Maxime,
On Tue, 2020-02-25 at 10:54 +0100, Maxime Ripard wrote:
> Hi Stefan,
>
> On Mon, Feb 24, 2020 at 08:25:46PM +0100, Stefan Wahren wrote:
> > Hi Maxime,
> >
> > Am 24.02.20 um 10:06 schrieb Maxime Ripard:
> > > The driver has really only supported one clock so far and has hardcoded
> >
Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote:
> Instead of declaring the clk_init_data and then calling memset on it, just
> initialise properly.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
> ---
structure so that we can support more clocks later on.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This is
linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.fre
; to make sure it happens.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This is a digitally signed message part
_
h the other function names, and drop the fw from the
> function name.
It seems you didn't :)
As it does use the fw interface I'd say keep it in the name, with that:
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linu
he future, let's decouple the clock data from
> the provider data.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Desc
Hi Maxime,
On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote:
> The current firmware clock driver for the RaspberryPi can only be probed by
> manually registering an associated platform_device.
>
> While this works fine for cpufreq where the device gets attached a clkdev
> lookup, it would b
an simply call
> clk_hw_register with a static clk_fixed_factor structure.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This is
ael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Signed-off-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing
use its managed variant
> to take care of that for us.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This i
bal pointer from the structure.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
Acked-by: Nicolas Saenz Julienne
Thanks!
Nicolas
signature.asc
Description: This is a digitally signed message part
__
On Wed, 2020-02-26 at 15:26 +0100, Maxime Ripard wrote:
> Hi Nicolas,
>
> On Tue, Feb 25, 2020 at 05:13:33PM +0100, Nicolas Saenz Julienne wrote:
> > On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote:
> > > The pllb_arm clk_hw pointer in the raspberry_clk structure i
Hi Maxime,
On Wed, 2020-02-26 at 16:01 +0100, Maxime Ripard wrote:
[...]
> This was actually a shameless bait to start that discussion, so I'm
> glad it worked ;)
:)
[...]
> > - Some of those fw managed clocks you're creating have their mmio
> > counterpart
> > being registered by clk-bcm23
Hi Maxime,
On Mon, 2020-02-24 at 10:07 +0100, Maxime Ripard wrote:
> @@ -1460,6 +1456,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> }
>
> struct vc4_hdmi_variant bcm2835_variant = {
> + .max_pixel_clock= 14850,
Just a reminder this might change in the cl
It's not longer advised to use notifiers in order to setup custom DMA
ops.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/device.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 267b509df517..018c52688546 100644
--- a/drive
around the new function.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 60 ++--
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 9c1e638fa8ea..c9eb4ebcc2e9 100644
--- a
The function provides the cell sizes for a specific bus type. Instead of
passing it the device DT node sitting on top of that bus we directly
pass its parent which is the actual node the function will start looking
from.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 18
The bus behind the board's PCIe core has DMA addressing limitations. Add
an empty 'dma-ranges' property on all PCIe bus descriptions to inform
the OF core that a translation is due further down the line.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/boot/dts/freescale/f
which takes the given DT node as the
device's underlying bus and parses it accordingly.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 2 +-
drivers/gpu/host1x/bus.c| 2 +-
drivers/of/device.c | 30 --
driver
case, and make code a little more
explicit, create of_dma_config_copy() which will take another device's
DT node as an argument and simplify of_dma_config() by removing one of
it's redundant arguments.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/base/platform.c
hacky usages that can be properly fixed as I show with the
DT fixes on the Layerscape platform.
This was also tested on a Raspberry Pi 4 with a custom PCIe driver and
on a Seattle AMD board.
Regards,
Nicolas
[1] https://patchwork.kernel.org/patch/9650345/#20294961
[2] https://patchwork.kernel.or
Some devices don't have their own OF node, and are stuck passing their
bus node. Adapt the function for this use case.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 33 +++--
drivers/of/device.c| 3 ++-
include/linux/of_addr
The function was only available locally to of/address.c, make it
available to the OF subsystem.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c| 18 --
drivers/of/base.c | 25 +
drivers/of/of_private.h | 2 ++
3 files changed
qoriq-mc's node in order for DT's DMA
configuration code to get the DMA constraints from it.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
lls_parent() in order to deal with this limitation.
For now, it'll only be available privately to OF code.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/base.c | 44 +
drivers/of/of_private.h | 3 +++
2 files changed, 34 insertions(+
'len' in of_dma_get_range() is used to check the 'dma-ranges' property
length. After the fact, some calculations are run on the variable to be
then left unused.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 5 ++---
1 file changed, 2 insertions(+), 3 dele
On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote:
> On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
> wrote:
> > Hi All,
> > this series tries to address one of the issues blocking us from
> > upstreaming Broadcom's STB PCIe controller[1]. Namely,
On Wed, 2019-09-25 at 16:09 +0100, Robin Murphy wrote:
> On 25/09/2019 15:52, Nicolas Saenz Julienne wrote:
> > On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote:
> > > On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
> > > wrote:
> > > > Hi All,
&
> > > > Robin, have you looked into supporting multiple dma-ranges? It's the
> > > > next thing
> > > > we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in
> > > > the
> > > > works already.
> > >
> > > Multiple dma-ranges as far as configuring inbound windows should work
> >
fifo,
> filling up the broken sample and maintaining alignment.
>
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
On Tue, 2021-05-25 at 15:23 +0200, Maxime Ripard wrote:
> From: Dom Cobley
>
> The hardware uses this for generating the right audio
> data island packets when using formats other than PCM
>
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by
ff-by: Dom Cobley
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
On Tue, 2021-05-25 at 15:23 +0200, Maxime Ripard wrote:
> From: Dom Cobley
>
> This was a workaround for bugs in hardware on earlier Pi models
> and wasn't totally successful.
What's to expect sound wise on older RPis?
Regards,
Nicolas
On Tue, 2021-05-25 at 15:23 +0200, Maxime Ripard wrote:
> The hdmi-codec brings a lot of advanced features, including the HDMI
> channel mapping. Let's use it in our driver instead of our own codec.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
On Tue, 2021-05-25 at 15:23 +0200, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard
Adding a commit message would've been nice. But I guess the patch is trivial
enough.
Other than that:
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
On Thu, 2021-05-20 at 17:03 +0200, Maxime Ripard wrote:
> From: Mateusz Kwiatkowski
>
> The BCM2711 has a slightly different VEC than the one found in the older
> SoCs. Now that we support the new variant, add its compatible to the
> device tree.
>
> Signed-off-by: Mateusz Kwiatkowski
> Signed-
On Sat, 2021-06-12 at 17:17 +0200, Stefan Wahren wrote:
> Hi,
>
> while testing the mainline kernel (arm64, defconfig) on Raspberry Pi 3 B
> Plus with Raspberry Pi OS - 64 bit, sometimes X doesn't start into
> desktop properly (unexpected and unusable login screen instead of auto
> login or mouse
Aside from being more correct, the non optional version of the function
prints an error when failing to find the IRQ.
Fixes: eea9b97b4504 ("drm/v3d: Add support for V3D v4.2")
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/v3d_irq.c | 2 +-
1 file changed, 1 inser
quot;Merge v5.4-rc7 into drm-next")
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/v3d_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 915f8bfdb58c..3cfbdb8e6a91 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.
On Thu, 2020-07-30 at 12:44 -0400, Jim Quinlan wrote:
> On Wed, Jul 29, 2020 at 10:28 AM Rob Herring wrote:
> > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig wrote:
> > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > > > I started using devm_kcalloc() but at least two revi
Hi Jim,
On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> static void __init of_unittest_pci_dma_ranges(void)
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-brcmstb.c
> index bfc2542d54a8..8dacb9d3b7b6 100644
> --- a/drivers/pci/controller/pcie-brcmstb
On Thu, 2020-07-30 at 13:25 -0400, Jim Quinlan wrote:
> On Thu, Jul 30, 2020 at 1:05 PM Nicolas Saenz Julienne
> wrote:
> > Hi Jim,
> >
> > On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > > static void __init of_unittest_pci_dma_ranges(void)
> >
Hi Maxime,
On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The firmware clocks driver was previously probed through a platform_device
> created by the firmware driver.
>
> Since we will now have a node for that clocks driver, we need to create the
> device only in the case where there's
On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The firmware clocks driver was previously probed through a platform_device
> created by the firmware driver.
>
> Since we will now have a node for that clocks driver, we need to create the
> device only in the case where there's no node for
On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The current firmware clock driver for the RaspberryPi can only be probed by
> manually registering an associated platform_device.
>
> While this works fine for cpufreq where the device gets attached a clkdev
> lookup, it would be tedious to
Hi Maxime, as always, thanks for the series!
Some extra context, and comments below.
On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> The RaspberryPi4 firmware actually exposes more clocks than are currently
> handled by the driver and we will need to change some of them directly
> based
Hi Dave, sorry for the late reply.
On Tue, 2020-10-06 at 18:14 +0100, Dave Stevenson wrote:
> Hi Maxime
>
> On Tue, 6 Oct 2020 at 16:26, Maxime Ripard wrote:
> > Hi Dave,
> >
> > On Fri, Oct 02, 2020 at 04:57:05PM +0100, Dave Stevenson wrote:
> > > Hi Maxime
> > >
> > > On Fri, 2 Oct 2020 at 1
Hi maxime,
On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
>
> Add a property to o
On Thu, 2020-10-29 at 19:07 +0100, Maxime Ripard wrote:
> Hi Nicolas,
>
> On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> > Hi maxime,
> >
> > On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > > The RaspberryPi4 has both a W
On Thu, 2020-03-26 at 18:19 +0100, Stefan Wahren wrote:
> Am 26.03.20 um 13:20 schrieb Nicolas Saenz Julienne:
> > Current mode validation impedes setting up some video modes which should
> > be supported otherwise. Namely 1920x1200@60Hz.
> >
> > Fix this by lowe
eported-by: Stefan Wahren
Suggested-by: Dave Stevenson
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ce
On Fri, 2020-03-27 at 13:40 +0100, Maxime Ripard wrote:
> On Fri, Mar 27, 2020 at 12:46:52PM +0100, Nicolas Saenz Julienne wrote:
> > Hi Daniel,
> >
> > On Thu, 2020-03-26 at 13:20 +0100, Nicolas Saenz Julienne wrote:
> > > Current mode validation impedes setting up
Hi Daniel,
On Thu, 2020-03-26 at 13:20 +0100, Nicolas Saenz Julienne wrote:
> Current mode validation impedes setting up some video modes which should
> be supported otherwise. Namely 1920x1200@60Hz.
>
> Fix this by lowering the minimum HDMI state machine clock to pixel clock
>
Hi Tim, thanks for the info!
On Thu, 2020-10-01 at 11:15 +0100, Tim Gover wrote:
> hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC
> VCO to support a core-frequency of 550 MHz which is the minimum
> frequency required by the HVS at 4Kp60. The side effect is that if the
> disp
1 - 100 of 117 matches
Mail list logo
