* [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
* [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 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 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 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
* 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
* 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
* [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: 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: 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
* [PATCH] net: bcm63xx_enet: fix build failure
From: Sudip Mukherjee @ 2016-11-16 22:50 UTC (permalink / raw)
To: linux-arm-kernel
The build of mips bcm63xx_defconfig was failing with the error:
drivers/net/ethernet/broadcom/bcm63xx_enet.c:1440:2:
error: expected expression before 'return'
The return statement should be termibated with ';' and not ','.
Fixes: 42469bf5d9bb ("net: bcm63xx_enet: Utilize phy_ethtool_nway_reset")
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
---
build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/176269457
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a43ab90..3b14d51 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1435,7 +1435,7 @@ static int bcm_enet_nway_reset(struct net_device *dev)
priv = netdev_priv(dev);
if (priv->has_phy)
- return phy_ethtool_nway_reset(dev),
+ return phy_ethtool_nway_reset(dev);
return -EOPNOTSUPP;
}
--
1.9.1
^ permalink raw reply related
* [PATCH] net: bcm63xx_enet: fix build failure
From: David Miller @ 2016-11-16 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479336616-26500-1-git-send-email-sudipm.mukherjee@gmail.com>
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date: Wed, 16 Nov 2016 22:50:16 +0000
> The build of mips bcm63xx_defconfig was failing with the error:
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:1440:2:
> error: expected expression before 'return'
>
> The return statement should be termibated with ';' and not ','.
>
> Fixes: 42469bf5d9bb ("net: bcm63xx_enet: Utilize phy_ethtool_nway_reset")
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Already fixes in the current net-next tree.
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Fabio Estevam @ 2016-11-16 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116224024.GA11821@roeck-us.net>
On Wed, Nov 16, 2016 at 8:40 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> 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.
I can send the patch adding device_type for the i.MX dts files, but in
the meantime, it would be nice if you could send your proposal patch
to qemu as it will make qemu to work closer to the real hardware.
Thanks
> 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.
We can fix this too in the dts.
Thanks
^ permalink raw reply
* [PATCH v3 0/3] Rockchip: generalize GRF setup
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
The General register files contain a big bunch of settings for various
components. Things like the automatic sdmmc/jtag switch may even affect
us in a bad way, while that property (and possibly others) are not even
part of the dw_mmc controller itself.
And while the rk3288 could still carry adaptions to these defaults
in its mach files, this is no longer possible on the arm64 socs, while
things like the jtag-switch from above still can affect us there.
changes in v3:
- remove duplicate regmap header (now they're even sorted alphabetically)
- add Dougs Review-tag from v2
- fix the of_find_matching_node_and_match being over 80 chars
changes in v2:
- address comments from Doug Anderson
- drop platform device, as we actual probing may happen at some
unspecified later time during boot
- add reviews / acks received in v1
Heiko Stuebner (3):
dt-bindings: add used but undocumented rockchip grf compatible values
soc: rockchip: add driver handling grf setup
ARM: rockchip: drop rk3288 jtag/mmc switch handling
.../devicetree/bindings/soc/rockchip/grf.txt | 4 +
arch/arm/mach-rockchip/rockchip.c | 12 --
drivers/soc/rockchip/Kconfig | 10 ++
drivers/soc/rockchip/Makefile | 1 +
drivers/soc/rockchip/grf.c | 133 +++++++++++++++++++++
5 files changed, 148 insertions(+), 12 deletions(-)
create mode 100644 drivers/soc/rockchip/grf.c
--
2.10.2
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: add used but undocumented rockchip grf compatible values
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116230304.8432-1-heiko@sntech.de>
There are some more General Register Files used in devicetree files
already, but as of now undocumented in the binding document, fix that.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/grf.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index 013e71a..c6e62cb 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -5,11 +5,13 @@ is composed of many registers for system control.
From RK3368 SoCs, the GRF is divided into two sections,
- GRF, used for general non-secure system,
+- SGRF, used for general secure system,
- PMUGRF, used for always on system
Required Properties:
- compatible: GRF should be one of the followings
+ - "rockchip,rk3036-grf", "syscon": for rk3036
- "rockchip,rk3066-grf", "syscon": for rk3066
- "rockchip,rk3188-grf", "syscon": for rk3188
- "rockchip,rk3228-grf", "syscon": for rk3228
@@ -19,6 +21,8 @@ Required Properties:
- compatible: PMUGRF should be one of the followings
- "rockchip,rk3368-pmugrf", "syscon": for rk3368
- "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- compatible: SGRF should be one of the following
+ - "rockchip,rk3288-sgrf", "syscon": for rk3288
- reg: physical base address of the controller and length of memory mapped
region.
--
2.10.2
^ permalink raw reply related
* [PATCH v3 2/3] soc: rockchip: add driver handling grf setup
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116230304.8432-1-heiko@sntech.de>
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>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---
drivers/soc/rockchip/Kconfig | 10 ++++
drivers/soc/rockchip/Makefile | 1 +
drivers/soc/rockchip/grf.c | 133 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 144 insertions(+)
create mode 100644 drivers/soc/rockchip/grf.c
diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
index 7140ff8..20da55d 100644
--- a/drivers/soc/rockchip/Kconfig
+++ b/drivers/soc/rockchip/Kconfig
@@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
#
# Rockchip Soc drivers
#
+
+config ROCKCHIP_GRF
+ bool
+ default y
+ help
+ The General Register Files are a central component providing
+ special additional settings registers for a lot of soc-components.
+ In a lot of cases there also need to be default settings initialized
+ to make some of them conform to expectations of the kernel.
+
config ROCKCHIP_PM_DOMAINS
bool "Rockchip generic power domain"
depends on PM
diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
index 3d73d06..c851fa0 100644
--- a/drivers/soc/rockchip/Makefile
+++ b/drivers/soc/rockchip/Makefile
@@ -1,4 +1,5 @@
#
# Rockchip Soc drivers
#
+obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
new file mode 100644
index 0000000..190b0ed
--- /dev/null
+++ b/drivers/soc/rockchip/grf.c
@@ -0,0 +1,134 @@
+/*
+ * Rockchip Generic Register Files setup
+ *
+ * Copyright (c) 2016 Heiko Stuebner <heiko@sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/err.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define HIWORD_UPDATE(val, mask, shift) \
+ ((val) << (shift) | (mask) << ((shift) + 16))
+
+struct rockchip_grf_value {
+ const char *desc;
+ u32 reg;
+ u32 val;
+};
+
+struct rockchip_grf_info {
+ const struct rockchip_grf_value *values;
+ int num_values;
+};
+
+#define RK3036_GRF_SOC_CON0 0x140
+
+static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
+ /*
+ * Disable auto jtag/sdmmc switching that causes issues with the
+ * clock-framework and the mmc controllers making them unreliable.
+ */
+ { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11) },
+};
+
+static const struct rockchip_grf_info rk3036_grf __initconst = {
+ .values = rk3036_defaults,
+ .num_values = ARRAY_SIZE(rk3036_defaults),
+};
+
+#define RK3288_GRF_SOC_CON0 0x244
+
+static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
+ { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12) },
+};
+
+static const struct rockchip_grf_info rk3288_grf __initconst = {
+ .values = rk3288_defaults,
+ .num_values = ARRAY_SIZE(rk3288_defaults),
+};
+
+#define RK3368_GRF_SOC_CON15 0x43c
+
+static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
+ { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13) },
+};
+
+static const struct rockchip_grf_info rk3368_grf __initconst = {
+ .values = rk3368_defaults,
+ .num_values = ARRAY_SIZE(rk3368_defaults),
+};
+
+#define RK3399_GRF_SOC_CON7 0xe21c
+
+static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
+ { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12) },
+};
+
+static const struct rockchip_grf_info rk3399_grf __initconst = {
+ .values = rk3399_defaults,
+ .num_values = ARRAY_SIZE(rk3399_defaults),
+};
+
+static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
+ {
+ .compatible = "rockchip,rk3036-grf",
+ .data = (void *)&rk3036_grf,
+ }, {
+ .compatible = "rockchip,rk3288-grf",
+ .data = (void *)&rk3288_grf,
+ }, {
+ .compatible = "rockchip,rk3368-grf",
+ .data = (void *)&rk3368_grf,
+ }, {
+ .compatible = "rockchip,rk3399-grf",
+ .data = (void *)&rk3399_grf,
+ },
+ { /* sentinel */ },
+};
+
+static int __init rockchip_grf_init(void)
+{
+ const struct rockchip_grf_info *grf_info;
+ const struct of_device_id *match;
+ struct device_node *np;
+ struct regmap *grf;
+ int ret, i;
+
+ np = of_find_matching_node_and_match(NULL, rockchip_grf_dt_match,
+ &match);
+ if (!np)
+ return -ENODEV;
+ if (!match || !match->data) {
+ pr_err("%s: missing grf data\n", __func__);
+ return -EINVAL;
+ }
+
+ grf_info = match->data;
+
+ grf = syscon_node_to_regmap(np);
+ if (IS_ERR(grf)) {
+ pr_err("%s: could not get grf syscon\n", __func__);
+ return PTR_ERR(grf);
+ }
+
+ for (i = 0; i < grf_info->num_values; i++) {
+ const struct rockchip_grf_value *val = &grf_info->values[i];
+
+ pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
+ val->desc, val->reg, val->val);
+ ret = regmap_write(grf, val->reg, val->val);
+ if (ret < 0)
+ pr_err("%s: write to %#6x failed with %d\n",
+ __func__, val->reg, ret);
+ }
+
+ return 0;
+}
+postcore_initcall(rockchip_grf_init);
--
2.10.2
^ permalink raw reply related
* [PATCH v3 3/3] ARM: rockchip: drop rk3288 jtag/mmc switch handling
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116230304.8432-1-heiko@sntech.de>
We moved that functionality to a more generic place where it can also
be used for other socs, so drop it from architecture code.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
---
arch/arm/mach-rockchip/rockchip.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c
index e7fdf06..0008783 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -29,13 +29,11 @@
#include "core.h"
#include "pm.h"
-#define RK3288_GRF_SOC_CON0 0x244
#define RK3288_TIMER6_7_PHYS 0xff810000
static void __init rockchip_timer_init(void)
{
if (of_machine_is_compatible("rockchip,rk3288")) {
- struct regmap *grf;
void __iomem *reg_base;
/*
@@ -54,16 +52,6 @@ static void __init rockchip_timer_init(void)
} else {
pr_err("rockchip: could not map timer7 registers\n");
}
-
- /*
- * Disable auto jtag/sdmmc switching that causes issues
- * with the mmc controllers making them unreliable
- */
- grf = syscon_regmap_lookup_by_compatible("rockchip,rk3288-grf");
- if (!IS_ERR(grf))
- regmap_write(grf, RK3288_GRF_SOC_CON0, 0x10000000);
- else
- pr_err("rockchip: could not get grf syscon\n");
}
of_clk_init(NULL);
--
2.10.2
^ permalink raw reply related
* [PATCH] Replacement for Arm initrd memblock reserve and free inconsistency.
From: Russell King - ARM Linux @ 2016-11-16 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <592F4D3D062D79449F140027567F70E8FE0810D3@exchmbx03>
On Tue, Nov 15, 2016 at 03:45:55PM +0000, william.helsby at stfc.ac.uk wrote:
> The option of moving the initrd code later (after
> early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem() )
> was tested.
Moving stuff around tends to break...
I'd prefer to do it this way, as it's much more readable (and we prize
readability... see Documentation/CodingStyle.)
arch/arm/mm/init.c | 71 +++++++++++++++++++++++++++++++++---------------------
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..ffae20b25929 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -227,6 +227,48 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
return phys;
}
+static void __init arm_initrd_init(void)
+{
+#ifdef CONFIG_BLK_DEV_INITRD
+ unsigned long size;
+ phys_addr_t start;
+
+ /* FDT scan will populate initrd_start */
+ if (initrd_start && !phys_initrd_size) {
+ phys_initrd_start = __virt_to_phys(initrd_start);
+ phys_initrd_size = initrd_end - initrd_start;
+ }
+
+ initrd_start = initrd_end = 0;
+
+ if (!phys_initrd_size)
+ return;
+
+ start = phys_initrd_start & PAGE_MASK;
+ size = PAGE_ALIGN(phys_initrd_size + phys_initrd_start - start);
+
+ if (!memblock_is_region_memory(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ if (memblock_is_region_reserved(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ memblock_reserve(start, size);
+
+ /* Now convert initrd to virtual addresses */
+ initrd_start = __phys_to_virt(phys_initrd_start);
+ initrd_end = initrd_start + phys_initrd_size;
+#endif
+}
+
void __init arm_memblock_init(const struct machine_desc *mdesc)
{
/* Register the kernel text, kernel data and initrd with memblock. */
@@ -235,34 +277,7 @@ void __init arm_memblock_init(const struct machine_desc *mdesc)
#else
memblock_reserve(__pa(_stext), _end - _stext);
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
- /* FDT scan will populate initrd_start */
- if (initrd_start && !phys_initrd_size) {
- phys_initrd_start = __virt_to_phys(initrd_start);
- phys_initrd_size = initrd_end - initrd_start;
- }
- initrd_start = initrd_end = 0;
- if (phys_initrd_size &&
- !memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size &&
- memblock_is_region_reserved(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size) {
- memblock_reserve(phys_initrd_start, phys_initrd_size);
-
- /* Now convert initrd to virtual addresses */
- initrd_start = __phys_to_virt(phys_initrd_start);
- initrd_end = initrd_start + phys_initrd_size;
- }
-#endif
-
+ arm_initrd_init();
arm_mm_memblock_reserve();
/* reserve any platform specific memblock areas */
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Jason Gunthorpe @ 2016-11-16 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611161621260.20443@atull-VirtualBox2>
On Wed, Nov 16, 2016 at 04:28:27PM -0600, atull wrote:
> I agree that this needs a long description and I'm not sure
> why you're pushing back on that.
*shurg* it is just an unusual thing to ask for, but it is OK for a
subsystem to have a particular style like this. Other subsystems
do not.
I will add "This makes the driver prints display properly."
> 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.
The merge window is opening soon so it would be nice to land some of
this in 4.10.
Since I have to rebase and restructure a chunk of it, I'd like to get
the bulk of the broad feedback collected before doing that..
Jason
^ permalink raw reply
* [PATCH v2] input: touchscreen: silead: Add regulator support
From: Dmitry Torokhov @ 2016-11-17 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cdc827c1-f5ba-27b8-b7d0-4489fbd6da28@redhat.com>
On Wed, Nov 16, 2016 at 07:58:26PM +0100, Hans de Goede wrote:
> HI,
>
> On 16-11-16 18:51, Dmitry Torokhov wrote:
> >On Wed, Nov 16, 2016 at 12:55:07PM +0100, Hans de Goede wrote:
> >>On some tablets the touchscreen controller is powered by separate
> >>regulators, add support for this.
> >>
> >>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>Acked-by: Rob Herring <robh@kernel.org>
> >>---
> >>Changes in v2:
> >>-Use devm_regulator_bulk_get() and friends
> >>-Use devm_add_action_or_reset() to disable the regulator
> >>---
> >> .../bindings/input/touchscreen/silead_gsl1680.txt | 2 ++
> >> drivers/input/touchscreen/silead.c | 29 ++++++++++++++++++++++
> >> 2 files changed, 31 insertions(+)
> >>
> >>diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> >>index e844c3f..b726823 100644
> >>--- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> >>+++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> >>@@ -22,6 +22,8 @@ Optional properties:
> >> - touchscreen-inverted-y : See touchscreen.txt
> >> - touchscreen-swapped-x-y : See touchscreen.txt
> >> - silead,max-fingers : maximum number of fingers the touchscreen can detect
> >>+- vddio-supply : regulator phandle for controller VDDIO
> >>+- avdd-supply : regulator phandle for controller AVDD
> >>
> >> Example:
> >>
> >>diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> >>index f502c84..404830a 100644
> >>--- a/drivers/input/touchscreen/silead.c
> >>+++ b/drivers/input/touchscreen/silead.c
> >>@@ -29,6 +29,7 @@
> >> #include <linux/input/touchscreen.h>
> >> #include <linux/pm.h>
> >> #include <linux/irq.h>
> >>+#include <linux/regulator/consumer.h>
> >>
> >> #include <asm/unaligned.h>
> >>
> >>@@ -73,6 +74,7 @@ struct silead_ts_data {
> >> struct i2c_client *client;
> >> struct gpio_desc *gpio_power;
> >> struct input_dev *input;
> >>+ struct regulator_bulk_data regulators[2];
> >> char fw_name[64];
> >> struct touchscreen_properties prop;
> >> u32 max_fingers;
> >>@@ -433,6 +435,13 @@ static int silead_ts_set_default_fw_name(struct silead_ts_data *data,
> >> }
> >> #endif
> >>
> >>+static void silead_disable_regulator(void *arg)
> >>+{
> >>+ struct silead_ts_data *data = arg;
> >>+
> >>+ regulator_bulk_disable(ARRAY_SIZE(data->regulators), data->regulators);
> >>+}
> >>+
> >> static int silead_ts_probe(struct i2c_client *client,
> >> const struct i2c_device_id *id)
> >> {
> >>@@ -465,6 +474,26 @@ static int silead_ts_probe(struct i2c_client *client,
> >> if (client->irq <= 0)
> >> return -ENODEV;
> >>
> >>+ data->regulators[0].supply = "vddio";
> >>+ data->regulators[1].supply = "avdd";
> >>+ error = devm_regulator_bulk_get(dev, ARRAY_SIZE(data->regulators),
> >>+ data->regulators);
> >>+ if (error)
> >>+ return error;
> >>+
> >>+ /*
> >>+ * Enable regulators at probe and disable them at remove, we need
> >>+ * to keep the chip powered otherwise it forgets its firmware.
> >>+ */
> >
> >Hmm, this burns power though. Why can't we reload firmware on resume (it
> >should be already cached)?
>
> We already put the device in low-power mode using the power pin. Of the
> 20 or so different tablets I've with this touchscreen controller only
> 2 actually have a separate regulator for the controller, so I do not
> believe that powering down the regulator will be a big win, otherwise
> all tablets would have had this.
>
> > Does it take too long?
>
> It is a couple of kB written one 32-bit word at a time over i2c, so
> it's not fast.
OK, fair enough. Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH v2 1/3] driver: nvmem: Add ocotp driver support for imx6ul
From: Bai Ping @ 2016-11-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
i.MX6UL is an new SOC of i.MX6 family. Enable ocotp
driver support for this SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
drivers/nvmem/imx-ocotp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index ac27b9b..108e4bc 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -73,6 +73,7 @@ static int imx_ocotp_read(void *context, unsigned int offset,
{ .compatible = "fsl,imx6q-ocotp", (void *)128 },
{ .compatible = "fsl,imx6sl-ocotp", (void *)32 },
{ .compatible = "fsl,imx6sx-ocotp", (void *)128 },
+ { .compatible = "fsl,imx6ul-ocotp", (void *)128 },
{ },
};
MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] devicetree: bindings: nvmem: Add compatible string for imx6ul
From: Bai Ping @ 2016-11-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479344899-3141-1-git-send-email-ping.bai@nxp.com>
Add new compatible string for i.MX6UL SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
Changes for V2:
- reformat the changes suggested by Rob Herring
Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
index 383d588..966a72e 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
@@ -1,13 +1,15 @@
Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
This binding represents the on-chip eFuse OTP controller found on
-i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs.
+i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs.
Required properties:
- compatible: should be one of
"fsl,imx6q-ocotp" (i.MX6Q/D/DL/S),
"fsl,imx6sl-ocotp" (i.MX6SL), or
- "fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon".
+ "fsl,imx6sx-ocotp" (i.MX6SX),
+ "fsl,imx6ul-ocotp" (i.MX6UL),
+ followed by "syscon".
- reg: Should contain the register base and length.
- clocks: Should contain a phandle pointing to the gated peripheral clock.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: imx: Add ocotp node for imx6ul
From: Bai Ping @ 2016-11-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479344899-3141-1-git-send-email-ping.bai@nxp.com>
Add ocotp node for i.MX6UL SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index c5c05fd..c6f6613 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -849,6 +849,12 @@
reg = <0x021b0000 0x4000>;
};
+ ocotp: ocotp-ctrl at 021bc000 {
+ compatible = "fsl,imx6ul-ocotp", "syscon";
+ reg = <0x021bc000 0x4000>;
+ clocks = <&clks IMX6UL_CLK_OCOTP>;
+ };
+
lcdif: lcdif at 021c8000 {
compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
reg = <0x021c8000 0x4000>;
--
1.9.1
^ permalink raw reply related
* [PATCH] iommu: mtk: add common-clk dependency
From: Honghui Zhang @ 2016-11-17 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116193850.GK25626@codeaurora.org>
On Wed, 2016-11-16 at 11:38 -0800, Stephen Boyd wrote:
> On 11/16, Arnd Bergmann wrote:
> > After the MT2701 clock driver was added, we get a harmless warning for
> > the iommu driver that selects it, when compile-testing without
> > COMMON_CLK.
> >
> > warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_IMGSYS which has unmet direct dependencies (COMMON_CLK)
> >
> > Adding a dependency on COMMON_CLK avoids the warning.
> >
> > Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Hm.. why is an iommu driver selecting a clk driver? They should
> be using standard clk APIs so it's not like they need it for
> build time correctness. Shouldn't we drop the selects instead?
> Those look to have been introduced a few kernel versions ago, but
> they were selecting options that didn't exist until a few days
> ago when I merged the mediatek clk driver. The clk options are
> user-visible, so it should be possible to select them in the
> configuration phase.
>
Hi, Stephen,
I'm a bit out of date of the current clock code. Mediatek IOMMU v1
driver will need smi driver to enable iommu clients. And smi driver is
also respond to enable/disable the susbsys clocks for multi-media HW.
The relationship between iommu and smi is like the graphics below[1].
EMI (External Memory Interface)
|
m4u (Multimedia Memory Management Unit)
|
SMI Common(Smart Multimedia Interface Common)
|
+----------------+-------
| |
| |
SMI larb0 SMI larb1 ... SoCs have several SMI local
arbiter(larb).
(display) (vdec)
| |
| |
+-----+-----+ +----+----+
| | | | | |
| | |... | | | ... There are different ports in each
larb.
| | | | | |
OVL0 RDMA0 WDMA0 MC PP VLD
When enable SMI driver it will need those subsys clock provider.
But those clocks providers are disabled in default. Since it's needed by
smi driver, and smi was select by MTK_IOMMU_V1, I figure it should be
select by MTK_IOMMU_V1 too.
[1]Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
thanks.
> ----8<----
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 8ee54d71c7eb..37e204f3d9be 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -352,9 +352,6 @@ config MTK_IOMMU_V1
> select IOMMU_API
> select MEMORY
> select MTK_SMI
> - select COMMON_CLK_MT2701_MMSYS
> - select COMMON_CLK_MT2701_IMGSYS
> - select COMMON_CLK_MT2701_VDECSYS
> help
> Support for the M4U on certain Mediatek SoCs. M4U generation 1 HW is
> Multimedia Memory Managememt Unit. This option enables remapping of
>
^ permalink raw reply
* [PATCH] ARM: dt: imx31: fix AVIC base address
From: Vladimir Zapolskiy @ 2016-11-17 1:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
On i.MX31 AVIC interrupt controller base address is at 0x68000000.
The problem was shadowed by the AVIC driver, which takes the correct
base address from a SoC specific header file.
Fixes: d2a37b3d91f4 ("ARM i.MX31: Add devicetree support")
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
arch/arm/boot/dts/imx31.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index c534c1f..179335b 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -31,11 +31,11 @@
};
};
- avic: avic-interrupt-controller at 60000000 {
+ avic: interrupt-controller at 68000000 {
compatible = "fsl,imx31-avic", "fsl,avic";
interrupt-controller;
#interrupt-cells = <1>;
- reg = <0x60000000 0x100000>;
+ reg = <0x68000000 0x100000>;
};
soc {
--
2.10.2
^ permalink raw reply related
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