Nobody uses it. Get rid of it.
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchi/vchi.h | 7
.../interface/vchiq_arm/vchiq_shim.c | 39 ---
2 files changed, 46 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchi
They are neither produced nor expected, so just delete them.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchi/vchi_common.h | 40 ++-
1 file changed, 3 insertions(+), 37 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchi
For messages with a reason different from VCHIQ_MESSAGE_AVAILABLE the
responsibility for releasing them is kept in vchi, in other words,
services don't need to worry about it. As we're trying to unify vchi and
vchiq, move the release code into vchiq.
Signed-off-by: Nicolas Saenz Julienne
struct shim_service into struvt vchi_service, which is more consistent
with the rest of the exposed API.
Signed-off-by: Nicolas Saenz Julienne
---
.../bcm2835-audio/bcm2835-vchiq.c | 24 +++
.../vc04_services/interface/vchi/vchi.h | 27
.../interface/vchiq_arm
On Thu, 2020-05-21 at 15:35 -0400, Jim Quinlan wrote:
> On Wed, May 20, 2020 at 7:51 AM Nicolas Saenz Julienne
[...]
> > > /*
> > > @@ -602,20 +667,21 @@ static struct pci_ops brcm_pcie_ops = {
> > >
> > > static inline void brcm_pcie_bridge_sw_ini
Hi Maxime,
On Fri, 2020-05-15 at 10:19 +0200, Maxime Ripard wrote:
> Hi Nicolas,
>
> On Mon, May 04, 2020 at 02:05:47PM +0200, Nicolas Saenz Julienne wrote:
> > Hi Maxime, as always, thanks for the series!
> > Some extra context, and comments below.
> >
> >
On Wed, 2020-05-20 at 10:30 -0400, Jim Quinlan wrote:
> On Wed, May 20, 2020 at 7:51 AM Nicolas Saenz Julienne
> wrote:
[...]
> > > +
> > > +static const struct pcie_cfg_data bcm7278_cfg = {
> > > + .reg_field_info = pcie_reg_field_i
On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> From: Jim Quinlan
>
> The proper value of the parameter SCB_MAX_BURST_SIZE varies
> per chip. The 2711 family requires 128B whereas other devices
> can employ 512. The assignment is complicated by the fact
> that the values for this
Hi Jim,
On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> From: Jim Quinlan
>
> Add in compatibility strings and code for three Broadcom STB chips.
> Some of the register locations, shifts, and masks are different
> for certain chips, requiring the use of different constants based
> on
Hi Jim,
thanks for having a go at this! My two cents.
On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> The device variable 'dma_pfn_offset' is used to do a single
> linear map between cpu addrs and dma addrs. The variable
> 'dma_map' is added to struct device to point to an array
> of
On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote:
> Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
> loaded explicitly. Earlier versions didn't need that as they where using
> an EEPROM for that purpose. This series takes care of setting up the
&
On Wed, 2020-05-13 at 12:17 +0100, Lorenzo Pieralisi wrote:
> On Tue, May 05, 2020 at 06:13:13PM +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
&
Eric Anholt's repo isn't used anymore. List current one.
Signed-off-by: Nicolas Saenz Julienne
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 091ec22c1a23..60908ace8d31 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3320,7
On Sat, 2020-05-09 at 12:02 +0200, Stefan Wahren wrote:
> Hi Nicolas,
>
> Am 07.05.20 um 23:48 schrieb Rob Herring:
> > On Tue, 5 May 2020 18:13:15 +0200, Nicolas Saenz Julienne wrote:
> > > The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip
> >
: Add Broadcom STB PCIe host controller
driver")
Signed-off-by: Nicolas Saenz Julienne
---
drivers/pci/controller/pcie-brcmstb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c
b/drivers/pci/controller/pcie-brcmstb.c
index 0b97b94c4a9a..795a03be4
Hi Bin,
On Wed, 2020-05-06 at 13:33 +0800, Bin Meng wrote:
> Hi Nicolas,
>
> On Wed, May 6, 2020 at 12:26 AM Nicolas Saenz Julienne
> wrote:
> > On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
> > may either be loaded directly from an E
ename function
- Use callback in xhci-pci.c
Nicolas Saenz Julienne (2):
arm: rpi: Add function to trigger VL805's firmware load
usb: xhci: Load Raspberry Pi 4 VL805's firmware
arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++
arch/arm/mach-bcm283x/include/mach/msg.h | 7
arch/ar
in between the PCIe configuration and xHCI startup.
Introduce a callback in xhci_pci_probe() to run this platform specific
routine.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v2:
- Get rid of #ifdef CONFIG_BCM2711
- Get rid of redundant error message
Changes since v1:
- Create
Saenz Julienne
---
Changes since v2:
- Correct wrong function name in comment
- Add better comment on rpi_firmware_init_vl805()
Changes since v1:
- Rename function so it's not mistaken with regular firmware loading
arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++
arch/arm/mach-bcm283x
can't be set as a module neither
this can. Reflect that on the firmware interface Kconfg.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v5:
- Fix Kconfig issue with allmodconfig
Changes since v4:
- Do not split up error message
Changes since v3:
- Add more complete error message
xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on
RPi4's VideoCore firmware interface to be up and running. It's possible
for both initializations to race, so make sure it's available prior to
starting.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Florian Fainelli
logic and the VL805 firmware blob. The function this patch
introduces triggers the aforementioned process.
Signed-off-by: Nicolas Saenz Julienne
---
Change since v7:
- Use usleep_delay()
- Add comment about PCI errors
- Don't wait on error
- Typos
Change since v6:
- Add test to avoid loading
The property is needed in order to trigger VL805's firmware load. Note
that gap between the property introduced and the previous one is due to
the properties not being defined.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Florian Fainelli
---
include/soc/bcm2835/raspberrypi-firmware.h
since v5:
- Fix issues reported by Kbuild test robot
Changes since v4:
- Addressed Sergei's comments
- Fix potential warning in patch #2
Changes since v3:
- Addressed Greg's comments
There was no v2, my bad.
Changes since v1:
- Addressed Floarians comments
Nicolas Saenz Julienne (4):
soc
On Tue, 2020-05-05 at 16:59 +0200, Matthias Brugger wrote:
[...]
> > > > > > +#ifdef CONFIG_BCM2711
> > > > >
> > > > > This won't work with rpi_arm64_defconfig.
> > > > > Can't we just evaluate at runtime if we need to do anything in
> > > > > xhci_pci_fixup.
> > > >
> > > > I can't see why,
On Tue, 2020-05-05 at 15:39 +0200, Matthias Brugger wrote:
>
> On 05/05/2020 14:53, Nicolas Saenz Julienne wrote:
> > Hi Matthias,
> >
> > On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
> > > On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> &g
e new generic dt property:
Acked-by: Nicolas Saenz Julienne
Regards,
Nicolas
> ---
> drivers/pci/controller/pcie-brcmstb.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-
t; Signed-off-by: Jim Quinlan
> Acked-by: Florian Fainelli
>
> Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller
> driver")
> ---
Acked-by: Nicolas Saenz Julienne
Regards,
Nicolas
> drivers/pci/controller/pcie-brcmstb.c | 4 ++--
> 1 file chan
On Fri, 2020-05-01 at 10:28 -0400, Jim Quinlan wrote:
> From: Jim Quinlan
>
> clk_put() was being invoked on a clock obtained by
> devm_clk_get_optional().
>
> Signed-off-by: Jim Quinlan
> Acked-by: Florian Fainelli
> ---
Acked-by: Nicolas Saenz Julienne
Regards,
Hi Matthias,
On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
>
> On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> > When needed, RPi4's co-processor (called VideoCore) has to be instructed
> > to load VL805's firmware (the chip providing xHCI support). VideoC
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 Stefan, thanks for the review!
On Sat, 2020-05-02 at 11:05 +0200, Stefan Wahren wrote:
> > + /* Make sure we don't trigger a firmware load unnecesarely *
> s/unnecesarely/unnecessarily/
Noted
> > + pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET, );
> pci_read_config_dword()
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
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
On Thu, 2020-04-30 at 15:31 +0200, Mark Kettenis wrote:
> > From: Nicolas Saenz Julienne
> > Date: Thu, 30 Apr 2020 15:04:32 +0200
> >
> > On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
> > may either be loaded directly fro
in between the PCIe configuration and xHCI startup.
Introduce a callback in xhci_pci_probe() to run this platform specific
routine.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
- Create callback
board/raspberrypi/rpi/rpi.c | 12
drivers/usb/host/xhci-pci.c | 6
Saenz Julienne
---
Changes since v1:
- Rename function so it's not mistaken with regular firmware loading
arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++
arch/arm/mach-bcm283x/include/mach/msg.h | 7
arch/arm/mach-bcm283x/msg.c | 43 +++
3 files
.
Note that this builds on top of Sylwester Nawrocki's "USB host support
for Raspberry Pi 4 board" series.
---
Changes since v1:
- Rename function
- Use callback in xhci-pci.c
Nicolas Saenz Julienne (2):
arm: rpi: Add function to trigger VL805's firmware load
usb: xhci: Load Rasp
issues reported by Kbuild test robot
Changes since v4:
- Addressed Sergei's comments
- Fix potential warning in patch #2
Changes since v3:
- Addressed Greg's comments
There was no v2, my bad.
Changes since v1:
- Addressed Floarians comments
Nicolas Saenz Julienne (4):
soc: bcm2835: Add notify
xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on
RPi4's VideoCore firmware interface to be up and running. It's possible
for both initializations to race, so make sure it's available prior to
starting.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Florian Fainelli
logic and the VL805 firmware blob. The function this patch
introduces triggers the aforementioned process.
Signed-off-by: Nicolas Saenz Julienne
---
Change since v6:
- Add test to avoid loading the firmware when not needed
- Since we have it around, print VL805's firmware version, it'll make
can't be set as a module neither
this can. Reflect that on the firmware interface Kconfg.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v5:
- Fix Kconfig issue with allmodconfig
Changes since v4:
- Do not split up error message
Changes since v3:
- Add more complete error message
The property is needed in order to trigger VL805's firmware load. Note
that gap between the property introduced and the previous one is due to
the properties not being defined.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Florian Fainelli
---
include/soc/bcm2835/raspberrypi-firmware.h
On Mon, 2019-10-21 at 16:36 -0400, Qian Cai wrote:
> I managed to get more information here,
>
> [0.00] cma: dma_contiguous_reserve(limit c000)
> [0.00] cma: dma_contiguous_reserve: reserving 64 MiB for global area
> [0.00] cma: cma_declare_contiguous(size
On Mon, 2019-10-21 at 13:25 -0400, Qian Cai wrote:
> > On Oct 21, 2019, at 1:01 PM, Nicolas Saenz Julienne
> > wrote:
> >
> > Could you enable CMA debugging to see if anything interesting comes out of
> > it.
>
> I did but nothing interesting came out. Did
On Mon, 2019-10-21 at 10:46 -0400, Qian Cai wrote:
> > On Oct 21, 2019, at 10:34 AM, Nicolas Saenz Julienne > > wrote:
> >
> > On Mon, 2019-10-21 at 10:15 -0400, Qian Cai wrote:
> > > > On Sep 11, 2019, at 2:25 PM, Nicolas Saenz Julienne <
> &
On Mon, 2019-10-21 at 10:15 -0400, Qian Cai wrote:
> > On Sep 11, 2019, at 2:25 PM, Nicolas Saenz Julienne
> > wrote:
> >
> > So far all arm64 devices have supported 32 bit DMA masks for their
> > peripherals. This is not true anymore for the Raspberry Pi 4 as mo
which dma_capable() can't detect as it only checks for
addresses bigger then the maximum allowed DMA address.
Fix this by verifying in dma_capable() if the DMA address range provided
is at any point lower than the minimum possible DMA address on the bus.
Signed-off-by: Nicolas Saenz Julienne
setup, sta2x11_pdev_to_mapping() is
moved to avoid warnings whenever CONFIG_PM is not enabled.
Signed-off-by: Nicolas Saenz Julienne
---
Changed since v1:
- use variable to avoid recalculating AMBA's max address
- remove x86's dma-direct.h as it's not longer needed
Note: This was only
2019 at 06:51:37PM +0200, Nicolas Saenz Julienne wrote:
> > The devices found behind this PCIe chip have unusual DMA mapping
> > constraints as there is an AMBA interconnect placed in between them and
> > the different PCI endpoints. The offset between physical memory
>
setup, sta2x11_pdev_to_mapping() is
moved to avoid warnings whenever CONFIG_PM is not enabled.
Signed-off-by: Nicolas Saenz Julienne
---
Note: This was only compile tested.
arch/x86/Kconfig | 1 -
arch/x86/include/asm/device.h | 3 -
arch/x86/pci/sta2x11-fixup.c | 135
On Wed, 2019-10-16 at 16:08 +0100, Catalin Marinas wrote:
> On Wed, Oct 16, 2019 at 07:47:14AM -0700, Nathan Chancellor wrote:
> > When building arm64 allnoconfig, CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32
> > get disabled so there is a warning about max_dma being unused.
> >
> >
2 = min;
> +#if defined(CONFIG_ZONE_DMA) || defined(CONFIG_ZONE_DMA32)
> unsigned long max_dma = min;
> +#endif
>
> memset(zone_size, 0, sizeof(zone_size));
>
Reviewed-by: Nicolas Saenz Julienne
Thanks!
signature.asc
Description: This is a digitally signed message part
On Tue, 2019-10-15 at 00:43 -0700, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 06:51:29PM +0200, Nicolas Saenz Julienne wrote:
> > It's more explicit and lets dma-direct handle the specifics of how to
> > translate addresses.
> >
> > On top of that ge
Hi Matthias!
One small comment, I'll test everything later on.
On Fri, 2019-10-11 at 20:48 +0200, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> Depending on the HW, the maximal usable DMA burst size can vary.
> If not set accordingly a timeout in the transmit queue happens and no
It's more explicit and lets dma-direct handle the specifics of how to
translate addresses.
On top of that get rid of warnings as, since the introduction of commit
6fa1d28e38c ("sh: use generic dma_noncoherent_ops"), it's impossible for
the dev to be NULL.
Signed-off-by: Nicolas Saen
On Thu, 2019-10-10 at 11:05 +0800, Candle Sun wrote:
> > > -static void hid_concatenate_usage_page(struct hid_parser *parser)
> > > +static void hid_concatenate_last_usage_page(struct hid_parser *parser)
> > > {
> > > int i;
> > > + unsigned int usage;
> > > + unsigned int
On Wed, 2019-10-09 at 20:53 +0800, Candle Sun wrote:
> From: Candle Sun
>
> Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
> to Main item") adds support for Usage Page item after Usage ID items
> (such as keyboards manufactured by Primax).
>
> Usage Page concatenation
On Tue, 2019-10-08 at 20:03 -0500, Rob Herring wrote:
> On Tue, Oct 8, 2019 at 3:52 PM Nicolas Saenz Julienne
> wrote:
> > Hi Rob/Robin,
> >
> > On Tue, 2019-10-08 at 14:52 -0500, Rob Herring wrote:
> > > From: Robin Murphy
> > >
> > > Since
Hi Rob/Robin,
On Tue, 2019-10-08 at 14:52 -0500, Rob Herring wrote:
> From: Robin Murphy
>
> Since the "dma-ranges" property is only valid for a node representing a
> bus, of_dma_get_range() currently assumes the node passed in is a leaf
> representing a device, and starts the walk from its
On Thu, 2019-10-03 at 20:53 -0500, Rob Herring wrote:
> > > > But I think that with this series, given the fact that we now treat the
> > > > lack
> > > > of
> > > > dma-ranges as a 1:1 mapping instead of an error, we could rewrite the
> > > > function
> > > > like this:
> > >
> > > Now, I'm
IDR register and specifies
that any unwarranted register access will raise an undefined exception.
Overall, given the bogus DT, a reasonable outcome.
This was originally seen on a Raspberry Pi 2 built with bcm2835_defconfig.
Reported-by: "kernelci.org bot"
Signed-off-by: Nicolas Saenz Jul
M2711")
Signed-off-by: Nicolas Saenz Julienne
Tested-by: Matthias Brugger
Acked-by: Stefan Wahren
---
Changes since v1:
- Add Fixes tag and Acked-by
drivers/mmc/host/sdhci-iproc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-ipr
On Fri, 2019-10-04 at 14:52 +0200, Nicolas Saenz Julienne wrote:
> The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
> after multiblock reads even when ACMD12 is disabled. This triggers
> spurious interrupts after the data transfer is done with the following
: ADMA Err: 0x | ADMA Ptr: 0xf3025208
mmc1: sdhci:
Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock
reads and suppress the spurious interrupts.
Signed-off-by: Nicolas Saenz Julienne
Tested-by: Matthias Brugger
On Thu, 2019-10-03 at 16:47 -0700, Florian Fainelli wrote:
> On 10/3/19 12:39 PM, Nicolas Saenz Julienne wrote:
> > On Thu, 2019-10-03 at 11:08 -0700, Florian Fainelli wrote:
> > > On 10/2/19 4:45 AM, Nicolas Saenz Julienne wrote:
> > > > Currently, in arm_dt_init_cp
On Thu, 2019-10-03 at 11:08 -0700, Florian Fainelli wrote:
> On 10/2/19 4:45 AM, Nicolas Saenz Julienne wrote:
> > Currently, in arm_dt_init_cpu_maps(), the hwid of the boot CPU is read
> > from MPIDR on SMP devices and set to 0 for non SMP. This value is then
> > matched
the way we choose whether to get MPIDR or not. Instead of
depending on SMP check the number of CPUs defined in DT. Anything > 1
means MPIDR will be available.
This was seen on a Raspberry Pi 2 build with bcm2835_defconfig.
Reported-by: "kernelci.org bot"
Signed-off-by: Nicolas S
On Mon, 2019-09-30 at 16:24 -0500, Rob Herring wrote:
> On Mon, Sep 30, 2019 at 8:32 AM Nicolas Saenz Julienne
> wrote:
> > On Mon, 2019-09-30 at 05:57 -0700, Christoph Hellwig wrote:
> > > On Thu, Sep 26, 2019 at 07:24:49PM -0500, Rob Herring wrote:
> > > > -i
chitectures can enable CONFIG_OPTIMIZE_INLINING.
> So, __always_inline is now the only guaranteed way of forcible inlining.
>
> I also added __always_inline to 4 functions in the call-graph from the
> __get_user_check() macro.
>
> Fixes: 9012d011660e ("compiler: allow all arches to
On Mon, 2019-09-30 at 05:57 -0700, Christoph Hellwig wrote:
> On Thu, Sep 26, 2019 at 07:24:49PM -0500, Rob Herring wrote:
> > -int of_dma_configure(struct device *dev, struct device_node *np, bool
> > force_dma)
> > +int of_dma_configure(struct device *dev, struct device_node *parent, bool
> >
On Mon, 2019-09-30 at 11:36 +0200, Benjamin Tissoires wrote:
> Hi,
>
> [also addingg Nicolas, the author of 58e75155009c]
Thanks!
>
> On Mon, Sep 30, 2019 at 10:10 AM Candle Sun wrote:
> > From: Candle Sun
> >
> > Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
> >
a_get_range() work on bus nodes
Re-tested the whole series. Verified both the unittests run fine and PCIe's
behaviour is fixed.
Tested-by: Nicolas Saenz Julienne
Also for the whole series:
Reviewed-by: Nicolas Saenz Julienne
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
ceived a regression report from Nicolas Saenz Julienne:
>
> https://lkml.org/lkml/2019/9/27/263
>
> This problem has cropped up on arch/arm/config/bcm2835_defconfig
> because it enables CONFIG_CC_OPTIMIZE_FOR_SIZE. The compiler tends
> to prefer not inlining functions with -O
On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> Commit 9012d011660e ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> this option. A couple of build errors were reported by randconfig,
> but all of them have been ironed out.
>
>
On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> Commit 9012d011660e ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> this option. A couple of build errors were reported by randconfig,
> but all of them have been ironed out.
>
>
Robin Murphy
> Cc: Julien Grall
> Cc: Nicolas Saenz Julienne
> Cc: Oleksandr Andrushchenko
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: xen-de...@lists.xenproject.org
> Signed-off-by: Rob Herring
Just so it isn't forgotten, the same appli
Let the name indicate that they are used to calculate ZONE_DMA32's size
as opposed to ZONE_DMA.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
arch/arm64/mm/init.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch
-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
I kept the Reviewed-by as the last bug solution was proposed by Catalin
Changes in v6:
- Fixed bug in max_zone_phys
Changes in v5:
- Fixed swiotlb initialization
Changes in v4:
- Fixed issue when NUMA=n and ZONE_DMA=n
- Merged two
These zones usage has evolved with time and the comments were outdated.
This joins both ZONE_DMA and ZONE_DMA32 explanation and gives up to date
examples on how they are used on different architectures.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Christoph Hellwig
Reviewed-by: Catalin
essential
Nicolas Saenz Julienne (4):
arm64: mm: use arm64_dma_phys_limit instead of calling
max_zone_dma_phys()
arm64: rename variables used to calculate ZONE_DMA32's size
arm64: use both ZONE_DMA and ZONE_DMA32
mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type'
arch/arm64
By the time we call zones_sizes_init() arm64_dma_phys_limit already
contains the result of max_zone_dma_phys(). We use the variable instead
of calling the function directly to save some precious cpu time.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
arch/arm64/mm
On Wed, 2019-09-11 at 15:35 +0100, Catalin Marinas wrote:
> On Wed, Sep 11, 2019 at 12:54:38PM +0200, Nicolas Saenz Julienne wrote:
> > On Mon, 2019-09-09 at 11:58 +0200, Nicolas Saenz Julienne wrote:
> > > /*
> > > - * Return the maximum physical address for
On Mon, 2019-09-09 at 11:58 +0200, Nicolas Saenz Julienne wrote:
> +
> /*
> - * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)). It
> - * currently assumes that for memory starting above 4G, 32-bit devices will
> - * use a DMA offset.
> + * Return th
On Mon, 2019-09-09 at 21:33 +0200, Stefan Wahren wrote:
> Hi Nicolas,
>
> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
> > Hi all,
> > this series attempts to address some issues we found while bringing up
> > the new Raspberry Pi 4 in arm64 and it's intended
These zones usage has evolved with time and the comments were outdated.
This joins both ZONE_DMA and ZONE_DMA32 explanation and gives up to date
examples on how they are used on different architectures.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Christoph Hellwig
Reviewed-by: Catalin
By the time we call zones_sizes_init() arm64_dma_phys_limit already
contains the result of max_zone_dma_phys(). We use the variable instead
of calling the function directly to save some precious cpu time.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
arch/arm64/mm
-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
Changes in v5:
- Fixed swiotlb initialization
Changes in v4:
- Fixed issue when NUMA=n and ZONE_DMA=n
- Merged two max_zone_dma*_phys() functions
Changes in v3:
- Used fixed size ZONE_DMA
- Fix check befor swiotlb_init()
Changes in v2
Let the name indicate that they are used to calculate ZONE_DMA32's size
as opposed to ZONE_DMA.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
arch/arm64/mm/init.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch
ZONE_DMA comments into one
- Address Christoph's comments
- If this approach doesn't get much traction I'll just drop the patch
from the series as it's not really essential
Nicolas Saenz Julienne (4):
arm64: mm: use arm64_dma_phys_limit instead of calling
max_zone_dma_phys()
arm64: rename
On Sun, 2019-09-08 at 22:27 +0100, Catalin Marinas wrote:
> On Fri, Sep 06, 2019 at 02:06:14PM +0200, Nicolas Saenz Julienne wrote:
> > @@ -430,7 +454,7 @@ void __init arm64_memblock_init(void)
> >
> > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> >
>
By the time we call zones_sizes_init() arm64_dma_phys_limit already
contains the result of max_zone_dma_phys(). We use the variable instead
of calling the function directly to save some precious cpu time.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
arch/arm64/mm
These zones usage has evolved with time and the comments were outdated.
This joins both ZONE_DMA and ZONE_DMA32 explanation and gives up to date
examples on how they are used on different architectures.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Christoph Hellwig
Reviewed-by: Catalin
-by: Nicolas Saenz Julienne
---
Changes in v4:
- Fixed issue when NUMA=n and ZONE_DMA=n
- Merged two max_zone_dma*_phys() functions
Changes in v3:
- Used fixed size ZONE_DMA
- Fix check befor swiotlb_init()
Changes in v2:
- Update comment to reflect new zones split
- ZONE_DMA will never be left
traction I'll just drop the patch
from the series as it's not really essential
Nicolas Saenz Julienne (4):
arm64: mm: use arm64_dma_phys_limit instead of calling
max_zone_dma_phys()
arm64: rename variables used to calculate ZONE_DMA32's size
arm64: use both ZONE_DMA and ZONE_DMA32
mm
Let the name indicate that they are used to calculate ZONE_DMA32's size
as opposed to ZONE_DMA.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
---
arch/arm64/mm/init.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch
On Thu, 2019-09-05 at 18:19 +0100, Catalin Marinas wrote:
> On Mon, Sep 02, 2019 at 04:10:41PM +0200, Nicolas Saenz Julienne wrote:
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 8956c22634dd..f02a4945aeac 100644
> > --- a/arch/arm64/mm/init.c
> >
-by: Nicolas Saenz Julienne
---
Changes in v3:
- Used fixed size ZONE_DMA
- Fix check befor swiotlb_init()
Changes in v2:
- Update comment to reflect new zones split
- ZONE_DMA will never be left empty
arch/arm64/Kconfig| 4 +++
arch/arm64/include/asm/page.h | 2 ++
arch/arm64/mm
These zones usage has evolved with time and the comments were outdated.
This joins both ZONE_DMA and ZONE_DMA32 explanation and gives up to date
examples on how they are used on different architectures.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Christoph Hellwig
---
Changes in v3
Let the name indicate that they are used to calculate ZONE_DMA32's size
as opposed to ZONE_DMA.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v3: None
Changes in v2: None
arch/arm64/mm/init.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff
701 - 800 of 1177 matches
Mail list logo
