* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Moritz Fischer @ 2016-11-16 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611161621260.20443@atull-VirtualBox2>
Hi Jason,
On Wed, Nov 16, 2016 at 2:28 PM, atull <atull@opensource.altera.com> wrote:
> On Wed, 16 Nov 2016, Jason Gunthorpe wrote:
>
>> On Wed, Nov 16, 2016 at 10:39:26AM -0800, Moritz Fischer wrote:
>> > > As you say, it is crystal clear already, and this is an acceptable commit
>> > > message.. Please suggest a text if you want to see something
>> > > different.
>> > >
>> >
>> > It still needs a long message. Just do it.
>>
>> Can I put your reviewed-by on this when I resend the series?
For this particular patch, feel free to add my Reviewed-By: after fixing
the long description. As Alan said there's currently a lot of patches
in flight and we're working on coming up with a better workflow.
Stay tuned.
>>
>> Will you have time to review the other patches this week?
>>
>> Jason
>>
>
> Hi Jason,
>
> I agree that this needs a long description and I'm not sure
> why you're pushing back on that.
>
> You will need to rebase this series on linux-next. I won't
> have much time this week to look at this, sorry. Not sure
> what the hurry is. I see the value of this, but things are
> busy right now. I'll be getting up to speed on how the
> kernel does sg and this is kind of a fundamental change to
> the API so I appreciate your patience.
Same here. We'll get prototypes next week, so I'm busy this week
and next week. I agree there's no massive hurry.
Thanks,
Moritz
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Guenter Roeck @ 2016-11-16 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Bd2X3pVqExBtBw_uHReDDkf6J2VdMXnAXynCAHxoX60A@mail.gmail.com>
On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> Hi Guenter,
>
> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Anyway, I guess the problem is that the "official" dtb files no longer provide
> > the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> > expect that they are provided. Is that correct ?
>
> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
Yes, but not the 'device_type' property, which the kernel seems to expect.
The qemu patch below fixes the problem for sabrelite, I just don't know
if that is really the way to go. You tell me; I'll be happy to submit
the necessary patch(es) into qemu.
The same is true for 'chosen'. Right now qemu expects this node to exist.
It does exist for sabrelite, but apparently not for imx25-pdk.
Guenter
---
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 1b913a4..080d1e5 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
g_free(nodename);
}
} else {
+ Error *err = NULL;
+
+ if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
+ qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
+ }
+
rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
acells, binfo->loader_start,
scells, binfo->ram_size);
^ permalink raw reply related
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: atull @ 2016-11-16 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116201720.GC19593@obsidianresearch.com>
On Wed, 16 Nov 2016, Jason Gunthorpe wrote:
> On Wed, Nov 16, 2016 at 10:39:26AM -0800, Moritz Fischer wrote:
> > > As you say, it is crystal clear already, and this is an acceptable commit
> > > message.. Please suggest a text if you want to see something
> > > different.
> > >
> >
> > It still needs a long message. Just do it.
>
> Can I put your reviewed-by on this when I resend the series?
>
> Will you have time to review the other patches this week?
>
> Jason
>
Hi Jason,
I agree that this needs a long description and I'm not sure
why you're pushing back on that.
You will need to rebase this series on linux-next. I won't
have much time this week to look at this, sorry. Not sure
what the hurry is. I see the value of this, but things are
busy right now. I'll be getting up to speed on how the
kernel does sg and this is kind of a fundamental change to
the API so I appreciate your patience.
Alan
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Fabio Estevam @ 2016-11-16 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116221002.GA19925@roeck-us.net>
Hi Guenter,
On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Anyway, I guess the problem is that the "official" dtb files no longer provide
> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> expect that they are provided. Is that correct ?
imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Guenter Roeck @ 2016-11-16 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116184649.GF11228@leverpostej>
On Wed, Nov 16, 2016 at 06:46:50PM +0000, Mark Rutland wrote:
> On Wed, Nov 16, 2016 at 09:45:35AM -0800, Guenter Roeck wrote:
> > Hi,
>
> Hi,
>
> > my 'sabrelite' and 'imx25-pdk' qemu boot tests are failing in linux-next.
> >
> > Bisect for the sabrelite failure points to commit 'ARM: dts: imx: Remove skeleton.dtsi'.
> >
> > Bisect log is attached. Complete test logs are at
> > http://kerneltests.org/builders/qemu-arm-next/builds/571/steps/qemubuildcommand/logs/stdio
> >
> > Boot log for imx25-pdk:
> >
> > qemu-system-arm: findnode_nofail Couldn't find node /chosen: FDT_ERR_NOTFOUND
>
> So this implies we no longer have a /chosen node. We should add one to
> the relevant dts{i,} files, with stdout-path and so on.
>
> > Boot log for sabrelite:
> >
> > [ 0.000000] Booting Linux on physical CPU 0x0
> > [ 0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck at jupiter.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Tue Nov 15 22:34:35 PST 2016
> > [ 0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
> > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > [ 0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
> > [ 0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
> > [ 0.000000] bootconsole [ec_imx21] enabled
> > [ 0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
> > [ 0.000000] cma: Failed to reserve 64 MiB
> > [ 0.000000] Memory policy: Data cache writeback
> >
> > [ stuck here until aborted ]
>
> The last message was from build_mem_types_table(), called from
> paging_init(). We'll head on to unflatten_device_tree() shortly
> afterwards.
>
> I wonder if the DTB is corrupted somehow in this case. Maybe the initrd
> and cma failures is due to unparseable memory nodes.
>
This appears to be quite messed up. There should be an initrd.
Here is the log with memblock=debug.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.0-rc5-next-20161116 (groeck at server.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Wed Nov 16 13:05:32 PST 2016
[ 0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[ 0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[ 0.000000] bootconsole [ec_imx21] enabled
[ 0.000000] memblock_reserve: [0x00000010100000-0x00000011680737] flags 0x0 arm_memblock_init+0x28/0x190
[ 0.000000] INITRD: 0x14000000+0x00501600 is not a memory region - disabling initrd
[ 0.000000] memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
[ 0.000000] memblock_reserve: [0x00000014502000-0x0000001451885b] flags 0x0 early_init_dt_reserve_memory_arch+0x20/0x24
[ 0.000000] cma: Failed to reserve 64 MiB
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x0 reserved size = 0x159af94
[ 0.000000] memory.cnt = 0x1
[ 0.000000] memory[0x0] [0x00000000000000-0xffffffffffffffff], 0x0 bytes flags: 0x0
[ 0.000000] reserved.cnt = 0x3
[ 0.000000] reserved[0x0] [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x00000010100000-0x00000011680737], 0x1580738 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x00000014502000-0x0000001451885b], 0x1685c bytes flags: 0x0
[ 0.000000] Memory policy: Data cache writeback
Memory size is obviously a bit on the high side.
Here is the log after reverting the 'offenting' patch:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.0-rc5-next-20161116-00001-g3e6c6cb5519b (groeck at server.roeck-us.net) (gcc version 4.9.2 (GCC) ) #1 SMP Wed Nov 16 13:14:07 PST 2016
[ 0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Freescale i.MX6 DualLite SABRE Lite Board
[ 0.000000] earlycon: ec_imx21 at MMIO 0x021e8000 (options '')
[ 0.000000] bootconsole [ec_imx21] enabled
[ 0.000000] memblock_reserve: [0x00000010100000-0x00000011680737] flags 0x0 arm_memblock_init+0x28/0x190
[ 0.000000] memblock_reserve: [0x00000014000000-0x000000145015ff] flags 0x0 arm_memblock_init+0x108/0x190
[ 0.000000] memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
[ 0.000000] memblock_reserve: [0x00000014502000-0x00000014518883] flags 0x0 early_init_dt_reserve_memory_arch+0x20/0x24
[ 0.000000] cma: Failed to reserve 64 MiB
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x8000000 reserved size = 0x1a9c5bc
[ 0.000000] memory.cnt = 0x1
[ 0.000000] memory[0x0] [0x00000010000000-0x00000017ffffff], 0x8000000 bytes flags: 0x0
[ 0.000000] reserved.cnt = 0x4
[ 0.000000] reserved[0x0] [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x00000010100000-0x00000011680737], 0x1580738 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x00000014000000-0x000000145015ff], 0x501600 bytes flags: 0x0
[ 0.000000] reserved[0x3] [0x00000014502000-0x00000014518883], 0x16884 bytes flags: 0x0
Turns out cma allocation fails because the qemu default memory size for
sabrelite is 128MB, which isn't enough, or not enough anymore. That doesn't
seem to matter, though, as the boot succeeds without it (but only if I _don't_
set memblock=debug on the command line)
Anyway, I guess the problem is that the "official" dtb files no longer provide
the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
expect that they are provided. Is that correct ?
Thanks,
Guenter
^ permalink raw reply
* [PATCH 1/2] staging: vc04_services: remove duplicate mutex_lock_interruptible
From: Eric Anholt @ 2016-11-16 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116154139.3703209-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The driver tries to redefine mutex_lock_interruptible as an open-coded
> mutex_lock_killable, but that definition clashes with the normal
> mutex_lock_interruptible definition when CONFIG_DEBUG_LOCK_ALLOC
> is set:
These two are:
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161116/a24ca915/attachment.sig>
^ permalink raw reply
* [PATCH V2 0/2] ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-11-16 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479318727-9425-1-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> This patch series should fix and extend the patch V4 "ARM: bcm2835: Add names
> for the Raspberry Pi GPIO lines" from Linus Walleij and Eric Anholt.
>
> Changes in V2:
> - fix URL to firmware DT blob
> - drop dtsi file since Model A+ and Zero aren't identical
Pulled. Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161116/b13780d4/attachment.sig>
^ permalink raw reply
* [PATCH V8 0/6] thermal: bcm2835: add thermal driver
From: Eric Anholt @ 2016-11-16 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479214212.2224.24.camel@intel.com>
Zhang Rui <rui.zhang@intel.com> writes:
> On Fri, 2016-11-11 at 09:01 -0800, Eric Anholt wrote:
>> kernel at martin.sperl.org writes:
>>
>> >
>> > From: Martin Sperl <kernel@martin.sperl.org>
>> Since Eduardo seems to be AFK, I've pulled this series to my -next
>> branches.
> I will take the thermal soc patches this time if we still don't have
> response from Eduardo by the end of this week.
>
> For this patches set, will you queue them up or do you prefer to go via
> thermal tree?
I was queuing up the entire series (including the driver) through the
SOC trees.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161116/44f00e23/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Doug Anderson @ 2016-11-16 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115223900.30728-3-heiko@sntech.de>
Heiko,
On Tue, Nov 15, 2016 at 2:38 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> The General Register Files are an area of registers containing a lot
> of single-bit settings for numerous components as well full components
> like usbphy control. Therefore all used components are accessed
> via the syscon provided by the grf nodes or from the sub-devices
> created through the simple-mfd created from the grf node.
>
> Some settings are not used by anything but will need to be set up
> according to expectations on the kernel side.
>
> Best example is the force_jtag setting, which defaults to on and
> results in the soc switching the pin-outputs between jtag and sdmmc
> automatically depending on the card-detect status. This conflicts
> heavily with how the dw_mmc driver expects to do its work and also
> with the clock-controller, which has most likely deactivated the
> jtag clock due to it being unused.
>
> So far the handling of this setting was living in the mach-rockchip
> code for the arm32-based rk3288 but that of course doesn't work
> for arm64 socs and would also look ugly for further arm32 socs.
>
> Also always disabling this setting is quite specific to linux and
> its subsystems, other operating systems might prefer other settings,
> so that the bootloader cannot really set a sane default for all.
>
> So introduce a top-level driver for the grf that handles these
> settings that need to be a certain way but nobody cares about.
>
> Other needed settings might surface in the future and can then
> be added here, but only as a last option. Ideally general GRF
> settings should be handled in the driver needing them.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/soc/rockchip/Kconfig | 10 ++++
> drivers/soc/rockchip/Makefile | 1 +
> drivers/soc/rockchip/grf.c | 134 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 145 insertions(+)
Other than the header file stuff pointed out by Shawn, this looks good
to me now.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Maxime Ripard @ 2016-11-16 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108153752.a17440e784f2e3993c79ee69@free.fr>
On Tue, Nov 08, 2016 at 03:37:52PM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 23:37:41 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Fri, Oct 28, 2016 at 07:34:20PM +0200, Jean-Francois Moine wrote:
> > > On Fri, 28 Oct 2016 00:03:16 +0200
> > > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> [snip]
> > > > > > We've been calling them bus and mod.
> > > > >
> > > > > I can understand "bus" (which is better than "apb"), but why "mod"?
> > > >
> > > > Allwinner has been calling the clocks that are supposed to generate
> > > > the external signals (depending on where you were looking) module or
> > > > mod clocks (which is also why we have mod in the clock
> > > > compatibles). The module 1 clocks being used for the audio and the
> > > > module 0 for the rest (SPI, MMC, NAND, display, etc.)
> > >
> > > I did not find any 'module' in the H3 documentation.
> > > So, is it really a good name?
> >
> > It's true that they use it less nowadays, but they still do,
> > ie. https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L513
>
> There is a 'mod' suffix, but it is used for the bus gates only, not for
> the main clocks.
>
> > And we have to remain consistent anyway.
>
> I don't see any consistency in the H3 DT:
> - the bus gates are named "ahb" and apb"
We've been inconsistent in the past, hence why it would be great to
have bus instead.
> - the (main) clocks are named "mmc", "usb0_phy" and "ir"
> There is no "bus" nor "mod".
Look into the other devices, for other SoCs. Pointing out that we've
been bad in the past doesn't mean that we can't improve.
> > > > > > > +
> > > > > > > +- resets: phandle to the reset of the device
> > > > > > > +
> > > > > > > +- ports: phandle's to the LCD ports
> > > > > >
> > > > > > Please use the OF graph.
> > > > >
> > > > > These ports are references to the graph of nodes. See
> > > > > http://www.kernelhub.org/?msg=911825&p=2
> > > >
> > > > In an OF-graph, your phandle to the LCD controller would be replaced
> > > > by an output endpoint.
> > >
> > > This is the DE controller. There is no endpoint link at this level.
> >
> > The display engine definitely has an endpoint: the TCON.
>
> Not at all. The video chain is simply
> CRTC (TCON) -> connector (HDMI/LCD/DAC/..)
> The DE is an ancillary device which handles the planes.
And what does it do exactly with those planes? It outputs it to the
TCON.
> > > The Device Engine just handles the planes of the LCDs, but, indeed,
> > > the LCDs must know about the DE and the DE must know about the LCDs.
> > > There are 2 ways to realize this knowledge in the DT:
> > > 1) either the DE has one or two phandle's to the LCDs,
> > > 2) or the LCDs have a phandle to the DE.
> > >
> > > I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
> > > which is part of the video link (OF-graph LCD <-> connector).
> > > It would be possible to have phandles to the LCDs themselves, but this
> > > asks for more code.
> > >
> > > The second way is also possible, but it also complexifies a bit the
> > > exchanges DE <-> LCD.
> >
> > I'm still not sure how it would complexify anything, and why you can't
> > use the display graph to model the relation between the display engine
> > and the TCON (and why you want to use a generic property that refers
> > to the of-graph while it really isn't).
>
> Complexification:
> 1- my solution:
> At startup time, the DE device is the DRM device.
How do you deal with SoCs with multiple display engines then?
> It has to know the devices entering in the video chains.
> The CRTCs (LCD/TCON) are found by
> ports[i] -> parent
> The connectors are found by
> ports[i] -> endpoint -> remote_endpoint -> parent
> 2- with ports pointing to the LCDs:
> The CRTCs (LCD/TCON) are simply
> ports[i]
> The connectors are found by
> loop on all ports of ports[i]
> ports[i][j] -> endpoint -> remote_endpoint -> parent
> 3- with a phandle to the DE in the LCDs:
What do you mean with LCD? Panels? Why would panels have a phandle to
the display engine?
> The DE cannot be the DRM device because there is no information about
> the video devices in the DT. Then, the DRM devices are the LCDs.
> These LCDs must give their indices to the DE. So, the DE must implement
> some callback function to accept a LCD definition, and there must be
> a list of DEs in the driver to make the association DE <-> LCD[i]
> Some more problem may be raised if a user wants to have the same frame
> buffer on the 2 LCDs of a DE.
I have no idea what you're talking about, sorry.
> Anyway, my solution is already used in the IMX Soc.
> See 'display-subsystem' in arch/arm/boot/dts/imx6q.dtsi for an example.
Pointing out random example in the tree doesn't make a compelling
argument.
> > > > > > > +void de2_disable_vblank(struct drm_device *drm, unsigned crtc)
> > > > > > > +{
> > > > > > > + struct priv *priv = drm->dev_private;
> > > > > > > + struct lcd *lcd = priv->lcds[crtc];
> > > > > > > +
> > > > > > > + tcon_write(lcd->mmio, gint0,
> > > > > > > + tcon_read(lcd->mmio, gint0) &
> > > > > > > + ~TCON_GINT0_TCON1_Vb_Int_En);
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* panel functions */
> > > > > >
> > > > > > Panel functions? In the CRTC driver?
> > > > >
> > > > > Yes, dumb panel.
> > > >
> > > > What do you mean by that? Using a Parallel/RGB interface?
> > >
> > > Sorry, I though this was a well-known name. The 'dump panel' was used
> > > in the documentation of my previous ARM machine as the video frame sent
> > > to the HDMI controller. 'video_frame' is OK for you?
> >
> > If it's the frame sent to the encoder, then it would be the CRTC by
> > DRM's nomenclature.
>
> The CRTC is a software entity. The frame buffer is a hardware entity.
Why are you about framebuffer now, this is nowhere in that
discussion. Any way, the framebuffer is also what is put in a plane,
so there's a name collision here, and you'll probably want to change
it.
Judging by the previous discussion, this should really be called
encoder if it encodes the frames on a bus format, or CRTC if it
composes the planes.
> > > > > > > +static const struct {
> > > > > > > + char chan;
> > > > > > > + char layer;
> > > > > > > + char pipe;
> > > > > > > +} plane2layer[DE2_N_PLANES] = {
> > > > > > > + [DE2_PRIMARY_PLANE] = {0, 0, 0},
> > > > > > > + [DE2_CURSOR_PLANE] = {1, 0, 1},
> > > > > > > + [DE2_VI_PLANE] = {0, 1, 0},
> > > > > > > +};
> [snip]
> > > > > >
> > > > > > Comments?
> > > > >
> > > > > This
> > > > > primary plane is channel 0 (VI), layer 0, pipe 0
> > > > > cursor plane is channel 1 (UI), layer 0, pipe 1
> > > > > overlay plane is channel 0 (VI), layer 1, pipe 0
> > > > > or the full explanation:
> > > > > Constraints:
> > > > > The VI channels can do RGB or YUV, while UI channels can do RGB
> > > > > only.
> > > > > The LCD 0 has 1 VI channel and 4 UI channels, while
> > > > > LCD 1 has only 1 VI channel and 1 UI channel.
> > > > > The cursor must go to a channel bigger than the primary channel,
> > > > > otherwise it is not transparent.
> > > > > First try:
> > > > > Letting the primary plane (usually RGB) in the 2nd channel (UI),
> > > > > as this is done in the legacy driver, asks for the cursor to go
> > > > > to the next channel (UI), but this one does not exist in LCD1.
> > > > > Retained layout:
> > > > > So, we must use only 2 channels for the same behaviour on LCD0
> > > > > (H3) and LCD1 (A83T)
> > > > > The retained combination is:
> > > > > - primary plane in the first channel (VI),
> > > > > - cursor plane inthe 2nd channel (UI), and
> > > > > - overlay plane in the 1st channel (VI).
> > > > >
> > > > > Note that there could be 3 overlay planes (a channel has 4
> > > > > layers), but I am not sure that the A83T or the H3 could
> > > > > support 3 simultaneous video streams...
> > > >
> > > > Do you know if the pipe works in the old display engine?
> > > >
> > > > Especially about the two-steps composition that wouldn't allow you to
> > > > have alpha on all the planes?
> > > >
> > > > If it is similar, I think hardcoding the pipe number is pretty bad,
> > > > because that would restrict the combination of planes and formats,
> > > > while some other might have worked.
> > >
> > > From what I understood about the DE2, the pipes just define the priority
> > > of the overlay channels (one pipe for one channel).
> > > With the cursor constraint, there must be at least 2 channels in
> > > order (primary, cursor). Then, with these 2 channels/pipes, there can be
> > > 6 so-called overlay planes (3 RGB/YUV and 3 RGB only).
> > > Enabling the pipes 2 and 3 (LCD 0 only) would offer 8 more planes, but
> > > RGB only. Then, it might be useful to have dynamic pipes.
> >
> > That's very valuable (and definitely should go into a comment),
> > thanks!
> >
> > I still believe that's it should be into a (simple at first)
> > atomic_check. That would be easier to extend and quite easy to
> > document and get simply by looking at the code.
>
> Sorry for I don't understand what you mean.
You can check all the constraints you exposed above in atomic_check
instead of hardcoding it.
> > > > > > > +static int __init de2_drm_init(void)
> > > > > > > +{
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > +/* uncomment to activate the drm traces at startup time */
> > > > > > > +/* drm_debug = DRM_UT_CORE | DRM_UT_DRIVER | DRM_UT_KMS |
> > > > > > > + DRM_UT_PRIME | DRM_UT_ATOMIC; */
> > > > > >
> > > > > > That's useless.
> > > > >
> > > > > Right, but it seems that some people don't know how to debug a DRM
> > > > > driver. This is only a reminder.
> > > > >
> > > > > > > + DRM_DEBUG_DRIVER("\n");
> > > > > > > +
> > > > > > > + ret = platform_driver_register(&de2_lcd_platform_driver);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + ret = platform_driver_register(&de2_drm_platform_driver);
> > > > > > > + if (ret < 0)
> > > > > > > + platform_driver_unregister(&de2_lcd_platform_driver);
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > >
> > > > > > And that really shouldn't be done that way.
> > > > >
> > > > > May you explain?
> > > >
> > > > This goes against the whole idea of the device and driver
> > > > model. Drivers should only register themselves, device should be
> > > > created by buses (or by using some external components if the bus
> > > > can't: DT, ACPI, etc.). If there's a match, you get probed.
> > > >
> > > > A driver that creates its own device just to probe itself violates
> > > > that.
> > >
> > > In this function (module init), there is no driver yet.
> > > The module contains 2 drivers: the DE (planes) and the LCD (CRTC),
> > > and there is no macro to handle such modules.
> >
> > Ah, yes, my bad. I thought you were registering a device and a
> > driver. Still this is a very unusual pattern. Why do you need to split
> > the two? Can't you just merge them?
>
> The DE and the LCDs are different devices on different drivers.
> A DE must be only one device because it has to handle concurent
> accesses from its 2 LCDs. Then 2 drivers.
If it's different drivers, why are they in the same module?
> But only one module. Why? Because there cannot be double direction
> calls from one module to an other one, and, in our case, for example,
> - the DRM (DE) device must call vblank functions which are handled in
> the CRTC (TCON) device, and
> - the CRTC device must call DE initialization functions at startup time.
I'm sorry, but that doesn't make any sense. The crtc device should
take care of the CRTC functions. Your DRM CRTC and encoders can
definitely be shared across different devices, you can have a look at
how we're doing it for sun4i.
We basically have 3 drivers to create most of the display pipeline:
- One for the DRM device
- One for the display engine
- One for the TCON
Once they have all loaded and registered in the component framework,
their bind callback is called, and it's when the DRM entities are
created using exported functions to manipulate what needs to be setup.
It's definitely doable, it just takes some effort.
> > > > > > > +int de2_plane_init(struct drm_device *drm, struct lcd *lcd)
> > > > > > > +{
> > > > > > > + int ret, possible_crtcs = 1 << lcd->crtc_idx;
> > > > > > > +
> > > > > > > + ret = de2_one_plane_init(drm, &lcd->planes[DE2_PRIMARY_PLANE],
> > > > > > > + DRM_PLANE_TYPE_PRIMARY, possible_crtcs,
> > > > > > > + ui_formats, ARRAY_SIZE(ui_formats));
> > > > > > > + if (ret >= 0)
> > > > > > > + ret = de2_one_plane_init(drm, &lcd->planes[DE2_CURSOR_PLANE],
> > > > > > > + DRM_PLANE_TYPE_CURSOR, possible_crtcs,
> > > > > > > + ui_formats, ARRAY_SIZE(ui_formats));
> > > > > >
> > > > > > Nothing looks really special about that cursor plane. Any reasion not
> > > > > > to make it an overlay?
> > > > >
> > > > > As explained above (channel/layer/pipe plane definitions), the cursor
> > > > > cannot go in a channel lower or equal to the one of the primary plane.
> > > > > Then, it must be known and, so, have an explicit plane.
> > > >
> > > > If you were to make it a plane, you could use atomic_check to check
> > > > this and make sure this doesn't happen. And you would gain a generic
> > > > plane that can be used for other purposes if needed.
> > >
> > > The function drm_crtc_init_with_planes() offers a cursor plane for free.
> > > On the other side, having 6 overlay planes is more than the SoCs can
> > > support.
> >
> > It's not really for free, it costs you a generic plane that could
> > definitely be used for something else and cannot anymore because
> > they've been hardcoded to a cursor.
> >
> > And having a camera, the VPU or even an application directly output
> > directly into one of these planes seems a much better use of a generic
> > plane than a cursor.
>
> Looking at the harder case (A83T), there may be 8 planes on 2 channels.
> Using a primary plane and the cursor,
> 8 planes - primary plane - cursor plane = 6 planes
> 6 planes are available.
> If I count correctly, in your example:
> one camera + one VPU + one application = 3 planes
> 3 planes are used.
> So, 3 planes are still available.
>
> On the other side, removing the cursor would just let one more plane.
> Do we really need this one? In other words, I'd be pleased to know how
> you run 7 applications doing video overlay.
You can use those planes to do composition too, with each application
having one or more plane. Android uses that.
There's no argument to have a cursor plane, really. Even regular
graphic stack like X can use a regular overlay to have its cursor on
it. It doesn't *remove* anything, it just allows to use the plane for
what it was supposed to be used for.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161116/98fa4f0f/attachment.sig>
^ permalink raw reply
* [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Scott Wood @ 2016-11-16 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB1925E935B4E7F5D1D1E521D5F5BE0@DB5PR0401MB1925.eurprd04.prod.outlook.com>
On 11/16/2016 05:33 AM, Sriram Dash wrote:
>> From: Scott Wood
>> On 11/15/2016 06:39 AM, Sriram Dash wrote:
>>>> From: Scott Wood
>>>> On 11/13/2016 11:27 PM, Sriram Dash wrote:
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>>>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>>>> new file mode 100644
>>>>> index 0000000..d934c80
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>>>> @@ -0,0 +1,36 @@
>>>>> +Driver for Freescale USB 3.0 PHY
>>>>> +
>>>>> +Required properties:
>>>>> +
>>>>> +- compatible : fsl,qoriq-usb3-phy
>>>>
>>>
>>> Hi Scott,
>>>
>>>> This is a very vague compatible. Are there versioning registers
>>>> within this register block?
>>>>
>>>
>>> There are versioning registers for the phy (1.0 and 1.1). But the
>>> current erratum
>>> A008751 does not require the mentioning of the version numbers. Was
>>> planning to take care of the versioning when there is code diversity
>>> on the basis of the version number.
>>
>> That is not how device tree bindings work. The describe the hardware, not the
>> driver.
>>
>> That said, is the block version sufficient to tell whether a given chip has this
>> erratum? If so, you don't need a special property for the erratum. If not, what is
>> different about the PHY that is not described by the versioning?
Can you find out the answer to this?
>> In any case, it would be nice to mention the version register and its offset in the
>> binding, just so that it becomes part of the definition of this compatible string, and
>> if we come out with some QorIQ chip with a
>> USB3 PHY that is totally different and doesn't have that version register, it'll be
>> clear that it needs a different compatible.
>>
>
> Okay. Will include version number in the next rev for Documentation and dt.
I'm not asking you to put the version number in the dt if it can be read
from a register. I'm asking you to have the binding describe the
version register, as part of the definition of what "fsl,qoriq-usb3-phy"
means.
>>> The only reason for __raw_writel is to make the code faster.
>>
>> Does that really matter here?
>>
>>> However, shall I use writel(with both barriers and byte swap) instead
>>
>> Yes, if the registers are little-endian on all chips.
>>
>
> The endianness is not same for all Socs. But for most Socs, it is big-endian.
> Is "iowrite32be" better instead?
Then the device tree node needs to say what endian it is, and you need
to choose the appropriate accessor at runtime.
But is it really big endian for most or even any SoCs? This hardware
isn't present on our PPC chips, right (I checked a couple of the most
recent PPC RMs and it shows USB 2.0 only)? So it'd just be the few ARM
chips that made almost everything big endian, and even there the couple
RMs I checked (ls1021a and ls1043a) have these registers described as
little-endian.
>>> and then make appropriate changes in the value 32'h27672B2A?
>>
>> Not sure what you mean here.
>>
>>> In my knowledge, there are more than 5 errata in pipeline,
>>
>> Then please get all of these errata described in the device tree ASAP (unless their
>> presence can be reliably inferred from the block version, as discussed above).
>>
>
> Yes. We will push the errata asap.
My point is that the device tree node should be complete when you submit
it. Don't wait for the implementation of a workaround to advertise the
existence of an erratum in the device tree.
-Scott
^ permalink raw reply
* [PATCH 1/1] ARM: dts: enable GPIO-b for Broadcom NSP
From: Florian Fainelli @ 2016-11-16 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479130219-25639-1-git-send-email-yendapally.reddy@broadcom.com>
On 11/14/2016 05:30 AM, Yendapally Reddy Dhananjaya Reddy wrote:
> This enables the GPIO-b support for Broadcom NSP SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Applied, thanks
--
Florian
^ permalink raw reply
* [PATCH devicetree/next] ARM: BCM5301X: Add DT for TP-LINK Archer C9 V1
From: Florian Fainelli @ 2016-11-16 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113101209.22185-1-zajec5@gmail.com>
On 11/13/2016 02:12 AM, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> It's BCM4709A0 based device with 16 MiB flash, 128 MiB of RAM and two
> PCIe based on-PCB BCM4360 chipsets.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
Applied, thanks!
--
Florian
^ permalink raw reply
* [PATCH v1 3/3] ARM: dts: Add node for Broadcom OTP controller driver
From: Florian Fainelli @ 2016-11-16 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477336324-10543-4-git-send-email-jonathan.richardson@broadcom.com>
On 10/24/2016 12:12 PM, Jonathan Richardson wrote:
> From: Jonathan Richardson <jonathar@broadcom.com>
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Oza Pawandeep <oza@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Applied, thanks
--
Florian
^ permalink raw reply
* [PATCH v1 4/4] ARM: dts: Enable interrupt support for cygnus crmu gpio driver
From: Florian Fainelli @ 2016-11-16 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476817238-1226-5-git-send-email-jonathan.richardson@broadcom.com>
On 10/18/2016 12:00 PM, Jonathan Richardson wrote:
> The M0 processor handles interrupts for the always-on CRMU GPIO
> controller. Setting the CRMU GPIO driver with the mailbox controller as
> the interrupt parent allows the mailbox controller to forward interrupts
> from the M0 to the GPIO driver for processing.
>
> Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Reviewed-by: Vikram Prakash <vikram.prakash@broadcom.com>
> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Applied, thanks
--
Florian
^ permalink raw reply
* [PATCH v1 3/4] ARM: dts: Enable Broadcom iProc mailbox controller
From: Florian Fainelli @ 2016-11-16 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476817238-1226-4-git-send-email-jonathan.richardson@broadcom.com>
On 10/18/2016 12:00 PM, Jonathan Richardson wrote:
> Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Reviewed-by: Vikram Prakash <vikram.prakash@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Applied, thanks
--
Florian
^ permalink raw reply
* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Maxime Ripard @ 2016-11-16 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116141841.2030776-1-arnd@arndb.de>
Hi Arnd,
On Wed, Nov 16, 2016 at 03:18:18PM +0100, Arnd Bergmann wrote:
> gcc warns about a way that it could use an uninitialized variable:
>
> drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
> drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
> zero, and both of these are forbidden. To shut up the warning anyway,
> this changes the logic to initialize the return code to the first
> divider value before looking at the others.
>
> Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks for that patch.
Just out of curiosity, which gcc gives those warnings? I have 6.2 and
it didn't output anything..
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161116/1ea0fcf3/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y
From: Ard Biesheuvel @ 2016-11-16 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116192331.2jwpewu33dwji3fa@pengutronix.de>
On 16 November 2016 at 19:23, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> On Thu, Oct 27, 2016 at 05:27:08PM +0100, Ard Biesheuvel wrote:
>> This series is a followup to the single patch 'modversions: treat symbol
>> CRCs as 32 bit quantities on 64 bit archs', of which two versions have
>> been sent out so far [0][1]
>>
>> As pointed out by Michael, GNU ld behaves a bit differently between arm64
>> and PowerPC64, and where the former gets rid of all runtime relocations
>> related to CRCs, the latter is not as easily convinced.
>>
>> Patch #1 fixes the issue where CRCs are corrupted by the runtime relocation
>> routines for 32-bit PowerPC, for which the original fix was effectively
>> reverted by commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix
>> causes perf issues")
>>
>> Patch #2 adds handling of R_PPC64_ADDR32 relocations against the NULL .dynsym
>> symbol entry to the PPC64 runtime relocation routines, so it is prepared to
>> deal with CRCs being emitted as 32-bit quantities.
>>
>> Patch #3 is the original patch from the v1 and v2 submissions.
>
> Is this related to me seeing
>
> [ 2.111424] mvneta: module verification failed: signature and/or required key missing - tainting kernel
> [ 2.126061] scsi_mod: no symbol version for _clear_bit
> [ 2.131257] scsi_mod: Unknown symbol _clear_bit (err -22)
> [ 2.138093] mvneta: no symbol version for _clear_bit
> [ 2.143117] mvneta: Unknown symbol _clear_bit (err -22)
> [ 2.144135] mvmdio: no symbol version for __gnu_mcount_nc
> [ 2.144138] mvmdio: Unknown symbol __gnu_mcount_nc (err -22)
> ...
>
> ? If so, this would be great to mention it in the commit log to make
> people searching for this issue actually find this patch set.
>
No, I don't think it is. My guess would be that it is caused by
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4dd1837d75
^ permalink raw reply
* [PATCH fpga 8/9] fpga socfpga: Use the scatterlist interface
From: Jason Gunthorpe @ 2016-11-16 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611160939140.3364@atull-VirtualBox2>
On Wed, Nov 16, 2016 at 09:45:23AM -0600, atull wrote:
> > What is the point of this if write_init gets a copy of the buffer -
> > what is that supposed to be?
>
> Sometimes write_init needs to look at the header of the image.
> You can see that in the socfpga-a10.c (on linux-next/master)
I know what it is for, I'm asking what should it be if we are calling
write_init multiple times.
It feels like the driver needs to indicate the header length it wants
to inspect and the core core needs to make that much of the bitstream
available to write_init() before calling write().
Is that what you were thinking?
> at this stuff, this is coming at a busy time). My point there
> was that there was code that needed to go into the core so that
> the ICE40 and the cyclone spi driver that are on the mailing
> list won't have to have the same workaround that you were
> adding to the socfpga.c driver.
Sure, that is easy for write() - not clear on write_init sematics?
I will send a revised series.
I'd also like to close on the zynq bitfile verification patch, did you
have any comments on that?
Jason
^ permalink raw reply
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Jason Gunthorpe @ 2016-11-16 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116183926.GA14341@live.com>
On Wed, Nov 16, 2016 at 10:39:26AM -0800, Moritz Fischer wrote:
> > As you say, it is crystal clear already, and this is an acceptable commit
> > message.. Please suggest a text if you want to see something
> > different.
> >
>
> It still needs a long message. Just do it.
Can I put your reviewed-by on this when I resend the series?
Will you have time to review the other patches this week?
Jason
^ permalink raw reply
* [PATCH 1/3 v4] ARM: dts: rename MSM8660/APQ8060 pmicintc to pm8058
From: Linus Walleij @ 2016-11-16 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478508284-10847-1-git-send-email-linus.walleij@linaro.org>
On Mon, Nov 7, 2016 at 9:44 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The name "pmicintc" is ambiguous: there is a second power
> management IC named PM8901 on these systems, and it is also
> an interrupt controller. To make things clear, just name the
> node alias "pm8058", this in unambigous and has all information
> we need.
>
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v4:
> - Add Bjorn's ACK.
> - Follow version numbering of the primary patch.
Are these three patches getting applied?
I don't see them in -next or anything...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/1] drivers: dma-contiguous: Ensure cma reserve region never cross the low/high mem boundary
From: Laura Abbott @ 2016-11-16 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479305975-21670-1-git-send-email-jason.hui.liu@nxp.com>
On 11/16/2016 06:19 AM, Jason Liu wrote:
> If the cma reserve region goes through the device-tree method,
> also need ensure the cma reserved region not cross the low/high
> mem boundary. This patch did the similar fix as commit:16195dd
> ("mm: cma: Ensure that reservations never cross the low/high mem boundary")
>
> Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/base/dma-contiguous.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index e167a1e1..2bc093c 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -244,6 +244,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
> {
> phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
> phys_addr_t mask = align - 1;
> + phys_addr_t highmem_start;
> unsigned long node = rmem->fdt_node;
> struct cma *cma;
> int err;
> @@ -256,6 +257,32 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
> pr_err("Reserved memory: incorrect alignment of CMA region\n");
> return -EINVAL;
> }
> +#ifdef CONFIG_X86
> + /*
> + * high_memory isn't direct mapped memory so retrieving its physical
> + * address isn't appropriate. But it would be useful to check the
> + * physical address of the highmem boundary so it's justfiable to get
> + * the physical address from it. On x86 there is a validation check for
> + * this case, so the following workaround is needed to avoid it.
> + */
> + highmem_start = __pa_nodebug(high_memory);
> +#else
> + highmem_start = __pa(high_memory);
> +#endif
The inline #ifdef is not great style, we shouldn't be spreading it around.
> +
> + /*
> + * All pages in the reserved area must come from the same zone.
> + * If the reserved region crosses the low/high memory boundary,
> + * try to fix it up and then fall back to allocate from the low mem
> + */
> + if (rmem->base < highmem_start &&
> + (rmem->base + rmem->size) > highmem_start) {
> + memblock_free(rmem->base, rmem->size);
> + rmem->base = memblock_alloc_range(rmem->size, align, 0,
> + highmem_start, MEMBLOCK_NONE);
> + if (!rmem->base)
> + return -ENOMEM;
> + }
Given the alloc happened in the of code, it seems bad form to be
bringing the free and re-alloc here. Perhaps we should be doing the
limiting and checking in the reserved mem code?
If there is no other solution, at the least this deserves a pr_warn
so users know why a reason specified may not be getting requested.
>
> err = cma_init_reserved_mem(rmem->base, rmem->size, 0, &cma);
> if (err) {
>
Thanks,
Laura
^ permalink raw reply
* [PATCH v2] arm/arm64: KVM: VGIC: limit ITARGETSR bits to number of VCPUs
From: Christoffer Dall @ 2016-11-16 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116175716.31578-1-andre.przywara@arm.com>
On Wed, Nov 16, 2016 at 05:57:16PM +0000, Andre Przywara wrote:
> The GICv2 spec says in section 4.3.12 that a "CPU targets field bit that
> corresponds to an unimplemented CPU interface is RAZ/WI."
> Currently we allow the guest to write any value in there and it can
> read that back.
> Mask the written value with the proper CPU mask to be spec compliant.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
^ permalink raw reply
* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Linus Walleij @ 2016-11-16 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116141841.2030776-1-arnd@arndb.de>
On Wed, Nov 16, 2016 at 3:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc warns about a way that it could use an uninitialized variable:
>
> drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
> drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
> zero, and both of these are forbidden. To shut up the warning anyway,
> this changes the logic to initialize the return code to the first
> divider value before looking at the others.
>
> Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Allwinner late DT changes for 4.10
From: Linus Walleij @ 2016-11-16 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115210034.mwqnsggmmbzoav77@lukather>
On Tue, Nov 15, 2016 at 10:00 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Here is a pull request that should be merged after the pinctrl PR,
> hence probably in your late PR.
>
> This is just a mechanic conversion to the generic pinconf bindings and
> removal of the useless pinmux properties we had.
This pull request:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
And much encouraged as an awesome cleanup.
Yours,
Linus Walleij
^ 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