* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
From: Andrey Ryabinin @ 2019-08-15 12:21 UTC (permalink / raw)
To: Will Deacon, Mark Rutland
Cc: crecklin, ard.biesheuvel, catalin.marinas, bhsharma, Steve Capper,
kasan-dev, glider, dvyukov, maz, linux-arm-kernel
In-Reply-To: <20190815120908.kboyqfnr2fivuva4@willie-the-truck>
On 8/15/19 3:09 PM, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 05:03:24PM +0100, Mark Rutland wrote:
>> From ecdf60051a850f817d98f84ae9011afa2311b8f1 Mon Sep 17 00:00:00 2001
>> From: Mark Rutland <mark.rutland@arm.com>
>> Date: Wed, 14 Aug 2019 15:31:57 +0100
>> Subject: [PATCH] kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE
>>
>> The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into
>> KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC.
>>
>> Since commit:
>>
>> 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
>>
>> ... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than
>> defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if
>> CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time
>> splats due to KASAN_SHADOW_OFFSET not being set:
>>
>> | [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
>> | scripts/kconfig/conf --syncconfig Kconfig
>> | CC scripts/mod/empty.o
>> | clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
>> | scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
>> | make[1]: *** [scripts/mod/empty.o] Error 1
>> | Makefile:1123: recipe for target 'prepare0' failed
>> | make: *** [prepare0] Error 2
>>
>> Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into
>> KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing
>> common definition of +CFLAGS_KASAN_NOSANITIZE to the top of
>> Makefile.kasan.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Steve Capper <steve.capper@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> ---
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
From: Will Deacon @ 2019-08-15 12:22 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: Mark Rutland, crecklin, ard.biesheuvel, catalin.marinas, bhsharma,
Steve Capper, kasan-dev, glider, dvyukov, maz, linux-arm-kernel
In-Reply-To: <8e472cf5-21d1-be9e-9e47-ec40e35b3192@virtuozzo.com>
On Thu, Aug 15, 2019 at 03:21:48PM +0300, Andrey Ryabinin wrote:
> On 8/15/19 3:09 PM, Will Deacon wrote:
>
> > On Wed, Aug 14, 2019 at 05:03:24PM +0100, Mark Rutland wrote:
> >> From ecdf60051a850f817d98f84ae9011afa2311b8f1 Mon Sep 17 00:00:00 2001
> >> From: Mark Rutland <mark.rutland@arm.com>
> >> Date: Wed, 14 Aug 2019 15:31:57 +0100
> >> Subject: [PATCH] kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE
> >>
> >> The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into
> >> KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC.
> >>
> >> Since commit:
> >>
> >> 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
> >>
> >> ... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than
> >> defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if
> >> CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time
> >> splats due to KASAN_SHADOW_OFFSET not being set:
> >>
> >> | [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
> >> | scripts/kconfig/conf --syncconfig Kconfig
> >> | CC scripts/mod/empty.o
> >> | clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
> >> | scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
> >> | make[1]: *** [scripts/mod/empty.o] Error 1
> >> | Makefile:1123: recipe for target 'prepare0' failed
> >> | make: *** [prepare0] Error 2
> >>
> >> Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into
> >> KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing
> >> common definition of +CFLAGS_KASAN_NOSANITIZE to the top of
> >> Makefile.kasan.
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: Steve Capper <steve.capper@arm.com>
> >> Cc: Will Deacon <will@kernel.org>
> >> ---
>
>
> Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Thanks, Andrey!
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
From: Michael Nazzareno Trimarchi @ 2019-08-15 12:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, Michael Turquette,
linux-sunxi, linux-kernel, dri-devel, Chen-Yu Tsai, Rob Herring,
Jagan Teki, Daniel Vetter, linux-amarula, linux-clk,
linux-arm-kernel
In-Reply-To: <20190813060502.teeevudz6cjn35tl@flea>
Hi Maxime
On Tue, Aug 13, 2019 at 8:05 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Jul 29, 2019 at 08:59:04AM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
> > <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > > > Hi Maxime,
> > > >
> > > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > >
> > > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > > > <maxime.ripard@bootlin.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi wrote:
> > > > > > > > > > tcon-pixel clock is the rate that you want to achive on display side
> > > > > > > > > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > > > > > > > > you need to have a clock that is able to put outside bits and speed
> > > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock of
> > > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most of
> > > > > > > > > > the display.
> > > > > > > > >
> > > > > > > > > So this is what the issue is then?
> > > > > > > > >
> > > > > > > > > This one does make sense, and you should just change the rate in the
> > > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > > > >
> > > > > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > > > > discussion or the commit log before though.
> > > > > > > > >
> > > > > > > > Something like this?
> > > > > > > >
> > > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++++++++++---------
> > > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > > > > > drm_display_mode *mode,
> > > > > > > > }
> > > > > > > >
> > > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > > > > - const struct drm_display_mode *mode)
> > > > > > > > + const struct drm_display_mode *mode,
> > > > > > > > + u32 tcon_mul)
> > > > > > > > {
> > > > > > > > /* Configure the dot clock */
> > > > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > > > > > >
> > > > > > > > /* Set the resolution */
> > > > > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > > > sun4i_tcon *tcon,
> > > > > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > > > > u8 lanes = device->lanes;
> > > > > > > > u32 block_space, start_delay;
> > > > > > > > - u32 tcon_div;
> > > > > > > > + u32 tcon_div, tcon_mul;
> > > > > > > >
> > > > > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > > > > + tcon->dclk_min_div = 4;
> > > > > > > > + tcon->dclk_max_div = 127;
> > > > > > > >
> > > > > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > > > > + tcon_mul = bpp / lanes;
> > > > > > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > > > > > >
> > > > > > > > /* Set dithering if needed */
> > > > > > > > sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> > > > > > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > > > sun4i_tcon *tcon,
> > > > > > > > */
> > > > > > > > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > > > > > > > tcon_div &= GENMASK(6, 0);
> > > > > > > > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > > > > > > > + block_space = mode->htotal * tcon_div * tcon_mul;
> > > > > > > > block_space -= mode->hdisplay + 40;
> > > > > > > >
> > > > > > > > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > > > > > > > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > > > > > > > sun4i_tcon *tcon,
> > > > > > > >
> > > > > > > > tcon->dclk_min_div = 7;
> > > > > > > > tcon->dclk_max_div = 7;
> > > > > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > > > > >
> > > > > > > > /* Set dithering if needed */
> > > > > > > > sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> > > > > > > > @@ -487,7 +489,7 @@ static void sun4i_tcon0_mode_set_rgb(struct
> > > > > > > > sun4i_tcon *tcon,
> > > > > > > >
> > > > > > > > tcon->dclk_min_div = 6;
> > > > > > > > tcon->dclk_max_div = 127;
> > > > > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > > > > >
> > > > > > > > /* Set dithering if needed */
> > > > > > > > sun4i_tcon0_mode_set_dithering(tcon, connector);
> > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > > index 5c3ad5be0690..a07090579f84 100644
> > > > > > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > > @@ -13,8 +13,6 @@
> > > > > > > > #include <drm/drm_encoder.h>
> > > > > > > > #include <drm/drm_mipi_dsi.h>
> > > > > > > >
> > > > > > > > -#define SUN6I_DSI_TCON_DIV 4
> > > > > > > > -
> > > > > > > > struct sun6i_dsi {
> > > > > > > > struct drm_connector connector;
> > > > > > > > struct drm_encoder encoder;
> > > > > > >
> > > > > > > I had more something like this in mind:
> > > > > > > http://code.bulix.org/nlp5a4-803511
> > > > > >
> > > > > > Worth to look at it. was it working on your panel? meanwhile I will check it.
> > > > >
> > > > > I haven't tested it.
> > > > >
> > > > > > We have updated with below change [1], seems working on but is
> > > > > > actually checking the each divider as before start with 4... till 127.
> > > > > >
> > > > > > This new approach, is start looking the best divider from 4.. based on
> > > > > > the idea vs rounded it will ended up best divider like [2]
> > > > >
> > > > > But why?
> > > > >
> > > > > I mean, it's not like it's the first time I'm asking this...
> > > > >
> > > > > If the issue is what Micheal described, then the divider has nothing
> > > > > to do with it. We've had that discussion over and over again.
> > > >
> > > > This is what Michael is mentioned in above mail "tcon-pixel clock is
> > > > the rate that you want to achive on display side and if you have 4
> > > > lanes 32bit or lanes and different bit number that you need to have
> > > > a clock that is able to put outside bits and speed equal to
> > > > pixel-clock * bits / lanes. so If you want a pixel-clock of 40 mhz
> > > > and you have 32bits and 4 lanes you need to have a clock of 40 * 32
> > > > / 4 in no-burst mode. "
> > >
> > > Yeah, so we need to change the clock rate.
> > >
> > > > He is trying to manage the bpp/lanes into dclk_mul (in last mail)
> > > > and it can multiply with pixel clock which is rate argument in
> > > > sun4i_dclk_round_rate.
> > > >
> > > > The solution I have mentioned in dclk_min, max is bpp/lanes also
> > > > multiple rate in dotclock sun4i_dclk_round_rate.
> > > >
> > > > In both cases the overall pll_rate depends on dividers, the one that I
> > > > have on this patch is based on BSP and the Michael one is more generic
> > > > way so-that it can not to touch other functionalities and looping
> > > > dividers to find the best one.
> > > >
> > > > If dclk_min/max is bpp/lanes then dotclock directly using divider 6
> > > > (assuming 24-bit and 4 lanes) and return the pll_rate and divider 6
> > > > associated.
> > > >
> > > > if dclk_mul is bpp/lanes, on Michael new change, the dividers start
> > > > with 4 and end with 127 but the constant ideal rate which rate *
> > > > bpp/lanes but the loop from sun4i_dclk_round_rate computed the divider
> > > > as 6 only, ie what I'm mentioned on the above mail.
> > >
> > > We've been over this a couple of times already.
> > >
> > > The clock is generated like this:
> > >
> > > PLL -> TCON Module Clock -> TCON DCLK
> > >
> > > You want the TCON DCLK to be at the pixel clock rate * bpp /
> > > lanes. Fine, that makes sense.
> > >
> > > Except that the patch you've sent, instead of changing the rate
> > > itself, changes the ratio between the module clock and DCLK.
> > >
> > > And this is where the issue lies. First, from a logical viewpoint, it
> > > doesn't make sense. If you want to change the clock rate, then just do
> > > it. Don't hack around the multipliers trying to fall back to something
> > > that works for you.
> > >
> > > Then, the ratio itself needs to be set to 4. This is the part that
> > > we've discussed way too many times already, but in the Allwinner BSP,
> > > that ratio is hardcoded to 4, and we've had panels that need it at
> > > that value.
> > >
> > > So, what you want to do is to have:
> > >
> > > TCON DCLK = pixel clock * bpp / lanes
> > > TCON Module Clock = DCLK * 4
> > > PLL = Module Clock * Module Clock Divider (which I believe is 1 in most cases)
> >
> > pll-mipi 1 1 1 178200000
> > 0 0 50000
> > tcon0 2 2 1 178200000
> > 0 0 50000
> > tcon-pixel-clock 1 1 1 29700000
> > 0 0 50000
>
> Is this before or after your patches?
>
This is just an example of clock tree to be clear to everyone how they
are connected
> > This is an english problem from my side:
> > tcon-pixel-clock is DCLK
> > tcon0 must be tcon-pixel-clock * bpp / lanes, because the logic need to
> > put a bit every cycle.
>
> Again, I'm not saying this is wrong, but each time I've looked at it
> the BSP was using a 4 divider between the tcon module clock and the
> dotclock.
>
We have tested on 4-5 displays. Well I don't care on bsp but I care
about if it works
and if other SoC has similar approach on clock calculation.
> So, please prove me wrong here.
>
Having only 10 pages of documentation is a bit difficult.
> > One solution can be:
> > - set_rate_exclusive to tcon0 and calculate as display pixel clock *
> > bpp / lanes
>
> I'm not sure what set_rate_exclusive has to do with it. I mean, it's a
> good idea to use it, but it shouldn't really change anything to the
> discussion.
Well, this will just do a minimal change on source code and put the constrains
to the tcon0
>
> > - calculate the tcon-pixel-clock using all divider
>
> I'm not sure what you mean by that.
>
> > Problem is that the function that calculate tcon-pixel-clock does not
> > have any constrain on the ideal value.
>
> It does have constraints, but you're right that it will not try to
> find an exact match and bail out if it can't do it, but will find the
> closest match.
>
We need to find the closest divider that match the pixel clock and be close
to the ideal tcon0 rate.
> > What you are suggesting is not correct in my opinion or I'm not
> > following your suggesstion.
>
> Then prove me wrong.
>
> > What I know is that if we have a pixel-clock of dvi display of 50Mhz
> > and we have 4 lanes 32bit we need a clock in the logic of 400Mhz
> > (this is the ideal throughtput).
> > So tcon-pixel-clock is 50mhz and tcon0 is 400Mhz.
>
> There's one thing to keep in mind though. The TCON dotclock in the
> MIPI-DSI case isn't directly tied to the Bit Clock, it's simply an
> internal clock in the pipeline to feed the FIFO of the MIPI-DSI
> controller. The MIPI-DSI controller itself will generate that clock,
> and only that one will have those constraints.
>
I have done the same thinking but because it works for us seems that
somehow is used
to internal logic too
Michael
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] tee subsys for v5.4
From: Arnd Bergmann @ 2019-08-15 12:39 UTC (permalink / raw)
To: Jens Wiklander; +Cc: SoC Team, arm-soc, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20190815065659.GA13498@jax>
On Thu, Aug 15, 2019 at 8:57 AM Jens Wiklander
<jens.wiklander@linaro.org> wrote:
>
> Hello arm-soc maintainers,
>
> Please pull this OP-TEE driver patch. It adds a call to might_sleep()
> during RPC in the OP-TEE driver in order to be more friendly with
> CONFIG_PREEMPT_VOLUNTARY.
>
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] fixes for omap variants for v5.3-rc cycle
From: Arnd Bergmann @ 2019-08-15 12:39 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1565844391-332885@atomide.com>
On Thu, Aug 15, 2019 at 6:49 AM Tony Lindgren <tony@atomide.com> wrote:
>
> From: "Tony Lindgren" <tony@atomide.com>
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.3/fixes-rc4
>
> for you to fetch changes up to 4a65bbb9109ed7edd4b6ed7168ced48abb8561a2:
>
> soc: ti: pm33xx: Make two symbols static (2019-08-13 05:05:38 -0700)
>
> ----------------------------------------------------------------
> Fixes for omap variants for v5.3-rc cycle
>
> We have another fix to disable voltage switching for am57xx SDIO as
> the bootrom cannot handle all the voltages after a reset that thought
> I had already sent a pull request for earlier but forgot. And we also
> update dra74x iodelay configuration for mmc3 to use the recommended
> values.
>
> Then I noticed we had introduced few new boot warnings with the various
> recent ti-sysc changes and wanted to fix those. I also noticed we still
> have too many warnings to be able to spot the real ones easily and fixed
> up few of those. Sure some of the warnings have been around for a long
> time and few of the fixes could have waited for the merge window, but
> having more usable dmesg log level output is a valuable.
>
> Other fixes are IO size correction for am335x UARTs that cause issues
> for at least FreeBSD using the same device tree file that checks that
> the child IO range is not larger than the parent has.
>
> For omap1 ams-delta keyboard we need to fix a irq ack that broke with
> all the recent gpio changes.
>
> And there are also few static checker warning fixes for recent am335x
> PM changes and ti-sysc driver and one switch fall-though update.
Pulled into fixes, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] firmware: arm_scmi: updates for v5.4
From: Arnd Bergmann @ 2019-08-15 12:40 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Olof Johansson, SoC Team, ARM SoC Team, ALKML, Kevin Hilman
In-Reply-To: <20190814172454.26191-1-sudeep.holla@arm.com>
On Wed, Aug 14, 2019 at 7:25 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Hi ARM SoC Team,
>
> Please pull !
> There are minor changes in clock and hwmon subsystems that are Acked-by
> Stephen Boyd and Guenter Roeck. It also contains a new reset driver that
> is reviewed by Philipp Zabel. Further all these are in -next for a while.
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: dts: vexpress: updates for v5.4
From: Arnd Bergmann @ 2019-08-15 12:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Kevin Hilman, Liviu Dudau, SoC Team,
ARM SoC Team, Olof Johansson, ALKML
In-Reply-To: <20190814172425.26089-1-sudeep.holla@arm.com>
On Wed, Aug 14, 2019 at 7:24 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> ----------------------------------------------------------------
> ARMv7 Vexpress DTS updates for v5.4
>
> Couple of updates adding missing: SPDX GPL-2.0 license identifier
> and newline at the end of the file
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64: dts: juno: updates for v5.4
From: Arnd Bergmann @ 2019-08-15 12:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Kevin Hilman, Liviu Dudau, SoC Team, ARM SoC Team, Olof Johansson,
ALKML
In-Reply-To: <20190814172408.25995-1-sudeep.holla@arm.com>
On Wed, Aug 14, 2019 at 7:24 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-update-5.4
>
> for you to fetch changes up to a24810673638d5da0336ccae5407c3fd59da14ac:
>
> arm64: dts: fast models: Remove clcd's max-memory-bandwidth (2019-08-05 11:44:00 +0100)
>
> ----------------------------------------------------------------
> ARMv8 Juno/FVP update for v5.4
>
> Single patch removing optional 'max-memory-bandwidth' property for CLCD
> that enables to allocate and use 32bpp buffers(used on FVP for Android
> development)
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/13] usb: ohci-nxp: enable compile-testing
From: Greg Kroah-Hartman @ 2019-08-15 12:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Felipe Balbi, linux-usb, linux-kernel, Vladimir Zapolskiy, soc,
Alan Stern, Sylvain Lemieux, linux-arm-kernel
In-Reply-To: <20190809144043.476786-2-arnd@arndb.de>
On Fri, Aug 09, 2019 at 04:40:27PM +0200, Arnd Bergmann wrote:
> The driver hardcodes a hardware I/O address the way one should
> generally not do, and this prevents both compile-testing, and
> moving the platform to CONFIG_ARCH_MULTIPLATFORM.
>
> Change the code to be independent of the machine headers
> to allow those two. Removing the hardcoded address would
> be hard and is not necessary, so leave that in place for now.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/usb/host/Kconfig | 3 ++-
> drivers/usb/host/ohci-nxp.c | 25 ++++++++++++++++++-------
> 2 files changed, 20 insertions(+), 8 deletions(-)
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64: dts: Amlogic fixes for v5.3-rc
From: Arnd Bergmann @ 2019-08-15 12:47 UTC (permalink / raw)
To: Kevin Hilman
Cc: open list:ARM/Amlogic Meson SoC support, SoC Team, arm-soc,
Linux ARM
In-Reply-To: <7h1rxq0ws9.fsf@baylibre.com>
On Tue, Aug 13, 2019 at 1:49 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-fixes
>
> for you to fetch changes up to dc7f2cb218b5ef65ab3d455a0e62d27e44075203:
>
> arm64: dts: amlogic: odroid-n2: keep SD card regulator always on (2019-08-05 14:06:55 -0700)
>
> ----------------------------------------------------------------
> arm64: dts: Amlogic fixes for v5.3-rc
> - a few small DT fixes for g12a/g12b platforms
Pulled into arm/fixes, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/7] ARM: preparation for multiplatform iop32x
From: Arnd Bergmann @ 2019-08-15 12:50 UTC (permalink / raw)
To: SoC Team
Cc: Dave Jiang, Linus Walleij, Russell King, Linux ARM, Dan Williams,
Imre Kaloz, Martin Michlmayr, Lennert Buytenhek
In-Reply-To: <20190809162956.488941-1-arnd@arndb.de>
On Fri, Aug 9, 2019 at 6:30 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> I'm looking into converting some of the remaining ARMv5
> platforms in arch/arm/ to work together in a single kernel
> binary.
>
> IOP32x seems to be a fairly easy target for multiplatform
> by itself, but the way the plat-iop code interacts with
> three generations of the code, and how the dma-adma driver
> is configured at compile-time for each version gets in the
> way.
>
> I considered adding more indirection layers for those two,
> but removing iop33x and iop13xx is much easier in comparison,
> so this is the first approach I'm posting.
>
> If we conclude that iop33x and iop13xx are indeed not used
> any more, the remaining patches in this series are
> straightforward. The actual multiplatform conversion also
> requires changes to the irqchip driver that are not completely
> mechanic, and we can discuss those after deciding what to do
> with the first set.
>
> Adding a few people to Cc that historically worked on IOP.
I applied the IOP series to to the arm/soc branch now,
thanks for the reviews!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/10] PCI: layerscape: Modify the way of getting capability with different PEX
From: Andrew Murray @ 2019-08-15 12:51 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, gregkh,
jingoohan1, linuxppc-dev, linux-pci, linux-kernel, leoyang.li,
minghuan.Lian, devicetree, robh+dt, linux-arm-kernel,
gustavo.pimentel, bhelgaas, kishon, shawnguo, mingkai.hu
In-Reply-To: <20190815083716.4715-5-xiaowei.bao@nxp.com>
On Thu, Aug 15, 2019 at 04:37:11PM +0800, Xiaowei Bao wrote:
> The different PCIe controller in one board may be have different
> capability of MSI or MSIX, so change the way of getting the MSI
> capability, make it more flexible.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 28 +++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index be61d96..9404ca0 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -22,6 +22,7 @@
>
> struct ls_pcie_ep {
> struct dw_pcie *pci;
> + struct pci_epc_features *ls_epc;
> };
>
> #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> @@ -40,25 +41,26 @@ static const struct of_device_id ls_pcie_ep_of_match[] = {
> { },
> };
>
> -static const struct pci_epc_features ls_pcie_epc_features = {
> - .linkup_notifier = false,
> - .msi_capable = true,
> - .msix_capable = false,
> -};
> -
> static const struct pci_epc_features*
> ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
> {
> - return &ls_pcie_epc_features;
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> +
> + return pcie->ls_epc;
> }
>
> static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> enum pci_barno bar;
>
> for (bar = BAR_0; bar <= BAR_5; bar++)
> dw_pcie_ep_reset_bar(pci, bar);
> +
> + pcie->ls_epc->msi_capable = ep->msi_cap ? true : false;
> + pcie->ls_epc->msix_capable = ep->msix_cap ? true : false;
> }
>
> static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> @@ -118,6 +120,7 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct dw_pcie *pci;
> struct ls_pcie_ep *pcie;
> + struct pci_epc_features *ls_epc;
> struct resource *dbi_base;
> int ret;
>
> @@ -129,6 +132,10 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> if (!pci)
> return -ENOMEM;
>
> + ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
> + if (!ls_epc)
> + return -ENOMEM;
> +
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> if (IS_ERR(pci->dbi_base))
> @@ -139,6 +146,13 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> pci->ops = &ls_pcie_ep_ops;
> pcie->pci = pci;
>
> + ls_epc->linkup_notifier = false,
> + ls_epc->msi_capable = true,
> + ls_epc->msix_capable = true,
As [msi,msix]_capable is shortly set from ls_pcie_ep_init - is there any
reason to set them here (to potentially incorrect values)?
Thanks,
Andrew Murray
> + ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> +
> + pcie->ls_epc = ls_epc;
> +
> platform_set_drvdata(pdev, pcie);
>
> ret = ls_add_pcie_ep(pcie, pdev);
> --
> 2.9.5
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Ux500 updates for v5.4 take one
From: Arnd Bergmann @ 2019-08-15 12:52 UTC (permalink / raw)
To: Linus Walleij
Cc: SoC Team, arm-soc, Ulf Hansson, Linux ARM, Nicholas Mc Guire
In-Reply-To: <CACRpkdbH-h5fRwuidcpeOp8mtRoKUW65SAk8a4A==BCDzn3QMA@mail.gmail.com>
On Sun, Jul 28, 2019 at 11:42 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi ARM SoC folks,
>
> here are some initial patches for Ux500 targeted for the v5.4 kernel
> cycle.
>
> Please pull it in! Details in the signed tag.
>
> Yours,
> Linus Walleij
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
> tags/ux500-v5.4-1
>
> for you to fetch changes up to 163ce24a435061f9ff7e1673fec5be0868bdb7d3:
>
> MAINTAINERS: add soc/ux500 (2019-07-23 10:44:14 +0200)
>
> ----------------------------------------------------------------
> This is a slew of Ux500 updates for the v5.4 kernel cycle:
>
> - Stop populating the PRCMU devices from the core CPU
> file, it works just fine at device_initcall() level.
>
> - Add a missing of_node_put() in the core file.
>
> - Simplify the debug UART code.
>
> - Add myself to MAINTAINERS
>
Pulled into arm/soc, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Ux500 DTS updates for v5.4 take one
From: Arnd Bergmann @ 2019-08-15 12:52 UTC (permalink / raw)
To: Linus Walleij; +Cc: SoC Team, arm-soc, mathieu poirier, Linux ARM, Leo Yan
In-Reply-To: <CACRpkdbKX7a15SC-zwxmH_ygGzOKrn0h-pzzm22UpRcLRfRVNA@mail.gmail.com>
On Sun, Jul 28, 2019 at 11:35 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi ARM SoC folks,
>
> this is the first slew of DTS updates for Ux500 for v5.4, maybe
> there will be more, but this needs to get out there. Especially
> the long overdue CoreSight conversion that got stuck in my
> tree for no good reason.
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Greg Kroah-Hartman @ 2019-08-15 13:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190811080520.21712-7-hch@lst.de>
On Sun, Aug 11, 2019 at 10:05:20AM +0200, Christoph Hellwig wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_object so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default. Architectures can still override this in
> arch_setup_pdev_archdata if needed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/base/platform.c | 15 +++++++++++++--
> include/linux/platform_device.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index ec974ba9c0c4..b216fcb0a8af 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -264,6 +264,17 @@ struct platform_object {
> char name[];
> };
>
> +static void setup_pdev_archdata(struct platform_device *pdev)
> +{
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dma_mask)
> + pdev->dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &pdev->dma_mask;
> + arch_setup_pdev_archdata(pdev);
> +};
> +
> /**
> * platform_device_put - destroy a platform device
> * @pdev: platform device to free
> @@ -310,7 +321,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> - arch_setup_pdev_archdata(&pa->pdev);
> + setup_pdev_archdata(&pa->pdev);
> }
>
> return pa ? &pa->pdev : NULL;
> @@ -512,7 +523,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
> int platform_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> - arch_setup_pdev_archdata(pdev);
> + setup_pdev_archdata(pdev);
> return platform_device_add(pdev);
> }
> EXPORT_SYMBOL_GPL(platform_device_register);
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 9bc36b589827..a2abde2aef25 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -24,6 +24,7 @@ struct platform_device {
> int id;
> bool id_auto;
> struct device dev;
> + u64 dma_mask;
Why is the dma_mask in 'struct device' which is part of this structure,
not sufficient here? Shouldn't the "platform" be setting that up
correctly already in the "archdata" type callback?
confused,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] reset: Add driver for dispmix reset
From: Philipp Zabel @ 2019-08-15 13:05 UTC (permalink / raw)
To: Fancy Fang, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: dl-linux-imx, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org
In-Reply-To: <AM6PR04MB49369AD1DE69A51B38471608F3E20@AM6PR04MB4936.eurprd04.prod.outlook.com>
Hi Fancy,
On Wed, 2019-06-26 at 06:46 +0000, Fancy Fang wrote:
> Hi Philipp,
>
> Thanks for your comments. And please see my answers below.
>
[...]
> > +Specifying sft-rstn control of devices
> > +======================================
> > +
> > +Device nodes in Display Mix should specify the reset channel required
> > +in their "resets" property, containing a phandle to the sft-rstn
> > +device node and an index to specify which channel to use, as
> > +described in Documentation/devicetree/bindings/reset/reset.txt.
> > +
> > +example:
> > +
> > + lcdif_resets: lcdif-resets {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #reset-cells = <0>;
> > +
> > + lcdif-soft-resetn {
> > + compatible = "lcdif,soft-resetn";
> > + resets = <&dispmix_sft_rstn IMX8MN_LCDIF_APB_CLK_RESET>,
> > + <&dispmix_sft_rstn
> > + IMX8MN_LCDIF_PIXEL_CLK_RESET>;
>
> From these names, on i.MX8MN these look like they could be an internal property of the DISPMIX clocks provided to the submodules. But on i.MX8MM the soft reset bits do look like actual module resets. Can you confirm whether this is true?
> [FF] I'll check this with the IC designer, and I'll let you know the result when I get the answer.
Did you get some feedback on what these resets actually are?
I'm asking because I'm wondering about how to best support VPUMIX for
the three VPU cores on i.MX8MM. The VPUMIX seems to have a SOFT_RESET
register and a CLOCK_ENABLE register, each with three bits, one bit for
each VPU. I'd be interested in knowing what these actually reset / gate
as well.
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Andy Shevchenko @ 2019-08-15 13:10 UTC (permalink / raw)
To: Wei Xu, Mika Westerberg
Cc: Salil Mehta, jinying, Tangkunshan, Linus Walleij, John Garry,
Linux Kernel Mailing List, Shameerali Kolothum Thodi, Linuxarm,
open list:GPIO SUBSYSTEM, huangdaode, Jonathan Cameron,
Liguozhu (Kenneth), Zhangyi ac,
linux-arm-kernel@lists.infradead.org, Shiju Jose
In-Reply-To: <5D514D6F.4090904@hisilicon.com>
On Mon, Aug 12, 2019 at 2:30 PM Wei Xu <xuwei5@hisilicon.com> wrote:
>
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
>
> Otherwise it will be failed to register interruption for the ACPI case.
> Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
> after gpiochip_add_irqchip but at that time the acpi data has not been
> attached yet.
>
> Tested with below steps on QEMU v4.1.0-rc3 and Linux kernel v5.3-rc4,
> and found pl061 interruption is missed in the /proc/interrupts:
> 1.
> qemu-system-aarch64 \
> -machine virt,gic-version=3 -cpu cortex-a57 \
> -m 1G,maxmem=4G,slots=4 \
> -kernel Image -initrd rootfs.cpio.gz \
> -net none -nographic \
> -bios QEMU_EFI.fd \
> -append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
>
> 2. cat /proc/interrupts in the guest console:
> estuary:/$ cat /proc/interrupts
> CPU0
> 2: 3228 GICv3 27 Level arch_timer
> 4: 15 GICv3 33 Level uart-pl011
> 42: 0 GICv3 23 Level arm-pmu
> IPI0: 0 Rescheduling interrupts
> IPI1: 0 Function call interrupts
> IPI2: 0 CPU stop interrupts
> IPI3: 0 CPU stop (for crash dump) interrupts
> IPI4: 0 Timer broadcast interrupts
> IPI5: 0 IRQ work interrupts
> IPI6: 0 CPU wake-up interrupts
> Err: 0
>
> Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Linus, I'm wondering if we can do this for all inside the GPIO library.
Thoughts?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/14] ARM: move lpc32xx and dove to multiplatform
From: Arnd Bergmann @ 2019-08-15 13:11 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, LINUXWATCHDOG, Jason Cooper, David S. Miller,
Greg Kroah-Hartman, Linus Walleij, USB list, Vladimir Zapolskiy,
open list:GPIO SUBSYSTEM, SoC Team, Networking, Alan Stern,
Guenter Roeck, linux-serial, Sylvain Lemieux, Gregory Clement,
Linux ARM, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a1Lgbz9RwVaOgNq=--gwvEG70tUi67XwsswjgnXAX6EhA@mail.gmail.com>
On Thu, Aug 1, 2019 at 9:33 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Aug 1, 2019 at 12:53 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote:
> > > For dove, the patches are basically what I had proposed back in
> > > 2015 when all other ARMv6/ARMv7 machines became part of a single
> > > kernel build. I don't know what the state is mach-dove support is,
> > > compared to the DT based support in mach-mvebu for the same
> > > hardware. If they are functionally the same, we could also just
> > > remove mach-dove rather than applying my patches.
> >
> > Well, the good news is that I'm down to a small board support file
> > for the Dove Cubox now - but the bad news is, that there's still a
> > board support file necessary to support everything the Dove SoC has
> > to offer.
> >
> > Even for a DT based Dove Cubox, I'm still using mach-dove, but it
> > may be possible to drop most of mach-dove now. Without spending a
> > lot of time digging through it, it's impossible to really know.
>
> Ok, so we won't remove it then, but I'd like to merge my patches to
> at least get away from the special case of requiring a separate kernel
> image for it.
>
> Can you try if applying patches 12 and 14 from my series causes
> problems for you? (it may be easier to apply the entire set
> or pull from [1] to avoid rebase conflicts).
I applied patches 12 and 13 into the soc tree now. There are some
other pending multiplatform conversions (iop32x, ep93xx, lpc32xx,
omap1), but it looks like none of those will be complete for 5.4.
I now expect that we can get most of the preparation into 5.4,
and maybe move them all over together in 5.5 after some more
testing. If someone finds a problem with the one of the
preparation steps, that we can revert the individual patches
more easily.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 05/14] media: rkisp1: add Rockchip ISP1 subdev driver
From: Sakari Ailus @ 2019-08-15 13:17 UTC (permalink / raw)
To: Helen Koike
Cc: devicetree, eddie.cai.linux, kernel, heiko, jacob2.chen,
jeffy.chen, zyc, linux-kernel, tfiga, linux-rockchip, Allon Huang,
Jacob Chen, hans.verkuil, laurent.pinchart, zhengsq, mchehab,
ezequiel, linux-arm-kernel, linux-media
In-Reply-To: <20190815082422.GM6133@paasikivi.fi.intel.com>
On Thu, Aug 15, 2019 at 11:24:22AM +0300, Sakari Ailus wrote:
> Hi Helen,
>
> On Wed, Aug 14, 2019 at 09:58:05PM -0300, Helen Koike wrote:
>
> ...
>
> > >> +static int rkisp1_isp_sd_set_fmt(struct v4l2_subdev *sd,
> > >> + struct v4l2_subdev_pad_config *cfg,
> > >> + struct v4l2_subdev_format *fmt)
> > >> +{
> > >> + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > >> + struct rkisp1_isp_subdev *isp_sd = &isp_dev->isp_sdev;
> > >> + struct v4l2_mbus_framefmt *mf = &fmt->format;
> > >> +
> > >
> > > Note that for sub-device nodes, the driver is itself responsible for
> > > serialising the access to its data structures.
> >
> > But looking at subdev_do_ioctl_lock(), it seems that it serializes the
> > ioctl calls for subdevs, no? Or I'm misunderstanding something (which is
> > most probably) ?
>
> Good question. I had missed this change --- subdev_do_ioctl_lock() is
> relatively new. But setting that lock is still not possible as the struct
> is allocated in the framework and the device is registered before the
> driver gets hold of it. It's a good idea to provide the same serialisation
> for subdevs as well.
>
> I'll get back to this later.
The main reason is actually that these ops are also called through the
sub-device kAPI, not only through the uAPI, and the locks are only taken
through the calls via uAPI.
So adding the locks to uAPI calls alone would not address the issue.
--
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next take at setting up a dma mask by default for platform devices
From: Greg Kroah-Hartman @ 2019-08-15 13:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190811080520.21712-1-hch@lst.de>
On Sun, Aug 11, 2019 at 10:05:14AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this is another attempt to make sure the dma_mask pointer is always
> initialized for platform devices. Not doing so lead to lots of
> boilerplate code, and makes platform devices different from all our
> major busses like PCI where we always set up a dma_mask. In the long
> run this should also help to eventually make dma_mask a scalar value
> instead of a pointer and remove even more cruft.
>
> The bigger blocker for this last time was the fact that the usb
> subsystem uses the presence or lack of a dma_mask to check if the core
> should do dma mapping for the driver, which is highly unusual. So we
> fix this first. Note that this has some overlap with the pending
> desire to use the proper dma_mmap_coherent helper for mapping usb
> buffers. The first two patches from this series should probably
> go into 5.3 and then uses as the basis for the decision to use
> dma_mmap_coherent.
I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
to be fixed, I'll wait for a respin of these before considering them.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next take at setting up a dma mask by default for platform devices
From: Christoph Hellwig @ 2019-08-15 13:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Gavin Li, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Laurentiu Tudor, Geoff Levand,
Shawn Guo, linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815132318.GA27208@kroah.com>
On Thu, Aug 15, 2019 at 03:23:18PM +0200, Greg Kroah-Hartman wrote:
> I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
> to be fixed, I'll wait for a respin of these before considering them.
I have a respun version ready, but I'd really like to hear some
comments from usb developers about the approach before spamming
everyone again..
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 01/14] media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format
From: Laurent Pinchart @ 2019-08-15 13:30 UTC (permalink / raw)
To: Helen Koike
Cc: devicetree, eddie.cai.linux, kernel, heiko, jacob2.chen,
jeffy.chen, zyc, linux-kernel, tfiga, linux-rockchip,
hans.verkuil, sakari.ailus, zhengsq, mchehab, ezequiel,
linux-arm-kernel, linux-media
In-Reply-To: <20190730184256.30338-2-helen.koike@collabora.com>
Hi Helen,
Thank you for the patch.
On Tue, Jul 30, 2019 at 03:42:43PM -0300, Helen Koike wrote:
> From: Shunqian Zheng <zhengsq@rock-chips.com>
>
> Add the Rockchip ISP1 specific processing parameter format
> V4L2_META_FMT_RK_ISP1_PARAMS and metadata format
> V4L2_META_FMT_RK_ISP1_STAT_3A for 3A.
I don't like V4L2_META_FMT_RK_ISP1_PARAMS much, as the parameters are
not passed to the hardware through a buffer, but instead written to
registers by the kernel driver. This is an area where V4L2 controls are
traditionally used. I do however understand that it's easier for driver
authors to pass a large set of controls this way when they have to be
applied atomically, but it's clearly a hack in my opinion. I won't
oppose to it though, as I know there's no way we can support this kind
of feature in V4L2 at the moment without an extensive amount of work, so
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> [update for upstream]
> Signed-off-by: Helen Koike <helen.koike@collabora.com>
>
> ---
>
> Changes in v8: None
> Changes in v7:
> - s/IPU3/RK_ISP1
>
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> include/uapi/linux/videodev2.h | 4 ++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index bb5b4926538a..2df20801a299 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1330,6 +1330,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_META_FMT_VSP1_HGT: descr = "R-Car VSP1 2-D Histogram"; break;
> case V4L2_META_FMT_UVC: descr = "UVC Payload Header Metadata"; break;
> case V4L2_META_FMT_D4XX: descr = "Intel D4xx UVC Metadata"; break;
> + case V4L2_META_FMT_RK_ISP1_PARAMS: descr = "Rockchip ISP1 3A params"; break;
> + case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A statistics"; break;
>
> default:
> /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2427bc4d8eba..ae1e375a10d7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -756,6 +756,10 @@ struct v4l2_pix_format {
> #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC Payload Header metadata */
> #define V4L2_META_FMT_D4XX v4l2_fourcc('D', '4', 'X', 'X') /* D4XX Payload Header metadata */
>
> +/* Vendor specific - used for RK_ISP1 camera sub-system */
> +#define V4L2_META_FMT_RK_ISP1_PARAMS v4l2_fourcc('R', 'K', '1', 'P') /* Rockchip ISP1 params */
> +#define V4L2_META_FMT_RK_ISP1_STAT_3A v4l2_fourcc('R', 'K', '1', 'S') /* Rockchip ISP1 3A statistics */
> +
> /* priv field value to indicates that subsequent fields are valid. */
> #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe
>
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Christoph Hellwig @ 2019-08-15 13:32 UTC (permalink / raw)
To: Robin Murphy
Cc: Gavin Li, Shawn Guo, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Geoff Levand, Greg Kroah-Hartman,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <fbea6e6d-7721-b51d-0501-582e8446e9c9@arm.com>
On Wed, Aug 14, 2019 at 04:49:13PM +0100, Robin Murphy wrote:
>> because we have to support platform_device structures that are
>> statically allocated.
>
> This would be a good point to also get rid of the long-standing bodge in
> platform_device_register_full().
platform_device_register_full looks odd to start with, especially
as the coumentation is rather lacking..
>> +static void setup_pdev_archdata(struct platform_device *pdev)
>
> Bikeshed: painting the generic DMA API properties as "archdata" feels a bit
> off-target :/
>
>> +{
>> + if (!pdev->dev.coherent_dma_mask)
>> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> + if (!pdev->dma_mask)
>> + pdev->dma_mask = DMA_BIT_MASK(32);
>> + if (!pdev->dev.dma_mask)
>> + pdev->dev.dma_mask = &pdev->dma_mask;
>> + arch_setup_pdev_archdata(pdev);
>
> AFAICS m68k's implementation of that arch hook becomes entirely redundant
> after this change, so may as well go. That would just leave powerpc's
> actual archdata, which at a glance looks like it could probably be cleaned
> up with not *too* much trouble.
Actually I think we can just kill both off. At the point archdata
is indeed entirely misnamed.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
From: Mike Rapoport @ 2019-08-15 13:37 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux@armlinux.org.uk,
linux-kernel@vger.kernel.org, Chester Lin, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu-5M-4=SbOzbqbLUYnfFw29vhfcrVD=N9j_APYpKjq2wQ@mail.gmail.com>
On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> (adding Mike)
>
> On Thu, 15 Aug 2019 at 14:28, Chester Lin <clin@suse.com> wrote:
> >
> > Hi Ard,
> >
> > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > > >
> > > > Hello Chester,
> > > >
> > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
> > > > >
> > > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > > uncompressed kernel. For example, we got the following error message when
> > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > > >
> > > > > EFI stub: Booting Linux Kernel...
> > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > > > > EFI stub: ERROR: Failed to relocate kernel
> > > > >
> > > > > After checking the EFI memory map we found that the first page [0 - 0xfff]
> > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > > > > set the dram base at 0, which was actually in a reserved region.
> > > > >
> > > >
> > > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > > ARM when using the decompressor. The decompressor rounds down its own
> > > > base address to a multiple of 128 MB, and assumes the whole area is
> > > > available for the decompressed kernel and related data structures.
> > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > > this is fragile). Note that the decompressor does not look at any DT
> > > > or EFI provided memory maps *at all*.
> > > >
> > > > So unfortunately, this is not something we can fix in the kernel, but
> > > > we should fix it in the bootloader or in GRUB, so it does not put any
> > > > reserved regions in the first 128 MB of memory,
> > > >
> > >
> > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > > ARM boot protocol docs are unclear about whether this memory should be
> > > used or not, but it is no longer used for its original purpose (page
> > > tables), and the RPi loader already keeps data there.
> > >
> > > Can you check whether the following patch works for you?
> > >
> > > diff --git a/drivers/firmware/efi/libstub/Makefile
> > > b/drivers/firmware/efi/libstub/Makefile
> > > index 0460c7581220..ee0661ddb25b 100644
> > > --- a/drivers/firmware/efi/libstub/Makefile
> > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > > string.o random.o \
> > >
> > > lib-$(CONFIG_ARM) += arm32-stub.o
> > > lib-$(CONFIG_ARM64) += arm64-stub.o
> > > +CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > >
> > > #
> > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > > b/drivers/firmware/efi/libstub/arm32-stub.c
> > > index e8f7aefb6813..66ff0c8ec269 100644
> > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > @@ -204,7 +204,7 @@ efi_status_t
> > > handle_kernel_image(efi_system_table_t *sys_table,
> > > * loaded. These assumptions are made by the decompressor,
> > > * before any memory map is available.
> > > */
> > > - dram_base = round_up(dram_base, SZ_128M);
> > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;
> > >
> > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
> > > reserve_size);
> > >
> >
> > I tried your patch on rpi2 and got the following panic. Just a reminder that I
> > have replaced some log messages with "......" since it might be too long to
> > post all.
> >
>
> OK. Good to know that this change helps you to get past the EFI stub boot issue.
>
> > In this case the kernel failed to reserve cma, which should hit the issue of
> > memblock_limit=0x1000 as I had mentioned in my patch description. The first
> > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> > with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> > was extremely low. That's why I expand the first reservation from 1 PAGESIZE to
> > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> > if any suggestion, thank you.
> This looks like it is a separate issue. The memblock/cma code should
> not choke on a reserved page of memory at 0x0.
>
> Perhaps Russell or Mike (cc'ed) have an idea how to address this?
Presuming that the last memblock dump comes from the end of
arm_memblock_init() with the this memory map
memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
adjust_lowmem_bounds() will set the memblock_limit (and respectively global
memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
happily fail.
I believe that the assumption for memblock_limit calculations was that the
first bank has several megs at least.
I wonder if this hack would help:
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index d9a0038..948e5b9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
* allocated when mapping the start of bank 0, which
* occurs before any free memory is mapped.
*/
- if (!memblock_limit) {
+ if (memblock_limit < PMD_SIZE) {
if (!IS_ALIGNED(block_start, PMD_SIZE))
memblock_limit = block_start;
else if (!IS_ALIGNED(block_end, PMD_SIZE))
> > boot-log:
> > --------
> >
> > Loading Linux test ...
> > EFI stub: Booting Linux Kernel...
> > EFI stub: Using DTB from configuration table
> > EFI stub: Exiting boot services and installing virtual address map...
> > Uncompressing Linux... done, booting the kernel.
> > [ 0.000000] Booting Linux on physical CPU 0xf00
> > [ 0.000000] Linux version 5.2.1-lpae (chester@linux-8mug) (......)
> > [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
> > [ 0.000000] CPU: div instructions available: patching division code
> > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > [ 0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B Rev 1.1
> > [ 0.000000] printk: bootconsole [earlycon0] enabled
> > [ 0.000000] Memory policy: Data cache writealloc
> > [ 0.000000] efi: Getting EFI parameters from FDT:
> > [ 0.000000] efi: System Table: 0x000000003df757c0
> > [ 0.000000] efi: MemMap Address: 0x000000002c1c5040
> > [ 0.000000] efi: MemMap Size: 0x000003c0
> > [ 0.000000] efi: MemMap Desc. Size: 0x00000028
> > [ 0.000000] efi: MemMap Desc. Version: 0x00000001
> > [ 0.000000] efi: EFI v2.70 by Das U-Boot
> > [ 0.000000] efi: SMBIOS=0x3cb62000 MEMRESERVE=0x3cb3d040
> > [ 0.000000] memblock_reserve: [0x000000003cb3d040-0x000000003cb3d04f] efi_config_parse_tables+0x25c/0x2d8
> > [ 0.000000] efi: Processing EFI memory map:
> > [ 0.000000] MEMBLOCK configuration:
> > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x0000000000000010
> > [ 0.000000] memory.cnt = 0x1
> > [ 0.000000] memory[0x0] [0x0000000000000000-0x000000003dffffff], 0x000000003e000000 bytes flags: 0x0
> > [ 0.000000] reserved.cnt = 0x1
> > [ 0.000000] reserved[0x0] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > [ 0.000000] memblock_remove: [0x0000000000000000-0xfffffffffffffffe] reserve_regions+0x68/0x23c
> > [ 0.000000] efi: 0x000000000000-0x000000000fff [Reserved | | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000000000000-0x0000000000000fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000000001000-0x000000307fff [Conventional Memory| | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000000001000-0x0000000000307fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000000308000-0x000002307fff [Boot Data | | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000000308000-0x0000000002307fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000002308000-0x000002a93fff [Loader Data | | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000002308000-0x0000000002a93fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000002a94000-0x000007cf5fff [Conventional Memory| | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000002a94000-0x0000000007cf5fff] early_init_dt_add_memory_arch+0x164/0x178
> > ......
> > ......
> > [ 0.000000] memblock_add: [0x000000003df76000-0x000000003dffffff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x00003f100000-0x00003f100fff [Memory Mapped I/O |RUN| | | | | | | | | | | ]
> > [ 0.000000] memblock_reserve: [0x000000002c1c5000-0x000000002c1c5fff] efi_init+0xd8/0x1c8
> > [ 0.000000] memblock_reserve: [0x0000000000400000-0x0000000001df2cef] arm_memblock_init+0x44/0x19c
> > [ 0.000000] memblock_reserve: [0x0000000000303000-0x0000000000307fff] arm_mm_memblock_reserve+0x30/0x38
> > [ 0.000000] memblock_reserve: [0x0000000007cf6000-0x0000000007cfc5c4] early_init_dt_reserve_memory_arch+0x2c/0x30
> > [ 0.000000] cma: Failed to reserve 64 MiB
> > [ 0.000000] MEMBLOCK configuration:
> > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x00000000019ff2c5
> > [ 0.000000] memory.cnt = 0xa
> > [ 0.000000] memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> > [ 0.000000] memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> > [ 0.000000] memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> > [ 0.000000] memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
> > [ 0.000000] memory[0x4] [0x000000003cb3f000-0x000000003cb3ffff], 0x0000000000001000 bytes flags: 0x4
> > [ 0.000000] memory[0x5] [0x000000003cb40000-0x000000003cb5ffff], 0x0000000000020000 bytes flags: 0x0
> > [ 0.000000] memory[0x6] [0x000000003cb60000-0x000000003cb68fff], 0x0000000000009000 bytes flags: 0x4
> > [ 0.000000] memory[0x7] [0x000000003cb69000-0x000000003df74fff], 0x000000000140c000 bytes flags: 0x0
> > [ 0.000000] memory[0x8] [0x000000003df75000-0x000000003df75fff], 0x0000000000001000 bytes flags: 0x4
> > [ 0.000000] memory[0x9] [0x000000003df76000-0x000000003dffffff], 0x000000000008a000 bytes flags: 0x0
> > [ 0.000000] reserved.cnt = 0x5
> > [ 0.000000] reserved[0x0] [0x0000000000303000-0x0000000000307fff], 0x0000000000005000 bytes flags: 0x0
> > [ 0.000000] reserved[0x1] [0x0000000000400000-0x0000000001df2cef], 0x00000000019f2cf0 bytes flags: 0x0
> > [ 0.000000] reserved[0x2] [0x0000000007cf6000-0x0000000007cfc5c4], 0x00000000000065c5 bytes flags: 0x0
> > [ 0.000000] reserved[0x3] [0x000000002c1c5000-0x000000002c1c5fff], 0x0000000000001000 bytes flags: 0x0
> > [ 0.000000] reserved[0x4] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x0000000000000000 max_addr=0x0000000000000000 early_alloc+0x44/0x70
> > [ 0.000000] Kernel panic - not syncing: early_alloc: Failed to allocate 4096 bytes align=0x1000
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.1-lpae #1 openSUSE Tumbleweed (unreleased)
> > [ 0.000000] Hardware name: BCM2835
> > [ 0.000000] Backtrace:
> > [ 0.000000] [<c043fafc>] (dump_backtrace) from [<c043fd84>] (show_stack+0x20/0x24)
> > [ 0.000000] r7:c1800000 r6:00000000 r5:600001d3 r4:c1901ba0
> > [ 0.000000] [<c043fd64>] (show_stack) from [<c0df9400>] (dump_stack+0xd0/0x104)
> > [ 0.000000] [<c0df9330>] (dump_stack) from [<c048061c>] (panic+0xf8/0x32c)
> > [ 0.000000] r10:c0307000 r9:c0001000 r8:00000003 r7:00000000 r6:00000000 r5:c181df04
> > [ 0.000000] r4:c192b8d8 r3:00000001
> > [ 0.000000] [<c0480528>] (panic) from [<c1609728>] (early_alloc+0x60/0x70)
> > [ 0.000000] r3:00001000 r2:00001000 r1:c10037e8 r0:c12fe64c
> > [ 0.000000] r7:00000000
> > [ 0.000000] [<c16096c8>] (early_alloc) from [<c1609114>] (arm_pte_alloc+0x34/0x94)
> > [ 0.000000] r7:00000000 r6:00000000 r4:c0307000
> > [ 0.000000] [<c16090e0>] (arm_pte_alloc) from [<c1609384>] (__create_mapping+0x210/0x2c0)
> > [ 0.000000] r9:c0001000 r8:c0001000 r7:00000001 r6:c13f22e0 r5:c0200000 r4:c0400000
> > [ 0.000000] [<c1609174>] (__create_mapping) from [<c160951c>] (create_mapping+0xe8/0x108)
> > [ 0.000000] r10:c0400000 r9:c16a2110 r8:c19c7a80 r7:00000000 r6:00400000 r5:c13f2000
> > [ 0.000000] r4:c1801ef0
> > [ 0.000000] [<c1609434>] (create_mapping) from [<c1609f50>] (paging_init+0x350/0x75c)
> > [ 0.000000] r4:c1842d40
> >
> >
> > > >
> > > > > grub> lsefimmap
> > > > > Type Physical start - end #Pages Size Attributes
> > > > > reserved 0000000000000000-0000000000000fff 00000001 4KiB WB
> > > > > conv-mem 0000000000001000-0000000007ef5fff 00007ef5 130004KiB WB
> > > > > RT-data 0000000007ef6000-0000000007f09fff 00000014 80KiB RT WB
> > > > > conv-mem 0000000007f0a000-000000002d871fff 00025968 615840KiB WB
> > > > > .....
> > > > >
> > > > > To avoid a reserved address, we have to ignore the memory regions which are
> > > > > marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
> > > > > chosen. If the region before the kernel base is unaligned, it will be
> > > > > marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
> > > > > will not be sticked with a very low address such as 0x1000.
> > > > >
> > >
> > > This is a separate issue, so it should be handled in a separate patch.
> > >
> > > > > Signed-off-by: Chester Lin <clin@suse.com>
> > > > > ---
> > > > > arch/arm/mm/mmu.c | 3 ++
> > > > > drivers/firmware/efi/libstub/arm32-stub.c | 43 ++++++++++++++++++-----
> > > > > 2 files changed, 37 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > > index f3ce34113f89..909b11ba48d8 100644
> > > > > --- a/arch/arm/mm/mmu.c
> > > > > +++ b/arch/arm/mm/mmu.c
> > > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > > > phys_addr_t block_start = reg->base;
> > > > > phys_addr_t block_end = reg->base + reg->size;
> > > > >
> > > > > + if (memblock_is_nomap(reg))
> > > > > + continue;
> > > > > +
> > > > > if (reg->base < vmalloc_limit) {
> > > > > if (block_end > lowmem_limit)
> > > > > /*
> > > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > index e8f7aefb6813..10d33d36df00 100644
> > > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > @@ -128,7 +128,7 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > >
> > > > > for (l = 0; l < map_size; l += desc_size) {
> > > > > efi_memory_desc_t *desc;
> > > > > - u64 start, end;
> > > > > + u64 start, end, spare, kernel_base;
> > > > >
> > > > > desc = (void *)memory_map + l;
> > > > > start = desc->phys_addr;
> > > > > @@ -144,27 +144,52 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > > case EFI_BOOT_SERVICES_DATA:
> > > > > /* Ignore types that are released to the OS anyway */
> > > > > continue;
> > > > > -
> > > > > + case EFI_RESERVED_TYPE:
> > > > > + /* Ignore reserved regions */
> > > > > + continue;
> > > > > case EFI_CONVENTIONAL_MEMORY:
> > > > > /*
> > > > > * Reserve the intersection between this entry and the
> > > > > * region.
> > > > > */
> > > > > start = max(start, (u64)dram_base);
> > > > > - end = min(end, (u64)dram_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > + kernel_base = round_up(start, PMD_SIZE);
> > > > > + spare = kernel_base - start;
> > > > > + end = min(end, kernel_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > +
> > > > > + status = efi_call_early(allocate_pages,
> > > > > + EFI_ALLOCATE_ADDRESS,
> > > > > + EFI_LOADER_DATA,
> > > > > + MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE,
> > > > > + &kernel_base);
> > > > > + if (status != EFI_SUCCESS) {
> > > > > + pr_efi_err(sys_table_arg,
> > > > > + "reserve_kernel_base: alloc failed.\n");
> > > > > + goto out;
> > > > > + }
> > > > > + *reserve_addr = kernel_base;
> > > > >
> > > > > + if (!spare)
> > > > > + break;
> > > > > + /*
> > > > > + * If there's a gap between start and kernel_base,
> > > > > + * it needs be reserved so that the memblock_limit
> > > > > + * will not fall on a very low address when running
> > > > > + * adjust_lowmem_bounds(), wchich could eventually
> > > > > + * cause CMA reservation issue.
> > > > > + */
> > > > > status = efi_call_early(allocate_pages,
> > > > > EFI_ALLOCATE_ADDRESS,
> > > > > - EFI_LOADER_DATA,
> > > > > - (end - start) / EFI_PAGE_SIZE,
> > > > > + EFI_RESERVED_TYPE,
> > > > > + spare / EFI_PAGE_SIZE,
> > > > > &start);
> > > > > if (status != EFI_SUCCESS) {
> > > > > pr_efi_err(sys_table_arg,
> > > > > - "reserve_kernel_base(): alloc failed.\n");
> > > > > + "reserve spare-region failed\n");
> > > > > goto out;
> > > > > }
> > > > > - break;
> > > > >
> > > > > + break;
> > > > > case EFI_LOADER_CODE:
> > > > > case EFI_LOADER_DATA:
> > > > > /*
> > > > > @@ -220,7 +245,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > *image_size = image->image_size;
> > > > > status = efi_relocate_kernel(sys_table, image_addr, *image_size,
> > > > > *image_size,
> > > > > - dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > + *reserve_addr + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > if (status != EFI_SUCCESS) {
> > > > > pr_efi_err(sys_table, "Failed to relocate kernel.\n");
> > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > @@ -233,7 +258,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > * in memory. The kernel determines the base of DRAM from the
> > > > > * address at which the zImage is loaded.
> > > > > */
> > > > > - if (*image_addr + *image_size > dram_base + ZIMAGE_OFFSET_LIMIT) {
> > > > > + if (*image_addr + *image_size > *reserve_addr + ZIMAGE_OFFSET_LIMIT) {
> > > > > pr_efi_err(sys_table, "Failed to relocate kernel, no low memory available.\n");
> > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > *reserve_size = 0;
> > > > > --
> > > > > 2.22.0
> > > > >
> > >
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Christoph Hellwig @ 2019-08-15 13:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Gavin Li, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Laurentiu Tudor, Geoff Levand,
Shawn Guo, linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815130325.GB17065@kroah.com>
On Thu, Aug 15, 2019 at 03:03:25PM +0200, Greg Kroah-Hartman wrote:
> > --- a/include/linux/platform_device.h
> > +++ b/include/linux/platform_device.h
> > @@ -24,6 +24,7 @@ struct platform_device {
> > int id;
> > bool id_auto;
> > struct device dev;
> > + u64 dma_mask;
>
> Why is the dma_mask in 'struct device' which is part of this structure,
> not sufficient here? Shouldn't the "platform" be setting that up
> correctly already in the "archdata" type callback?
Becaus the dma_mask in struct device is a pointer that needs to point
to something, and this is the best space we can allocate for 'something'.
m68k and powerpc currently do something roughly equivalent at the moment,
while everyone else just has horrible, horrible hacks. As mentioned in
the changelog the intent of this patch is that we treat platform devices
like any other bus, where the bus allocates the space for the dma_mask.
The long term plan is to eventually kill that weird pointer indirection
that doesn't help anyone, but for that we need to sort out the basics
first.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox