-by: Nicolas Saenz Julienne
---
@Uwe: I didn't found it necessary to call 'try_module_get()' as the rest
of modules depend on the 'rpi_firmware_get/put()' symbols which already
block users from unloading the module prematurely.
drivers/firmware/raspberrypi.c | 30
Upon unbinding the device make sure we release RPi's firmware interface.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/soc/bcm/raspberrypi-power.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/soc/bcm/raspberrypi-power.c
b/drivers/soc/bcm/raspberrypi-power.c
After passing the DMA buffer address through the firmware interface,
release the firmware handle, we won't need it anymore.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/input/touchscreen/raspberrypi-ts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen
Upon unbinding the device make sure we release RPi's firmware interface.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/reset/reset-raspberrypi.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/reset-raspberrypi.c
b/drivers/reset/reset
, now with 2 cells
- Add reference count to rpi_firmware_get()
Nicolas Saenz Julienne (10):
firmware: raspberrypi: Introduce rpi_firmware_put()
clk: bcm: rpi: Release firmware handle on unbind
gpio: raspberrypi-exp: Release firmware handle on unbind
reset: raspberrypi: Release firmware handle on
Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
- Use default pwm bindings and get rid
Upon unbinding the clock device make sure we release RPi's firmware
interface.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/clk/bcm/clk-raspberrypi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index
Upon unbinding the device make sure we release RPi's firmware interface.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpio/gpio-raspberrypi-exp.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-raspberrypi-exp.c
b/drivers/gpio/gpio
The PWM bus controlling the fan in RPi's official PoE hat can only be
controlled by the board's co-processor.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
- Update bindings to use 2 #pwm-cells
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 +++
.../pwm
On Thu, 2020-10-22 at 14:23 +0200, Ard Biesheuvel wrote:
> > +/**
> > + * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
> > + * @np: The node to start searching from or NULL to start from the root
> > + *
> > + * Gets the highest CPU physical address that is addressable by
the rest of the 32-bit address
space.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- Simplify code for readability.
Changes since v2:
- Updated commit log by shamelessly copying Ard's ACPI commit log
arch/arm64/mm/init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- use u64 with cpu_end
zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch
if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.
Cc: Jeremy Linton
Cc: Lorenzo Pieralisi
Cc: Nicolas Saenz Julienne
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Anshuman
Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- Remove HAS_DMA guards
drivers/of/unittest.c | 18 ++
1 file changed, 18 insertions(+)
diff --git
We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.
Suggested-by: Christoph Hellwig
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/mmzone.h | 20
the memory before the page allocator kicks in. There
isn't any apparent reason for doing this earlier.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index
Ard Biesheuvel (1):
arm64: mm: Set ZONE_DMA size based on early IORT scan
Nicolas Saenz Julienne (6):
arm64: mm: Move reserve_crashkernel() into mem_init()
arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
of/address: Introduce of_dma_get_max_cpu_address()
of: unittest
Hi Uwe,
Sorry for the late reply, got distracted with other stuff.
On Mon, 2020-10-19 at 08:52 +0200, Uwe Kleine-König wrote:
> On Fri, Oct 16, 2020 at 05:26:56PM +0200, Nicolas Saenz Julienne wrote:
> > On Fri, 2020-10-16 at 09:38 -0500, Rob Herring wrote:
> > > On Thu, Oct 1
Hi Saravana, thanks for your comments.
On Thu, 2020-10-15 at 09:52 -0700, Saravana Kannan wrote:
> On Thu, Oct 15, 2020 at 4:43 AM Nicolas Saenz Julienne
> wrote:
> > 'simple-mfd' usage implies there might be some kind of resource sharing
> > between the parent devic
On Fri, 2020-10-16 at 09:38 -0500, Rob Herring wrote:
> On Thu, Oct 15, 2020 at 6:43 AM Nicolas Saenz Julienne
> wrote:
> > 'simple-mfd' usage implies there might be some kind of resource sharing
> > between the parent device and its children.
>
> It does? No! The
On Thu, 2020-10-15 at 22:26 +0800, Hanjun Guo wrote:
> On 2020/10/15 3:12, Nicolas Saenz Julienne wrote:
> > From: Ard Biesheuvel
> >
> > We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
> > incorporating masters that can address less than 32 bit
On Thu, 2020-10-15 at 12:14 +0100, Richard Fitzgerald wrote:
> > Sadly I don't think creating a new device tree is a good solution here. If
> > we
> > were to do so for every RPi hat/usage it'd become unmanageable very fast.
> > There
> > is a way to maintain this in the open nonetheless. I
of their resources disappeared.
Signed-off-by: Nicolas Saenz Julienne
---
Some questions:
- To what extent do we care about cleanly unbinding platform devices at
runtime? My rationale here is: "It's a platform device, for all you
know you might be unbinding someting essential to the syste
Hi Richard,
your series is very welcome, upstream support for audio codecs on the RPi4 has
always been lackluster.
Could you provide more information on the actual products? Are there custom
made hats for the RPi4 or this wired into a generic development board.
On Wed, 2020-10-14 at 15:54 +0100,
On Thu, 2020-10-15 at 07:39 +0200, Christoph Hellwig wrote:
> On Wed, Oct 14, 2020 at 09:12:08PM +0200, Nicolas Saenz Julienne wrote:
> > + zone_dma_bits = min(zone_dma_bits,
> > + (unsigned
> > int)ilog2(of_dma_get_max_cpu_address(NULL)));
>
&
On Thu, 2020-10-15 at 07:38 +0200, Christoph Hellwig wrote:
> On Wed, Oct 14, 2020 at 09:12:07PM +0200, Nicolas Saenz Julienne wrote:
> > Set zone_dma_bits default value through a define so as for architectures
> > to be able to override it with their default value.
>
>
On Thu, 2020-10-15 at 07:42 +0200, Christoph Hellwig wrote:
> > +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
> > +{
> > + phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
> > + struct of_range_parser parser;
> > + phys_addr_t subtree_max_addr;
> > + struct device_node
On Wed, 2020-10-14 at 17:04 -0500, Rob Herring wrote:
> On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
> wrote:
> > Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
> > data as the rest of dma-ranges unit tests.
> >
> > Signed-
On Thu, 2020-10-15 at 08:56 +0200, Ard Biesheuvel wrote:
> On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote:
> > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
> > wrote:
> > > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> > > ph
On Thu, 2020-10-15 at 09:40 +0100, Will Deacon wrote:
> On Wed, Oct 14, 2020 at 09:12:03PM +0200, Nicolas Saenz Julienne wrote:
> > crashkernel might reserve memory located in ZONE_DMA. We plan to delay
> > ZONE_DMA's initialization after unflattening the devicetree and ACPI's
On Wed, 2020-10-14 at 17:02 -0500, Rob Herring wrote:
> On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne
> wrote:
> > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
> > physical address addressable by all DMA masters in the system. It's
&g
the rest of the 32-bit address
space.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v2:
- Updated commit log by shamelessly copying Ard's ACPI counterpart commit log
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/mm/init.c | 5 ++---
2 files changed, 3 insertions
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v2:
- Use PHYS_ADDR_MAX
zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch
- Move crashkernel reservation later in boot process
Changes since v1:
- Parse dma-ranges instead of using machine compatible string
Ard Biesheuvel (1):
arm64: mm: Set ZONE_DMA size based on early IORT scan
Nicolas Saenz Julienne (7):
arm64: mm: Move reserve_crashkernel() into mem_init
the memory before the page allocator kicks in and there is
no need to do it earlier.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index a53c1e0fb017..1d29f2ca81c7
if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.
Cc: Jeremy Linton
Cc: Lorenzo Pieralisi
Cc: Nicolas Saenz Julienne
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Anshuman
The default behavior for arm64 changed, so reflect that.
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Catalin Marinas
---
include/linux/mmzone.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fb3bf696c05e
Set zone_dma_bits default value through a define so as for architectures
to be able to override it with their default value.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/dma-direct.h | 3 +++
kernel/dma/direct.c| 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff
Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/unittest.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers
Hi Rob,
On Mon, 2020-10-12 at 10:25 -0500, Rob Herring wrote:
> On Sat, Oct 10, 2020 at 10:12 AM Nicolas Saenz Julienne
> wrote:
> > The function provides the CPU physical address addressable by the most
> > constrained bus in the system. It might be useful in order to
>
ed, I'll update all commit logs.
> On Sat, 10 Oct 2020 at 17:12, Nicolas Saenz Julienne
> wrote:
> > The function provides the CPU physical address addressable by the most
> > constrained bus in the system. It might be useful in order to
> > dynamically set up memory
Hi Uwe,
On Tue, 2020-10-13 at 14:17 +0200, Uwe Kleine-König wrote:
> Hello Nicolas,
>
> On Tue, Oct 13, 2020 at 01:20:00PM +0200, Nicolas Saenz Julienne wrote:
> > On Mon, 2020-10-12 at 09:06 +0200, Uwe Kleine-König wrote:
> > > > + depends on RASPBERRYP
On Tue, 2020-10-13 at 14:08 +0200, Uwe Kleine-König wrote:
> On Tue, Oct 13, 2020 at 12:35:38PM +0200, Nicolas Saenz Julienne wrote:
> > Hi Uwe, thanks for having a look at this.
> >
> > On Mon, 2020-10-12 at 09:01 +0200, Uwe Kleine-König wrote:
> > > On Fri, Oc
Hi Uwe,
On Mon, 2020-10-12 at 09:06 +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Oct 09, 2020 at 05:30:30PM +0200, Nicolas Saenz Julienne wrote:
> > Adds support to control the PWM bus available in official Raspberry Pi
> > PoE HAT. Only RPi's co-processor has acce
Hi Uwe, thanks for having a look at this.
On Mon, 2020-10-12 at 09:01 +0200, Uwe Kleine-König wrote:
> On Fri, Oct 09, 2020 at 05:30:28PM +0200, Nicolas Saenz Julienne wrote:
> > The PWM bus controlling the fan in RPi's official PoE hat can only be
> > controlled by the board
With the help of of_dma_safe_phys_limit() we can get the topmost
physical address accessible for DMA to the whole system and use that
information to properly setup zone_dma_bits.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/mm/init.c
There no use for initializing it earlier in arm64_memblock_init().
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f6902a2b4ea6..0eca5865dcb1 100644
The default behavior for arm64 changed, so reflect that.
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Catalin Marinas
---
include/linux/mmzone.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fb3bf696c05e
On Sat, 2020-10-10 at 12:36 +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 19:10, Catalin Marinas wrote:
> > On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi
> > > wrote:
> > > > We can move this check to IORT code and
The function provides the CPU physical address addressable by the most
constrained bus in the system. It might be useful in order to
dynamically set up memory zones during boot.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 34 ++
include/linux
dma-ranges instead of using machine compatible string
Nicolas Saenz Julienne (5):
arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
of/address: Introduce of_dma_lower_bus_limit()
dma-direct: Turn zone_dma_bits default value into a define
arm64: mm: Dynamically resize zon
So as for architecture code to set their own default values when
relevant.
Signed-off-by: Nicolas Saenz Julienne
---
Note: This is not really needed, but I think it nicer having
architectures use this than setting zone_dma_bits in a random place in
arch code. That said, I'll hapily edit it out
Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/pwm/Kconfig | 7 ++
drivers/pwm/Makefile
write a new driver/bindings from scratch (as in
not reusing previous code).
That said, I'm more than happy to change things if there is a consensus that
another design will do the trick.
[1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/
---
Nicolas Saenz Julienne
The PWM bus controlling the fan in RPi's official PoE hat can only be
controlled by the board's co-processor.
Signed-off-by: Nicolas Saenz Julienne
---
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++
.../pwm/raspberrypi,firmware-pwm.h| 13
2
This is an example on how to enable the fan on top of RPi's official PoE
hat.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 +++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
b/arch/arm/boot
On Fri, 2020-10-09 at 11:13 +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 10:36, Nicolas Saenz Julienne
> wrote:
> > On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
> > > On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
> > > > On Thu,
Hi Jeremy.
On Thu, 2020-10-08 at 22:59 -0500, Jeremy Linton wrote:
> On 10/8/20 2:43 PM, Ard Biesheuvel wrote:
> > (+ Lorenzo)
> >
> > On Thu, 8 Oct 2020 at 12:14, Catalin Marinas
> > wrote:
> > > On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Jul
On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
> > On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > > Sadly I just realised that the series is incomplete, we have RPi4 users
> > &
Hi Catalin, sorry for the late reply.
On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote:
> On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote:
> > On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> > > On Thu, Oct 01, 2020 at 06:15:01PM +010
have to add clk_disable_unprepare() calls to the
> two error paths.
>
> Fixes: b98f52bc6495 ("PCI: brcmstb: Add control of rescal reset")
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Jim Quinlan
> ---
Reviewed-by: Nicolas Saenz Julienne
Thanks!
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
On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> > Hi Nicolas,
> >
> > Thanks for putting this together.
> >
> > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne
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
>
as the only platform interested in using this is the Raspberry Pi 4.
So update zone_dma_bits if the machine's compatible string matches
Raspberry Pi 4's, otherwise let arm64's mm code deal with it.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/fdt.c | 10 ++
1 file changed, 10 insertions
ZONE_DMA and only define both zones if running on RPi4.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e1a69a618832..3c3f462466eb 100644
--- a/arch
The default behavior for arm64 changed, so reflect that.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/mmzone.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fb3bf696c05e..d28ce77ccc2a 100644
Other code might need to reference it.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/dma-direct.h | 1 +
kernel/dma/direct.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 38ed3b55034d
Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.
I tested this on both a RPi4 and QEMU.
---
Nicolas Saenz Julienne (4):
of/fdt: Update zone_dma_bits when running in bcm2711
dma-direct: Turn zone_dma_bits default value into a define
On Wed, 2020-09-30 at 09:38 -0700, Nathan Chancellor wrote:
> On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> > Hi Nathan,
> >
> > On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> > > On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > > > Now
On Mon, 2020-09-21 at 22:49 +0200, Krzysztof Kozlowski wrote:
> Use PLATFORM_DEVID_NONE define instead of "-1" value because:
> - it brings some meaning,
> - it might point attention why auto device ID was not used.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
Hi Florian,
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/nsaenz/linux-rpi.git
tags/bcm2835-dt-next-2020-09-08
for you to fetch
On Tue, 2020-09-01 at 13:07 +0900, Hoegeun Kwon wrote:
> Hi everyone,
>
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
>
> Rebased on top of next-20200708 and [1].
>
> [1] :
On Thu, 2020-09-03 at 10:01 +0200, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more specific
> clock setup.
>
> Reviewed-by: Dave Stevenson
>
Hi Catalin, thanks for taking the time.
On Tue, 2020-09-08 at 12:14 +0100, Catalin Marinas wrote:
> > Also note the usage of 'zone_dma_bits' in the DMA code, which assumes that
> > ZONE_DMA's physical address space is always smaller than (1 <<
> > zone_dma_bits) -
> > 1.
>
> I think part of
hw = raspberrypi_clk_register(rpi, clks->parent,
> clks->id);
> if (IS_ERR(hw))
Acked-by: Nicolas Saenz Julienne
Tested-by: Nicolas Saenz Julienne
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
Hi Maxime,
On Mon, 2020-09-07 at 18:22 +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, Sep 03, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> > Hi everyone,
> >
> > Here's a (pretty long) series to introduce support in the VC4 DRM driver
> > for the display pipeline found in the BCM2711 (and
Hi Catalin, sorry for the late reply, I was on vacation.
On Fri, 2020-08-28 at 18:43 +0100, Catalin Marinas wrote:
> Hi Nicolas,
>
> On Wed, Aug 19, 2020 at 08:24:33PM +0200, Nicolas Saenz Julienne wrote:
> > There is no benefit in splitting the 32-bit address space into two
&
was sent along
> with UNICAM v4l2 driver and some misc changes you have collected in
> this series. Reference to v1:
> https://lore.kernel.org/linux-media/20200504092611.9798-1-laurent.pinch...@ideasonboard.com/
>
> On Mon, Jun 29, 2020 at 05:09:26PM +0200, Nicolas Saenz Julienne wr
with big crash
kernel allocations.
Signed-off-by: Nicolas Saenz Julienne
---
Whith this patch, on a 8GB RPi4 the setup looks like this:
DMA [mem 0x-0x3fff]
DMA32[mem 0x4000-0x]
Normal [mem 0x0001
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
- Check if phys_addr_ok() exists prior calling it
Christoph Hellwig (1):
dma-pool: fix coherent pool allocations for IOMMU mappings
Nicolas Saenz Julienne (1):
dma-pool: Only allocate from CMA when in same memory zone
drivers/iommu/dma-iommu.c | 4 +-
include/linux/dma-direct.h | 3
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
[hch: rebased, added
On Fri, 2020-08-14 at 08:11 +0200, Greg KH wrote:
> On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote:
> >
> > On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote:
> > > Hi everyone.
> > >
> > > On Mon, 2020-06-29 at
On Fri, 2020-08-14 at 08:06 +0200, Christoph Hellwig wrote:
> On Sat, Aug 08, 2020 at 08:33:54AM +0200, Christoph Hellwig wrote:
> > On Fri, Aug 07, 2020 at 10:50:19AM +0200, Nicolas Saenz Julienne wrote:
> > > On Fri, 2020-08-07 at 07:21 +0200, Christoph Hellwig wrote:
>
Hi everyone.
On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote:
> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> loaded directly from an EEPROM or, if not present, by the SoC's
> co-processor, VideoCore. This series reworks how
On Fri, 2020-08-07 at 07:21 +0200, Christoph Hellwig wrote:
> On Thu, Aug 06, 2020 at 08:47:55PM +0200, Nicolas Saenz Julienne wrote:
> > There is no guarantee to CMA's placement, so allocating a zone specific
> > atomic pool from CMA might return memory from a completely different
it
Christoph Hellwig (1):
dma-pool: fix coherent pool allocations for IOMMU mappings
Nicolas Saenz Julienne (1):
dma-pool: Only allocate from CMA when in same memory zone
drivers/iommu/dma-iommu.c | 4 +-
include/linux/dma-direct.h | 3 -
include/linux/dma-mapping.h | 5 +-
kernel/dma/direct.c
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
[hch: rebased, added
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
On Thu, 2020-08-06 at 07:18 +0200, Christoph Hellwig wrote:
> On Tue, Aug 04, 2020 at 11:43:15AM +0200, Nicolas Saenz Julienne wrote:
> > > Second I don't see the need (and actually some harm) in preventing
> > > GFP_KERNEL
> > > allocations from dipping into lower
On Tue, 2020-08-04 at 08:06 +0200, Christoph Hellwig wrote:
> On Mon, Aug 03, 2020 at 06:09:56PM +0200, Nicolas Saenz Julienne wrote:
> > + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
> > + return end <= DMA_BIT_MASK(zone_dma_bits);
> >
it
Christoph Hellwig (1):
dma-pool: fix coherent pool allocations for IOMMU mappings
Nicolas Saenz Julienne (1):
dma-pool: Only allocate from CMA when in same memory zone
drivers/iommu/dma-iommu.c | 4 +-
include/linux/dma-direct.h | 3 -
include/linux/dma-mapping.h | 5 +-
kernel
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1
parsing ranges.
Add test to catch regressions on that specific quirk as developers will
be tempted to edit it out in favor of the default method.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/unittest-data/tests-address.dtsi | 10 +-
drivers/of/unittest.c | 2
Hi Jim,
On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> The Raspberry Pi (RPI) is currently the only chip using this driver
> (pcie-brcmstb.c). There, only one memory controller is used, without an
> extension region, and the SCB0 viewport size is set to the size of the
> first and only
Hi Nathan,
On Thu, 2020-07-30 at 18:10 -0700, Nathan Chancellor wrote:
> On Tue, Jul 28, 2020 at 12:09:18PM +0200, Christoph Hellwig wrote:
> > Ok, I found a slight bug that wasn't intended. I wanted to make sure
> > we can always fall back to a lower pool, but got that wrong. Should be
> >
301 - 400 of 1177 matches
Mail list logo
