* [GIT PULL 5/5] ARM: exynos: mach/soc for v4.18
From: Olof Johansson @ 2018-05-14 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-6-krzk@kernel.org>
On Sun, May 13, 2018 at 05:42:38PM +0200, Krzysztof Kozlowski wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.18
>
> for you to fetch changes up to 9ad9a2183bf51da7f8840f2e7087816c0fc8c91d:
>
> ARM: exynos: Remove unused soc_is_exynos{4,5} (2018-05-13 14:07:03 +0200)
>
> ----------------------------------------------------------------
> Samsung mach/soc changes for v4.18
>
> 1. Remove at24_platform_data in S3C2440.
> 2. Fix invalid SPDX identifier.
> 3. Remove Exynos5440 entirely.
> 4. Cleanups.
> 5. Remove static mapping of SCU SFR and rely on DTS.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 4/5] arm64: dts: exynos: Stuff for v4.18
From: Olof Johansson @ 2018-05-14 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-5-krzk@kernel.org>
On Sun, May 13, 2018 at 05:42:37PM +0200, Krzysztof Kozlowski wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.18
>
> for you to fetch changes up to 8dd6203f32f20cb83469eb859efded9e403b3e9f:
>
> arm64: dts: exynos: Add mem-2-mem Scaler devices (2018-05-13 11:26:13 +0200)
>
> ----------------------------------------------------------------
> Samsung DTS ARM64 changes for v4.18
>
> 1. Fix DTC warnings.
> 2. Add mem-2-mem Scaler devices.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 3/5] ARM: dts: exynos: Stuff for v4.18
From: Olof Johansson @ 2018-05-14 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-4-krzk@kernel.org>
On Sun, May 13, 2018 at 05:42:36PM +0200, Krzysztof Kozlowski wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.18
>
> for you to fetch changes up to 83cb529b2ef4f3446e60e75522d76fdaaea4724c:
>
> ARM: dts: exynos: Update x and y properties for mms114 touchscreen (2018-05-13 15:15:49 +0200)
>
> ----------------------------------------------------------------
> Samsung DTS ARM changes for v4.18
>
> 1. Add support for USB OTG port on Origen board.
> 2. Allow earlycon on Rinato board.
> 3. Cleanup from obsolete properties.
> 4. Fix DTC warnings.
> 5. Remove Exynos5440 entirely.
> 6. Add mem-2-mem Scaler devices.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 2/5] soc: samsung: Stuff for v4.18
From: Olof Johansson @ 2018-05-14 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-3-krzk@kernel.org>
On Sun, May 13, 2018 at 05:42:35PM +0200, Krzysztof Kozlowski wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-4.18
>
> for you to fetch changes up to b2b568c591ddbb20d597e256212579d70dbf3000:
>
> soc: samsung: pm_domains: Deprecate support for clocks (2018-04-17 17:25:42 +0200)
>
> ----------------------------------------------------------------
> Samsung soc drivers changes for v4.18
>
> 1. Clock operations during power domain on/off were moved to respective
> clock driver so clean up obsolete code from power domain driver.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 1/5] ARM: defconfig: Exynos for v4.18
From: Olof Johansson @ 2018-05-14 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-2-krzk@kernel.org>
On Sun, May 13, 2018 at 05:42:34PM +0200, Krzysztof Kozlowski wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.18
>
> for you to fetch changes up to b0121046cacdbc99475871aceb2e9e57995c2ba1:
>
> ARM: multi_v7_config: enable S6E63J0X03 panel driver (2018-04-16 20:22:28 +0200)
>
> ----------------------------------------------------------------
> Samsung defconfig changes for v4.18
>
> 1. Enable Samsung S6E63J0X03 DSI panel.
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Peter Rosin @ 2018-05-14 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514162828.GE28661@phenom.ffwll.local>
On 2018-05-14 18:28, Daniel Vetter wrote:
> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>> On 2018-05-10 10:10, Andrzej Hajda wrote:
>>> On 04.05.2018 15:52, Peter Rosin wrote:
>>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>>> down along with the bridge. Thus, there will no longer linger any
>>>> dangling pointers from the bridge consumer (the drm_device) to some
>>>> non-existent bridge supplier.
>>>>
>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>> ---
>>>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
>>>> include/drm/drm_bridge.h | 2 ++
>>>> 2 files changed, 20 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>> index 78d186b6831b..0259f0a3ff27 100644
>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>> @@ -26,6 +26,7 @@
>>>> #include <linux/mutex.h>
>>>>
>>>> #include <drm/drm_bridge.h>
>>>> +#include <drm/drm_device.h>
>>>> #include <drm/drm_encoder.h>
>>>>
>>>> #include "drm_crtc_internal.h"
>>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
>>>> if (bridge->dev)
>>>> return -EBUSY;
>>>>
>>>> + if (encoder->dev->dev != bridge->odev) {
>>>
>>> I wonder why device_link_add does not handle this case (self dependency)
>>> silently as noop, as it seems to be a correct behavior.
>>
>> It's kind-of a silly corner-case though, so perfectly understandable
>> that it isn't handled.
>>
>>>> + bridge->link = device_link_add(encoder->dev->dev,
>>>> + bridge->odev, 0);
>>>> + if (!bridge->link) {
>>>> + dev_err(bridge->odev, "failed to link bridge to %s\n",
>>>> + dev_name(encoder->dev->dev));
>>>> + return -EINVAL;
>>>> + }
>>>> + }
>>>> +
>>>> bridge->dev = encoder->dev;
>>>> bridge->encoder = encoder;
>>>>
>>>> if (bridge->funcs->attach) {
>>>> ret = bridge->funcs->attach(bridge);
>>>> if (ret < 0) {
>>>> + if (bridge->link)
>>>> + device_link_del(bridge->link);
>>>> + bridge->link = NULL;
>>>> bridge->dev = NULL;
>>>> bridge->encoder = NULL;
>>>> return ret;
>>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>>> if (bridge->funcs->detach)
>>>> bridge->funcs->detach(bridge);
>>>>
>>>> + if (bridge->link)
>>>> + device_link_del(bridge->link);
>>>> + bridge->link = NULL;
>>>> +
>>>> bridge->dev = NULL;
>>>> }
>>>>
>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>> index b656e505d11e..804189c63a4c 100644
>>>> --- a/include/drm/drm_bridge.h
>>>> +++ b/include/drm/drm_bridge.h
>>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>>> * @list: to keep track of all added bridges
>>>> * @timings: the timing specification for the bridge, if any (may
>>>> * be NULL)
>>>> + * @link: drm consumer <-> bridge supplier
>>>
>>> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
>>> to the bridge" would be better.
>>
>> I meant "<->" to indicate that the link is bidirectional, not that the
>> relationship is in any way symmetric. I wasn't aware of any implication
>> of a symmetric relationship when using "<->", do you have a reference?
>> But I guess the different arrow notations in math are somewhat overloaded
>> and that someone at some point must have used "<->" to indicate a
>> symmetric relationship...
>
> Yeah I agree with Andrzej here, for me <-> implies a symmetric
> relationship. Spelling it out like Andrzej suggested sounds like the
> better idea.
> -Daniel
Ok, I guess that means I have to do a v3 after all. Or can this
trivial documentation update be done by the committer? I hate to
spam everyone with another volley...
Or perhaps I should squash patches 2-23 that are all rather similar
and mechanic? I separated them to allow for easier review from
individual driver maintainers, but that didn't seem to happen
anyway...
Cheers,
Peter
>
>>
>>> Anyway:
>>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
>>
>> Thanks!
>>
>> Cheers,
>> Peter
>>
>>> ?--
>>> Regards
>>> Andrzej
>>>
>>>> * @funcs: control functions
>>>> * @driver_private: pointer to the bridge driver's internal context
>>>> */
>>>> @@ -271,6 +272,7 @@ struct drm_bridge {
>>>> struct drm_bridge *next;
>>>> struct list_head list;
>>>> const struct drm_bridge_timings *timings;
>>>> + struct device_link *link;
>>>>
>>>> const struct drm_bridge_funcs *funcs;
>>>> void *driver_private;
>>>
>>>
>>
>
^ permalink raw reply
* [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
From: Paul Kocialkowski @ 2018-05-14 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511085938.wjmdsdjfvdxd4shk@flea>
Hi,
Le vendredi 11 mai 2018 ? 10:59 +0200, Maxime Ripard a ?crit :
> On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > > as found on the Ainol AW1 tablet.
> > > >
> > > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > > the two extra lanes per component are grounded.
> > > >
> > > > In the future, it might become necessary to introduce a dedicated
> > > > device-tree property to specify the bus format to use instead of the
> > > > default one for the panel. This will allow supporting different bus
> > > > formats for the same panel modes.
> > > >
> > > > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > > > ---
> > > > drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++
> > > > 1 file changed, 26 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = {
> > > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > > };
> > > >
> > > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > > + .clock = 40000,
> > > > + .hdisplay = 800,
> > > > + .hsync_start = 800 + 112,
> > > > + .hsync_end = 800 + 112 + 1,
> > > > + .htotal = 800 + 112 + 1 + 87,
> > > > + .vdisplay = 480,
> > > > + .vsync_start = 480 + 141,
> > > > + .vsync_end = 480 + 141 + 1,
> > > > + .vtotal = 480 + 141 + 1 + 38,
> > > > + .vrefresh = 60,
> > > > +};
> > > > +
> > > > +static const struct panel_desc innolux_at070tn90 = {
> > > > + .modes = &innolux_at070tn90_mode,
> > > > + .num_modes = 1,
> > > > + .size = {
> > > > + .width = 154,
> > > > + .height = 86,
> > > > + },
> > > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > > +};
> > > > +
> > >
> > > I'm not really convinced this is the right approach. You said it
> > > yourself, the panel is using a 24-bits interface, and you just happen
> > > to have a tablet that routed it using a 18-bits interface instead.
> > >
> > > That doesn't belong in the driver, especially associated to the
> > > compatible, but where the routing is described: in the device
> > > tree. And given that the panel interface is a 24 bits panel, if we
> > > were to have a default, we should have this one, and not the one
> > > fitting your use case.
> >
> > I fully agree, this is why I suggested introducing a dedicated dt
> > property for selecting the bus format (in the commit message). I still
> > proposed this patch as a temporary solution, but I'm definitely willing
> > to craft a proper solution as well.
> >
> > Here is an initial proposition:
> > 1. Making bus_format an array in struct panel_desc and listing all the
> > relevant bus formats that the panel can support there;
>
> I'm not sure this is needed, the input format is always the same in
> your case, the panel will always take a 24 bits RGB value. What you
> want to change is the encoder output format (and I guess you want that
> to be meaningful to enable or not the dithering).
Isn't the panel format supposed to match what the encoder's output
should be aiming for? In my case, that would be RGB666, so the idea
would be specifying both MEDIA_BUS_FMT_RGB666_1X18 and
MEDIA_BUS_FMT_RGB888_1X24 in a list of supported bus formats for the
panel. This way, both my setup and RGB888 setups can be supported.
> > 2. Introducing an optional "bus-format" dt property that indicates which
> > bus format to use, and using the first index of the bus formats array if
> > the property is not present;
>
> I guess the width would be enough, and that way we can take the
> bus-width format that is already defined (but used in the v4l2
> framework, not in DRM yet).
Well, we already have bus-format defines on the DRM side and it feels
like mapping these directly in device-tree would be more useful as a
description of the hardware than just having the bus width.
Cheers,
Paul
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/0cca7363/attachment.sig>
^ permalink raw reply
* [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Paul Kocialkowski @ 2018-05-14 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511143647.ici2bfoeeldto3ju@flea>
Hi and thanks for the review!
Le vendredi 11 mai 2018 ? 16:36 +0200, Maxime Ripard a ?crit :
> On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> > @@ -0,0 +1,297 @@
> > +/*
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> This really should be the first line, and with a C++ style comment, as
> in:
>
> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> /*
> * Copyright (C) ...
>
> See Documentation/process/license-rules.rst
Okay, will do in v5.
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> > + brightness-levels = < 0 1 1 1 1 2 2 2
> > + 2 3 3 3 3 4 4 4
> > + 5 5 5 6 6 6 7 7
> > + 8 8 8 9 9 9 10 10
> > + 10 11 11 12 12 12 13 13
> > + 14 14 14 15 15 16 16 17
> > + 17 17 18 18 19 19 20 20
> > + 21 21 21 22 22 23 23 24
> > + 24 25 25 26 26 27 27 28
> > + 28 29 30 30 31 31 32 32
> > + 33 33 34 35 35 36 36 37
> > + 38 38 39 39 40 41 41 42
> > + 43 43 44 44 45 46 47 47
> > + 48 49 49 50 51 51 52 53
> > + 54 54 55 56 57 57 58 59
> > + 60 61 61 62 63 64 65 65
> > + 66 67 68 69 70 71 71 72
> > + 73 74 75 76 77 78 79 80
> > + 81 82 83 84 85 86 87 88
> > + 89 90 91 92 93 94 95 96
> > + 97 98 99 101 102 103 104 105
> > + 106 108 109 110 111 112 114 115
> > + 116 117 119 120 121 123 124 125
> > + 127 128 129 131 132 133 135 136
> > + 138 139 141 142 144 145 147 148
> > + 150 151 153 154 156 157 159 161
> > + 162 164 166 167 169 171 173 174
> > + 176 178 180 181 183 185 187 189
> > + 191 192 194 196 198 200 202 204
> > + 206 208 210 212 214 216 219 221
> > + 223 225 227 229 232 234 236 238
> > + 241 242 244 246 248 250 253 255>;
>
> You kind of overdid it here :)
>
> What I meant to say before was that if you have 10 elements (and you
> really should have something in that magnitude) each step should
> increase the perceived brightness by 10%.
Mhh I think 10 elements would fall too short to really depict the curve
with appropriate precision. Given the usual size for brightness cursors
in e.g. gnome-shell, it feels like a bigger number would be more
appropriate. Let's make it to 100 with values from 0 to 255!
> In this particular case, I really think having something close to <0 4
> 8 16 32 64 128 255> would be enough.
>
> And in general, that kind of odd looking table without any more
> context is just screaming for a comment :)
Noted, I will explain the idea, but probably without the exact formula
that's really a nasty hack written down on a piece of paper sitting in
my garbage at this point.
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/c7a25e06/attachment-0001.sig>
^ permalink raw reply
* [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()
From: Dominik Brodowski @ 2018-05-14 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514171427.qyietn3fhilwokb2@lakrids.cambridge.arm.com>
On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> > Using this helper allows us to avoid the in-kernel calls to the
> > compat_sys_{f,}statfs64() sycalls, as are necessary for parameter
> > mangling in arm64's compat handling.
> >
> > Following the example of ksys_* functions, kcompat_sys_* functions are
> > intended to be a drop-in replacement for their compat_sys_*
> > counterparts, with the same calling convention.
> >
> > This is necessary to enable conversion of arm64's syscall handling to
> > use pt_regs wrappers.
>
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 6723ea51ec99..e0bf3e4bb897 100644
> > --- a/include/linux/syscalls.h
> > +++ b/include/linux/syscalls.h
> > @@ -59,6 +59,7 @@ struct tms;
> > struct utimbuf;
> > struct mq_attr;
> > struct compat_stat;
> > +struct compat_statfs64;
> > struct compat_timeval;
> > struct robust_list_head;
> > struct getcpu_cache;
> > @@ -1150,6 +1151,13 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,
> > ssize_t ksys_readahead(int fd, loff_t offset, size_t count);
> > unsigned int ksys_personality(unsigned int personality);
> >
> > +#ifdef CONFIG_COMPAT
> > +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz,
> > + struct compat_statfs64 __user * buf);
> > +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> > + struct compat_statfs64 __user * buf);
> > +#endif
>
> I've moved these to <linux/compat.h>, so that they live with the rest of
> the compat syscall stuff. That should avoid build failures the kbuild
> test robot picked up where compat_size_t wasn't dfined.
Please add a comment there, similar to what is in syscalls.h:
/*
* Kernel code should not call syscalls (i.e., sys_xyzyyz()) directly.
* Instead, use one of the functions which work equivalently, such as
* the ksys_xyzyyz() functions prototyped below.
*/
Once you have done so, feel free to add my
Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
tag to this patch.
Thanks,
Dominik
^ permalink raw reply
* [PATCH 0/3] arm64: dts: Draak: Enable HDMI input and VIN4
From: Geert Uytterhoeven @ 2018-05-14 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526032802-14376-1-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
On Fri, May 11, 2018 at 11:59 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> this series enables HDMI input and VIN4 on R-Car D3 Draak board.
>
> The Draak board has an HDMI input connected to an HDMI decoder that feeds
> the VIN capture interface through its parallel video interface.
>
> The series requires the just sent:
> [PATCH 0/5] rcar-vin: Add support for digital input on Gen3
>
> and enables image capture operations on D3 Draak board.
>
> The series has been developed on top of media-master tree but applies cleanly
> on top of latest renesas-driver.
>
> Geert: would you like a topic branch for this series to be included in
> renesas-drivers?
It seems patch 2 has been applied by Simon already, but there is some
discussion pending on patch 3?
> Patches for testing are available at:
> git://jmondi.org/linux d3/media-master/driver
> git://jmondi.org/linux d3/media-master/dts
> git://jmondi.org/linux d3/media-master/test
> git://jmondi.org/vin-tests d3
>
> Thanks
> j
>
> Jacopo Mondi (3):
> dt-bindings: media: rcar-vin: Add R8A77995 support
> arm64: dts: renesas: r8a77995: Add VIN4
> arm64: dts: renesas: draak: Describe HDMI input
>
> .../devicetree/bindings/media/rcar_vin.txt | 1 +
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++
> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 ++++
> 3 files changed, 80 insertions(+)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [GIT PULL] Gemini DTS updates for v4.18
From: Olof Johansson @ 2018-05-14 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ+GR2j01CMAnU=pYwZHPZ6j5hhEefF7HckUM4jq=n2MA@mail.gmail.com>
On Sat, May 12, 2018 at 01:41:07PM +0200, Linus Walleij wrote:
> Hi ARM SoC folks!
>
> This fixes a host of issues and adds some new stuff to the
> Gemini platforms. We now have them all running (more or
> less) with OpenWRT. Details in the patches and signed tag.
>
> Please pull this to ARM SoC DTS updates for v4.18.
>
> Yours,
> Linus Walleij
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
> tags/gemini-dts-arm-soc
>
> for you to fetch changes up to e7c881596baf8d1a4a1b872c4670da6723246936:
>
> ARM: dts: Fix DTC warnings (2018-05-12 13:27:24 +0200)
>
> ----------------------------------------------------------------
> DTS updates for the Gemini:
> - Set righ flashes on DNS-313
> - Activate ATA1 on NAS4220B
> - Set right harddisk triggers on the D-Link devices
> - Fix all DTC warnings
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH v3 1/4] drm/rockchip: add transfer function for cdn-dp
From: Enric Balletbo Serra @ 2018-05-14 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526291635-31122-1-git-send-email-hl@rock-chips.com>
Hi Lin,
2018-05-14 11:53 GMT+02:00 Lin Huang <hl@rock-chips.com>:
> From: Chris Zhong <zyw@rock-chips.com>
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
> Reviewed-by: Enric Balletbo <eballetbo@gmail.com>
If you need to send another version, could you use the following name
and email address instead?
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Thanks :)
Enric
> ---
> Changes in v2:
> - update patch following Enric suggest
> - None
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++++++++++++++++++++++----
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 69 ++++++++++++++++++++++++++++++----
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++++++-
> 4 files changed, 122 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> - ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
> - if (ret)
> + ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
> + if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> - ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> - DP_RECEIVER_CAP_SIZE);
> - if (ret) {
> + ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
> + sizeof(dp->dpcd));
> + if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> - if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> - DP_LINK_STATUS_SIZE)) {
> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
> }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> + struct drm_dp_aux_msg *msg)
> +{
> + struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
> + int ret;
> + u8 status;
> +
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> + msg->size);
> + break;
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> + msg->size);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + status = cdn_dp_get_aux_status(dp);
> + if (status == AUX_STATUS_ACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> + else if (status == AUX_STATUS_NACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> + else if (status == AUX_STATUS_DEFER)
> + msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> + return ret;
> +}
> +
> static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
> {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> + dp->aux.name = "DP-AUX";
> + dp->aux.transfer = cdn_dp_aux_transfer;
> + dp->aux.dev = dev;
> +
> + ret = drm_dp_aux_register(&dp->aux);
> + if (ret)
> + return ret;
>
> INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct platform_device *audio_pdev;
> struct work_struct event_work;
> struct edid *edid;
> + struct drm_dp_aux aux;
>
> struct mutex lock;
> bool connected;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index eb3042c..979355d 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -221,7 +221,12 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp, u16 addr,
> sizeof(field), field);
> }
>
> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> +/*
> + * Returns the number of bytes transferred on success, or a negative
> + * error code on failure. -ETIMEDOUT is returned if mailbox message was
> + * not send successfully;
> + */
> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> {
> u8 msg[5], reg[5];
> int ret;
> @@ -247,24 +252,41 @@ int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> goto err_dpcd_read;
>
> ret = cdn_dp_mailbox_read_receive(dp, data, len);
> + if (!ret)
> + return len;
>
> err_dpcd_read:
> + DRM_DEV_ERROR(dp->dev, "dpcd read failed: %d\n", ret);
> return ret;
> }
>
> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> +#define CDN_AUX_HEADER_SIZE 5
> +#define CDN_AUX_MSG_SIZE 20
> +/*
> + * Returns the number of bytes transferred on success, or a negative error
> + * code on failure. -ETIMEDOUT is returned if mailbox message was not send
> + * success; -EINVAL is returned if get the wrong data size after message
> + * is sent
> + */
> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> {
> - u8 msg[6], reg[5];
> + u8 msg[CDN_AUX_MSG_SIZE + CDN_AUX_HEADER_SIZE];
> + u8 reg[CDN_AUX_HEADER_SIZE];
> int ret;
>
> - msg[0] = 0;
> - msg[1] = 1;
> + if (WARN_ON(len > CDN_AUX_MSG_SIZE) || WARN_ON(len <= 0))
> + return -EINVAL;
> +
> + msg[0] = (len >> 8) & 0xff;
> + msg[1] = len & 0xff;
> msg[2] = (addr >> 16) & 0xff;
> msg[3] = (addr >> 8) & 0xff;
> msg[4] = addr & 0xff;
> - msg[5] = value;
> +
> + memcpy(msg + CDN_AUX_HEADER_SIZE, data, len);
> +
> ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX, DPTX_WRITE_DPCD,
> - sizeof(msg), msg);
> + CDN_AUX_HEADER_SIZE + len, msg);
> if (ret)
> goto err_dpcd_write;
>
> @@ -277,8 +299,12 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> if (ret)
> goto err_dpcd_write;
>
> - if (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))
> + if ((len != (reg[0] << 8 | reg[1])) ||
> + (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))) {
> ret = -EINVAL;
> + } else {
> + return len;
> + }
>
> err_dpcd_write:
> if (ret)
> @@ -286,6 +312,33 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> return ret;
> }
>
> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp)
> +{
> + u8 status;
> + int ret;
> +
> + ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX,
> + DPTX_GET_LAST_AUX_STAUS, 0, NULL);
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_DP_TX,
> + DPTX_GET_LAST_AUX_STAUS,
> + sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdn_dp_mailbox_read_receive(dp, &status, sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + return status;
> +
> +err_get_hpd:
> + DRM_DEV_ERROR(dp->dev, "get aux status failed: %d\n", ret);
> + return ret;
> +}
> +
> int cdn_dp_load_firmware(struct cdn_dp_device *dp, const u32 *i_mem,
> u32 i_size, const u32 *d_mem, u32 d_size)
> {
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index c4bbb4a83..6580b11 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> @@ -328,6 +328,13 @@
> #define GENERAL_BUS_SETTINGS 0x03
> #define GENERAL_TEST_ACCESS 0x04
>
> +/* AUX status*/
> +#define AUX_STATUS_ACK 0
> +#define AUX_STATUS_NACK 1
> +#define AUX_STATUS_DEFER 2
> +#define AUX_STATUS_SINK_ERROR 3
> +#define AUX_STATUS_BUS_ERROR 4
> +
> #define DPTX_SET_POWER_MNG 0x00
> #define DPTX_SET_HOST_CAPABILITIES 0x01
> #define DPTX_GET_EDID 0x02
> @@ -469,8 +476,11 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
> int cdn_dp_event_config(struct cdn_dp_device *dp);
> u32 cdn_dp_get_event(struct cdn_dp_device *dp);
> int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value);
> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len);
> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
> + u8 *data, u16 len);
> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
> + u8 *data, u16 len);
> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp);
> int cdn_dp_get_edid_block(void *dp, u8 *edid,
> unsigned int block, size_t length);
> int cdn_dp_train_link(struct cdn_dp_device *dp);
> --
> 2.7.4
>
^ permalink raw reply
* [GIT PULL 5/5] Broadcom soc changes for 4.18
From: Olof Johansson @ 2018-05-14 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511214339.24139-5-f.fainelli@gmail.com>
On Fri, May 11, 2018 at 02:43:38PM -0700, Florian Fainelli wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/soc
>
> for you to fetch changes up to 56e4446df9c1214e886fdc7603a5c1cb99cb1843:
>
> ARM: brcmstb: Add support for the V7 memory map (2018-05-09 12:14:42 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM-based machine/platform files
> changes for 4.18, please pull the following:
>
> - Doug updates arch/arm/include/asm/cpuinfo.h such that this header file
> can be used by both C and assembly code. This particular change will
> also be included in a Sunxi pull request to support A83T SMP support.
>
> - Doug also updates our DEBUG_LL routine to support newer chips such as
> 7278 which have a version 7 memory map which moves the registers from
> physical address 0xf000_0000 down to 0x0800_0000. This requires us to
> look up the processor MIDR and determine the base address from the
> PERIPHBASE register.
>
> - Florian updates the Brahma-B15 read-ahead cache implementation such
> that it works on the Brahma-B53 CPUs, which also have an identical
> read-ahead cache implementation, with a different set of offsets. He
> also provides the Brahma-B15 MIDR definition such that it can be used by
> other pieces of code in the future.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 4/5] Broadcom drivers changes for 4.18
From: Olof Johansson @ 2018-05-14 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511214339.24139-4-f.fainelli@gmail.com>
On Fri, May 11, 2018 at 02:43:37PM -0700, Florian Fainelli wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/drivers
>
> for you to fetch changes up to b1d0973e9a1b4742ec80f3cf59ecc84a0998465b:
>
> memory: brcmstb: dpfe: Remove need for dpfe_dev (2018-05-09 12:15:26 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM/ARM64/MIPS SoCs drivers changes
> for 4.18, please pull the following:
>
> - Florian removes the synthetic struct device in the DPFE driver which
> was used to attach sysfs attributes and uses the platform_device we are
> probed from instead.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/5] Broadcom devicetree changes for 4.18
From: Olof Johansson @ 2018-05-14 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511214339.24139-3-f.fainelli@gmail.com>
On Fri, May 11, 2018 at 02:43:36PM -0700, Florian Fainelli wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/devicetree
>
> for you to fetch changes up to a05f1e36a57d02374a203719abc5bf2e8c51e125:
>
> ARM: dts: BCM5301X: Switch D-Link DIR-885L to the new partitions syntax (2018-05-11 09:46:38 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM-based SoC Device Tree changes
> for 4.18, please pull the following:
>
> - Stefan provides updates to the BCM2835 RNG Device Tree binding and
> Device Tree node by adding its missing interrupt line.
>
> - Rafal switches the Luxul XWC-1000 and the D-Link DIR-885L to the new
> partitions syntax which allows specifying a partition parser
>
> - Rafal also updates a bunch of BCM5301X Device Tree source files to a
> more standard SPDX tag and dual GPL 2.0 and MIT. This is a follow-up
> to this discussion with Greg:
> https://lkml.org/lkml/2018/4/28/179
>
> - Dan adds support for two Luxul devices: XAP-1610 (based on BCM47094)
> and XWR-3150 V1 (similar to XWR-3100)
>
> - Stefan provides a set of updates to the BCM283x Device Tree sources to
> support the Raspberry Pi 3 B+ for both the ARM and ARM64 kernels. He
> adds the required nodes for the LAN7515 USB Ethernet, Cypress CYW43455
> BT/WiFi combo chip. Stefan also provides a few fixes for the PWM pin
> assignment for RPi 3B and Zero/Zero W. Finally, Stefan adds the
> missing GPIOs for controlling additional peripherals now that support
> for the RPi 3 GPIO expander has landed
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/5 v2] Broadcom defconfig-arm64 changes for 4.18
From: Olof Johansson @ 2018-05-14 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513170134.11472-1-f.fainelli@gmail.com>
On Sun, May 13, 2018 at 10:01:34AM -0700, Florian Fainelli wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/defconfig-arm64
>
> for you to fetch changes up to ebf089248dab2ef569e5e26a607f0977a71182b7:
>
> arm64: defconfig: Increase CMA size for VC4 (2018-05-13 09:55:21 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM64-based SoCs defconfig changes
> for 4.18, please pull the following:
>
> - Stefan provides a set of updates targeting the Raspberry Pi 3 B+
> platform: LAN7515 USB Ethernet driver, Cypress CYW43455 Bluetooth when
> using the Pi 3 B+ in AArch64 boot mode. He also updates the ARM64
> defconfig to create a bigger default CMA region to let the VideoCore 4
> driver initialize correctly.
>
> ----------------------------------------------------------------
> Florian Fainelli (1):
> Merge tag 'bcm2835-defconfig-64-next-2018-04-30' into defconfig-arm64/next
>
> Stefan Wahren (2):
> arm64: defconfig: Enable LAN and BT support for RPi 3 B+
> arm64: defconfig: Increase CMA size for VC4
Merged, thanks. When you revisit, feel free to delete the previous tag and
using a new name (-2 suffix or something). That way there's less risk for
confusion at our end.
-Olof
^ permalink raw reply
* [PATCH 08/18] arm64: convert raw syscall invocation to C
From: Dominik Brodowski @ 2018-05-14 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514114104.oubxdf526hf2m6t5@lakrids.cambridge.arm.com>
On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> I agree it would be nicer if it had a wrapper that took a pt_regs, even
> if it does nothing with it.
>
> We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> need a ksys_ni_syscall() for our traps.c logic, and adding this
> uniformly would involve some arch-specific rework for x86, too, so I
> decided it was not worth the effort.
Couldn't you just open-code the "return -ENOSYS;" in traps.c? Error
injection has no reasonable stable ABI/API expectations, so that's not a
show-stopper either.
Thanks,
Dominik
^ permalink raw reply
* [GIT PULL 1/5] Broadcom defconfig changes for 4.18
From: Olof Johansson @ 2018-05-14 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511214339.24139-1-f.fainelli@gmail.com>
On Fri, May 11, 2018 at 02:43:34PM -0700, Florian Fainelli wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/defconfig
>
> for you to fetch changes up to f8928381021121123e9f4f783606c51cd37ab5d9:
>
> Merge tag 'bcm2835-defconfig-next-2018-04-30' into defconfig/next (2018-05-01 11:53:24 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM-based SoCs defconfig changes for
> 4.18, please pull the following:
>
> - Stefan provides a set of updates targeting the Raspberry Pi 3 B+
> platform: LAN7515 USB Ethernet driver, Cypress CYW43455 Bluetooth and
> he also enables the VCHIQ driver to help with continous testing on
> kernelci.org.
Merged.
I noticed you're a little thin on signatures of your PGP key, let's get
a few more there if possible. Happy to sign it at some future conference.
-Olof
^ permalink raw reply
* [GIT PULL] arm64: hisi: SoC driver updates for v4.18
From: Olof Johansson @ 2018-05-14 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AF5ABC1.60009@hisilicon.com>
On Fri, May 11, 2018 at 03:42:09PM +0100, Wei Xu wrote:
> Hi Arnd, Hi Olof,
>
> Please help to pull the following changes.
> Sorry for the inconvenience, because it depends on this patch [1]
> which was merged in the rc3, I rebased the pull on rc3.
> Thanks!
>
> [1] HISI LPC: Add Kconfig MFD_CORE dependency
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/bus?h=v4.17-rc3&id=4b313ca7b661ab8782f3dcb4a8996632a470b4da
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
>
> Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
>
> are available in the Git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-drivers-for-4.18
>
> for you to fetch changes up to adf3457b4ce6940885be3e5ee832c6949fba4166:
>
> HISI LPC: Add ACPI UART support (2018-05-10 17:45:52 +0100)
>
> ----------------------------------------------------------------
> ARM64: hisi: SoC driver updates for 4.18
>
> - Update hisi LPC bus driver to use the platform driver APIs
> other than the MFD APIs to support connected device like UART
Merged, thanks.
Same thing here as with the DT branch though -- if you look at a lot
of other patches under drivers/bus, nearly all of them use "bus: <...>"
as prefix, so please move over to using that for yours as well on future
patches/pull requests.
-Olof
^ permalink raw reply
* [GIT PULL] arm64: defconfig: hisilicon config updates for v4.18
From: Olof Johansson @ 2018-05-14 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AF5A94A.4080308@hisilicon.com>
Hi Wei,
On Fri, May 11, 2018 at 03:31:38PM +0100, Wei Xu wrote:
> Hi Arnd, Hi Olof,
>
> Please help to pull the following changes.
>
> About the CLOCK_STUB and the MAILBOX consolidate patch,
> Jassi and Stephen have acked it.
> Could you let me know how to handle this kind case
> if it is not OK to be in this pull?
I don't think there's any need to group the Kconfig changes with the defconfig
updates here, is there?
So, the clk Kconfig change can go in through the clk maintainer (in one patch),
the mailbox can go in through that maintainer as a separate patch. The update
to the defconfig is just removing what's now the new default, so it's not
urgent to do.
Based on this, can you respin the pull request with that patch dropped? Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] arm64: dts: hisilicon dts updates for v4.18
From: Olof Johansson @ 2018-05-14 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AF5A668.8010903@hisilicon.com>
Hi,
On Fri, May 11, 2018 at 03:19:20PM +0100, Wei Xu wrote:
> Hi Arnd, Hi Olof,
>
> Please help to pull the following changes.
> Thanks!
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-4.18
>
> for you to fetch changes up to 84f7ed0f22e8eb42e81b69cd7772c3600c9f4959:
>
> arm64: dts: hi3798cv200: enable emmc support for poplar board (2018-05-11 11:23:10 +0100)
>
> ----------------------------------------------------------------
> ARM64: DT: Hisilicon SoC DT updates for 4.18
>
> - Add mailbox, stub clock, CPU frequency scaling, thermal cooling
> management and pcie msi interruption support for hi3660
> - Add LPC support for hip06 and hip07
> - Add PCIe, usb and emmc support for hi3798cv200
>
> ----------------------------------------------------------------
> John Garry (2):
> arm64: dts: hisi: Enable Hisi LPC node for hip06
> arm64: dts: hisi: Enable Hisi LPC node for hip07
>
> Kaihua Zhong (2):
> dts: arm64: hi3660: Add mailbox node
> dts: arm64: hi3660: Add stub clock node
>
> Leo Yan (1):
> dts: arm64: hi3660: Add CPU frequency scaling support
>
> Shawn Guo (3):
> arm64: dts: hi3798cv200: enable PCIe support for poplar board
> arm64: dts: hi3798cv200: enable usb2 support for poplar board
> arm64: dts: hi3798cv200: enable emmc support for poplar board
>
> Tao Wang (1):
> dts: arm64: hi3660: Add thermal cooling management
>
> Yao Chen (1):
> arm64: dts: hi3660: Add pcie msi interrupt attribute
We try to use a very consistent patch prefix format on device tree changes to
make it easier to get an overview, and you're unfortunately a bit inconsistent
here.
Would you mind respinning this with "arm64: dts: hi<...>:" as the consistent
prefix please?
Thanks!
-Olof
^ permalink raw reply
* [PATCH 20/21] i2c: stu300: make use of i2c_8bit_addr_from_msg
From: Linus Walleij @ 2018-05-14 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514145330.4857-21-peda@axentia.se>
On Mon, May 14, 2018 at 4:53 PM, Peter Rosin <peda@axentia.se> wrote:
> Because it looks neater.
>
> Also restructure debug output for resends, since that code as a
> result is only handling debug output.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Looks good to me!
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [arm:to-build 14/17] arch/arm/crypto/ghash-ce-core.S:58: Error: Missing value for required parameter `limit' of macro `mask'
From: kbuild test robot @ 2018-05-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
First bad commit (maybe != root cause):
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git to-build
head: 645e28666dcc94625fa28a8f18338dbc46f9f35d
commit: 25dc994b00089f8fc233b4b0475c851790d768b9 [14/17] ARM: spectre-v1: add speculative safe mask and csdb macros
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 25dc994b00089f8fc233b4b0475c851790d768b9
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/crypto/ghash-ce-core.S: Assembler messages:
>> arch/arm/crypto/ghash-ce-core.S:58: Error: Missing value for required parameter `limit' of macro `mask'
>> arch/arm/crypto/ghash-ce-core.S:58: Error: Missing value for required parameter `limit' of macro `mask'
>> arch/arm/crypto/ghash-ce-core.S:58: Error: ARM register expected -- `sub .req,d28,'
>> arch/arm/crypto/ghash-ce-core.S:58: Error: ARM register expected -- `bic .req,.req,d28'
>> arch/arm/crypto/ghash-ce-core.S:58: Error: ARM register expected -- `and .req,d28,.req,asr#31'
>> arch/arm/crypto/ghash-ce-core.S:218: Error: parse error -- `vmov.i8 MASK,#0xe1'
>> arch/arm/crypto/ghash-ce-core.S:219: Error: Neon double or quad precision register expected -- `vshl.u64 MASK,MASK,#57'
>> arch/arm/crypto/ghash-ce-core.S:221: Error: VFP/Neon double precision register expected -- `vmull.p64 T1,XL_L,MASK'
>> arch/arm/crypto/ghash-ce-core.S:221: Error: VFP/Neon double precision register expected -- `vmull.p64 XL,T1_H,MASK'
vim +58 arch/arm/crypto/ghash-ce-core.S
f1e866b1 Ard Biesheuvel 2015-03-10 13
f1e866b1 Ard Biesheuvel 2015-03-10 14 SHASH .req q0
3759ee05 Ard Biesheuvel 2017-07-24 15 T1 .req q1
3759ee05 Ard Biesheuvel 2017-07-24 16 XL .req q2
3759ee05 Ard Biesheuvel 2017-07-24 17 XM .req q3
3759ee05 Ard Biesheuvel 2017-07-24 18 XH .req q4
3759ee05 Ard Biesheuvel 2017-07-24 19 IN1 .req q4
f1e866b1 Ard Biesheuvel 2015-03-10 20
f1e866b1 Ard Biesheuvel 2015-03-10 21 SHASH_L .req d0
f1e866b1 Ard Biesheuvel 2015-03-10 22 SHASH_H .req d1
3759ee05 Ard Biesheuvel 2017-07-24 23 T1_L .req d2
3759ee05 Ard Biesheuvel 2017-07-24 24 T1_H .req d3
3759ee05 Ard Biesheuvel 2017-07-24 25 XL_L .req d4
3759ee05 Ard Biesheuvel 2017-07-24 26 XL_H .req d5
3759ee05 Ard Biesheuvel 2017-07-24 27 XM_L .req d6
3759ee05 Ard Biesheuvel 2017-07-24 28 XM_H .req d7
3759ee05 Ard Biesheuvel 2017-07-24 29 XH_L .req d8
3759ee05 Ard Biesheuvel 2017-07-24 30
3759ee05 Ard Biesheuvel 2017-07-24 31 t0l .req d10
3759ee05 Ard Biesheuvel 2017-07-24 32 t0h .req d11
3759ee05 Ard Biesheuvel 2017-07-24 33 t1l .req d12
3759ee05 Ard Biesheuvel 2017-07-24 34 t1h .req d13
3759ee05 Ard Biesheuvel 2017-07-24 35 t2l .req d14
3759ee05 Ard Biesheuvel 2017-07-24 36 t2h .req d15
3759ee05 Ard Biesheuvel 2017-07-24 37 t3l .req d16
3759ee05 Ard Biesheuvel 2017-07-24 38 t3h .req d17
3759ee05 Ard Biesheuvel 2017-07-24 39 t4l .req d18
3759ee05 Ard Biesheuvel 2017-07-24 40 t4h .req d19
3759ee05 Ard Biesheuvel 2017-07-24 41
3759ee05 Ard Biesheuvel 2017-07-24 42 t0q .req q5
3759ee05 Ard Biesheuvel 2017-07-24 43 t1q .req q6
3759ee05 Ard Biesheuvel 2017-07-24 44 t2q .req q7
3759ee05 Ard Biesheuvel 2017-07-24 45 t3q .req q8
3759ee05 Ard Biesheuvel 2017-07-24 46 t4q .req q9
3759ee05 Ard Biesheuvel 2017-07-24 47 T2 .req q9
3759ee05 Ard Biesheuvel 2017-07-24 48
3759ee05 Ard Biesheuvel 2017-07-24 49 s1l .req d20
3759ee05 Ard Biesheuvel 2017-07-24 50 s1h .req d21
3759ee05 Ard Biesheuvel 2017-07-24 51 s2l .req d22
3759ee05 Ard Biesheuvel 2017-07-24 52 s2h .req d23
3759ee05 Ard Biesheuvel 2017-07-24 53 s3l .req d24
3759ee05 Ard Biesheuvel 2017-07-24 54 s3h .req d25
3759ee05 Ard Biesheuvel 2017-07-24 55 s4l .req d26
3759ee05 Ard Biesheuvel 2017-07-24 56 s4h .req d27
3759ee05 Ard Biesheuvel 2017-07-24 57
3759ee05 Ard Biesheuvel 2017-07-24 @58 MASK .req d28
3759ee05 Ard Biesheuvel 2017-07-24 59 SHASH2_p8 .req d28
3759ee05 Ard Biesheuvel 2017-07-24 60
3759ee05 Ard Biesheuvel 2017-07-24 61 k16 .req d29
3759ee05 Ard Biesheuvel 2017-07-24 62 k32 .req d30
3759ee05 Ard Biesheuvel 2017-07-24 63 k48 .req d31
3759ee05 Ard Biesheuvel 2017-07-24 64 SHASH2_p64 .req d31
f1e866b1 Ard Biesheuvel 2015-03-10 65
f1e866b1 Ard Biesheuvel 2015-03-10 66 .text
f1e866b1 Ard Biesheuvel 2015-03-10 67 .fpu crypto-neon-fp-armv8
f1e866b1 Ard Biesheuvel 2015-03-10 68
3759ee05 Ard Biesheuvel 2017-07-24 69 .macro __pmull_p64, rd, rn, rm, b1, b2, b3, b4
3759ee05 Ard Biesheuvel 2017-07-24 70 vmull.p64 \rd, \rn, \rm
3759ee05 Ard Biesheuvel 2017-07-24 71 .endm
3759ee05 Ard Biesheuvel 2017-07-24 72
f1e866b1 Ard Biesheuvel 2015-03-10 73 /*
3759ee05 Ard Biesheuvel 2017-07-24 74 * This implementation of 64x64 -> 128 bit polynomial multiplication
3759ee05 Ard Biesheuvel 2017-07-24 75 * using vmull.p8 instructions (8x8 -> 16) is taken from the paper
3759ee05 Ard Biesheuvel 2017-07-24 76 * "Fast Software Polynomial Multiplication on ARM Processors Using
3759ee05 Ard Biesheuvel 2017-07-24 77 * the NEON Engine" by Danilo Camara, Conrado Gouvea, Julio Lopez and
3759ee05 Ard Biesheuvel 2017-07-24 78 * Ricardo Dahab (https://hal.inria.fr/hal-01506572)
3759ee05 Ard Biesheuvel 2017-07-24 79 *
3759ee05 Ard Biesheuvel 2017-07-24 80 * It has been slightly tweaked for in-order performance, and to allow
3759ee05 Ard Biesheuvel 2017-07-24 81 * 'rq' to overlap with 'ad' or 'bd'.
f1e866b1 Ard Biesheuvel 2015-03-10 82 */
3759ee05 Ard Biesheuvel 2017-07-24 83 .macro __pmull_p8, rq, ad, bd, b1=t4l, b2=t3l, b3=t4l, b4=t3l
3759ee05 Ard Biesheuvel 2017-07-24 84 vext.8 t0l, \ad, \ad, #1 @ A1
3759ee05 Ard Biesheuvel 2017-07-24 85 .ifc \b1, t4l
3759ee05 Ard Biesheuvel 2017-07-24 86 vext.8 t4l, \bd, \bd, #1 @ B1
3759ee05 Ard Biesheuvel 2017-07-24 87 .endif
3759ee05 Ard Biesheuvel 2017-07-24 88 vmull.p8 t0q, t0l, \bd @ F = A1*B
3759ee05 Ard Biesheuvel 2017-07-24 89 vext.8 t1l, \ad, \ad, #2 @ A2
3759ee05 Ard Biesheuvel 2017-07-24 90 vmull.p8 t4q, \ad, \b1 @ E = A*B1
3759ee05 Ard Biesheuvel 2017-07-24 91 .ifc \b2, t3l
3759ee05 Ard Biesheuvel 2017-07-24 92 vext.8 t3l, \bd, \bd, #2 @ B2
3759ee05 Ard Biesheuvel 2017-07-24 93 .endif
3759ee05 Ard Biesheuvel 2017-07-24 94 vmull.p8 t1q, t1l, \bd @ H = A2*B
3759ee05 Ard Biesheuvel 2017-07-24 95 vext.8 t2l, \ad, \ad, #3 @ A3
3759ee05 Ard Biesheuvel 2017-07-24 96 vmull.p8 t3q, \ad, \b2 @ G = A*B2
3759ee05 Ard Biesheuvel 2017-07-24 97 veor t0q, t0q, t4q @ L = E + F
3759ee05 Ard Biesheuvel 2017-07-24 98 .ifc \b3, t4l
3759ee05 Ard Biesheuvel 2017-07-24 99 vext.8 t4l, \bd, \bd, #3 @ B3
3759ee05 Ard Biesheuvel 2017-07-24 100 .endif
3759ee05 Ard Biesheuvel 2017-07-24 101 vmull.p8 t2q, t2l, \bd @ J = A3*B
3759ee05 Ard Biesheuvel 2017-07-24 102 veor t0l, t0l, t0h @ t0 = (L) (P0 + P1) << 8
3759ee05 Ard Biesheuvel 2017-07-24 103 veor t1q, t1q, t3q @ M = G + H
3759ee05 Ard Biesheuvel 2017-07-24 104 .ifc \b4, t3l
3759ee05 Ard Biesheuvel 2017-07-24 105 vext.8 t3l, \bd, \bd, #4 @ B4
3759ee05 Ard Biesheuvel 2017-07-24 106 .endif
3759ee05 Ard Biesheuvel 2017-07-24 107 vmull.p8 t4q, \ad, \b3 @ I = A*B3
3759ee05 Ard Biesheuvel 2017-07-24 108 veor t1l, t1l, t1h @ t1 = (M) (P2 + P3) << 16
3759ee05 Ard Biesheuvel 2017-07-24 109 vmull.p8 t3q, \ad, \b4 @ K = A*B4
3759ee05 Ard Biesheuvel 2017-07-24 110 vand t0h, t0h, k48
3759ee05 Ard Biesheuvel 2017-07-24 111 vand t1h, t1h, k32
3759ee05 Ard Biesheuvel 2017-07-24 112 veor t2q, t2q, t4q @ N = I + J
3759ee05 Ard Biesheuvel 2017-07-24 113 veor t0l, t0l, t0h
3759ee05 Ard Biesheuvel 2017-07-24 114 veor t1l, t1l, t1h
3759ee05 Ard Biesheuvel 2017-07-24 115 veor t2l, t2l, t2h @ t2 = (N) (P4 + P5) << 24
3759ee05 Ard Biesheuvel 2017-07-24 116 vand t2h, t2h, k16
3759ee05 Ard Biesheuvel 2017-07-24 117 veor t3l, t3l, t3h @ t3 = (K) (P6 + P7) << 32
3759ee05 Ard Biesheuvel 2017-07-24 118 vmov.i64 t3h, #0
3759ee05 Ard Biesheuvel 2017-07-24 119 vext.8 t0q, t0q, t0q, #15
3759ee05 Ard Biesheuvel 2017-07-24 120 veor t2l, t2l, t2h
3759ee05 Ard Biesheuvel 2017-07-24 121 vext.8 t1q, t1q, t1q, #14
3759ee05 Ard Biesheuvel 2017-07-24 122 vmull.p8 \rq, \ad, \bd @ D = A*B
3759ee05 Ard Biesheuvel 2017-07-24 123 vext.8 t2q, t2q, t2q, #13
3759ee05 Ard Biesheuvel 2017-07-24 124 vext.8 t3q, t3q, t3q, #12
3759ee05 Ard Biesheuvel 2017-07-24 125 veor t0q, t0q, t1q
3759ee05 Ard Biesheuvel 2017-07-24 126 veor t2q, t2q, t3q
3759ee05 Ard Biesheuvel 2017-07-24 127 veor \rq, \rq, t0q
3759ee05 Ard Biesheuvel 2017-07-24 128 veor \rq, \rq, t2q
3759ee05 Ard Biesheuvel 2017-07-24 129 .endm
3759ee05 Ard Biesheuvel 2017-07-24 130
3759ee05 Ard Biesheuvel 2017-07-24 131 //
3759ee05 Ard Biesheuvel 2017-07-24 132 // PMULL (64x64->128) based reduction for CPUs that can do
3759ee05 Ard Biesheuvel 2017-07-24 133 // it in a single instruction.
3759ee05 Ard Biesheuvel 2017-07-24 134 //
3759ee05 Ard Biesheuvel 2017-07-24 135 .macro __pmull_reduce_p64
3759ee05 Ard Biesheuvel 2017-07-24 136 vmull.p64 T1, XL_L, MASK
3759ee05 Ard Biesheuvel 2017-07-24 137
3759ee05 Ard Biesheuvel 2017-07-24 138 veor XH_L, XH_L, XM_H
3759ee05 Ard Biesheuvel 2017-07-24 139 vext.8 T1, T1, T1, #8
3759ee05 Ard Biesheuvel 2017-07-24 140 veor XL_H, XL_H, XM_L
3759ee05 Ard Biesheuvel 2017-07-24 141 veor T1, T1, XL
3759ee05 Ard Biesheuvel 2017-07-24 142
3759ee05 Ard Biesheuvel 2017-07-24 143 vmull.p64 XL, T1_H, MASK
3759ee05 Ard Biesheuvel 2017-07-24 144 .endm
3759ee05 Ard Biesheuvel 2017-07-24 145
3759ee05 Ard Biesheuvel 2017-07-24 146 //
3759ee05 Ard Biesheuvel 2017-07-24 147 // Alternative reduction for CPUs that lack support for the
3759ee05 Ard Biesheuvel 2017-07-24 148 // 64x64->128 PMULL instruction
3759ee05 Ard Biesheuvel 2017-07-24 149 //
3759ee05 Ard Biesheuvel 2017-07-24 150 .macro __pmull_reduce_p8
3759ee05 Ard Biesheuvel 2017-07-24 151 veor XL_H, XL_H, XM_L
3759ee05 Ard Biesheuvel 2017-07-24 152 veor XH_L, XH_L, XM_H
3759ee05 Ard Biesheuvel 2017-07-24 153
3759ee05 Ard Biesheuvel 2017-07-24 154 vshl.i64 T1, XL, #57
3759ee05 Ard Biesheuvel 2017-07-24 155 vshl.i64 T2, XL, #62
3759ee05 Ard Biesheuvel 2017-07-24 156 veor T1, T1, T2
3759ee05 Ard Biesheuvel 2017-07-24 157 vshl.i64 T2, XL, #63
3759ee05 Ard Biesheuvel 2017-07-24 158 veor T1, T1, T2
3759ee05 Ard Biesheuvel 2017-07-24 159 veor XL_H, XL_H, T1_L
3759ee05 Ard Biesheuvel 2017-07-24 160 veor XH_L, XH_L, T1_H
3759ee05 Ard Biesheuvel 2017-07-24 161
3759ee05 Ard Biesheuvel 2017-07-24 162 vshr.u64 T1, XL, #1
3759ee05 Ard Biesheuvel 2017-07-24 163 veor XH, XH, XL
3759ee05 Ard Biesheuvel 2017-07-24 164 veor XL, XL, T1
3759ee05 Ard Biesheuvel 2017-07-24 165 vshr.u64 T1, T1, #6
3759ee05 Ard Biesheuvel 2017-07-24 166 vshr.u64 XL, XL, #1
3759ee05 Ard Biesheuvel 2017-07-24 167 .endm
3759ee05 Ard Biesheuvel 2017-07-24 168
3759ee05 Ard Biesheuvel 2017-07-24 169 .macro ghash_update, pn
f1e866b1 Ard Biesheuvel 2015-03-10 170 vld1.64 {XL}, [r1]
f1e866b1 Ard Biesheuvel 2015-03-10 171
f1e866b1 Ard Biesheuvel 2015-03-10 172 /* do the head block first, if supplied */
f1e866b1 Ard Biesheuvel 2015-03-10 173 ldr ip, [sp]
f1e866b1 Ard Biesheuvel 2015-03-10 174 teq ip, #0
f1e866b1 Ard Biesheuvel 2015-03-10 175 beq 0f
f1e866b1 Ard Biesheuvel 2015-03-10 176 vld1.64 {T1}, [ip]
f1e866b1 Ard Biesheuvel 2015-03-10 177 teq r0, #0
f1e866b1 Ard Biesheuvel 2015-03-10 178 b 1f
f1e866b1 Ard Biesheuvel 2015-03-10 179
f1e866b1 Ard Biesheuvel 2015-03-10 180 0: vld1.64 {T1}, [r2]!
f1e866b1 Ard Biesheuvel 2015-03-10 181 subs r0, r0, #1
f1e866b1 Ard Biesheuvel 2015-03-10 182
f1e866b1 Ard Biesheuvel 2015-03-10 183 1: /* multiply XL by SHASH in GF(2^128) */
f1e866b1 Ard Biesheuvel 2015-03-10 184 #ifndef CONFIG_CPU_BIG_ENDIAN
f1e866b1 Ard Biesheuvel 2015-03-10 185 vrev64.8 T1, T1
f1e866b1 Ard Biesheuvel 2015-03-10 186 #endif
f1e866b1 Ard Biesheuvel 2015-03-10 187 vext.8 IN1, T1, T1, #8
3759ee05 Ard Biesheuvel 2017-07-24 188 veor T1_L, T1_L, XL_H
f1e866b1 Ard Biesheuvel 2015-03-10 189 veor XL, XL, IN1
f1e866b1 Ard Biesheuvel 2015-03-10 190
3759ee05 Ard Biesheuvel 2017-07-24 191 __pmull_\pn XH, XL_H, SHASH_H, s1h, s2h, s3h, s4h @ a1 * b1
f1e866b1 Ard Biesheuvel 2015-03-10 192 veor T1, T1, XL
3759ee05 Ard Biesheuvel 2017-07-24 193 __pmull_\pn XL, XL_L, SHASH_L, s1l, s2l, s3l, s4l @ a0 * b0
3759ee05 Ard Biesheuvel 2017-07-24 194 __pmull_\pn XM, T1_L, SHASH2_\pn @ (a1+a0)(b1+b0)
f1e866b1 Ard Biesheuvel 2015-03-10 195
3759ee05 Ard Biesheuvel 2017-07-24 196 veor T1, XL, XH
f1e866b1 Ard Biesheuvel 2015-03-10 197 veor XM, XM, T1
f1e866b1 Ard Biesheuvel 2015-03-10 198
3759ee05 Ard Biesheuvel 2017-07-24 199 __pmull_reduce_\pn
f1e866b1 Ard Biesheuvel 2015-03-10 200
3759ee05 Ard Biesheuvel 2017-07-24 201 veor T1, T1, XH
3759ee05 Ard Biesheuvel 2017-07-24 202 veor XL, XL, T1
f1e866b1 Ard Biesheuvel 2015-03-10 203
f1e866b1 Ard Biesheuvel 2015-03-10 204 bne 0b
f1e866b1 Ard Biesheuvel 2015-03-10 205
f1e866b1 Ard Biesheuvel 2015-03-10 206 vst1.64 {XL}, [r1]
f1e866b1 Ard Biesheuvel 2015-03-10 207 bx lr
3759ee05 Ard Biesheuvel 2017-07-24 208 .endm
3759ee05 Ard Biesheuvel 2017-07-24 209
3759ee05 Ard Biesheuvel 2017-07-24 210 /*
3759ee05 Ard Biesheuvel 2017-07-24 211 * void pmull_ghash_update(int blocks, u64 dg[], const char *src,
3759ee05 Ard Biesheuvel 2017-07-24 212 * struct ghash_key const *k, const char *head)
3759ee05 Ard Biesheuvel 2017-07-24 213 */
3759ee05 Ard Biesheuvel 2017-07-24 214 ENTRY(pmull_ghash_update_p64)
3759ee05 Ard Biesheuvel 2017-07-24 215 vld1.64 {SHASH}, [r3]
3759ee05 Ard Biesheuvel 2017-07-24 216 veor SHASH2_p64, SHASH_L, SHASH_H
3759ee05 Ard Biesheuvel 2017-07-24 217
3759ee05 Ard Biesheuvel 2017-07-24 @218 vmov.i8 MASK, #0xe1
3759ee05 Ard Biesheuvel 2017-07-24 @219 vshl.u64 MASK, MASK, #57
3759ee05 Ard Biesheuvel 2017-07-24 220
3759ee05 Ard Biesheuvel 2017-07-24 @221 ghash_update p64
3759ee05 Ard Biesheuvel 2017-07-24 222 ENDPROC(pmull_ghash_update_p64)
3759ee05 Ard Biesheuvel 2017-07-24 223
:::::: The code at line 58 was first introduced by commit
:::::: 3759ee057261a45da0505e79084de8b6ac31c4a5 crypto: arm/ghash - add NEON accelerated fallback for vmull.p64
:::::: TO: Ard Biesheuvel <ard.biesheuvel@linaro.org>
:::::: CC: Herbert Xu <herbert@gondor.apana.org.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 34067 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180515/d17b0643/attachment-0001.gz>
^ permalink raw reply
* [PATCH v6 09/11] firmware: xilinx: Add debugfs for clock control APIs
From: Jolly Shah @ 2018-05-14 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5bcc47f7-3352-f0e6-29c5-78d5be96c1d1@arm.com>
Hi Sudeep,
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Thursday, May 10, 2018 7:31 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel at linaro.org;
> mingo at kernel.org; gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; mturquette at baylibre.com;
> sboyd at codeaurora.org; michal.simek at xilinx.com; robh+dt at kernel.org;
> mark.rutland at arm.com; linux-clk at vger.kernel.org
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com>
> Subject: Re: [PATCH v6 09/11] firmware: xilinx: Add debugfs for clock control
> APIs
>
>
>
> On 10/04/18 20:38, Jolly Shah wrote:
> > From: Rajan Vaja <rajanv@xilinx.com>
> >
> > Add debugfs file to control clocks using firmware APIs through debugfs
> > interface.
> >
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > ---
> > drivers/firmware/xilinx/zynqmp-debug.c | 48
> > ++++++++++++++++++++++++++++++++++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/drivers/firmware/xilinx/zynqmp-debug.c
> > b/drivers/firmware/xilinx/zynqmp-debug.c
> > index 1cb69f7..837fcd1 100644
> > --- a/drivers/firmware/xilinx/zynqmp-debug.c
> > +++ b/drivers/firmware/xilinx/zynqmp-debug.c
> > @@ -34,6 +34,15 @@ static struct pm_api_info pm_api_list[] = {
> > PM_API(PM_GET_API_VERSION),
> > PM_API(PM_IOCTL),
> > PM_API(PM_QUERY_DATA),
> > + PM_API(PM_CLOCK_ENABLE),
> > + PM_API(PM_CLOCK_DISABLE),
> > + PM_API(PM_CLOCK_GETSTATE),
> > + PM_API(PM_CLOCK_SETDIVIDER),
> > + PM_API(PM_CLOCK_GETDIVIDER),
> > + PM_API(PM_CLOCK_SETRATE),
> > + PM_API(PM_CLOCK_GETRATE),
> > + PM_API(PM_CLOCK_SETPARENT),
> > + PM_API(PM_CLOCK_GETPARENT),
> > };
> >
> > /**
> > @@ -87,6 +96,7 @@ static int process_api_request(u32 pm_id, u64
> *pm_api_arg, u32 *pm_api_ret)
> > const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> > u32 pm_api_version;
> > int ret;
> > + u64 rate;
> >
> > if (!eemi_ops)
> > return -ENXIO;
> > @@ -132,6 +142,44 @@ static int process_api_request(u32 pm_id, u64
> *pm_api_arg, u32 *pm_api_ret)
> > pm_api_ret[2], pm_api_ret[3]);
> > break;
> > }
> > + case PM_CLOCK_ENABLE:
> > + ret = eemi_ops->clock_enable(pm_api_arg[0]);
> > + break;
>
> As I mentioned in earlier patch, I don't see the need for this debugfs interface.
> Clock lay has read-only interface in debugfs already. Also if you want to debug
> clocks, you can do so using the driver which uses these clocks. Do you really
> want to manage clocks in user-space ?
> The whole idea of EEMI kind of interface is to abstract and hide the fine details
> even from non-trusted rich OS like Linux kernel, but by providing this you are
> doing exactly opposite.
>
> --
> Regards,
> Sudeep
No we don't want to manage clocks in user-space. This debugfs is meant for developer who wants to debug APIs behavior in case something doesn't work as expected. Debugfs should be off by default in production images.
Thanks,
Jolly Shah
^ permalink raw reply
* [PATCH v3] coresight: documentation: update sysfs section
From: Kim Phillips @ 2018-05-14 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a09cbbb5-0237-31f5-dc81-d816c9ec26c5@infradead.org>
- Align and show updated ls devices output from the TC2, based on
current driver
- Provide an example from an ETMv4 based system (Juno)
- Reflect changes to the way the RAM write pointer is accessed since
it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
management entries").
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
v3: address Randy Dunlap's showns->shown, corrected - and + line merging
v2: address Mathieu's comment about clarifying the sinks on the Juno
vs. TC2 platforms.
Documentation/trace/coresight.txt | 43 +++++++++++++++++++------------
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 6f0120c3a4f1..15d2a0f1e1b8 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -141,13 +141,25 @@ register the device with the core framework. The unregister function takes
a reference to a "struct coresight_device", obtained at registration time.
If everything goes well during the registration process the new devices will
-show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
+show up under /sys/bus/coresight/devices, as shown here for a TC2 platform:
root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:~#
+and here for a Juno platform:
+
+root at juno:~# ls /sys/bus/coresight/devices/
+20010000.etf 20120000.replicator 22040000.etm 230c0000.funnel
+20030000.tpiu 20130000.funnel 220c0000.funnel 23140000.etm
+20040000.funnel 20140000.etf 22140000.etm 23240000.etm
+20070000.etr 20150000.funnel 23040000.etm 23340000.etm
+root at juno:~#
+
+Note that on Juno users can select the ETF, ETR and TPIU as a sink target while
+on TC2, the ETB and TPIU can be selected.
+
The functions take a "struct coresight_device", which looks like this:
struct coresight_desc {
@@ -193,16 +205,16 @@ the information carried in "THIS_MODULE".
How to use the tracer modules
-----------------------------
-Before trace collection can start, a coresight sink needs to be identify.
+Before trace collection can start, a coresight sink needs to be identified.
There is no limit on the amount of sinks (nor sources) that can be enabled at
any given moment. As a generic operation, all device pertaining to the sink
class will have an "active" entry in sysfs:
root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
+enable_sink mgmt power subsystem trigger_cntr uevent
root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
1
@@ -216,16 +228,13 @@ trigger a trace capture:
root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
+
+Observe the write pointer moving:
+
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x1a8
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x19a6
Trace collection is stopped the same way:
--
2.17.0
^ 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