[PATCH v2] Documentation: tee: Document TEE kernel interface
Update documentation with TEE bus infrastructure which provides an
interface for kernel client drivers to communicate with corresponding
Trusted Application.
Signed-off-by: Sumit Garg
---
Changes in v2:
- Add TEE client driver example snippet.
Documentation/tee.txt | 68 +++
1 file changed, 68 insertions(+)
diff --git a/Documentation/tee.txt b/Documentation/tee.txt
index c8fad81..350dd40 100644
--- a/Documentation/tee.txt
+++ b/Documentation/tee.txt
@@ -53,6 +53,66 @@ clients, forward them to the TEE and send back the results.
In the case of
supplicants the communication goes in the other direction, the TEE sends
requests to the supplicant which then sends back the result.
+The TEE kernel interface
+
+
+Kernel provides a TEE bus infrastructure where a Trusted Application is
+represented as a device identified via Universally Unique Identifier (UUID) and
+client drivers register a table of supported device UUIDs.
+
+TEE bus infrastructure registers following APIs:
+- match(): iterates over the client driver UUID table to find a corresponding
+ match for device UUID. If a match is found, then this particular device is
+ probed via corresponding probe API registered by the client driver. This
+ process happens whenever a device or a client driver is registered with TEE
+ bus.
+- uevent(): notifies user-space (udev) whenever a new device is registered on
+ TEE bus for auto-loading of modularized client drivers.
+
+TEE bus device enumeration is specific to underlying TEE implementation, so it
+is left open for TEE drivers to provide corresponding implementation.
+
+Then TEE client driver can talk to a matched Trusted Application using APIs
+listed in include/linux/tee_drv.h.
+
+TEE client driver example
+-
+
+Suppose a TEE client driver needs to communicate with a Trusted Application
+having UUID: ``ac6a4085-0e82-4c33-bf98-8eb8e118b6c2``, so driver registration
+snippet would look like::
+
+ static const struct tee_client_device_id client_id_table[] = {
+ {UUID_INIT(0xac6a4085, 0x0e82, 0x4c33,
+ 0xbf, 0x98, 0x8e, 0xb8, 0xe1, 0x18, 0xb6, 0xc2)},
+ {}
+ };
+
+ MODULE_DEVICE_TABLE(tee, client_id_table);
+
+ static struct tee_client_driver client_driver = {
+ .id_table = client_id_table,
+ .driver = {
+ .name = DRIVER_NAME,
+ .bus= &tee_bus_type,
+ .probe = client_probe,
+ .remove = client_remove,
+ },
+ };
+
+ static int __init client_init(void)
+ {
+ return driver_register(&client_driver.driver);
+ }
+
+ static void __exit client_exit(void)
+ {
+ driver_unregister(&client_driver.driver);
+ }
+
+ module_init(client_init);
+ module_exit(client_exit);
+
OP-TEE driver
=
@@ -112,6 +172,14 @@ kernel are handled by the kernel driver. Other RPC
messages will be forwarded to
tee-supplicant without further involvement of the driver, except switching
shared memory buffer representation.
+OP-TEE device enumeration
+-
+
+OP-TEE provides a pseudo Trusted Application: drivers/tee/optee/device.c in
+order to support device enumeration. In other words, OP-TEE driver invokes this
+application to retrieve a list of Trusted Applications which can be registered
+as devices on the TEE bus.
+
AMD-TEE driver
==
--
2.7.4
[PATCH] regulator: mt6360: Add support for MT6360 regulator
From: Gene Chen
Add MT6360 regulator driver include 2-channel buck and
6-channel ldo
Signed-off-by: Gene Chen
base-commit: 098c4adf249c198519a4abebe482b1e6b8c50e47
---
drivers/regulator/Kconfig| 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6360-regulator.c | 571 +++
include/linux/mfd/mt6360.h | 5 +
4 files changed, 587 insertions(+)
create mode 100644 drivers/regulator/mt6360-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f4b72cb..05a3b14 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -680,6 +680,16 @@ config REGULATOR_MT6358
This driver supports the control of different power rails of device
through regulator interface.
+config REGULATOR_MT6360
+ tristate "MT6360 SubPMIC Regulator"
+ depends on MFD_MT6360
+ select CRC8
+ help
+ Say Y here to enable MT6360 regulator support.
+ This is support MT6360 PMIC/LDO part include
+ 2-channel buck with Thermal Shutdown and Overlord Protection
+ 6-channel High PSRR and Low Dropout LDO.
+
config REGULATOR_MT6380
tristate "MediaTek MT6380 PMIC"
depends on MTK_PMIC_WRAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6610ee0..1137af0 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_REGULATOR_MPQ7920) += mpq7920.o
obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
+obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
diff --git a/drivers/regulator/mt6360-regulator.c
b/drivers/regulator/mt6360-regulator.c
new file mode 100644
index 000..f0d878b
--- /dev/null
+++ b/drivers/regulator/mt6360-regulator.c
@@ -0,0 +1,571 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ *
+ * Author: Gene Chen
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+enum {
+ MT6360_PMIC_BUCK1 = 0,
+ MT6360_PMIC_BUCK2,
+ MT6360_PMIC_LDO6,
+ MT6360_PMIC_LDO7,
+};
+
+enum {
+ MT6360_LDO_LDO1 = 0,
+ MT6360_LDO_LDO2,
+ MT6360_LDO_LDO3,
+ MT6360_LDO_LDO5,
+};
+
+#define MT6360_MAX_REGULATOR (4)
+
+/* PMIC register defininition */
+#define MT6360_PMIC_BUCK1_VOSEL(0x10)
+#define MT6360_PMIC_BUCK1_EN_CTRL2 (0x17)
+#define MT6360_PMIC_BUCK2_VOSEL(0x20)
+#define MT6360_PMIC_BUCK2_EN_CTRL2 (0x27)
+#define MT6360_PMIC_LDO7_EN_CTRL2 (0x31)
+#define MT6360_PMIC_LDO7_CTRL3 (0x35)
+#define MT6360_PMIC_LDO6_EN_CTRL2 (0x37)
+#define MT6360_PMIC_LDO6_CTRL3 (0x3B)
+#define MT6360_PMIC_REGMAX (0x3C)
+
+/* LDO register defininition */
+#define MT6360_LDO_LDO3_EN_CTRL2 (0x05)
+#define MT6360_LDO_LDO3_CTRL3 (0x09)
+#define MT6360_LDO_LDO5_EN_CTRL2 (0x0B)
+#define MT6360_LDO_LDO5_CTRL0 (0x0C)
+#define MT6360_LDO_LDO5_CTRL3 (0x0F)
+#define MT6360_LDO_LDO2_EN_CTRL2 (0x11)
+#define MT6360_LDO_LDO2_CTRL3 (0x15)
+#define MT6360_LDO_LDO1_EN_CTRL2 (0x17)
+#define MT6360_LDO_LDO1_CTRL3 (0x1B)
+#define MT6360_LDO_REGMAX (0x1C)
+
+#define MT6360_OPMODE_LP (2)
+#define MT6360_OPMODE_ULP (3)
+#define MT6360_OPMODE_NORMAL (0)
+
+struct mt6360_regulator_desc {
+ const struct regulator_desc desc;
+ unsigned int control_reg;
+ unsigned int mode_set_mask;
+ unsigned int mode_get_mask;
+};
+
+struct mt6360_regulator_devdata {
+ int i2c_idx;
+ const struct regmap_config *regmap_config;
+ const struct mt6360_regulator_desc *reg_descs;
+ int num_reg_descs;
+ const struct mt6360_pmu_irq_desc *irq_descs;
+ int num_irq_descs;
+};
+
+struct mt6360_regulator_data {
+ struct i2c_client *i2c;
+ struct device *dev;
+ struct regulator_dev *rdev[MT6360_MAX_REGULATOR];
+ struct regmap *regmap;
+ unsigned int chip_rev;
+ u8 crc8_table[CRC8_TABLE_SIZE];
+};
+
+#define MT6360_REGU_IRQH(_name, _rid, _event) \
+static irqreturn_t mt6360_pmu_##_name##_handler(int irq, void *data) \
+{ \
+ struct mt6360_regulator_data *mrd = data; \
+ dev_warn(mrd->dev, "%s\n", __func__); \
+ regulator_notifier_call_chain(mrd->rdev[_rid], _event, NULL); \
+ return IRQ_HANDLED; \
+}
+
+#define MT6360_REGU_IRQ(_name) { #_name, mt6360_pmu_##_name##_handler }
+
+/* PMIC irqs */
+MT6360_REGU_IRQH(buck1_pgb_evt, MT6360_PMIC_BUCK1, REGULATOR_EVENT_FAIL)
+MT6360_REGU_IRQH(buck1_oc_evt, MT6360_PMIC_BUCK1, REGULATO
linux-next: Tree for Jun 4
Hi all,
News: The merge window has opened, so please do *not* add v5.9 material
to your linux-next included branches until after v5.8-rc1 has been
released.
Changes since 20200603:
Removed tree: sh
Renamed tree: sh-rf to sh
My fixes tree contains:
4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")
The overlayfs tree lost its build failure.
The v4l-dvb-next tree lost its build failure.
The tip tree gained conflicts against the sparc-next tree.
The akpm tree gained a build failure for which I applied a patch.
Non-merge commits (relative to Linus' tree): 10238
10675 files changed, 875263 insertions(+), 176758 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 324 trees (counting Linus' and 82 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (38696e33e2bd Merge tag 'xtensa-20200603' of
git://github.com/jcmvbkbc/linux-xtensa)
Merging fixes/master (da03d0610044 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (6a8b55ed4056 Linux 5.7-rc3)
Merging arc-current/for-curr (9d9368e839c2 ARC: [arcompact] fix bitrot with 2
levels of interrupt)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (99706d62fb50 Merge tag
'omap-for-v5.7/cpsw-fixes-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging uniphier-fixes/fixes (0e698dfa2822 Linux 5.7-rc4)
Merging arm64-fixes/for-next/fixes (ba051f097fc3 arm64/kernel: Fix return value
when cpu_online() fails in __cpu_up())
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length
array with flexible-array member)
Merging powerpc-fixes/fixes (2f26ed1764b4 powerpc/64s: Disable sanitisers for C
syscall/interrupt entry/exit code)
Merging s390-fixes/fixes (4c1cbcbd6c56 s390/kaslr: add support for
R_390_JMP_SLOT relocation type)
Merging sparc/master (fcdf818d239e Merge branch 'sparc-scnprintf')
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging bpf/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging ipsec/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging netfilter/master (bdc48fa11e46 checkpatch/coding-style: deprecate
80-column warning)
Merging ipvs/master (0141317611ab Merge branch 'hns3-fixes')
Merging wireless-drivers/master (f92f26f2ed2c iwlwifi: pcie: handle QuZ configs
with killer NICs as well)
Merging mac80211/master (3d77e6a8804a Linux 5.7)
Merging rdma-fixes/for-rc (3d77e6a8804a Linux 5.7)
Merging sound-current/for-linus (d9b8fbf15d05 ALSA: es1688: Add the missed
snd_card_free())
Merging sound-asoc-fixes/for-linus (358c7c61fd04 Merge remote-tracking branch
'asoc/for-5.8' into asoc-linus)
Merging regmap-fixes/for-linus (323ca2daef47 Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (5fb565b69dab Merge remote-tracking branch
'regulator/for-5.8' into regulator-linus)
Merging spi-fixes/for-linus (7ce6dc9ef58d Merge remote-tracking branch
'spi/for-5.8' into spi-linus)
Merging pci-current/for-linus (ef46738cc47a
Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation]
Hello,
On Wed, Jun 03, 2020 at 11:33:52PM +, Agarwal, Anchal wrote:
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> On Tue, May 19, 2020 at 11:27:50PM +, Anchal Agarwal wrote:
> > From: Munehisa Kamata
> >
> > S4 power transition states are much different than xen
> > suspend/resume. Former is visible to the guest and frontend drivers
> should
> > be aware of the state transitions and should be able to take appropriate
> > actions when needed. In transition to S4 we need to make sure that at
> least
> > all the in-flight blkif requests get completed, since they probably
> contain
> > bits of the guest's memory image and that's not going to get saved any
> > other way. Hence, re-issuing of in-flight requests as in case of xen
> resume
> > will not work here. This is in contrast to xen-suspend where we need to
> > freeze with as little processing as possible to avoid dirtying RAM late
> in
> > the migration cycle and we know that in-flight data can wait.
> >
> > Add freeze, thaw and restore callbacks for PM suspend and hibernation
> > support. All frontend drivers that needs to use
> PM_HIBERNATION/PM_SUSPEND
> > events, need to implement these xenbus_driver callbacks. The freeze
> handler
> > stops block-layer queue and disconnect the frontend from the backend
> while
> > freeing ring_info and associated resources. Before disconnecting from
> the
> > backend, we need to prevent any new IO from being queued and wait for
> existing
> > IO to complete. Freeze/unfreeze of the queues will guarantee that there
> are no
> > requests in use on the shared ring. However, for sanity we should check
> > state of the ring before disconnecting to make sure that there are no
> > outstanding requests to be processed on the ring. The restore handler
> > re-allocates ring_info, unquiesces and unfreezes the queue and
> re-connect to
> > the backend, so that rest of the kernel can continue to use the block
> device
> > transparently.
> >
> > Note:For older backends,if a backend doesn't have commit'12ea729645ace'
> > xen/blkback: unmap all persistent grants when frontend gets
> disconnected,
> > the frontend may see massive amount of grant table warning when freeing
> > resources.
> > [ 36.852659] deferring g.e. 0xf9 (pfn 0x)
> > [ 36.855089] xen:grant_table: WARNING:e.g. 0x112 still in use!
> >
> > In this case, persistent grants would need to be disabled.
> >
> > [Anchal Changelog: Removed timeout/request during blkfront freeze.
> > Reworked the whole patch to work with blk-mq and incorporate upstream's
> > comments]
>
> Please tag versions using vX and it would be helpful if you could list
> the specific changes that you performed between versions. There where
> 3 RFC versions IIRC, and there's no log of the changes between them.
>
> I will elaborate on "upstream's comments" in my changelog in my next round of
> patches.
Sorry for being picky, but can you please make sure your email client
properly quotes previous emails on reply. Note the lack of '>' added
to the quoted parts of your reply.
> > + }
> > +
> > break;
> > + }
> > +
> > + /*
> > + * We may somehow receive backend's Closed again while
> thawing
> > + * or restoring and it causes thawing or restoring to
> fail.
> > + * Ignore such unexpected state regardless of the backend
> state.
> > + */
> > + if (info->connected == BLKIF_STATE_FROZEN) {
>
> I think you can join this with the previous dev->state ==
> XenbusStateClosed?
>
> Also, won't the device be in the Closed state already if it's in state
> frozen?
> Yes but I think this mostly due to a hypothetical case if during thawing
> backend switches to Closed state.
> I am not entirely sure if that could happen. Could use some expertise here.
I think the frontend seeing the backend in the closed state during
restore would be a bug that should prevent the frontend from
resuming.
> > + /* Kick the backend to disconnect */
> > + xenbus_switch_state(dev, XenbusStateClosing);
> > +
> > + /*
> > + * We don't want to move forward before the frontend is
> diconnected
> > + * from the backend cleanly.
> > + */
> > + timeout =
> wait_for_completion_timeout(&info->wait_backend_disconnected,
> > + timeout);
> > + if (!timeout) {
> > + err = -EBUSY;
>
> Note err is only used here, and I think could just be dropped.
>
> This err is what's b
Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
On Thu, Jun 04, 2020 at 01:17:06AM +0530, Bhupesh Sharma wrote:
> On Wed, Jun 3, 2020 at 9:03 PM John Donnelly
> wrote:
> > > On Jun 3, 2020, at 8:20 AM, chenzhou wrote:
> > > On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > index 7f9e5a6dc48c..bd67b90d35bd 100644
> > --- a/kernel/crash_core.c
> > +++ b/kernel/crash_core.c
> > @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
> > return 0;
> > }
> >
> > - low_base = memblock_find_in_range(0, 1ULL << 32, low_size,
> > CRASH_ALIGN);
> > + low_base = memblock_find_in_range(0,0xc000, low_size,
> > CRASH_ALIGN);
> > if (!low_base) {
> > pr_err("Cannot reserve %ldMB crashkernel low memory,
> > please try smaller size.\n",
> > (unsigned long)(low_size >> 20));
> >
> >
> > >>>I suspect 0xc000 would need to be a CONFIG item and not
> > >>> hard-coded.
> > >>>
> > >> if you consider this as valid change, can you please incorporate as
> > >> part of your patch-set.
> > >
> > > After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and
> > > ZONE_DMA32")，the 0-4G memory is splited to DMA [mem
> > > 0x-0x3fff] and DMA32 [mem
> > > 0x4000-0x] on arm64.
> > >
> > > From the above discussion, on your platform, the low crashkernel fall
> > > in DMA32 region, but your environment needs to access DMA region, so
> > > there is the call trace.
> > >
> > > I have a question, why do you choose 0xc000 here?
> > >
> > > Besides, this is common code, we also need to consider about x86.
> > >
> >
> > + nsaenzjulie...@suse.de
> >
> > Exactly . This is why it needs to be a CONFIG option for Raspberry
> > .., or device tree option.
> >
> >
> > We could revert 1a8e1cef7 since it broke Arm kdump too.
>
> Well, unfortunately the patch for commit 1a8e1cef7603 ("arm64: use
> both ZONE_DMA and ZONE_DMA32") was not Cc'ed to the kexec mailing
> list, thus we couldn't get many eyes on it for a thorough review from
> kexec/kdump p-o-v.
>
> Also we historically never had distinction in common arch code on the
> basis of the intended end use-case: embedded, server or automotive, so
> I am not sure introducing a Raspberry specific CONFIG option would be
> a good idea.
Right, we need a fix that works for everybody, since we try hard for a
single Image that works for all platforms.
What I don't really understand is why, with Chen's patches applied, we can't
just keep the crashkernel out of the DMA zones altogether when no base is
specified. I guess I'll just look out for your patch!
Will
Re: [PATCH v3 2/2] checks: Improve i2c reg property checking
On Tue, Jun 02, 2020 at 11:28:05AM +0300, Andy Shevchenko wrote: > On Tue, Jun 2, 2020 at 11:03 AM Serge Semin > wrote: > > On Thu, May 28, 2020 at 06:26:50PM +0930, Joel Stanley wrote: > > ... > > > > +#define I2C_TEN_BIT_ADDRESS (1 << 31) > > > > As Andy neatly pointed out here: > > https://lore.kernel.org/lkml/20200527133656.gv1634...@smile.fi.intel.com/ > > (1 << 31) is UB. > > Thanks, Serge. Yes, we have to use 1U in the definitions (for 31 is > necessary, for the rest is for the sake of consistency). Joel, I know it seems trivial, but I'm a bit flat out right now. Can you please resend with the 1U fix applied. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v6 5/5] drivers/tty/serial: add LiteUART driver
On Wed, May 27, 2020 at 6:27 PM Mateusz Holenko wrote: > > From: Filip Kokosinski > > This commit adds driver for the FPGA-based LiteUART serial controller > from LiteX SoC builder. > > The current implementation supports LiteUART configured > for 32 bit data width and 8 bit CSR bus width. > > It does not support IRQ. > > Signed-off-by: Filip Kokosinski > Signed-off-by: Mateusz Holenko > --- > > Notes: > Changes in v6: > - LiteUART ports now stored in xArray > - removed PORT_LITEUART > - fixed formatting > - removed some unnecessary defines > > No changes in v5. > > Changes in v4: > - fixed copyright header > - removed a wrong dependency on UARTLITE from Kconfig > - added a dependency on LITEX_SOC_CONTROLLER to LITEUART in Kconfig > > Changes in v3: > - aliases made optional > - used litex_get_reg/litex_set_reg functions instead of macros > - SERIAL_LITEUART_NR_PORTS renamed to SERIAL_LITEUART_MAX_PORTS > - PORT_LITEUART changed from 122 to 123 > - added dependency on LITEX_SOC_CONTROLLER > - patch number changed from 4 to 5 > > No changes in v2. > > MAINTAINERS | 1 + > drivers/tty/serial/Kconfig| 31 +++ > drivers/tty/serial/Makefile | 1 + > drivers/tty/serial/liteuart.c | 404 ++ > 4 files changed, 437 insertions(+) > create mode 100644 drivers/tty/serial/liteuart.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 51d2d6a61fb0..d855fe807833 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9846,6 +9846,7 @@ M:Mateusz Holenko > S: Maintained > F: Documentation/devicetree/bindings/*/litex,*.yaml > F: drivers/soc/litex/litex_soc_ctrl.c > +F: drivers/tty/serial/liteuart.c > F: include/linux/litex.h > > LIVE PATCHING > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index adf9e80e7dc9..17aaf0afb27a 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1562,6 +1562,37 @@ config SERIAL_MILBEAUT_USIO_CONSOLE > receives all kernel messages and warnings and which allows logins in > single user mode). > > +config SERIAL_LITEUART > + tristate "LiteUART serial port support" > + depends on HAS_IOMEM > + depends on OF || COMPILE_TEST > + depends on LITEX_SOC_CONTROLLER > + select SERIAL_CORE > + help > + This driver is for the FPGA-based LiteUART serial controller from > LiteX > + SoC builder. > + > + Say 'Y' here if you wish to use the LiteUART serial controller. > + Otherwise, say 'N'. > + > +config SERIAL_LITEUART_MAX_PORTS > + int "Maximum number of LiteUART ports" > + depends on SERIAL_LITEUART > + default "1" > + help > + Set this to the maximum number of serial ports you want the driver > + to support. > + > +config SERIAL_LITEUART_CONSOLE > + bool "LiteUART serial port console support" > + depends on SERIAL_LITEUART=y > + select SERIAL_CORE_CONSOLE > + help > + Say 'Y' here if you wish to use the FPGA-based LiteUART serial > controller > + from LiteX SoC builder as the system console (the system console is > the > + device which receives all kernel messages and warnings and which > allows > + logins in single user mode). Otherwise, say 'N'. > + > endmenu > > config SERIAL_MCTRL_GPIO > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile > index d056ee6cca33..9f8ba419ff3b 100644 > --- a/drivers/tty/serial/Makefile > +++ b/drivers/tty/serial/Makefile > @@ -89,6 +89,7 @@ obj-$(CONFIG_SERIAL_OWL) += owl-uart.o > obj-$(CONFIG_SERIAL_RDA) += rda-uart.o > obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o > obj-$(CONFIG_SERIAL_SIFIVE)+= sifive.o > +obj-$(CONFIG_SERIAL_LITEUART) += liteuart.o > > # GPIOLIB helpers for modem control lines > obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o > diff --git a/drivers/tty/serial/liteuart.c b/drivers/tty/serial/liteuart.c > new file mode 100644 > index ..22b7612c13ca > --- /dev/null > +++ b/drivers/tty/serial/liteuart.c > @@ -0,0 +1,404 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * LiteUART serial controller (LiteX) Driver > + * > + * Copyright (C) 2019-2020 Antmicro > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include kbuild test robot reported problems with this patch, namely: implicit declaration of function 'kzalloc' This is caused by the missing include directive. When I was testing it I must have missed the warning, but the compilation succeeded and the resulting binary worked fine on HW (LiteX/mor1kx platform). The fix is a simple one-liner, adding a new include: +#include Since this is a very small fix and does not modify the actual code of the driver I want to wait for more feed
Re: kernel/trace/blktrace.c:347:12: sparse: sparse: incorrect type in assignment (different address spaces)
On 6/3/20 7:30 PM, Jens Axboe wrote: >> Can you please let me know how can we proceed with the series so that >> we can stop these emails ? > Which patch from Jan? I saw one, and it had issues. Then there's a second > one, which is ordered behind a series that's not in my tree and wasn't > queued for 5.8. And finally, there's your series, which seemed to be a > subset of Jan's patch for patch 1. > > So it's really not very clear. Maybe if folks got together and actually > put together a series to fix this it would be easier to get this done. > > -- Jens Axboe I sent an updated series on the linux-block/for-next which removes the duplicate patch (Jan's rcu warning fix). In case you happened to apply other series before mine (with V2) which has Jan's patch I'll resend this one with V3.
Re: [PATCH 2/3] dt-bindings: display: bridge: Add documentation for LT9611
Hi Laurent,
Sorry for late reply, I was out last week.
On 28-05-20, 04:48, Laurent Pinchart wrote:
> > +
> > + interrupts:
> > +maxItems: 1
> > +description: interrupt line for the chip
>
> I think you could drop the descriptions for the reg and interrupt
> properties, they don't add much.
Sure, will do
> > + reset-gpios:
> > +maxItems: 1
> > +description: GPIO connected to active high RESET pin.
> > +
> > + vdd-supply:
> > +description: Regulator for 1.8V MIPI phy power.
> > +
> > + vcc-supply:
> > +description: Regulator for 3.3V IO power.
> > +
> > + ports:
> > +type: object
> > +
> > +properties:
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + port@0:
> > +type: object
> > +additionalProperties: false
> > +
> > +description: |
> > + HDMI port for HDMI output
>
> The usual practice is to have the input ports first, followed by the
> output ports. Is there a reason not to follow that rule ?
I was not aware of this rule, is it documented somewhere?
Nevertheless will update..
> > +
> > +properties:
> > + reg:
> > +const: 0
> > +
> > +patternProperties:
> > + endpoint:
>
> If you want to use patternProperties, this should be
>
> "^endpoint@[0-9]+$":
>
> (including the quotes). Same below.
Ok
>
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > + remote-endpoint: true
>
> How about
>
> remote-endpoint:
> $ref: /schemas/types.yaml#/definitions/phandle
>
> and the same below ?
Ok
>
> You also need a reg property if multiple endpoints are present.
Will update
>
> > +
> > +required:
> > + - reg
> > +
> > + port@1:
> > +type: object
> > +additionalProperties: false
> > +
> > +description: |
> > + MIPI port-1 for MIPI input
> > +
> > +properties:
> > + reg:
> > +const: 1
> > +
> > +patternProperties:
> > + endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > + remote-endpoint: true
> > +
> > +required:
> > + - reg
> > +
> > + port@2:
> > +type: object
> > +additionalProperties: false
> > +
> > +description: |
> > + MIPI port-2 for MIPI input
>
> A description of how the two MIPI inputs differ would be useful. In
> particular, are both mandatory, or is it valid to connect only one of
> the two ? If using a single input is supported, can it be either, or
> does it have to be the first one ? When using both inputs, what should
> be connected to them ?
Sure I will add details. port-1 is mandatory and port-2 optional. port-2
is used in combination with port-1 to drive displays for higher
resolution like 4k
> > +
> > +properties:
> > + reg:
> > +const: 2
> > +
> > +patternProperties:
> > + endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > + remote-endpoint: true
> > +
> > +required:
> > + - reg
> > +
> > +required:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - vdd-supply
> > + - vcc-supply
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +
> > +i2c10 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + lt9611_codec: hdmi-bridge@3b {
>
> Please drop unused labels.
ok
>
> > +compatible = "lontium,lt9611";
> > +reg = <0x3b>;
> > +
> > +reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
> > +interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>;
> > +
> > +vdd-supply = <<9611_1v8>;
> > +vcc-supply = <<9611_3v3>;
> > +
> > +ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > +reg = <0>;
> > +lt9611_out: endpoint {
> > + remote-endpoint = <&hdmi_con>;
> > +};
> > + };
> > +
> > + port@1 {
> > +reg = <1>;
> > +lt9611_a: endpoint {
> > + remote-endpoint = <&dsi0_out>;
> > +};
> > + };
> > +
> > + port@2 {
> > +reg = <2>;
> > +lt9611_b: endpoint {
> > + remote-endpoint = <&dsi1_out>;
> > +};
> > + };
> > +};
> > + };
> > +};
>
> It's customary to end YAML schema files with ... on a separate line.
Will update
Thanks for the review
--
~Vinod
Re: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
On Thu, Jun 04, 2020 at 02:04:58AM +0530, Bhupesh Sharma wrote:
> On Wed, Jun 3, 2020 at 4:50 PM Kamlakant Patel wrote:
> > > diff --git a/arch/arm64/kernel/crash_core.c
> > > b/arch/arm64/kernel/crash_core.c
> > > index 1f646b07e3e9..314391a156ee 100644
> > > --- a/arch/arm64/kernel/crash_core.c
> > > +++ b/arch/arm64/kernel/crash_core.c
> > > @@ -7,6 +7,14 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +
> > > +static inline u64 get_tcr_el1_t1sz(void);
> > > +
> > > +static inline u64 get_tcr_el1_t1sz(void) {
> > > + return (read_sysreg(tcr_el1) & TCR_T1SZ_MASK) >> TCR_T1SZ_OFFSET; }
> > >
> > > void arch_crash_save_vmcoreinfo(void)
> > > {
> > > @@ -16,6 +24,8 @@ void arch_crash_save_vmcoreinfo(void)
> > > kimage_voffset);
> > > vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
> > > PHYS_OFFSET);
> > > + vmcoreinfo_append_str("NUMBER(TCR_EL1_T1SZ)=0x%llx\n",
> > > + get_tcr_el1_t1sz());
> > I tested this patch on top of upstream kernel v5.7 and I am getting "crash:
> > cannot determine VA_BITS_ACTUAL" error with crash tool.
> > I looked into crash-utility source and it is expecting tcr_el1_t1sz not
> > TCR_EL1_T1SZ.
> > Could you please check.
>
> Indeed. As per James comments on the v5 (see [1]) where he suggested
> converting ttcr_el1_t1sz into TCR_EL1_T1SZ, I made the change in v6
> accordingly.
>
> This time I haven't sent out the v6 userspace changes
> (makedumpfile/crash-utility) upstream first, since we are waiting for
> kernel changes to be accepted first, as we have seen in the past that
> while the userspace patches have been accepted, the kernel patches
> required a respin cycle, thus leading to inconsistencies, as you also
> pointed out with crash-utility.
Yes, and that';s the right way to do it. Userspace can't rely on the
stability of a kernel interface if it's no in the upstream kernel!
So doing with the ALL CAPS names is the right thing to do.
Will
[PATCH] compiler.h: Move instrumentation_begin()/end() into new header
* Linus Torvalds wrote:
> On Mon, Jun 1, 2020 at 6:08 AM Ingo Molnar wrote:
> >
> > include/linux/compiler.h| 53 +++
>
> I have pulled this, but do we really want to add this to a header file
> that is _so_ core that it gets included for basically every single
> file built?
>
> I don't even see those instrumentation_begin/end() things used
> anywhere right now.
>
> It seems excessive. That 53 lines is maybe not a lot, but it pushed
> that header file to over 12kB, and while it's mostly comments, it's
> extra IO and parsing basically for _every_ single file compiled in the
> kernel.
>
> For what appears to be absolutely zero upside right now, and I really
> don't see why this should be in such a core header file!
>
> I don't even see this as having anything at all to do with
> "compiler.h" in the first place.
>
> I really think we should think twice about making core header files
> bigger like this. No, we're nowhere the disaster that C++ project
> headers are, but tokenization and parsing is actually a pretty big
> part of the build costs (which may surprise some people who think it's
> all the fancy optimizations that cost a lot of CPU time).
Fully agreed - and I made the attached patch to address this.
The code got cleaner and better structured, but it didn't help much in
terms of inclusion count:
2616 total .o files
2447
2436
2404
The reason is that is included almost everywhere as
well, and the instrumentation_begin()/end() annotations affect the
BUG*() and WARN*() primitives as well.
At least non-x86 would have less instrumentation related noise, for
now at least.
Thanks,
Ingo
==>
From: Ingo Molnar
Date: Thu, 4 Jun 2020 08:36:22 +0200
Subject: [PATCH] compiler.h: Move instrumentation_begin()/end() into new
header
Linus pointed out that compiler.h - which is a key header that gets included in
every
single of the 28,000+ kernel files files being built - was unnecessarily
bloated in:
65538943: ("vmlinux.lds.h: Create section for protection against
instrumentation")
Move these primitives into a new header: , and include
that
header in context_tracking.h and x86/asm/bug.h, which makes use of it.
Reported-by: Linus Torvalds
Signed-off-by: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Peter Zijlstra
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/bug.h | 1 +
include/linux/compiler.h | 53 -
include/linux/context_tracking.h | 2 ++
include/linux/instrumentation.h | 57
4 files changed, 60 insertions(+), 53 deletions(-)
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index facba9bc30ca..37e4480dba75 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -3,6 +3,7 @@
#define _ASM_X86_BUG_H
#include
+#include
/*
* Despite that some emulators terminate on UD2, we use it for WARN().
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 6325d64e3c3b..448c91bf543b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -120,65 +120,12 @@ void ftrace_likely_update(struct ftrace_likely_data *f,
int val,
/* Annotate a C jump table to allow objtool to follow the code flow */
#define __annotate_jump_table __section(.rodata..c_jump_table)
-#ifdef CONFIG_DEBUG_ENTRY
-/* Begin/end of an instrumentation safe region */
-#define instrumentation_begin() ({ \
- asm volatile("%c0:\n\t" \
-".pushsection .discard.instr_begin\n\t"\
-".long %c0b - .\n\t" \
-".popsection\n\t" : : "i" (__COUNTER__)); \
-})
-
-/*
- * Because instrumentation_{begin,end}() can nest, objtool validation considers
- * _begin() a +1 and _end() a -1 and computes a sum over the instructions.
- * When the value is greater than 0, we consider instrumentation allowed.
- *
- * There is a problem with code like:
- *
- * noinstr void foo()
- * {
- * instrumentation_begin();
- * ...
- * if (cond) {
- * instrumentation_begin();
- * ...
- * instrumentation_end();
- * }
- * bar();
- * instrumentation_end();
- * }
- *
- * If instrumentation_end() would be an empty label, like all the other
- * annotations, the inner _end(), which is at the end of a conditional block,
- * would land on the instruction after the block.
- *
- * If we then consider the sum of the !cond path, we'll see that the call to
- * bar() is with a 0-value, even though, we meant it to happen with a positive
- * value.
- *
- * To avoid this, have _end() be a NOP instruction, this ensures it will be
- * part of the condition block and does not escape.
- */
-#define instrumentation_end() ({
Re: [PATCH] x86/mm: use max memory block size with unaligned memory end
On 04.06.20 05:54, Daniel Jordan wrote:
> Some of our servers spend 14 out of the 21 seconds of kernel boot
> initializing memory block sysfs directories and then creating symlinks
> between them and the corresponding nodes. The slowness happens because
> the machines get stuck with the smallest supported memory block size on
> x86 (128M), which results in 16,288 directories to cover the 2T of
> installed RAM, and each of these paths does a linear search of the
> memory blocks for every block id, with atomic ops at each step.
With 4fb6eabf1037 ("drivers/base/memory.c: cache memory blocks in xarray
to accelerate lookup") merged by Linus' today (strange, I thought this
would be long upstream) all linear searches should be gone and at least
the performance observation in this patch no longer applies.
The memmap init should nowadays consume most time.
--
Thanks,
David / dhildenb
Re: [PATCH][next] ovl: fix null pointer dereference on null stack pointer on error return
On Wed, Jun 3, 2020 at 6:15 PM Colin Ian King wrote:
>
> On 03/06/2020 17:11, Amir Goldstein wrote:
> > On Wed, Jun 3, 2020 at 6:46 PM Colin King wrote:
> >>
> >> From: Colin Ian King
> >>
> >> There are two error return paths where the call to path_put is
> >> dereferencing the null pointer 'stack'. Fix this by avoiding the
> >> error exit path via label 'out_err' that will lead to the path_put
> >> calls and instead just return the error code directly.
> >>
> >> Addresses-Coverity: ("Dereference after null check)"
> >> Fixes: 4155c10a0309 ("ovl: clean up getting lower layers")
> >> Signed-off-by: Colin Ian King
> >
> >
> > Which branch is that based on?
> > Doesn't seem to apply to master nor next
>
> It was based on today's linux-next
Yeah, it's actually
Fixes: 73819e26c0f0 ("ovl: get rid of redundant members in struct ovl_fs")
So I'll just fold your patch. There's still a change in the loop
count for later errors, but that's okay, since
ovl_lower_dir()/ovl_mount_dir_noesc() use the path_put_init() variant.
Actually ovl_lower_dir() can get rid of that path_put_init()
completely, since now the only caller will take care of that...
Thanks for reporting!
Miklos
Re: [PATCH 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Hi Laurent,
On 28-05-20, 04:52, Laurent Pinchart wrote:
> > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > + enum drm_bridge_attach_flags flags)
> > +{
> > + struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
> > + int ret;
> > +
> > + dev_dbg(lt9611->dev, "bridge attach\n");
>
>
> Connector creation in bridge drivers is deprecated. Please at least add
Okay what is the right way for connector creation? I can add support for
that.
> support for the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, to make connector
> creation optional. Ideally the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case
will add that
> should not be implemented at all. This will require the display
> controller driver to use DRM_BRIDGE_ATTACH_NO_CONNECTOR. Which display
> controller(s) do you use this driver with ?
I am using with msm display driver, this was tested on dragon-board
db845c board.
Thanks
--
~Vinod
Re: Re: [RFC v2 7/9] mm/damon: Implement callbacks for physical memory monitoring
On Wed, 3 Jun 2020 18:09:21 +0200 David Hildenbrand wrote:
> On 03.06.20 16:11, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > This commit implements the four callbacks (->init_target_regions,
> > ->update_target_regions, ->prepare_access_check, and ->check_accesses)
> > for the basic access monitoring of the physical memory address space.
> > By setting the callback pointers to point those, users can easily
> > monitor the accesses to the physical memory.
> >
> > Internally, it uses the PTE Accessed bit, as similar to that of the
> > virtual memory support. Also, it supports only page frames that
> > supported by idle page tracking. Acutally, most of the code is stollen
> > from idle page tracking. Users who want to use other access check
> > primitives and monitor the frames that not supported with this
> > implementation could implement their own callbacks on their own.
> >
> > Signed-off-by: SeongJae Park
> > ---
> > include/linux/damon.h | 5 ++
> > mm/damon.c| 184 ++
> > 2 files changed, 189 insertions(+)
> >
> > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > index 1a788bfd1b4e..f96503a532ea 100644
> > --- a/include/linux/damon.h
> > +++ b/include/linux/damon.h
> > @@ -216,6 +216,11 @@ void kdamond_update_vm_regions(struct damon_ctx *ctx);
> > void kdamond_prepare_vm_access_checks(struct damon_ctx *ctx);
> > unsigned int kdamond_check_vm_accesses(struct damon_ctx *ctx);
> >
> > +void kdamond_init_phys_regions(struct damon_ctx *ctx);
> > +void kdamond_update_phys_regions(struct damon_ctx *ctx);
> > +void kdamond_prepare_phys_access_checks(struct damon_ctx *ctx);
> > +unsigned int kdamond_check_phys_accesses(struct damon_ctx *ctx);
> > +
> > int damon_set_pids(struct damon_ctx *ctx, int *pids, ssize_t nr_pids);
> > int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,
> > unsigned long aggr_int, unsigned long regions_update_int,
> > diff --git a/mm/damon.c b/mm/damon.c
> > index f5cbc97a3bbc..6a5c6d540580 100644
> > --- a/mm/damon.c
> > +++ b/mm/damon.c
> > @@ -19,7 +19,9 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -480,6 +482,11 @@ void kdamond_init_vm_regions(struct damon_ctx *ctx)
> > }
> > }
> >
> > +/* Do nothing. Users should set the initial regions by themselves */
> > +void kdamond_init_phys_regions(struct damon_ctx *ctx)
> > +{
> > +}
> > +
> > static void damon_mkold(struct mm_struct *mm, unsigned long addr)
> > {
> > pte_t *pte = NULL;
> > @@ -611,6 +618,178 @@ unsigned int kdamond_check_vm_accesses(struct
> > damon_ctx *ctx)
> > return max_nr_accesses;
> > }
> >
> > +/* access check functions for physical address based regions */
> > +
> > +/* This code is stollen from page_idle.c */
> > +static struct page *damon_phys_get_page(unsigned long pfn)
> > +{
> > + struct page *page;
> > + pg_data_t *pgdat;
> > +
> > + if (!pfn_valid(pfn))
> > + return NULL;
> > +
>
> Who provides these pfns? Can these be random pfns, supplied unchecked by
> user space? Or are they at least mapped into some user space process?
Your guess is right, users can give random physical address and that will be
translated into pfn.
>
> IOW, do we need a pfn_to_online_page() to make sure the memmap even was
> initialized?
Thank you for pointing out this! I will use it in the next spin. Also, this
code is stollen from page_idle_get_page(). Seems like it should also be
modified to use it. I will send the patch for it, either.
Thanks,
SeongJae Park
>
> --
> Thanks,
>
> David / dhildenb
Re: [PATCH 00/10] Remove uninitialized_var() macro
On Thu, Jun 4, 2020 at 5:33 AM Nathan Chancellor
wrote:
>
> On Wed, Jun 03, 2020 at 04:31:53PM -0700, Kees Cook wrote:
> > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > (or can in the future), and suppresses unrelated compiler warnings
> > (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> > either simply initialize the variable or make compiler changes.
> >
> > As recommended[2] by[3] Linus[4], remove the macro.
> >
> > Most of the 300 uses don't cause any warnings on gcc 9.3.0, so they're in
> > a single treewide commit in this series. A few others needed to actually
> > get cleaned up, and I broke those out into individual patches.
> >
> > -Kees
> >
> > [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> > [2]
> > https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> > [3]
> > https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> > [4]
> > https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
> >
> > Kees Cook (10):
> > x86/mm/numa: Remove uninitialized_var() usage
> > drbd: Remove uninitialized_var() usage
> > b43: Remove uninitialized_var() usage
> > rtlwifi: rtl8192cu: Remove uninitialized_var() usage
> > ide: Remove uninitialized_var() usage
> > clk: st: Remove uninitialized_var() usage
> > spi: davinci: Remove uninitialized_var() usage
> > checkpatch: Remove awareness of uninitialized_var() macro
> > treewide: Remove uninitialized_var() usage
> > compiler: Remove uninitialized_var() macro
>
> I applied all of these on top of cb8e59cc8720 and ran a variety of
> builds with clang for arm32, arm64, mips, powerpc, s390, and x86_64 [1]
> and only saw one warning pop up (which was about a variable being
> unused, commented on patch 9 about it). No warnings about uninitialized
> variables came up; clang's -Wuninitialized was not impacted by
> 78a5255ffb6a ("Stop the ad-hoc games with -Wno-maybe-initialized") so it
> should have caught anything egregious.
>
> [1]: https://github.com/nathanchance/llvm-kernel-testing
>
> For the series, consider it:
>
> Tested-by: Nathan Chancellor [build]
>
Hi Kees,
I tried with updated version (checkpatch) of your tree and see no
(new) warnings in my build-log.
Feel free to add my...
Tested-by: Sedat Dilek
Thanks.
Regards,
- Sedat -
Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
Hi Mathieu, +Will On 2020-06-03 23:14, Mathieu Poirier wrote: On Wed, Jun 03, 2020 at 02:34:10PM +0100, Robin Murphy wrote: On 2020-06-03 14:22, Mike Leach wrote: > Hi Sai, > > On Wed, 3 Jun 2020 at 13:14, Sai Prakash Ranjan > wrote: > > > > Hi Mike, > > > > On 2020-06-03 16:57, Mike Leach wrote: > > > Hi, > > > > > > On Wed, 3 Jun 2020 at 11:24, Sai Prakash Ranjan > > > wrote: > > > > > > > > Hi Mike, > > > > > > > > Thanks again for looking at this. > > > > > > > > On 2020-06-03 03:42, Mike Leach wrote: > > > > [...] > > > > > > > > > > > > > > > > SMMU/IOMMU won't be able to do much here as it is the client's > > > > > > responsiblity to > > > > > > properly shutdown and SMMU device link just makes sure that > > > > > > SMMU(supplier) shutdown is > > > > > > called only after its consumers shutdown callbacks are called. > > > > > > > > > > I think this use case can be handled slightly differently than the > > > > > general requirements for modular CoreSight drivers. > > > > > > > > > > What is needed here is a way of stopping the underlying ETR hardware > > > > > from issuing data to the SMMU, until the entire device has been shut > > > > > down, in a way that does not remove the driver, breaking existing > > > > > references and causing a system crash. > > > > > > > > > > We could introduce a new mode to the ETR driver - e.g. > > > > > CS_MODE_SHUTDOWN. > > > > > > > > > > At the end of the block tmc_shutdown(struct amba_device *adev), set > > > > > drvdata->mode to CS_MODE_SHUTDOWN & remove the coresight_unregister(). > > > > > This new mode can be used to prevent the underlying hardware from > > > > > being able to restart until the device is re-powered. > > > > > > > > > > This mode can be detected in the code that enables / disables the ETR > > > > > and handled appropriately (updates to tmc_enable_etr_sink and > > > > > tmc_disable_etr_sink). > > > > > This mode will persist until the device is re-started - but because we > > > > > are on the device shutdown path this is not an issue. > > > > > > > > > > This should leave the CoreSight infrastructure stable until the > > > > > drivers are shut down normally as part of the device power down > > > > > process. > > > > > > > > > > > > > Sounds good to me, but if the coresight_unregister() is the trouble > > > > point > > > > causing these crashes, then can't we just remove that from > > > > tmc_shutdown() > > > > callback? This would be like maintaining the same behaviour as now > > > > where > > > > on reboot/shutdown we basically don't do anything except for disabling > > > > ETR. > > > > > > No - the new mode prevents race conditions where the thread shutting > > > down the SMMU does the ETR shutdown, but then another thread happens > > > to be trying to start trace and restarts the ETR. > > > It also prevents the condition Mathieu discussed where a thread might > > > be attempting to shutdown trace - this could try to disable the > > > hardware again re-releasing resources/ re-flushing and waiting for > > > stop. > > > > > > > I do not think there will a race between SMMU shutdown and ETR shutdown. > > Driver core takes care of calling SMMU shutdown after its consumer > > shutdown callbacks via device link, otherwise there would already be > > bugs in all other client drivers. > > > > I am not saying there could be a race between tmc_shutdowm and > Smmu_shutdown - there may be a case if the coresight_disable_path > sequence is running and gets to the point of disabling the ETR after > the SMMU callback has disabled it. I'm confused now - there is no "SMMU callback", we're talking about the system-wide cleanup from kernel_shutdown_prepare() or kernel_restart_prepare(). As far as I'm aware userspace should be long gone by that point, so although trace may have been left running, the chance of racing against other driver operations seems pretty unlikely. Robin has a point - user space is long gone at this time. As such the first question to ask is what kind of CS session was running at the time the system was shutting down. Was it a perf session of a sysfs session? I'm guessing it was a sysfs session because user space has been blown away a while back and part of that process should have killed all perf sessions. I was enabling trace via sysfs. If I am correct then simply switching off the ETR HW in the shutdown() amba bus callback should be fine - otherwise Mike's approach is mandatory. There is also the exchange between Robin and Sai about removing the SMMU shutdown callback, but that thread is still incomplete. If Robin is hinting at removing SMMU shutdown callback, then I think adding all these shutdown callbacks to all clients of SMMU can be avoided. Git blaming the thing shows it was added to avoid some kexec memory corruption. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2 0/6] seqlock: seqcount_t call sites bugfixes
On Wed, Jun 03, 2020 at 04:49:43PM +0200, Ahmed S. Darwish wrote: > Hi, > > Since patch #7 and #8 from the series: > >[PATCH v1 00/25] seqlock: Extend seqcount API with associated locks > > https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de > > are now pending on the lockdep/x86 IRQ state tracking patch series: > >[PATCH 00/14] x86/entry: disallow #DB more and x86/entry lockdep/nmi >https://lkml.kernel.org/r/20200529212728.795169...@infradead.org > >[PATCH v3 0/5] lockdep: Change IRQ state tracking to use per-cpu variables >https://lkml.kernel.org/r/20200529213550.683440...@infradead.org > > This is a repost only of the seqcount_t call sites bugfixes that were on > top of the seqlock patch series. > > These fixes are independent, and can thus be merged on their own. I'm > reposting them now so they can at least hit -rc2 or -rc3. I'm confused on what I should do with patch 6 here for dma-buf. Looks like just a good cleanup/prep work, so I'd queue it for linux-next and 5.9, but sounds like you want this in earlier. Do you need this in 5.8-rc for some work meant for 5.9? Will this go in through some topic branch directly? Should I apply it? Patch itself lgtm, I'm just confused what I should do with it. -Daniel > > Changelog-v2: > > - patch #1: Add a missing up_read() on netdev_get_name() error path > exit. Thanks to Dan/kbuild-bot report. > > - patch #4: new patch, invalid preemptible context found by the new > lockdep checks added in the seqlock series + kbuild-bot. > > Thanks, > > 8<-- > > Ahmed S. Darwish (6): > net: core: device_rename: Use rwsem instead of a seqcount > net: phy: fixed_phy: Remove unused seqcount > u64_stats: Document writer non-preemptibility requirement > net: mdiobus: Disable preemption upon u64_stats update > block: nr_sects_write(): Disable preemption on seqcount write > dma-buf: Remove custom seqcount lockdep class key > > block/blk.h| 2 ++ > drivers/dma-buf/dma-resv.c | 9 +-- > drivers/net/phy/fixed_phy.c| 26 > drivers/net/phy/mdio_bus.c | 2 ++ > include/linux/dma-resv.h | 2 -- > include/linux/u64_stats_sync.h | 43 ++ > net/core/dev.c | 40 ++- > 7 files changed, 56 insertions(+), 68 deletions(-) > > base-commit: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 > -- > 2.20.1 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v9 06/18] media: platform: Delete the resetting hardware flow in the system PM ops
Delete the resetting hardware flow in suspend and resume function
because that resetting operation will be done in device_run().
Signed-off-by: Xia Jiang
---
v9: new patch
---
check.txt | 13 +
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 2 --
2 files changed, 13 insertions(+), 2 deletions(-)
create mode 100644 check.txt
diff --git a/check.txt b/check.txt
new file mode 100644
index ..aed39e5f62f2
--- /dev/null
+++ b/check.txt
@@ -0,0 +1,13 @@
+WARNING:LONG_LINE: line over 80 characters
+#820: FILE: ./drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c:820:
++ if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param,
&dst_buf->vb2_buf, &fb))
+
+total: 0 errors, 1 warnings, 1271 lines checked
+
+NOTE: For some of the reported defects, checkpatch may be able to
+ mechanically convert to the typical style using --fix or --fix-inplace.
+
+./drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c has style problems, please
review.
+
+NOTE: If any of the errors are false positives, please report
+ them to the maintainer, see CHECKPATCH in MAINTAINERS.
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index fb624385969e..7f74597262fc 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1191,7 +1191,6 @@ static __maybe_unused int mtk_jpeg_pm_suspend(struct
device *dev)
{
struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
- mtk_jpeg_dec_reset(jpeg->dec_reg_base);
mtk_jpeg_clk_off(jpeg);
return 0;
@@ -1202,7 +1201,6 @@ static __maybe_unused int mtk_jpeg_pm_resume(struct
device *dev)
struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
mtk_jpeg_clk_on(jpeg);
- mtk_jpeg_dec_reset(jpeg->dec_reg_base);
return 0;
}
--
2.18.0
[PATCH v9 05/18] media: platform: Improve power on and power off flow
Call pm_runtime_get_sync() before starting a frame and then
pm_runtime_put() after completing it. This can save power for the time
between processing two frames.
Signed-off-by: Xia Jiang
---
v9: use pm_runtime_put() to replace pm_runtime_put_sync()
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 27 +--
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 12609ca46fd9..fb624385969e 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -710,23 +710,6 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct
mtk_jpeg_ctx *ctx,
return v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
}
-static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
-{
- struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
- struct vb2_v4l2_buffer *vb;
- int ret = 0;
-
- ret = pm_runtime_get_sync(ctx->jpeg->dev);
- if (ret < 0)
- goto err;
-
- return 0;
-err:
- while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
- v4l2_m2m_buf_done(vb, VB2_BUF_STATE_QUEUED);
- return ret;
-}
-
static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
{
struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
@@ -751,8 +734,6 @@ static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
-
- pm_runtime_put_sync(ctx->jpeg->dev);
}
static const struct vb2_ops mtk_jpeg_qops = {
@@ -761,7 +742,6 @@ static const struct vb2_ops mtk_jpeg_qops = {
.buf_queue = mtk_jpeg_buf_queue,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish= vb2_ops_wait_finish,
- .start_streaming= mtk_jpeg_start_streaming,
.stop_streaming = mtk_jpeg_stop_streaming,
};
@@ -812,7 +792,7 @@ static void mtk_jpeg_device_run(void *priv)
struct mtk_jpeg_src_buf *jpeg_src_buf;
struct mtk_jpeg_bs bs;
struct mtk_jpeg_fb fb;
- int i;
+ int i, ret;
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -832,6 +812,10 @@ static void mtk_jpeg_device_run(void *priv)
return;
}
+ ret = pm_runtime_get_sync(jpeg->dev);
+ if (ret < 0)
+ goto dec_end;
+
mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs);
if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param,
&dst_buf->vb2_buf, &fb))
goto dec_end;
@@ -957,6 +941,7 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
v4l2_m2m_buf_done(src_buf, buf_state);
v4l2_m2m_buf_done(dst_buf, buf_state);
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
+ pm_runtime_put(ctx->jpeg->dev);
return IRQ_HANDLED;
}
--
2.18.0
[PATCH v9 01/18] media: platform: Improve subscribe event flow for bug fixing
Let v4l2_ctrl_subscribe_event() do the job for other types except
V4L2_EVENT_SOURCE_CHANGE.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v9: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index f82a81a3bdee..4ad4a4b30a0e 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -446,9 +446,9 @@ static int mtk_jpeg_subscribe_event(struct v4l2_fh *fh,
switch (sub->type) {
case V4L2_EVENT_SOURCE_CHANGE:
return v4l2_src_change_event_subscribe(fh, sub);
- default:
- return -EINVAL;
}
+
+ return v4l2_ctrl_subscribe_event(fh, sub);
}
static int mtk_jpeg_g_selection(struct file *file, void *priv,
--
2.18.0
[PATCH v9 13/18] media: platform: Delete redundant code and add annotation for an enum
Delete unused member variables annotation.
Delete unused variable definition.
Delete redundant log print, because V4L2 debug logs already print it.
Add annotation for enum mtk_jpeg_ctx_state.
Signed-off-by: Xia Jiang
---
v9: add annotation for enum mtk_jpeg_ctx_state
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 15 ++-
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 8 ++--
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index c9c0357b2d6c..6c82134d6b3d 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -176,14 +176,13 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
struct mtk_jpeg_ctx *ctx, int q_type)
{
struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
- struct mtk_jpeg_dev *jpeg = ctx->jpeg;
int i;
pix_mp->field = V4L2_FIELD_NONE;
if (ctx->state != MTK_JPEG_INIT) {
mtk_jpeg_adjust_fmt_mplane(ctx, f);
- goto end;
+ return 0;
}
pix_mp->num_planes = fmt->colplanes;
@@ -202,7 +201,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
if (pfmt->sizeimage == 0)
pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
- goto end;
+ return 0;
}
/* type is MTK_JPEG_FMT_TYPE_CAPTURE */
@@ -219,16 +218,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
pfmt->bytesperline = stride;
pfmt->sizeimage = stride * h;
}
-end:
- v4l2_dbg(2, debug, &jpeg->v4l2_dev, "wxh:%ux%u\n",
-pix_mp->width, pix_mp->height);
- for (i = 0; i < pix_mp->num_planes; i++) {
- v4l2_dbg(2, debug, &jpeg->v4l2_dev,
-"plane[%d] bpl=%u, size=%u\n",
-i,
-pix_mp->plane_fmt[i].bytesperline,
-pix_mp->plane_fmt[i].sizeimage);
- }
return 0;
}
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 64a731261214..5fcdf6950782 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -30,6 +30,12 @@
#define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024)
+/**
+ * enum mtk_jpeg_ctx_state - states of the context state machine
+ * @MTK_JPEG_INIT: current state is initialized
+ * @MTK_JPEG_RUNNING: current state is running
+ * @MTK_JPEG_SOURCE_CHANGE:current state is source resolution change
+ */
enum mtk_jpeg_ctx_state {
MTK_JPEG_INIT = 0,
MTK_JPEG_RUNNING,
@@ -109,9 +115,7 @@ struct mtk_jpeg_q_data {
* @out_q: source (output) queue information
* @cap_q: destination (capture) queue queue information
* @fh:V4L2 file handle
- * @dec_param parameters for HW decoding
* @state: state of the context
- * @header_valid: set if header has been parsed and valid
* @colorspace: enum v4l2_colorspace; supplemental to pixelformat
* @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
* @quantization: enum v4l2_quantization, colorspace quantization
--
2.18.0
[PATCH v9 07/18] media: platform: Improve the implementation of the system PM ops
Add v4l2_m2m_suspend() function call in mtk_jpeg_suspend() to make sure
that the current frame is processed completely before suspend.
Add v4l2_m2m_resume() function call in mtk_jpeg_resume() to unblock the
driver from scheduling next frame.
Signed-off-by: Xia Jiang
---
v9: use v4l2_m2m_suspend() and v4l2_m2m_resume() to improve the
implemention of the system PM ops
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 7f74597262fc..49bdbf1c435f 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1208,10 +1208,13 @@ static __maybe_unused int mtk_jpeg_pm_resume(struct
device *dev)
static __maybe_unused int mtk_jpeg_suspend(struct device *dev)
{
int ret;
+ struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
if (pm_runtime_suspended(dev))
return 0;
+ v4l2_m2m_suspend(jpeg->m2m_dev);
+
ret = mtk_jpeg_pm_suspend(dev);
return ret;
}
@@ -1219,12 +1222,15 @@ static __maybe_unused int mtk_jpeg_suspend(struct
device *dev)
static __maybe_unused int mtk_jpeg_resume(struct device *dev)
{
int ret;
+ struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
if (pm_runtime_suspended(dev))
return 0;
ret = mtk_jpeg_pm_resume(dev);
+ v4l2_m2m_resume(jpeg->m2m_dev);
+
return ret;
}
--
2.18.0
[PATCH v9 03/18] media: platform: Improve getting and requesting irq flow for bug fixing
Delete platform_get_resource operation for irq.
Return actual value rather than EINVAL when fail to get and request
irq.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v9: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 67a022d04df7..2677580941b0 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1103,12 +1103,10 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
return ret;
}
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
dec_irq = platform_get_irq(pdev, 0);
- if (!res || dec_irq < 0) {
+ if (dec_irq < 0) {
dev_err(&pdev->dev, "Failed to get dec_irq %d.\n", dec_irq);
- ret = -EINVAL;
- return ret;
+ return dec_irq;
}
ret = devm_request_irq(&pdev->dev, dec_irq, mtk_jpeg_dec_irq, 0,
@@ -1116,7 +1114,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "Failed to request dec_irq %d (%d)\n",
dec_irq, ret);
- ret = -EINVAL;
goto err_req_irq;
}
--
2.18.0
[PATCH v9 17/18] media: platform: Rename existing functions/defines/variables
Rename existing funcitons/defines/variables with a _dec prefix and
without dec_ prefix to prepare for the addition of the jpeg encoder
feature.
Signed-off-by: Xia Jiang
---
v9: new patch
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 196 +-
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 8 +-
.../media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h | 7 +-
3 files changed, 107 insertions(+), 104 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index e0e522a502e1..8d5a78c775a6 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -27,7 +27,7 @@
#include "mtk_jpeg_core.h"
#include "mtk_jpeg_dec_parse.h"
-static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
.colplanes = 1,
@@ -53,7 +53,7 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
},
};
-#define MTK_JPEG_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_formats)
+#define MTK_JPEG_DEC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_dec_formats)
struct mtk_jpeg_src_buf {
struct vb2_v4l2_buffer b;
@@ -75,12 +75,12 @@ static inline struct mtk_jpeg_src_buf
*mtk_jpeg_vb2_to_srcbuf(
return container_of(to_vb2_v4l2_buffer(vb), struct mtk_jpeg_src_buf, b);
}
-static int mtk_jpeg_querycap(struct file *file, void *priv,
+static int mtk_jpeg_dec_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
struct mtk_jpeg_dev *jpeg = video_drvdata(file);
- strscpy(cap->driver, MTK_JPEG_NAME " decoder", sizeof(cap->driver));
+ strscpy(cap->driver, MTK_JPEG_NAME, sizeof(cap->driver));
strscpy(cap->card, MTK_JPEG_NAME " decoder", sizeof(cap->card));
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
dev_name(jpeg->dev));
@@ -109,22 +109,23 @@ static int mtk_jpeg_enum_fmt(struct mtk_jpeg_fmt
*mtk_jpeg_formats, int n,
return 0;
}
-static int mtk_jpeg_enum_fmt_vid_cap(struct file *file, void *priv,
-struct v4l2_fmtdesc *f)
+static int mtk_jpeg_dec_enum_fmt_vid_cap(struct file *file, void *priv,
+struct v4l2_fmtdesc *f)
{
- return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
+ return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats,
+MTK_JPEG_DEC_NUM_FORMATS, f,
MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
}
-static int mtk_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
-struct v4l2_fmtdesc *f)
+static int mtk_jpeg_dec_enum_fmt_vid_out(struct file *file, void *priv,
+struct v4l2_fmtdesc *f)
{
- return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
-MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
+ return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
+f, MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
}
-static struct mtk_jpeg_q_data *mtk_jpeg_get_q_data(struct mtk_jpeg_ctx *ctx,
- enum v4l2_buf_type type)
+static struct mtk_jpeg_q_data *
+mtk_jpeg_get_q_data(struct mtk_jpeg_ctx *ctx, enum v4l2_buf_type type)
{
if (V4L2_TYPE_IS_OUTPUT(type))
return &ctx->out_q;
@@ -141,8 +142,8 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct
mtk_jpeg_ctx *ctx,
MTK_JPEG_FMT_FLAG_DEC_OUTPUT :
MTK_JPEG_FMT_FLAG_DEC_CAPTURE;
- for (k = 0; k < MTK_JPEG_NUM_FORMATS; k++) {
- struct mtk_jpeg_fmt *fmt = &mtk_jpeg_formats[k];
+ for (k = 0; k < MTK_JPEG_DEC_NUM_FORMATS; k++) {
+ struct mtk_jpeg_fmt *fmt = &mtk_jpeg_dec_formats[k];
if (fmt->fourcc == pixelformat && fmt->flags & fmt_flag)
return fmt;
@@ -270,8 +271,8 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file,
void *priv,
return 0;
}
-static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file *file, void *priv,
- struct v4l2_format *f)
+static int mtk_jpeg_dec_try_fmt_vid_cap_mplane(struct file *file, void *priv,
+ struct v4l2_format *f)
{
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
struct mtk_jpeg_fmt *fmt;
@@ -291,8 +292,8 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file
*file, void *priv,
return mtk_jpeg_try_fmt_mplane(f, fmt, ctx, MTK_JPEG_FMT_TYPE_CAPTURE);
}
-static int mtk_jpeg_try_fmt_vid_out_mplane(struct file *file, void *priv,
- struct v4l2_format *f)
+static int mtk_jpeg_dec_try_fmt_vid_out_mplane(struct file *file, void *p
RE: [PATCH] x86/speculation: Check whether speculation is force disabled
>It conflicts with your new code. We can have an argument on whether IB should >follow how SSB is being handled. Before that is settled, Thank you for the information. It conflicts but I think users who read the below document get confused. Documentation/userspace-api/spec_ctrl.rst. Especially, seccomp users must know the difference of this implicit specification because both IB and SSB are force disabled simultaneously when seccomp is enabled without SECCOMP_FILTER_FLAG_SPEC_ALLOW on x86. -Original Message- From: Waiman Long Sent: Thursday, June 4, 2020 12:40 AM To: Tada, Kenta (Sony) ; x...@kernel.org; t...@linutronix.de; mi...@redhat.com; b...@alien8.de; h...@zytor.com; jpoim...@redhat.com; pet...@infradead.org; tony.l...@intel.com; pawan.kumar.gu...@linux.intel.com Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/speculation: Check whether speculation is force disabled On 6/3/20 3:12 AM, Tada, Kenta (Sony) wrote: > Once PR_SPEC_FORCE_DISABLE is set, users cannot set PR_SPEC_ENABLE. > This commit checks whether PR_SPEC_FORCE_DISABLE was previously set. > > Signed-off-by: Kenta Tada > --- > arch/x86/kernel/cpu/bugs.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > index ed54b3b21c39..678ace157035 100644 > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -1173,6 +1173,9 @@ static int ib_prctl_set(struct task_struct *task, > unsigned long ctrl) > if (spectre_v2_user == SPECTRE_V2_USER_STRICT || > spectre_v2_user == SPECTRE_V2_USER_STRICT_PREFERRED) > return -EPERM; > + /* If speculation is force disabled, enable is not allowed */ > + if (task_spec_ib_force_disable(task)) > + return -EPERM; > task_clear_spec_ib_disable(task); > task_update_spec_tif(task); > break; There is a comment up a few lines about this: /* * Indirect branch speculation is always allowed when * mitigation is force disabled. */ It conflicts with your new code. We can have an argument on whether IB should follow how SSB is being handled. Before that is settled, Nacked-by: Waiman Long
[PATCH v9 11/18] media: platform: Use generic rounding helpers
Use clamp() to replace mtk_jpeg_bound_align_image() and round() to
replace mtk_jpeg_align().
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v9: change the patch title description
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 41 +--
drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c | 8 ++--
drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h | 5 ---
3 files changed, 15 insertions(+), 39 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index bd1cc58324c6..c9c0357b2d6c 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -151,25 +151,6 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct
mtk_jpeg_ctx *ctx,
return NULL;
}
-static void mtk_jpeg_bound_align_image(u32 *w, unsigned int wmin,
- unsigned int wmax, unsigned int walign,
- u32 *h, unsigned int hmin,
- unsigned int hmax, unsigned int halign)
-{
- int width, height, w_step, h_step;
-
- width = *w;
- height = *h;
- w_step = 1 << walign;
- h_step = 1 << halign;
-
- v4l_bound_align_image(w, wmin, wmax, walign, h, hmin, hmax, halign, 0);
- if (*w < width && (*w + w_step) <= wmax)
- *w += w_step;
- if (*h < height && (*h + h_step) <= hmax)
- *h += h_step;
-}
-
static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
struct v4l2_format *f)
{
@@ -211,24 +192,24 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[0];
- mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
- MTK_JPEG_MAX_WIDTH, 0,
- &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
- MTK_JPEG_MAX_HEIGHT, 0);
+ pix_mp->height = clamp(pix_mp->height, MTK_JPEG_MIN_HEIGHT,
+ MTK_JPEG_MAX_HEIGHT);
+ pix_mp->width = clamp(pix_mp->width, MTK_JPEG_MIN_WIDTH,
+ MTK_JPEG_MAX_WIDTH);
pfmt->bytesperline = 0;
/* Source size must be aligned to 128 */
- pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
+ pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
if (pfmt->sizeimage == 0)
pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
goto end;
}
/* type is MTK_JPEG_FMT_TYPE_CAPTURE */
- mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
- MTK_JPEG_MAX_WIDTH, fmt->h_align,
- &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
- MTK_JPEG_MAX_HEIGHT, fmt->v_align);
+ pix_mp->height = clamp(round_up(pix_mp->height, fmt->v_align),
+ MTK_JPEG_MIN_HEIGHT, MTK_JPEG_MAX_HEIGHT);
+ pix_mp->width = clamp(round_up(pix_mp->width, fmt->h_align),
+ MTK_JPEG_MIN_WIDTH, MTK_JPEG_MAX_WIDTH);
for (i = 0; i < fmt->colplanes; i++) {
struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[i];
@@ -734,8 +715,8 @@ static void mtk_jpeg_set_dec_src(struct mtk_jpeg_ctx *ctx,
{
bs->str_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
bs->end_addr = bs->str_addr +
-mtk_jpeg_align(vb2_get_plane_payload(src_buf, 0), 16);
- bs->size = mtk_jpeg_align(vb2_plane_size(src_buf, 0), 128);
+ round_up(vb2_get_plane_payload(src_buf, 0), 16);
+ bs->size = round_up(vb2_plane_size(src_buf, 0), 128);
}
static int mtk_jpeg_set_dec_dst(struct mtk_jpeg_ctx *ctx,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
index ddf0dfa78e20..68abcfd7494d 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
@@ -153,10 +153,10 @@ static int mtk_jpeg_calc_dst_size(struct
mtk_jpeg_dec_param *param)
param->sampling_w[i];
/* output format is 420/422 */
param->comp_w[i] = padding_w >> brz_w[i];
- param->comp_w[i] = mtk_jpeg_align(param->comp_w[i],
- MTK_JPEG_DCTSIZE);
- param->img_stride[i] = i ? mtk_jpeg_align(param->comp_w[i], 16)
- : mtk_jpeg_align(param->comp_w[i], 32);
+ param->comp_w[i] = round_up(param->comp_w[i],
+ MTK_JPEG_DCTSIZE);
+
[PATCH v9 18/18] media: platform: Add jpeg enc feature
Add mtk jpeg encode v4l2 driver based on jpeg decode, because that jpeg
decode and encode have great similarities with function operation.
Signed-off-by: Xia Jiang
---
v9: add member variable(struct v4l2_rect) in out_q structure for storing
the active crop information.
move the renaming exsting functions/defines/variables to a separate patch.
---
drivers/media/platform/mtk-jpeg/Makefile | 5 +-
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 845 +++---
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 44 +-
.../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c | 193
.../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h | 123 +++
5 files changed, 1084 insertions(+), 126 deletions(-)
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h
diff --git a/drivers/media/platform/mtk-jpeg/Makefile
b/drivers/media/platform/mtk-jpeg/Makefile
index 48516dcf96e6..76c33aad0f3f 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o \
+mtk_jpeg_dec_hw.o \
+mtk_jpeg_dec_parse.o \
+mtk_jpeg_enc_hw.o
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 8d5a78c775a6..754030e4adde 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -3,6 +3,7 @@
* Copyright (c) 2016 MediaTek Inc.
* Author: Ming Hsiu Tsai
* Rick Chang
+ * Xia Jiang
*/
#include
@@ -23,10 +24,59 @@
#include
#include
+#include "mtk_jpeg_enc_hw.h"
#include "mtk_jpeg_dec_hw.h"
#include "mtk_jpeg_core.h"
#include "mtk_jpeg_dec_parse.h"
+static struct mtk_jpeg_fmt mtk_jpeg_enc_formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .colplanes = 1,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_CAPTURE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_NV12M,
+ .hw_format = JPEG_ENC_YUV_FORMAT_NV12,
+ .h_sample = {4, 4},
+ .v_sample = {4, 2},
+ .colplanes = 2,
+ .h_align= 4,
+ .v_align= 4,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_NV21M,
+ .hw_format = JEPG_ENC_YUV_FORMAT_NV21,
+ .h_sample = {4, 4},
+ .v_sample = {4, 2},
+ .colplanes = 2,
+ .h_align= 4,
+ .v_align= 4,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .hw_format = JPEG_ENC_YUV_FORMAT_YUYV,
+ .h_sample = {8},
+ .v_sample = {4},
+ .colplanes = 1,
+ .h_align= 5,
+ .v_align= 3,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .hw_format = JPEG_ENC_YUV_FORMAT_YVYU,
+ .h_sample = {8},
+ .v_sample = {4},
+ .colplanes = 1,
+ .h_align= 5,
+ .v_align= 3,
+ .flags = MTK_JPEG_FMT_FLAG_ENC_OUTPUT,
+ },
+};
+
static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
@@ -53,6 +103,7 @@ static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
},
};
+#define MTK_JPEG_ENC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_enc_formats)
#define MTK_JPEG_DEC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_dec_formats)
struct mtk_jpeg_src_buf {
@@ -64,6 +115,11 @@ struct mtk_jpeg_src_buf {
static int debug;
module_param(debug, int, 0644);
+static inline struct mtk_jpeg_ctx *ctrl_to_ctx(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl->handler, struct mtk_jpeg_ctx, ctrl_hdl);
+}
+
static inline struct mtk_jpeg_ctx *mtk_jpeg_fh_to_ctx(struct v4l2_fh *fh)
{
return container_of(fh, struct mtk_jpeg_ctx, fh);
@@ -75,6 +131,19 @@ static inline struct mtk_jpeg_src_buf
*mtk_jpeg_vb2_to_srcbuf(
return container_of(to_vb2_v4l2_buffer(vb), struct mtk_jpeg_src_buf, b);
}
+static int mtk_jpeg_enc_querycap(struct file *file, void *priv,
+struct v4l2_capability *cap)
+{
+ struct mtk_jpeg_dev *jpeg = video_drvdata(file);
+
+ strscpy(cap->driver, MTK_JPEG_NAME, sizeof(cap->driver));
+ strscpy(cap->card, MTK_
[PATCH v9 12/18] media: platform: Change MTK_JPEG_COMP_MAX macro definition location
Move MTK_JPEG_COMP_MAX definition to mtk_jpeg_core.h file, because it is used by mtk_jpeg_core.c file. Reviewed-by: Tomasz Figa Signed-off-by: Xia Jiang --- v9: no changes --- drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 ++ drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 1 - 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h index 28e9b30ad5c3..64a731261214 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h @@ -15,6 +15,8 @@ #define MTK_JPEG_NAME "mtk-jpeg" +#define MTK_JPEG_COMP_MAX 3 + #define MTK_JPEG_FMT_FLAG_DEC_OUTPUT BIT(0) #define MTK_JPEG_FMT_FLAG_DEC_CAPTURE BIT(1) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h index 2945da842dfa..21ec8f96797f 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h @@ -8,7 +8,6 @@ #ifndef _MTK_JPEG_REG_H #define _MTK_JPEG_REG_H -#define MTK_JPEG_COMP_MAX 3 #define MTK_JPEG_BLOCK_MAX 10 #define MTK_JPEG_DCTSIZE 8 -- 2.18.0
[PATCH v9 10/18] media: platform: Stylistic changes for improving code quality
Change register offset hex numerals from uppercase to lowercase. Change data type of max/min width/height from integer to unsigned integer. Signed-off-by: Xia Jiang --- v9: move changing data type of max/min width/height to this patch --- .../media/platform/mtk-jpeg/mtk_jpeg_core.h| 8 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 18 +- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h index 999bd1427809..28e9b30ad5c3 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h @@ -21,10 +21,10 @@ #define MTK_JPEG_FMT_TYPE_OUTPUT 1 #define MTK_JPEG_FMT_TYPE_CAPTURE 2 -#define MTK_JPEG_MIN_WIDTH 32 -#define MTK_JPEG_MIN_HEIGHT32 -#define MTK_JPEG_MAX_WIDTH 8192 -#define MTK_JPEG_MAX_HEIGHT8192 +#define MTK_JPEG_MIN_WIDTH 32U +#define MTK_JPEG_MIN_HEIGHT32U +#define MTK_JPEG_MAX_WIDTH 8192U +#define MTK_JPEG_MAX_HEIGHT8192U #define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h index 94db04e9cdb6..2945da842dfa 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h @@ -20,29 +20,29 @@ #define BIT_INQST_MASK_ALLIRQ 0x37 #define JPGDEC_REG_RESET 0x0090 -#define JPGDEC_REG_BRZ_FACTOR 0x00F8 -#define JPGDEC_REG_DU_NUM 0x00FC +#define JPGDEC_REG_BRZ_FACTOR 0x00f8 +#define JPGDEC_REG_DU_NUM 0x00fc #define JPGDEC_REG_DEST_ADDR0_Y0x0140 #define JPGDEC_REG_DEST_ADDR0_U0x0144 #define JPGDEC_REG_DEST_ADDR0_V0x0148 -#define JPGDEC_REG_DEST_ADDR1_Y0x014C +#define JPGDEC_REG_DEST_ADDR1_Y0x014c #define JPGDEC_REG_DEST_ADDR1_U0x0150 #define JPGDEC_REG_DEST_ADDR1_V0x0154 #define JPGDEC_REG_STRIDE_Y0x0158 -#define JPGDEC_REG_STRIDE_UV 0x015C +#define JPGDEC_REG_STRIDE_UV 0x015c #define JPGDEC_REG_IMG_STRIDE_Y0x0160 #define JPGDEC_REG_IMG_STRIDE_UV 0x0164 -#define JPGDEC_REG_WDMA_CTRL 0x016C +#define JPGDEC_REG_WDMA_CTRL 0x016c #define JPGDEC_REG_PAUSE_MCU_NUM 0x0170 -#define JPGDEC_REG_OPERATION_MODE 0x017C +#define JPGDEC_REG_OPERATION_MODE 0x017c #define JPGDEC_REG_FILE_ADDR 0x0200 -#define JPGDEC_REG_COMP_ID 0x020C +#define JPGDEC_REG_COMP_ID 0x020c #define JPGDEC_REG_TOTAL_MCU_NUM 0x0210 #define JPGDEC_REG_COMP0_DATA_UNIT_NUM 0x0224 -#define JPGDEC_REG_DU_CTRL 0x023C +#define JPGDEC_REG_DU_CTRL 0x023c #define JPGDEC_REG_TRIG0x0240 #define JPGDEC_REG_FILE_BRP0x0248 -#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024C +#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024c #define JPGDEC_REG_QT_ID 0x0270 #define JPGDEC_REG_INTERRUPT_STATUS0x0274 #define JPGDEC_REG_STATUS 0x0278 -- 2.18.0
[PATCH v9 16/18] media: platform: Rename jpeg dec file name
Rename the files which are for decode feature. This is preparing
path since the jpeg enc patch will be added later.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v9: no changes
---
drivers/media/platform/mtk-jpeg/Makefile | 2 +-
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
.../platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}| 2 +-
.../platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}| 2 +-
.../mtk-jpeg/{mtk_jpeg_parse.c => mtk_jpeg_dec_parse.c} | 2 +-
.../mtk-jpeg/{mtk_jpeg_parse.h => mtk_jpeg_dec_parse.h} | 2 +-
.../platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h} | 0
7 files changed, 7 insertions(+), 7 deletions(-)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}
(99%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}
(98%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.c =>
mtk_jpeg_dec_parse.c} (98%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.h =>
mtk_jpeg_dec_parse.h} (92%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h}
(100%)
diff --git a/drivers/media/platform/mtk-jpeg/Makefile
b/drivers/media/platform/mtk-jpeg/Makefile
index 92a4fc046bfe..48516dcf96e6 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 6c82134d6b3d..e0e522a502e1 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -23,9 +23,9 @@
#include
#include
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
#include "mtk_jpeg_core.h"
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
{
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
similarity index 99%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
index 68abcfd7494d..afbbfd5d02bc 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
@@ -9,7 +9,7 @@
#include
#include
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
#define MTK_JPEG_DUNUM_MASK(val) (((val) - 1) & 0x3)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
index 7b0687f8f4b6..1cc37dbfc8e7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
@@ -11,7 +11,7 @@
#include
#include "mtk_jpeg_core.h"
-#include "mtk_jpeg_reg.h"
+#include "mtk_jpeg_dec_reg.h"
enum {
MTK_JPEG_DEC_RESULT_EOF_DONE= 0,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
index f862d38f3af7..b95c45791c29 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
@@ -8,7 +8,7 @@
#include
#include
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
#define TEM0x01
#define SOF0 0xc0
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
similarity index 92%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
index 0a48eeabaff2..2918f15811f8 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
@@ -8,7 +8,7 @@
#ifndef _MTK_JPEG_PARSE_H
#define _MTK_JPEG_PARSE_H
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
bool mtk_jpeg_parse(struct mtk_jpeg_dec_param *param, u8 *src_addr_va,
u32 src_size);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
similarity index 100%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
--
2.18.0
[PATCH v9 09/18] media: platform: Delete zeroing the reserved fields
Delete zeroing the reserved fields because that the core already
does it.
Signed-off-by: Xia Jiang
---
v9: new patch
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index bb4ebce881ee..bd1cc58324c6 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -198,7 +198,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
struct mtk_jpeg_dev *jpeg = ctx->jpeg;
int i;
- memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
pix_mp->field = V4L2_FIELD_NONE;
if (ctx->state != MTK_JPEG_INIT) {
@@ -217,7 +216,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
&pix_mp->height, MTK_JPEG_MIN_HEIGHT,
MTK_JPEG_MAX_HEIGHT, 0);
- memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
pfmt->bytesperline = 0;
/* Source size must be aligned to 128 */
pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
@@ -237,7 +235,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
u32 stride = pix_mp->width * fmt->h_sample[i] / 4;
u32 h = pix_mp->height * fmt->v_sample[i] / 4;
- memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
pfmt->bytesperline = stride;
pfmt->sizeimage = stride * h;
}
@@ -270,7 +267,6 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file,
void *priv,
q_data = mtk_jpeg_get_q_data(ctx, f->type);
- memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
pix_mp->width = q_data->w;
pix_mp->height = q_data->h;
pix_mp->field = V4L2_FIELD_NONE;
@@ -294,7 +290,6 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file,
void *priv,
pfmt->bytesperline = q_data->bytesperline[i];
pfmt->sizeimage = q_data->sizeimage[i];
- memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
v4l2_dbg(1, debug, &jpeg->v4l2_dev,
"plane[%d] bpl=%u, size=%u\n",
--
2.18.0
Re: [PATCH v2] x86_64: fix jiffies ODR violation
On Tue, Jun 2, 2020 at 9:31 PM 'Bob Haarman' via Clang Built Linux
wrote:
>
> 'jiffies' and 'jiffies_64' are meant to alias (two different symbols
> that share the same address). Most architectures make the symbols alias
> to the same address via linker script assignment in their
> arch//kernel/vmlinux.lds.S:
>
> jiffies = jiffies_64;
>
> which is effectively a definition of jiffies.
>
> jiffies and jiffies_64 are both forward declared for all arch's in:
> include/linux/jiffies.h.
>
> jiffies_64 is defined in kernel/time/timer.c for all arch's.
>
> x86_64 was peculiar in that it wasn't doing the above linker script
> assignment, but rather was:
> 1. defining jiffies in arch/x86/kernel/time.c instead via linker script.
> 2. overriding the symbol jiffies_64 from kernel/time/timer.c in
> arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'.
>
> As Fangrui notes:
>
> In LLD, symbol assignments in linker scripts override definitions in
> object files. GNU ld appears to have the same behavior. It would
> probably make sense for LLD to error "duplicate symbol" but GNU ld
> is unlikely to adopt for compatibility reasons.
>
> So we have an ODR violation (UB), which we seem to have gotten away
> with thus far. Where it becomes harmful is when we:
>
> 1. Use -fno-semantic-interposition.
>
> As Fangrui notes:
>
> Clang after LLVM commit 5b22bcc2b70d
> ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local")
> defaults to -fno-semantic-interposition similar semantics which help
> -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined
> within the same translation unit. Unlike GCC
> -fno-semantic-interposition, Clang emits such relocations referencing
> local symbols for non-pic code as well.
>
> This causes references to jiffies to refer to '.Ljiffies$local' when
> jiffies is defined in the same translation unit. Likewise, references
> to jiffies_64 become references to '.Ljiffies_64$local' in translation
> units that define jiffies_64. Because these differ from the names
> used in the linker script, they will not be rewritten to alias one
> another.
>
> Combined with ...
>
> 2. Full LTO effectively treats all source files as one translation
> unit, causing these local references to be produced everywhere. When
> the linker processes the linker script, there are no longer any
> references to jiffies_64' anywhere to replace with 'jiffies'. And
> thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias
> at all.
>
> In the process of porting patches enabling Full LTO from arm64 to
> x86_64, we observe spooky bugs where the kernel appeared to boot, but
> init doesn't get scheduled.
>
> Instead, we can avoid the ODR violation by matching other arch's by
> defining jiffies only by linker script. For -fno-semantic-interposition
> + Full LTO, there is no longer a global definition of jiffies for the
> compiler to produce a local symbol which the linker script won't ensure
> aliases to jiffies_64.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/852
> Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible")
> Cc: sta...@vger.kernel.org
> Reported-by: Nathan Chancellor
> Reported-by: Alistair Delva
> Suggested-by: Fangrui Song
> Debugged-by: Nick Desaulniers
> Debugged-by: Sami Tolvanen
> Signed-off-by: Bob Haarman
> Reviewed-by: Andi Kleen
> Reviewed-by: Josh Poimboeuf
> ---
> v2:
> * Changed commit message as requested by Josh Poimboeuf
> (no code change)
>
Hi,
I have tested v2 with my local patch-series together.
Feel free to add my...
Tested-by: Sedat Dilek # build+boot on
Debian/testing AMD64 with selfmade llvm-toolchain v10.0.1-rc1+
Thanks.
Regards,
- Sedat -
> ---
> arch/x86/kernel/time.c| 4
> arch/x86/kernel/vmlinux.lds.S | 4 ++--
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
> index 371a6b348e44..e42faa792c07 100644
> --- a/arch/x86/kernel/time.c
> +++ b/arch/x86/kernel/time.c
> @@ -25,10 +25,6 @@
> #include
> #include
>
> -#ifdef CONFIG_X86_64
> -__visible volatile unsigned long jiffies __cacheline_aligned_in_smp =
> INITIAL_JIFFIES;
> -#endif
> -
> unsigned long profile_pc(struct pt_regs *regs)
> {
> unsigned long pc = instruction_pointer(regs);
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index 1bf7e312361f..7c35556c7827 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -40,13 +40,13 @@ OUTPUT_FORMAT(CONFIG_OUTPUT_FORMAT)
> #ifdef CONFIG_X86_32
> OUTPUT_ARCH(i386)
> ENTRY(phys_startup_32)
> -jiffies = jiffies_64;
> #else
> OUTPUT_ARCH(i386:x86-64)
> ENTRY(phys_startup_64)
> -jiffies_64 = jiffies;
> #endif
>
> +jiffies = jiffies_64;
> +
> #if defined(CONFIG_X86_64)
> /*
> * On 64-bit, align RODATA to 2MB so we retain large page mappings for
> --
> 2.27.0.rc2.251.g90737beb825-goog
>
> --
> You received this message because you are subscribed t
[PATCH v9 08/18] media: platform: Cancel the last frame handling flow
There is no need to queue an empty buffer for signaling a last frame,
because all frames are separate from each other in JPEG.
Signed-off-by: Xia Jiang
---
v9: new patch
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 21 +--
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 49bdbf1c435f..bb4ebce881ee 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -55,15 +55,9 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
#define MTK_JPEG_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_formats)
-enum {
- MTK_JPEG_BUF_FLAGS_INIT = 0,
- MTK_JPEG_BUF_FLAGS_LAST_FRAME = 1,
-};
-
struct mtk_jpeg_src_buf {
struct vb2_v4l2_buffer b;
struct list_head list;
- int flags;
struct mtk_jpeg_dec_param dec_param;
};
@@ -520,8 +514,6 @@ static int mtk_jpeg_qbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
vb = vb2_get_buffer(vq, buf->index);
jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(vb);
- jpeg_src_buf->flags = (buf->m.planes[0].bytesused == 0) ?
- MTK_JPEG_BUF_FLAGS_LAST_FRAME : MTK_JPEG_BUF_FLAGS_INIT;
end:
return v4l2_m2m_qbuf(file, fh->m2m_ctx, buf);
}
@@ -676,10 +668,6 @@ static void mtk_jpeg_buf_queue(struct vb2_buffer *vb)
param = &jpeg_src_buf->dec_param;
memset(param, 0, sizeof(*param));
- if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
- v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Got eos\n");
- goto end;
- }
header_valid = mtk_jpeg_parse(param, (u8 *)vb2_plane_vaddr(vb, 0),
vb2_get_plane_payload(vb, 0));
if (!header_valid) {
@@ -792,19 +780,12 @@ static void mtk_jpeg_device_run(void *priv)
struct mtk_jpeg_src_buf *jpeg_src_buf;
struct mtk_jpeg_bs bs;
struct mtk_jpeg_fb fb;
- int i, ret;
+ int ret;
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(&src_buf->vb2_buf);
- if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
- for (i = 0; i < dst_buf->vb2_buf.num_planes; i++)
- vb2_set_plane_payload(&dst_buf->vb2_buf, i, 0);
- buf_state = VB2_BUF_STATE_DONE;
- goto dec_end;
- }
-
if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
mtk_jpeg_queue_src_chg_event(ctx);
ctx->state = MTK_JPEG_SOURCE_CHANGE;
--
2.18.0
[PATCH v9 14/18] media: dt-bindings: Add jpeg enc device tree node document
Add jpeg enc device tree node document.
Reviewed-by: Rob Herring
Signed-off-by: Xia Jiang
---
v9: no changes
---
.../bindings/media/mediatek-jpeg-encoder.txt | 37 +++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
new file mode 100644
index ..fa8da699493b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -0,0 +1,37 @@
+* MediaTek JPEG Encoder
+
+MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
+
+Required properties:
+- compatible : should be one of:
+ "mediatek,mt2701-jpgenc"
+ ...
+ followed by "mediatek,mtk-jpgenc"
+- reg : physical base address of the JPEG encoder registers and length of
+ memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+ Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
+- power-domains: a phandle to the power domain, see
+ Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current SoCs, see
+ Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+ for details.
+- iommus: should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+
+Example:
+ jpegenc: jpegenc@1500a000 {
+ compatible = "mediatek,mt2701-jpgenc",
+"mediatek,mtk-jpgenc";
+ reg = <0 0x1500a000 0 0x1000>;
+ interrupts = ;
+ clocks = <&imgsys CLK_IMG_VENC>;
+ clock-names = "jpgenc";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <&larb2>;
+ iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>,
+<&iommu MT2701_M4U_PORT_JPGENC_BSDMA>;
+ };
--
2.18.0
[PATCH v9 02/18] media: platform: Improve queue set up flow for bug fixing
Add checking created buffer size follow in mtk_jpeg_queue_setup().
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v9: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 4ad4a4b30a0e..67a022d04df7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -571,6 +571,13 @@ static int mtk_jpeg_queue_setup(struct vb2_queue *q,
if (!q_data)
return -EINVAL;
+ if (*num_planes) {
+ for (i = 0; i < *num_planes; i++)
+ if (sizes[i] < q_data->sizeimage[i])
+ return -EINVAL;
+ return 0;
+ }
+
*num_planes = q_data->fmt->colplanes;
for (i = 0; i < q_data->fmt->colplanes; i++) {
sizes[i] = q_data->sizeimage[i];
--
2.18.0
Re: [PATCH 2/3] dt-bindings: display: bridge: Add documentation for LT9611
Hi Vinod,
On Thu, Jun 04, 2020 at 12:48:59PM +0530, Vinod Koul wrote:
> Hi Laurent,
>
> Sorry for late reply, I was out last week.
No worries.
> On 28-05-20, 04:48, Laurent Pinchart wrote:
> > > +
> > > + interrupts:
> > > +maxItems: 1
> > > +description: interrupt line for the chip
> >
> > I think you could drop the descriptions for the reg and interrupt
> > properties, they don't add much.
>
> Sure, will do
>
> > > + reset-gpios:
> > > +maxItems: 1
> > > +description: GPIO connected to active high RESET pin.
> > > +
> > > + vdd-supply:
> > > +description: Regulator for 1.8V MIPI phy power.
> > > +
> > > + vcc-supply:
> > > +description: Regulator for 3.3V IO power.
> > > +
> > > + ports:
> > > +type: object
> > > +
> > > +properties:
> > > + "#address-cells":
> > > +const: 1
> > > +
> > > + "#size-cells":
> > > +const: 0
> > > +
> > > + port@0:
> > > +type: object
> > > +additionalProperties: false
> > > +
> > > +description: |
> > > + HDMI port for HDMI output
> >
> > The usual practice is to have the input ports first, followed by the
> > output ports. Is there a reason not to follow that rule ?
>
> I was not aware of this rule, is it documented somewhere?
> Nevertheless will update..
I don't think it's documented, no. It's just a common practice.
> > > +
> > > +properties:
> > > + reg:
> > > +const: 0
> > > +
> > > +patternProperties:
> > > + endpoint:
> >
> > If you want to use patternProperties, this should be
> >
> > "^endpoint@[0-9]+$":
> >
> > (including the quotes). Same below.
>
> Ok
>
> > > +type: object
> > > +additionalProperties: false
> > > +
> > > +properties:
> > > + remote-endpoint: true
> >
> > How about
> >
> > remote-endpoint:
> > $ref: /schemas/types.yaml#/definitions/phandle
> >
> > and the same below ?
>
> Ok
>
> > You also need a reg property if multiple endpoints are present.
>
> Will update
>
> > > +
> > > +required:
> > > + - reg
> > > +
> > > + port@1:
> > > +type: object
> > > +additionalProperties: false
> > > +
> > > +description: |
> > > + MIPI port-1 for MIPI input
> > > +
> > > +properties:
> > > + reg:
> > > +const: 1
> > > +
> > > +patternProperties:
> > > + endpoint:
> > > +type: object
> > > +additionalProperties: false
> > > +
> > > +properties:
> > > + remote-endpoint: true
> > > +
> > > +required:
> > > + - reg
> > > +
> > > + port@2:
> > > +type: object
> > > +additionalProperties: false
> > > +
> > > +description: |
> > > + MIPI port-2 for MIPI input
> >
> > A description of how the two MIPI inputs differ would be useful. In
> > particular, are both mandatory, or is it valid to connect only one of
> > the two ? If using a single input is supported, can it be either, or
> > does it have to be the first one ? When using both inputs, what should
> > be connected to them ?
>
> Sure I will add details. port-1 is mandatory and port-2 optional. port-2
> is used in combination with port-1 to drive displays for higher
> resolution like 4k
>
> > > +
> > > +properties:
> > > + reg:
> > > +const: 2
> > > +
> > > +patternProperties:
> > > + endpoint:
> > > +type: object
> > > +additionalProperties: false
> > > +
> > > +properties:
> > > + remote-endpoint: true
> > > +
> > > +required:
> > > + - reg
> > > +
> > > +required:
> > > + - "#address-cells"
> > > + - "#size-cells"
> > > + - port@0
> > > + - port@1
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - interrupts
> > > + - vdd-supply
> > > + - vcc-supply
> > > + - ports
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > +#include
> > > +#include
> > > +
> > > +i2c10 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + lt9611_codec: hdmi-bridge@3b {
> >
> > Please drop unused labels.
>
> ok
>
> > > +compatible = "lontium,lt9611";
> > > +reg = <0x3b>;
> > > +
> > > +reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
> > > +interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>;
> > > +
> > > +vdd-supply = <<9611_1v8>;
> > > +vcc-supply = <<9611_3v3>;
> > > +
> > > +ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@0 {
> > > +reg = <0>;
> > > +lt9611_out: endpoint {
> > > + remote-endpoint = <&hdmi_con>;
> > > +};
> > > + };
> > > +
> > > + por
Re: [PATCH] checkpatch: Avoid missing typo suggestions
On Thu, 2020-06-04 at 09:55 +0300, Maxim Uvarov wrote: > On Thu, 4 Jun 2020 at 03:39, Joe Perches wrote: Hi Maxim. > > btw: My codespell dictionary file moved to > > /usr/lib/python3/dist-packages/codespell_lib/data/dictionary.txt > > > > and I had to use --codespell --codespellfile=(above) so > > maybe there should be multiple lookups for this file > > like the array below. > > > > Are there other standard codespell dictionary locations? > > It might be better to support standard and non standard locations. It already does with the --codespellfile= opti. > I think it's better to request from codespell where his dictionary is. Maybe a good idea, but looking at the codespell git, for versions 1.17 on there are several standard dictionaries. https://github.com/codespell-project/codespell/tree/v1.17.1/codespell_lib/data > I created ticket for this: > https://github.com/codespell-project/codespell/issues/1540 Even if codespell is updated, the script would have to deal with older versions that don't support requesting that option. cheers, Joe
[PATCH v9 15/18] arm: dts: mt2701: Add jpeg enc device tree node
Add jpeg enc device tree node.
Signed-off-by: Xia Jiang
---
v9: add "mt2701" in the title description
---
arch/arm/boot/dts/mt2701.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 2c4ec82547ee..235bacc0e418 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -568,6 +568,19 @@
<&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
+ jpegenc: jpegenc@1500a000 {
+ compatible = "mediatek,mt2701-jpgenc",
+"mediatek,mtk-jpgenc";
+ reg = <0 0x1500a000 0 0x1000>;
+ interrupts = ;
+ clocks = <&imgsys CLK_IMG_VENC>;
+ clock-names = "jpgenc";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <&larb2>;
+ iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>,
+<&iommu MT2701_M4U_PORT_JPGENC_BSDMA>;
+ };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
--
2.18.0
[PATCH v9 00/18] Add support for mt2701 JPEG ENC support
This patchset add support for mt2701 JPEG ENC support. This is the compliance test result for jpeg dec and enc. The JPEG dec log: v4l2-compliance -d /dev/video0 v4l2-compliance SHA: 74377da4f5f3b63203c599d5dd75db6af91fdbb9, 32 bits, 32-bit time_t Compliance test for mtk-jpeg device /dev/video0: Driver Info: Driver name : mtk-jpeg Card type: mtk-jpeg decoder Bus info : platform:15004000.jpegdec Driver version : 5.7.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Detected JPEG Decoder Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video0 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK test invalid ioctls: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls:
[PATCH v9 04/18] media: platform: Change the fixed device node number to unfixed value
The driver can be instantiated multiple times, e.g. for a decoder and
an encoder. Moreover, other drivers could coexist on the same system.
This makes the static video node number assignment pointless, so switch
to automatic assignment instead.
Signed-off-by: Xia Jiang
---
v9: change the commit message
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 2677580941b0..12609ca46fd9 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1154,7 +1154,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
jpeg->dec_vdev->device_caps = V4L2_CAP_STREAMING |
V4L2_CAP_VIDEO_M2M_MPLANE;
- ret = video_register_device(jpeg->dec_vdev, VFL_TYPE_VIDEO, 3);
+ ret = video_register_device(jpeg->dec_vdev, VFL_TYPE_VIDEO, -1);
if (ret) {
v4l2_err(&jpeg->v4l2_dev, "Failed to register video device\n");
goto err_dec_vdev_register;
--
2.18.0
[PATCH] iommu: Don't attach deferred device in iommu_group_do_dma_attach
Attaching a deferred device should be delayed until dma api is called.
Cc: io...@lists.linux-foundation.org
Suggested-by: Joerg Roedel
Signed-off-by: Jerry Snitselaar
---
If you already have thrown a patch together, then ignore this. Also
feel free to swap out the signed-off-by with your's since
this is more your patch than mine. You can put a reviewed-by
and tested-by instead for me.
drivers/iommu/iommu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b5ea203f6c68..d43120eb1dc5 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1680,8 +1680,12 @@ static void probe_alloc_default_domain(struct bus_type
*bus,
static int iommu_group_do_dma_attach(struct device *dev, void *data)
{
struct iommu_domain *domain = data;
+ int ret = 0;
- return __iommu_attach_device(domain, dev);
+ if (!iommu_is_attach_deferred(domain, dev))
+ ret = __iommu_attach_device(domain, dev);
+
+ return ret;
}
static int __iommu_group_dma_attach(struct iommu_group *group)
--
2.24.0
[PATCH v3 00/10] net: eth: altera: tse: Add PTP and mSGDMA prefetcher
From: Joyce Ooi This patch series cleans up the Altera TSE driver and adds support for the newer msgdma prefetcher as well as ptp support when using the msgdma prefetcher. v2: Rename altera_ptp to intel_fpga_tod, modify msgdma and sgdma tx_buffer functions to be of type netdev_tx_t, and minor suggested edits v3: Modify tx_buffer to stop queue before returning NETDEV_TX_BUSY Dalon Westergreen (10): net: eth: altera: tse_start_xmit ignores tx_buffer call response net: eth: altera: set rx and tx ring size before init_dma call net: eth: altera: fix altera_dmaops declaration net: eth: altera: add optional function to start tx dma net: eth: altera: Move common functions to altera_utils net: eth: altera: Add missing identifier names to function declarations net: eth: altera: change tx functions to type netdev_tx_t net: eth: altera: add support for ptp and timestamping net: eth: altera: add msgdma prefetcher net: eth: altera: update devicetree bindings documentation .../devicetree/bindings/net/altera_tse.txt | 103 - drivers/net/ethernet/altera/Kconfig| 1 + drivers/net/ethernet/altera/Makefile | 3 +- drivers/net/ethernet/altera/altera_msgdma.c| 5 +- drivers/net/ethernet/altera/altera_msgdma.h| 30 +- .../net/ethernet/altera/altera_msgdma_prefetcher.c | 431 + .../net/ethernet/altera/altera_msgdma_prefetcher.h | 30 ++ .../ethernet/altera/altera_msgdmahw_prefetcher.h | 87 + drivers/net/ethernet/altera/altera_sgdma.c | 22 +- drivers/net/ethernet/altera/altera_sgdma.h | 32 +- drivers/net/ethernet/altera/altera_tse.h | 98 ++--- drivers/net/ethernet/altera/altera_tse_ethtool.c | 29 ++ drivers/net/ethernet/altera/altera_tse_main.c | 218 +-- drivers/net/ethernet/altera/altera_utils.c | 29 ++ drivers/net/ethernet/altera/altera_utils.h | 51 +++ drivers/net/ethernet/altera/intel_fpga_tod.c | 358 + drivers/net/ethernet/altera/intel_fpga_tod.h | 56 +++ 17 files changed, 1429 insertions(+), 154 deletions(-) create mode 100644 drivers/net/ethernet/altera/altera_msgdma_prefetcher.c create mode 100644 drivers/net/ethernet/altera/altera_msgdma_prefetcher.h create mode 100644 drivers/net/ethernet/altera/altera_msgdmahw_prefetcher.h create mode 100644 drivers/net/ethernet/altera/intel_fpga_tod.c create mode 100644 drivers/net/ethernet/altera/intel_fpga_tod.h -- 2.13.0
[PATCH v3 01/10] net: eth: altera: tse_start_xmit ignores tx_buffer call response
From: Dalon Westergreen
The return from tx_buffer call in tse_start_xmit is
inapropriately ignored. tse_buffer calls should return
0 for success or NETDEV_TX_BUSY. tse_start_xmit should
return not report a successful transmit when the tse_buffer
call returns an error condition.
In addition to the above, the msgdma and sgdma do not return
the same value on success or failure. The sgdma_tx_buffer
returned 0 on failure and a positive number of transmitted
packets on success. Given that it only ever sends 1 packet,
this made no sense. The msgdma implementation msgdma_tx_buffer
returns 0 on success.
-> Don't ignore the return from tse_buffer calls
-> Fix sgdma tse_buffer call to return 0 on success
and NETDEV_TX_BUSY on failure.
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: no change
v3: queue is stopped before returning NETDEV_TX_BUSY
---
drivers/net/ethernet/altera/altera_sgdma.c| 19 ---
drivers/net/ethernet/altera/altera_tse_main.c | 4 +++-
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_sgdma.c
b/drivers/net/ethernet/altera/altera_sgdma.c
index db97170da8c7..fe6276c7e4a3 100644
--- a/drivers/net/ethernet/altera/altera_sgdma.c
+++ b/drivers/net/ethernet/altera/altera_sgdma.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "altera_utils.h"
#include "altera_tse.h"
#include "altera_sgdmahw.h"
@@ -159,10 +160,11 @@ void sgdma_clear_txirq(struct altera_tse_private *priv)
SGDMA_CTRLREG_CLRINT);
}
-/* transmits buffer through SGDMA. Returns number of buffers
- * transmitted, 0 if not possible.
- *
- * tx_lock is held by the caller
+/* transmits buffer through SGDMA.
+ * original behavior returned the number of transmitted packets (always 1) &
+ * returned 0 on error. This differs from the msgdma. the calling function
+ * will now actually look at the code, so from now, 0 is good and return
+ * NETDEV_TX_BUSY when busy.
*/
int sgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer *buffer)
{
@@ -173,8 +175,11 @@ int sgdma_tx_buffer(struct altera_tse_private *priv,
struct tse_buffer *buffer)
struct sgdma_descrip __iomem *ndesc = &descbase[1];
/* wait 'til the tx sgdma is ready for the next transmit request */
- if (sgdma_txbusy(priv))
- return 0;
+ if (sgdma_txbusy(priv)) {
+ if (!netif_queue_stopped(priv->dev))
+ netif_stop_queue(priv->dev);
+ return NETDEV_TX_BUSY;
+ }
sgdma_setup_descrip(cdesc, /* current descriptor */
ndesc, /* next descriptor */
@@ -191,7 +196,7 @@ int sgdma_tx_buffer(struct altera_tse_private *priv, struct
tse_buffer *buffer)
/* enqueue the request to the pending transmit queue */
queue_tx(priv, buffer);
- return 1;
+ return 0;
}
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c
b/drivers/net/ethernet/altera/altera_tse_main.c
index 1671c1f36691..2a9e6157a8a1 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -595,7 +595,9 @@ static int tse_start_xmit(struct sk_buff *skb, struct
net_device *dev)
buffer->dma_addr = dma_addr;
buffer->len = nopaged_len;
- priv->dmaops->tx_buffer(priv, buffer);
+ ret = priv->dmaops->tx_buffer(priv, buffer);
+ if (ret)
+ goto out;
skb_tx_timestamp(skb);
--
2.13.0
[PATCH v3 02/10] net: eth: altera: set rx and tx ring size before init_dma call
From: Dalon Westergreen
It is more appropriate to set the rx and tx ring size before calling
the init function for the dma.
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: no change
v3: no change
---
drivers/net/ethernet/altera/altera_tse_main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c
b/drivers/net/ethernet/altera/altera_tse_main.c
index 2a9e6157a8a1..539e744e23f7 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -1154,6 +1154,10 @@ static int tse_open(struct net_device *dev)
int i;
unsigned long int flags;
+ /* set tx and rx ring size */
+ priv->rx_ring_size = dma_rx_num;
+ priv->tx_ring_size = dma_tx_num;
+
/* Reset and configure TSE MAC and probe associated PHY */
ret = priv->dmaops->init_dma(priv);
if (ret != 0) {
@@ -1196,8 +1200,6 @@ static int tse_open(struct net_device *dev)
priv->dmaops->reset_dma(priv);
/* Create and initialize the TX/RX descriptors chains. */
- priv->rx_ring_size = dma_rx_num;
- priv->tx_ring_size = dma_tx_num;
ret = alloc_init_skbufs(priv);
if (ret) {
netdev_err(dev, "DMA descriptors initialization failed\n");
--
2.13.0
[PATCH v3 07/10] net: eth: altera: change tx functions to type netdev_tx_t
From: Dalon Westergreen
Modify all msgdma and sgdma tx_buffer functions to be of type
netdev_tx_t, and also modify main tx function to be of
netdev_tx_t type.
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: this patch is added in patch version 2
v3: no change
---
drivers/net/ethernet/altera/altera_msgdma.c | 5 +++--
drivers/net/ethernet/altera/altera_msgdma.h | 4 ++--
drivers/net/ethernet/altera/altera_sgdma.c| 5 +++--
drivers/net/ethernet/altera/altera_sgdma.h| 4 ++--
drivers/net/ethernet/altera/altera_tse.h | 4 ++--
drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
6 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_msgdma.c
b/drivers/net/ethernet/altera/altera_msgdma.c
index ac1efd08267a..ac68151a7f47 100644
--- a/drivers/net/ethernet/altera/altera_msgdma.c
+++ b/drivers/net/ethernet/altera/altera_msgdma.c
@@ -106,7 +106,8 @@ void msgdma_clear_txirq(struct altera_tse_private *priv)
}
/* return 0 to indicate transmit is pending */
-int msgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer
*buffer)
+netdev_tx_t
+msgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer *buffer)
{
csrwr32(lower_32_bits(buffer->dma_addr), priv->tx_dma_desc,
msgdma_descroffs(read_addr_lo));
@@ -120,7 +121,7 @@ int msgdma_tx_buffer(struct altera_tse_private *priv,
struct tse_buffer *buffer)
msgdma_descroffs(stride));
csrwr32(MSGDMA_DESC_CTL_TX_SINGLE, priv->tx_dma_desc,
msgdma_descroffs(control));
- return 0;
+ return NETDEV_TX_OK;
}
u32 msgdma_tx_completions(struct altera_tse_private *priv)
diff --git a/drivers/net/ethernet/altera/altera_msgdma.h
b/drivers/net/ethernet/altera/altera_msgdma.h
index 23f5b2a13898..d816b24dfa7f 100644
--- a/drivers/net/ethernet/altera/altera_msgdma.h
+++ b/drivers/net/ethernet/altera/altera_msgdma.h
@@ -16,8 +16,8 @@ void msgdma_clear_txirq(struct altera_tse_private *priv);
u32 msgdma_tx_completions(struct altera_tse_private *priv);
void msgdma_add_rx_desc(struct altera_tse_private *priv,
struct tse_buffer *buffer);
-int msgdma_tx_buffer(struct altera_tse_private *priv,
-struct tse_buffer *buffer);
+netdev_tx_t msgdma_tx_buffer(struct altera_tse_private *priv,
+struct tse_buffer *buffer);
u32 msgdma_rx_status(struct altera_tse_private *priv);
int msgdma_initialize(struct altera_tse_private *priv);
void msgdma_uninitialize(struct altera_tse_private *priv);
diff --git a/drivers/net/ethernet/altera/altera_sgdma.c
b/drivers/net/ethernet/altera/altera_sgdma.c
index fe6276c7e4a3..6898ec682425 100644
--- a/drivers/net/ethernet/altera/altera_sgdma.c
+++ b/drivers/net/ethernet/altera/altera_sgdma.c
@@ -166,7 +166,8 @@ void sgdma_clear_txirq(struct altera_tse_private *priv)
* will now actually look at the code, so from now, 0 is good and return
* NETDEV_TX_BUSY when busy.
*/
-int sgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer *buffer)
+netdev_tx_t
+sgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer *buffer)
{
struct sgdma_descrip __iomem *descbase =
(struct sgdma_descrip __iomem *)priv->tx_dma_desc;
@@ -196,7 +197,7 @@ int sgdma_tx_buffer(struct altera_tse_private *priv, struct
tse_buffer *buffer)
/* enqueue the request to the pending transmit queue */
queue_tx(priv, buffer);
- return 0;
+ return NETDEV_TX_OK;
}
diff --git a/drivers/net/ethernet/altera/altera_sgdma.h
b/drivers/net/ethernet/altera/altera_sgdma.h
index 3fb201417820..6a41833f0965 100644
--- a/drivers/net/ethernet/altera/altera_sgdma.h
+++ b/drivers/net/ethernet/altera/altera_sgdma.h
@@ -13,8 +13,8 @@ void sgdma_disable_rxirq(struct altera_tse_private *priv);
void sgdma_disable_txirq(struct altera_tse_private *priv);
void sgdma_clear_rxirq(struct altera_tse_private *priv);
void sgdma_clear_txirq(struct altera_tse_private *priv);
-int sgdma_tx_buffer(struct altera_tse_private *priv,
- struct tse_buffer *buffer);
+netdev_tx_t sgdma_tx_buffer(struct altera_tse_private *priv,
+ struct tse_buffer *buffer);
u32 sgdma_tx_completions(struct altera_tse_private *priv);
void sgdma_add_rx_desc(struct altera_tse_private *priv,
struct tse_buffer *buffer);
diff --git a/drivers/net/ethernet/altera/altera_tse.h
b/drivers/net/ethernet/altera/altera_tse.h
index fa24ab3c7d6a..79d02748c89d 100644
--- a/drivers/net/ethernet/altera/altera_tse.h
+++ b/drivers/net/ethernet/altera/altera_tse.h
@@ -392,8 +392,8 @@ struct altera_dmaops {
void (*disable_rxirq)(struct altera_tse_private *priv);
void (*clear_txirq)(struct altera_tse_private *priv);
void (*clear_rxirq)(struct altera_tse_private *priv);
- int (*tx_buffer)(struct altera_tse_private *priv,
-struc
[PATCH v3 04/10] net: eth: altera: add optional function to start tx dma
From: Dalon Westergreen
Allow for optional start up of tx dma if the start_txdma
function is defined in altera_dmaops.
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: no change
v3: no change
---
drivers/net/ethernet/altera/altera_tse.h | 1 +
drivers/net/ethernet/altera/altera_tse_main.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/altera/altera_tse.h
b/drivers/net/ethernet/altera/altera_tse.h
index 7d0c98fc103e..26c5541fda27 100644
--- a/drivers/net/ethernet/altera/altera_tse.h
+++ b/drivers/net/ethernet/altera/altera_tse.h
@@ -401,6 +401,7 @@ struct altera_dmaops {
int (*init_dma)(struct altera_tse_private *priv);
void (*uninit_dma)(struct altera_tse_private *priv);
void (*start_rxdma)(struct altera_tse_private *priv);
+ void (*start_txdma)(struct altera_tse_private *priv);
};
/* This structure is private to each device.
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c
b/drivers/net/ethernet/altera/altera_tse_main.c
index 539e744e23f7..3c756afd0d39 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -1244,6 +1244,9 @@ static int tse_open(struct net_device *dev)
priv->dmaops->start_rxdma(priv);
+ if (priv->dmaops->start_txdma)
+ priv->dmaops->start_txdma(priv);
+
/* Start MAC Rx/Tx */
spin_lock(&priv->mac_cfg_lock);
tse_set_mac(priv, true);
@@ -1646,6 +1649,7 @@ static const struct altera_dmaops altera_dtype_sgdma = {
.init_dma = sgdma_initialize,
.uninit_dma = sgdma_uninitialize,
.start_rxdma = sgdma_start_rxdma,
+ .start_txdma = NULL,
};
static const struct altera_dmaops altera_dtype_msgdma = {
@@ -1665,6 +1669,7 @@ static const struct altera_dmaops altera_dtype_msgdma = {
.init_dma = msgdma_initialize,
.uninit_dma = msgdma_uninitialize,
.start_rxdma = msgdma_start_rxdma,
+ .start_txdma = NULL,
};
static const struct of_device_id altera_tse_ids[] = {
--
2.13.0
[PATCH v3 05/10] net: eth: altera: Move common functions to altera_utils
From: Dalon Westergreen
Move request_and_map and other shared functions to altera_utils. This
is the first step to moving common code out of tse specific code so
that it can be shared with future altera ethernet ip.
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: no change
v3: no change
---
drivers/net/ethernet/altera/altera_tse.h | 45 -
drivers/net/ethernet/altera/altera_tse_ethtool.c | 1 +
drivers/net/ethernet/altera/altera_tse_main.c| 32 +--
drivers/net/ethernet/altera/altera_utils.c | 29 ++
drivers/net/ethernet/altera/altera_utils.h | 51
5 files changed, 82 insertions(+), 76 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_tse.h
b/drivers/net/ethernet/altera/altera_tse.h
index 26c5541fda27..fa24ab3c7d6a 100644
--- a/drivers/net/ethernet/altera/altera_tse.h
+++ b/drivers/net/ethernet/altera/altera_tse.h
@@ -489,49 +489,4 @@ struct altera_tse_private {
*/
void altera_tse_set_ethtool_ops(struct net_device *);
-static inline
-u32 csrrd32(void __iomem *mac, size_t offs)
-{
- void __iomem *paddr = (void __iomem *)((uintptr_t)mac + offs);
- return readl(paddr);
-}
-
-static inline
-u16 csrrd16(void __iomem *mac, size_t offs)
-{
- void __iomem *paddr = (void __iomem *)((uintptr_t)mac + offs);
- return readw(paddr);
-}
-
-static inline
-u8 csrrd8(void __iomem *mac, size_t offs)
-{
- void __iomem *paddr = (void __iomem *)((uintptr_t)mac + offs);
- return readb(paddr);
-}
-
-static inline
-void csrwr32(u32 val, void __iomem *mac, size_t offs)
-{
- void __iomem *paddr = (void __iomem *)((uintptr_t)mac + offs);
-
- writel(val, paddr);
-}
-
-static inline
-void csrwr16(u16 val, void __iomem *mac, size_t offs)
-{
- void __iomem *paddr = (void __iomem *)((uintptr_t)mac + offs);
-
- writew(val, paddr);
-}
-
-static inline
-void csrwr8(u8 val, void __iomem *mac, size_t offs)
-{
- void __iomem *paddr = (void __iomem *)((uintptr_t)mac + offs);
-
- writeb(val, paddr);
-}
-
#endif /* __ALTERA_TSE_H__ */
diff --git a/drivers/net/ethernet/altera/altera_tse_ethtool.c
b/drivers/net/ethernet/altera/altera_tse_ethtool.c
index 4299f1301149..420d77f00eab 100644
--- a/drivers/net/ethernet/altera/altera_tse_ethtool.c
+++ b/drivers/net/ethernet/altera/altera_tse_ethtool.c
@@ -22,6 +22,7 @@
#include
#include "altera_tse.h"
+#include "altera_utils.h"
#define TSE_STATS_LEN 31
#define TSE_NUM_REGS 128
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c
b/drivers/net/ethernet/altera/altera_tse_main.c
index 3c756afd0d39..87f789e42b6e 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -33,7 +32,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -1320,35 +1319,6 @@ static struct net_device_ops altera_tse_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
-static int request_and_map(struct platform_device *pdev, const char *name,
- struct resource **res, void __iomem **ptr)
-{
- struct resource *region;
- struct device *device = &pdev->dev;
-
- *res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
- if (*res == NULL) {
- dev_err(device, "resource %s not defined\n", name);
- return -ENODEV;
- }
-
- region = devm_request_mem_region(device, (*res)->start,
-resource_size(*res), dev_name(device));
- if (region == NULL) {
- dev_err(device, "unable to request %s\n", name);
- return -EBUSY;
- }
-
- *ptr = devm_ioremap(device, region->start,
- resource_size(region));
- if (*ptr == NULL) {
- dev_err(device, "ioremap of %s failed!", name);
- return -ENOMEM;
- }
-
- return 0;
-}
-
/* Probe Altera TSE MAC device
*/
static int altera_tse_probe(struct platform_device *pdev)
diff --git a/drivers/net/ethernet/altera/altera_utils.c
b/drivers/net/ethernet/altera/altera_utils.c
index e6a7fc9d8fb1..c9bc7d0ea02a 100644
--- a/drivers/net/ethernet/altera/altera_utils.c
+++ b/drivers/net/ethernet/altera/altera_utils.c
@@ -31,3 +31,32 @@ int tse_bit_is_clear(void __iomem *ioaddr, size_t offs, u32
bit_mask)
u32 value = csrrd32(ioaddr, offs);
return (value & bit_mask) ? 0 : 1;
}
+
+int request_and_map(struct platform_device *pdev, const char *name,
+ struct resource **res, void __iomem **ptr)
+{
+ struct resource *region;
+ struct device *device = &pdev->dev;
+
+ *res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
+ if (!*res) {
+ dev_err(device, "resource %s not defined\n",
[PATCH v3 06/10] net: eth: altera: Add missing identifier names to function declarations
From: Dalon Westergreen The sgdma and msgdma header files included function declarations without identifier names for pointers. Add appropriate identifier names. Signed-off-by: Dalon Westergreen Signed-off-by: Joyce Ooi --- v2: this patch is added in patch version 2 v3: no change --- drivers/net/ethernet/altera/altera_msgdma.h | 30 ++- drivers/net/ethernet/altera/altera_sgdma.h | 32 +++-- 2 files changed, 33 insertions(+), 29 deletions(-) diff --git a/drivers/net/ethernet/altera/altera_msgdma.h b/drivers/net/ethernet/altera/altera_msgdma.h index 9813fbfff4d3..23f5b2a13898 100644 --- a/drivers/net/ethernet/altera/altera_msgdma.h +++ b/drivers/net/ethernet/altera/altera_msgdma.h @@ -6,19 +6,21 @@ #ifndef __ALTERA_MSGDMA_H__ #define __ALTERA_MSGDMA_H__ -void msgdma_reset(struct altera_tse_private *); -void msgdma_enable_txirq(struct altera_tse_private *); -void msgdma_enable_rxirq(struct altera_tse_private *); -void msgdma_disable_rxirq(struct altera_tse_private *); -void msgdma_disable_txirq(struct altera_tse_private *); -void msgdma_clear_rxirq(struct altera_tse_private *); -void msgdma_clear_txirq(struct altera_tse_private *); -u32 msgdma_tx_completions(struct altera_tse_private *); -void msgdma_add_rx_desc(struct altera_tse_private *, struct tse_buffer *); -int msgdma_tx_buffer(struct altera_tse_private *, struct tse_buffer *); -u32 msgdma_rx_status(struct altera_tse_private *); -int msgdma_initialize(struct altera_tse_private *); -void msgdma_uninitialize(struct altera_tse_private *); -void msgdma_start_rxdma(struct altera_tse_private *); +void msgdma_reset(struct altera_tse_private *priv); +void msgdma_enable_txirq(struct altera_tse_private *priv); +void msgdma_enable_rxirq(struct altera_tse_private *priv); +void msgdma_disable_rxirq(struct altera_tse_private *priv); +void msgdma_disable_txirq(struct altera_tse_private *priv); +void msgdma_clear_rxirq(struct altera_tse_private *priv); +void msgdma_clear_txirq(struct altera_tse_private *priv); +u32 msgdma_tx_completions(struct altera_tse_private *priv); +void msgdma_add_rx_desc(struct altera_tse_private *priv, + struct tse_buffer *buffer); +int msgdma_tx_buffer(struct altera_tse_private *priv, +struct tse_buffer *buffer); +u32 msgdma_rx_status(struct altera_tse_private *priv); +int msgdma_initialize(struct altera_tse_private *priv); +void msgdma_uninitialize(struct altera_tse_private *priv); +void msgdma_start_rxdma(struct altera_tse_private *priv); #endif /* __ALTERA_MSGDMA_H__ */ diff --git a/drivers/net/ethernet/altera/altera_sgdma.h b/drivers/net/ethernet/altera/altera_sgdma.h index 08afe1c9994f..3fb201417820 100644 --- a/drivers/net/ethernet/altera/altera_sgdma.h +++ b/drivers/net/ethernet/altera/altera_sgdma.h @@ -6,20 +6,22 @@ #ifndef __ALTERA_SGDMA_H__ #define __ALTERA_SGDMA_H__ -void sgdma_reset(struct altera_tse_private *); -void sgdma_enable_txirq(struct altera_tse_private *); -void sgdma_enable_rxirq(struct altera_tse_private *); -void sgdma_disable_rxirq(struct altera_tse_private *); -void sgdma_disable_txirq(struct altera_tse_private *); -void sgdma_clear_rxirq(struct altera_tse_private *); -void sgdma_clear_txirq(struct altera_tse_private *); -int sgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer *); -u32 sgdma_tx_completions(struct altera_tse_private *); -void sgdma_add_rx_desc(struct altera_tse_private *priv, struct tse_buffer *); -void sgdma_status(struct altera_tse_private *); -u32 sgdma_rx_status(struct altera_tse_private *); -int sgdma_initialize(struct altera_tse_private *); -void sgdma_uninitialize(struct altera_tse_private *); -void sgdma_start_rxdma(struct altera_tse_private *); +void sgdma_reset(struct altera_tse_private *priv); +void sgdma_enable_txirq(struct altera_tse_private *priv); +void sgdma_enable_rxirq(struct altera_tse_private *priv); +void sgdma_disable_rxirq(struct altera_tse_private *priv); +void sgdma_disable_txirq(struct altera_tse_private *priv); +void sgdma_clear_rxirq(struct altera_tse_private *priv); +void sgdma_clear_txirq(struct altera_tse_private *priv); +int sgdma_tx_buffer(struct altera_tse_private *priv, + struct tse_buffer *buffer); +u32 sgdma_tx_completions(struct altera_tse_private *priv); +void sgdma_add_rx_desc(struct altera_tse_private *priv, + struct tse_buffer *buffer); +void sgdma_status(struct altera_tse_private *priv); +u32 sgdma_rx_status(struct altera_tse_private *priv); +int sgdma_initialize(struct altera_tse_private *priv); +void sgdma_uninitialize(struct altera_tse_private *priv); +void sgdma_start_rxdma(struct altera_tse_private *priv); #endif /* __ALTERA_SGDMA_H__ */ -- 2.13.0
[PATCH v3 03/10] net: eth: altera: fix altera_dmaops declaration
From: Dalon Westergreen
The declaration of struct altera_dmaops does not have
identifier names. Add identifier names to confrom with
required coding styles.
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: no change
v3: no change
---
drivers/net/ethernet/altera/altera_tse.h | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_tse.h
b/drivers/net/ethernet/altera/altera_tse.h
index f17acfb579a0..7d0c98fc103e 100644
--- a/drivers/net/ethernet/altera/altera_tse.h
+++ b/drivers/net/ethernet/altera/altera_tse.h
@@ -385,20 +385,22 @@ struct altera_tse_private;
struct altera_dmaops {
int altera_dtype;
int dmamask;
- void (*reset_dma)(struct altera_tse_private *);
- void (*enable_txirq)(struct altera_tse_private *);
- void (*enable_rxirq)(struct altera_tse_private *);
- void (*disable_txirq)(struct altera_tse_private *);
- void (*disable_rxirq)(struct altera_tse_private *);
- void (*clear_txirq)(struct altera_tse_private *);
- void (*clear_rxirq)(struct altera_tse_private *);
- int (*tx_buffer)(struct altera_tse_private *, struct tse_buffer *);
- u32 (*tx_completions)(struct altera_tse_private *);
- void (*add_rx_desc)(struct altera_tse_private *, struct tse_buffer *);
- u32 (*get_rx_status)(struct altera_tse_private *);
- int (*init_dma)(struct altera_tse_private *);
- void (*uninit_dma)(struct altera_tse_private *);
- void (*start_rxdma)(struct altera_tse_private *);
+ void (*reset_dma)(struct altera_tse_private *priv);
+ void (*enable_txirq)(struct altera_tse_private *priv);
+ void (*enable_rxirq)(struct altera_tse_private *priv);
+ void (*disable_txirq)(struct altera_tse_private *priv);
+ void (*disable_rxirq)(struct altera_tse_private *priv);
+ void (*clear_txirq)(struct altera_tse_private *priv);
+ void (*clear_rxirq)(struct altera_tse_private *priv);
+ int (*tx_buffer)(struct altera_tse_private *priv,
+struct tse_buffer *buffer);
+ u32 (*tx_completions)(struct altera_tse_private *priv);
+ void (*add_rx_desc)(struct altera_tse_private *priv,
+ struct tse_buffer *buffer);
+ u32 (*get_rx_status)(struct altera_tse_private *priv);
+ int (*init_dma)(struct altera_tse_private *priv);
+ void (*uninit_dma)(struct altera_tse_private *priv);
+ void (*start_rxdma)(struct altera_tse_private *priv);
};
/* This structure is private to each device.
--
2.13.0
[PATCH v3 08/10] net: eth: altera: add support for ptp and timestamping
From: Dalon Westergreen
Add support for the ptp clock used with the tse, and update
the driver to support timestamping when enabled. We also
enable debugfs entries for the ptp clock to allow some user
control and interaction with the ptp clock.
Cc: Richard Cochran
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: this patch is added in patch version 2
v3: no change
---
drivers/net/ethernet/altera/Kconfig | 1 +
drivers/net/ethernet/altera/Makefile | 3 +-
drivers/net/ethernet/altera/altera_tse.h | 8 +
drivers/net/ethernet/altera/altera_tse_ethtool.c | 28 ++
drivers/net/ethernet/altera/altera_tse_main.c| 118 +++-
drivers/net/ethernet/altera/intel_fpga_tod.c | 358 +++
drivers/net/ethernet/altera/intel_fpga_tod.h | 56
7 files changed, 570 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/altera/intel_fpga_tod.c
create mode 100644 drivers/net/ethernet/altera/intel_fpga_tod.h
diff --git a/drivers/net/ethernet/altera/Kconfig
b/drivers/net/ethernet/altera/Kconfig
index 2690c398d2b2..6dec7094cb4b 100644
--- a/drivers/net/ethernet/altera/Kconfig
+++ b/drivers/net/ethernet/altera/Kconfig
@@ -3,6 +3,7 @@ config ALTERA_TSE
tristate "Altera Triple-Speed Ethernet MAC support"
depends on HAS_DMA
select PHYLIB
+ imply PTP_1588_CLOCK
---help---
This driver supports the Altera Triple-Speed (TSE) Ethernet MAC.
diff --git a/drivers/net/ethernet/altera/Makefile
b/drivers/net/ethernet/altera/Makefile
index a52db80aee9f..fc2e460926b3 100644
--- a/drivers/net/ethernet/altera/Makefile
+++ b/drivers/net/ethernet/altera/Makefile
@@ -5,4 +5,5 @@
obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
altera_tse-objs := altera_tse_main.o altera_tse_ethtool.o \
-altera_msgdma.o altera_sgdma.o altera_utils.o
+ altera_msgdma.o altera_sgdma.o altera_utils.o \
+ intel_fpga_tod.o
diff --git a/drivers/net/ethernet/altera/altera_tse.h
b/drivers/net/ethernet/altera/altera_tse.h
index 79d02748c89d..b7c176a808ac 100644
--- a/drivers/net/ethernet/altera/altera_tse.h
+++ b/drivers/net/ethernet/altera/altera_tse.h
@@ -28,6 +28,8 @@
#include
#include
+#include "intel_fpga_tod.h"
+
#define ALTERA_TSE_SW_RESET_WATCHDOG_CNTR 1
#define ALTERA_TSE_MAC_FIFO_WIDTH 4 /* TX/RX FIFO width in
* bytes
@@ -417,6 +419,12 @@ struct altera_tse_private {
/* TSE Revision */
u32 revision;
+ /* Shared PTP structure */
+ struct intel_fpga_tod_private ptp_priv;
+ int hwts_tx_en;
+ int hwts_rx_en;
+ u32 ptp_enable;
+
/* mSGDMA Rx Dispatcher address space */
void __iomem *rx_dma_csr;
void __iomem *rx_dma_desc;
diff --git a/drivers/net/ethernet/altera/altera_tse_ethtool.c
b/drivers/net/ethernet/altera/altera_tse_ethtool.c
index 420d77f00eab..cec41a2c7b00 100644
--- a/drivers/net/ethernet/altera/altera_tse_ethtool.c
+++ b/drivers/net/ethernet/altera/altera_tse_ethtool.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include "altera_tse.h"
@@ -222,6 +223,32 @@ static void tse_get_regs(struct net_device *dev, struct
ethtool_regs *regs,
buf[i] = csrrd32(priv->mac_dev, i * 4);
}
+static int tse_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info)
+{
+ struct altera_tse_private *priv = netdev_priv(dev);
+
+ if (priv->ptp_enable) {
+ if (priv->ptp_priv.ptp_clock)
+ info->phc_index =
+ ptp_clock_index(priv->ptp_priv.ptp_clock);
+
+ info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+
+ info->tx_types = (1 << HWTSTAMP_TX_OFF) |
+(1 << HWTSTAMP_TX_ON);
+
+ info->rx_filters = (1 << HWTSTAMP_FILTER_NONE) |
+ (1 << HWTSTAMP_FILTER_ALL);
+
+ return 0;
+ } else {
+ return ethtool_op_get_ts_info(dev, info);
+ }
+}
+
static const struct ethtool_ops tse_ethtool_ops = {
.get_drvinfo = tse_get_drvinfo,
.get_regs_len = tse_reglen,
@@ -234,6 +261,7 @@ static const struct ethtool_ops tse_ethtool_ops = {
.set_msglevel = tse_set_msglevel,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .get_ts_info = tse_get_ts_info,
};
void altera_tse_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c
b/drivers/net/ethernet/altera/altera_tse_main.c
index 24a1d30c6780..c874b8c1dd48 100644
--- a/dr
[PATCH v3 10/10] net: eth: altera: update devicetree bindings documentation
From: Dalon Westergreen Update devicetree bindings documentation to include msgdma prefetcher and ptp bindings. Cc: Rob Herring Cc: devicet...@vger.kernel.org Signed-off-by: Dalon Westergreen Signed-off-by: Joyce Ooi --- v2: no change v3: no change --- .../devicetree/bindings/net/altera_tse.txt | 103 + 1 file changed, 84 insertions(+), 19 deletions(-) diff --git a/Documentation/devicetree/bindings/net/altera_tse.txt b/Documentation/devicetree/bindings/net/altera_tse.txt index 0b7d4d3758ea..2f2d12603907 100644 --- a/Documentation/devicetree/bindings/net/altera_tse.txt +++ b/Documentation/devicetree/bindings/net/altera_tse.txt @@ -2,53 +2,86 @@ Required properties: - compatible: Should be "altr,tse-1.0" for legacy SGDMA based TSE, and should - be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE. + be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE, + and "altr,tse-msgdma-2.0" for MSGDMA with prefetcher based + implementations. ALTR is supported for legacy device trees, but is deprecated. altr should be used for all new designs. - reg: Address and length of the register set for the device. It contains the information of registers in the same order as described by reg-names - reg-names: Should contain the reg names - "control_port": MAC configuration space region - "tx_csr": xDMA Tx dispatcher control and status space region - "tx_desc": MSGDMA Tx dispatcher descriptor space region - "rx_csr" : xDMA Rx dispatcher control and status space region - "rx_desc": MSGDMA Rx dispatcher descriptor space region - "rx_resp": MSGDMA Rx dispatcher response space region - "s1": SGDMA descriptor memory - interrupts: Should contain the TSE interrupts and it's mode. - interrupt-names: Should contain the interrupt names - "rx_irq": xDMA Rx dispatcher interrupt - "tx_irq": xDMA Tx dispatcher interrupt + "rx_irq": DMA Rx dispatcher interrupt + "tx_irq": DMA Tx dispatcher interrupt - rx-fifo-depth: MAC receive FIFO buffer depth in bytes - tx-fifo-depth: MAC transmit FIFO buffer depth in bytes - phy-mode: See ethernet.txt in the same directory. - phy-handle: See ethernet.txt in the same directory. - phy-addr: See ethernet.txt in the same directory. A configuration should include phy-handle or phy-addr. -- altr,has-supplementary-unicast: - If present, TSE supports additional unicast addresses. - Otherwise additional unicast addresses are not supported. -- altr,has-hash-multicast-filter: - If present, TSE supports a hash based multicast filter. - Otherwise, hash-based multicast filtering is not supported. - - mdio device tree subnode: When the TSE has a phy connected to its local mdio, there must be device tree subnode with the following required properties: - - compatible: Must be "altr,tse-mdio". - #address-cells: Must be <1>. - #size-cells: Must be <0>. For each phy on the mdio bus, there must be a node with the following fields: - - reg: phy id used to communicate to phy. - device_type: Must be "ethernet-phy". The MAC address will be determined using the optional properties defined in ethernet.txt. +- altr,has-supplementary-unicast: + If present, TSE supports additional unicast addresses. + Otherwise additional unicast addresses are not supported. +- altr,has-hash-multicast-filter: + If present, TSE supports a hash based multicast filter. + Otherwise, hash-based multicast filtering is not supported. +- altr,has-ptp: + If present, TSE supports 1588 timestamping. Currently only + supported with the msgdma prefetcher. +- altr,tx-poll-cnt: + Optional cycle count for Tx prefetcher to poll descriptor + list. If not present, defaults to 128, which at 125MHz is + roughly 1usec. Only for "altr,tse-msgdma-2.0". +- altr,rx-poll-cnt: + Optional cycle count for Tx prefetcher to poll descriptor + list. If not present, defaults to 128, which at 125MHz is + roughly 1usec. Only for "altr,tse-msgdma-2.0". + +Required registers by compatibility string: + - "altr,tse-1.0" + "control_port": MAC configuration space region + "tx_csr": DMA Tx dispatcher control and status space region + "rx_csr" : DMA Rx dispatcher control and status space region + "s1": DMA descriptor memory + + - "altr,tse-msgdma-1.0" + "control_port": MAC configuration space region + "tx_csr": DMA Tx dispatcher control and status space region + "tx_desc": DMA Tx dispatcher descriptor space region + "rx_csr" : DMA Rx dispatcher control
[PATCH v3 09/10] net: eth: altera: add msgdma prefetcher
From: Dalon Westergreen
Add support for the mSGDMA prefetcher. The prefetcher adds support
for a linked list of descriptors in system memory. The prefetcher
feeds these to the mSGDMA dispatcher.
The prefetcher is configured to poll for the next descriptor in the
list to be owned by hardware, then pass the descriptor to the
dispatcher. It will then poll the next descriptor until it is
owned by hardware.
The dispatcher responses are written back to the appropriate
descriptor, and the owned by hardware bit is cleared.
The driver sets up a linked list twice the tx and rx ring sizes,
with the last descriptor pointing back to the first. This ensures
that the ring of descriptors will always have inactive descriptors
preventing the prefetcher from looping over and reusing descriptors
inappropriately. The prefetcher will continuously loop over these
descriptors. The driver modifies descriptors as required to update
the skb address and length as well as the owned by hardware bit.
In addition to the above, the mSGDMA prefetcher can be used to
handle rx and tx timestamps coming from the ethernet ip. These
can be included in the prefetcher response in the descriptor.
Signed-off-by: Dalon Westergreen
Signed-off-by: Joyce Ooi
---
v2: minor fixes and suggested edits
v3: queue is stopped before returning NETDEV_TX_BUSY
---
drivers/net/ethernet/altera/Makefile | 2 +-
.../net/ethernet/altera/altera_msgdma_prefetcher.c | 431 +
.../net/ethernet/altera/altera_msgdma_prefetcher.h | 30 ++
.../ethernet/altera/altera_msgdmahw_prefetcher.h | 87 +
drivers/net/ethernet/altera/altera_tse.h | 14 +
drivers/net/ethernet/altera/altera_tse_main.c | 51 +++
6 files changed, 614 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/altera/altera_msgdma_prefetcher.c
create mode 100644 drivers/net/ethernet/altera/altera_msgdma_prefetcher.h
create mode 100644 drivers/net/ethernet/altera/altera_msgdmahw_prefetcher.h
diff --git a/drivers/net/ethernet/altera/Makefile
b/drivers/net/ethernet/altera/Makefile
index fc2e460926b3..4834e972e906 100644
--- a/drivers/net/ethernet/altera/Makefile
+++ b/drivers/net/ethernet/altera/Makefile
@@ -6,4 +6,4 @@
obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
altera_tse-objs := altera_tse_main.o altera_tse_ethtool.o \
altera_msgdma.o altera_sgdma.o altera_utils.o \
- intel_fpga_tod.o
+ intel_fpga_tod.o altera_msgdma_prefetcher.o
diff --git a/drivers/net/ethernet/altera/altera_msgdma_prefetcher.c
b/drivers/net/ethernet/altera/altera_msgdma_prefetcher.c
new file mode 100644
index ..e8cd4d04730d
--- /dev/null
+++ b/drivers/net/ethernet/altera/altera_msgdma_prefetcher.c
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0
+/* MSGDMA Prefetcher driver for Altera ethernet devices
+ *
+ * Copyright (C) 2020 Intel Corporation. All rights reserved.
+ * Author(s):
+ * Dalon Westergreen
+ */
+
+#include
+#include
+#include
+#include "altera_tse.h"
+#include "altera_msgdma.h"
+#include "altera_msgdmahw.h"
+#include "altera_msgdma_prefetcher.h"
+#include "altera_msgdmahw_prefetcher.h"
+#include "altera_utils.h"
+
+int msgdma_pref_initialize(struct altera_tse_private *priv)
+{
+ int i;
+ struct msgdma_pref_extended_desc *rx_descs;
+ struct msgdma_pref_extended_desc *tx_descs;
+ dma_addr_t rx_descsphys;
+ dma_addr_t tx_descsphys;
+
+ priv->pref_rxdescphys = (dma_addr_t)0;
+ priv->pref_txdescphys = (dma_addr_t)0;
+
+ /* we need to allocate more pref descriptors than ringsize to
+* prevent all of the descriptors being owned by hw. To do this
+* we just allocate twice ring_size descriptors.
+* rx_ring_size = priv->rx_ring_size * 2
+* tx_ring_size = priv->tx_ring_size * 2
+*/
+
+ /* The prefetcher requires the descriptors to be aligned to the
+* descriptor read/write master's data width which worst case is
+* 512 bits. Currently we DO NOT CHECK THIS and only support 32-bit
+* prefetcher masters.
+*/
+
+ /* allocate memory for rx descriptors */
+ priv->pref_rxdesc =
+ dma_alloc_coherent(priv->device,
+ sizeof(struct msgdma_pref_extended_desc)
+ * priv->rx_ring_size * 2,
+ &priv->pref_rxdescphys, GFP_KERNEL);
+
+ if (!priv->pref_rxdesc)
+ goto err_rx;
+
+ /* allocate memory for tx descriptors */
+ priv->pref_txdesc =
+ dma_alloc_coherent(priv->device,
+ sizeof(struct msgdma_pref_extended_desc)
+ * priv->tx_ring_size * 2,
+ &priv->pref_txdescphys, GFP_KERNEL);
+
+ if (!priv->pref_txdesc)
+ goto err_tx;
+
+ /* setup base descriptor ring for tx & rx */
+
Re: 回复: Re: [RFC PATCH 0/8] dax: Add a dax-rmap tree to support reflink
On 2020/4/28 下午2:43, Dave Chinner wrote: On Tue, Apr 28, 2020 at 06:09:47AM +, Ruan, Shiyang wrote: 在 2020/4/27 20:28:36, "Matthew Wilcox" 写道: On Mon, Apr 27, 2020 at 04:47:42PM +0800, Shiyang Ruan wrote: This patchset is a try to resolve the shared 'page cache' problem for fsdax. In order to track multiple mappings and indexes on one page, I introduced a dax-rmap rb-tree to manage the relationship. A dax entry will be associated more than once if is shared. At the second time we associate this entry, we create this rb-tree and store its root in page->private(not used in fsdax). Insert (->mapping, ->index) when dax_associate_entry() and delete it when dax_disassociate_entry(). Do we really want to track all of this on a per-page basis? I would have thought a per-extent basis was more useful. Essentially, create a new address_space for each shared extent. Per page just seems like a huge overhead. Per-extent tracking is a nice idea for me. I haven't thought of it yet... But the extent info is maintained by filesystem. I think we need a way to obtain this info from FS when associating a page. May be a bit complicated. Let me think about it... That's why I want the -user of this association- to do a filesystem callout instead of keeping it's own naive tracking infrastructure. The filesystem can do an efficient, on-demand reverse mapping lookup from it's own extent tracking infrastructure, and there's zero runtime overhead when there are no errors present. Hi Dave, I ran into some difficulties when trying to implement the per-extent rmap tracking. So, I re-read your comments and found that I was misunderstanding what you described here. I think what you mean is: we don't need the in-memory dax-rmap tracking now. Just ask the FS for the owner's information that associate with one page when memory-failure. So, the per-page (even per-extent) dax-rmap is needless in this case. Is this right? Based on this, we only need to store the extent information of a fsdax page in its ->mapping (by searching from FS). Then obtain the owners of this page (also by searching from FS) when memory-failure or other rmap case occurs. So, a fsdax page is no longer associated with a specific file, but with a FS(or the pmem device). I think it's easier to understand and implement. -- Thanks, Ruan Shiyang. At the moment, this "dax association" is used to "report" a storage media error directly to userspace. I say "report" because what it does is kill userspace processes dead. The storage media error actually needs to be reported to the owner of the storage media, which in the case of FS-DAX is the filesytem. That way the filesystem can then look up all the owners of that bad media range (i.e. the filesystem block it corresponds to) and take appropriate action. e.g. - if it falls in filesytem metadata, shutdown the filesystem - if it falls in user data, call the "kill userspace dead" routines for each mapping/index tuple the filesystem finds for the given LBA address that the media error occurred. Right now if the media error is in filesystem metadata, the filesystem isn't even told about it. The filesystem can't even shut down - the error is just dropped on the floor and it won't be until the filesystem next tries to reference that metadata that we notice there is an issue. Cheers, Dave.
Re: [PATCH 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Hi Vinod,
On Thu, Jun 04, 2020 at 12:55:48PM +0530, Vinod Koul wrote:
> On 28-05-20, 04:52, Laurent Pinchart wrote:
>
> > > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > > + enum drm_bridge_attach_flags flags)
> > > +{
> > > + struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
> > > + int ret;
> > > +
> > > + dev_dbg(lt9611->dev, "bridge attach\n");
> >
> >
> > Connector creation in bridge drivers is deprecated. Please at least add
>
> Okay what is the right way for connector creation? I can add support for
> that.
Historically bridge drivers have created connectors. With support for
bridge chaining, this approach was considered not to scale. For
instance, I have a board where the SoC has an internal LVDS encoder, and
the board itself has an LVDS-to-DPI decoder followed by a DPI-to-HDMI
encoder. All three components are supported by bridge drivers, and only
the last one should create a connector. Furthermore, different
operations of the connector may be implemented by different bridges, for
instance with one bridge connected to the DDC lines to read EDID, and
another bridge connected to the HPD line to detect hotplug.
To support these systems, we have deprecated connector creation in
bridges, in favour of implementing new bridge callback functions for
connector-related operations (see .get_modes(), .get_edid() and
.detect() in struct drm_bridge_funcs). With this new model, each bridge
implements the operations it supports, and the display controller driver
binds the bridges together to create a connector that delegates the
connector operations to the appropriate bridge. A helper function,
drm_bridge_connector_init(), can be used to automate that.
To transition to this model, we require all new bridge to at least
optionally support disabling connector creation (as requested by the
DRM_BRIDGE_ATTACH_NO_CONNECTOR), and implement the drm_bridge_funcs
functions related to connector operations. Existing bridges are also
converted to the new model. Once all bridges used by a display
controller support the new model, the display controller is then
converted to use DRM_BRIDGE_ATTACH_NO_CONNECTOR and
drm_bridge_connector_init() (or implement the latter manually if the
helper doesn't support all the display controller's needs). Once all
display controllers using a bridge have been converted to the new model,
support for creating a connector (the !DRM_BRIDGE_ATTACH_NO_CONNECTOR
case) is removed from the bridge driver. Finally, once everybody will
use the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, we will simply drop it.
> > support for the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, to make connector
> > creation optional. Ideally the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case
>
> will add that
>
> > should not be implemented at all. This will require the display
> > controller driver to use DRM_BRIDGE_ATTACH_NO_CONNECTOR. Which display
> > controller(s) do you use this driver with ?
>
> I am using with msm display driver, this was tested on dragon-board
> db845c board.
--
Regards,
Laurent Pinchart
Re: [PATCH] mailbox: mailbox-test: Fix a potential Oops on allocation failure
On Wed, 03 Jun 2020, Dan Carpenter wrote:
> The callers are expecting NULL on error so if we return an error pointer
> it eventually results in an Oops.
>
> Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox
> Controllers")
> Signed-off-by: Dan Carpenter
> ---
> drivers/mailbox/mailbox-test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Lee Jones
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Thank you for your understanding, I wait for your response
With due respect, I am Mrs. George Olivia; I have decided to donate what I have to you / Motherless babies/Less privileged/Widows' because I am dying and diagnosed for cancer for about 2 years ago. I have been touched by God Almighty to donate from what I have inherited from my late husband to you for good work of God Almighty. I have asked Almighty God to forgive me and believe he has, because he is a Merciful God I will be going in for an operation surgery soon. I decided to will/donate the sum of ($ 8.1 million DOLLARS) to you for the good work of God Almighty, and also to help the motherless and less privilege and also forth assistance of the widows. At the moment I cannot take any telephone calls right now due to the fact that my relatives (that have squandered the funds gave them for this purpose before) are around me and my health status also. I have adjusted my will and my lawyer is aware. I wish you all the best and May the good Lord bless you abundantly, and please use the funds judiciously and always extend the good work to others. As soon as you get back to me, I shall give you info on what I need from you, then you will contact the bank and tell them I have willed those properties to you by quoting my personal file routing and account information. And I have also notified the bank that I am willing that properties to you for a good, effective and prudent work. I know I don't know you but I have been directed to do this by God Almighty. I Have all my Hospital document which i can send to you as prove to what am tell you and my seriousness to this. If you are interested in carrying out this task, get back to me for more details on this noble project of mine. Yours Faithfully, Mrs. George Olivia
[PATCH] mm: Fix pud_alloc_track()
From: Joerg Roedel
The pud_alloc_track() needs to do different checks based on whether
__ARCH_HAS_5LEVEL_HACK is defined, like it already does in
pud_alloc(). Otherwise it causes boot failures on PowerPC.
Provide the correct implementations for both possible settings of
__ARCH_HAS_5LEVEL_HACK to fix the boot problems.
Reported-by: Abdul Haleem
Tested-by: Abdul Haleem
Tested-by: Satheesh Rajendran
Fixes: d8626138009b ("mm: add functions to track page directory modifications")
Signed-off-by: Joerg Roedel
---
include/asm-generic/5level-fixup.h | 5 +
include/linux/mm.h | 26 +-
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/include/asm-generic/5level-fixup.h
b/include/asm-generic/5level-fixup.h
index 58046ddc08d0..afbab31fbd7e 100644
--- a/include/asm-generic/5level-fixup.h
+++ b/include/asm-generic/5level-fixup.h
@@ -17,6 +17,11 @@
((unlikely(pgd_none(*(p4d))) && __pud_alloc(mm, p4d, address)) ? \
NULL : pud_offset(p4d, address))
+#define pud_alloc_track(mm, p4d, address, mask)
\
+ ((unlikely(pgd_none(*(p4d))) &&
\
+ (__pud_alloc(mm, p4d, address) ||
({*(mask)|=PGTBL_P4D_MODIFIED;0;})))? \
+ NULL : pud_offset(p4d, address))
+
#define p4d_alloc(mm, pgd, address)(pgd)
#define p4d_alloc_track(mm, pgd, address, mask)(pgd)
#define p4d_offset(pgd, start) (pgd)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 66e0977f970a..ad3b31c5bcc3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2088,35 +2088,35 @@ static inline pud_t *pud_alloc(struct mm_struct *mm,
p4d_t *p4d,
NULL : pud_offset(p4d, address);
}
-static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
+static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
unsigned long address,
pgtbl_mod_mask *mod_mask)
-
{
- if (unlikely(pgd_none(*pgd))) {
- if (__p4d_alloc(mm, pgd, address))
+ if (unlikely(p4d_none(*p4d))) {
+ if (__pud_alloc(mm, p4d, address))
return NULL;
- *mod_mask |= PGTBL_PGD_MODIFIED;
+ *mod_mask |= PGTBL_P4D_MODIFIED;
}
- return p4d_offset(pgd, address);
+ return pud_offset(p4d, address);
}
-#endif /* !__ARCH_HAS_5LEVEL_HACK */
-
-static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
+static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
unsigned long address,
pgtbl_mod_mask *mod_mask)
+
{
- if (unlikely(p4d_none(*p4d))) {
- if (__pud_alloc(mm, p4d, address))
+ if (unlikely(pgd_none(*pgd))) {
+ if (__p4d_alloc(mm, pgd, address))
return NULL;
- *mod_mask |= PGTBL_P4D_MODIFIED;
+ *mod_mask |= PGTBL_PGD_MODIFIED;
}
- return pud_offset(p4d, address);
+ return p4d_offset(pgd, address);
}
+#endif /* !__ARCH_HAS_5LEVEL_HACK */
+
static inline pmd_t *pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long
address)
{
return (unlikely(pud_none(*pud)) && __pmd_alloc(mm, pud, address))?
--
2.26.2
Re: linux-next: fix ups for clashes between akpm and powerpc trees
Hi all,
On Thu, 4 Jun 2020 16:52:46 +1000 Stephen Rothwell
wrote:
>
> diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h
> b/arch/powerpc/include/asm/nohash/32/pgtable.h
> index c188a6f64bcd..1927e1b653f2 100644
> --- a/arch/powerpc/include/asm/nohash/32/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
> @@ -205,10 +205,6 @@ static inline void pmd_clear(pmd_t *pmdp)
> *pmdp = __pmd(0);
> }
>
> -
> -/* to find an entry in a kernel page-table-directory */
> -#define pgd_offset_k(address) pgd_offset(&init_mm, address)
> -
> /* to find an entry in a page-table-directory */
> #define pgd_index(address)((address) >> PGDIR_SHIFT)
> #define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
> @@ -241,7 +237,7 @@ static inline pte_basic_t pte_update(struct mm_struct
> *mm, unsigned long addr, p
> pte_basic_t old = pte_val(*p);
> pte_basic_t new = (old & ~(pte_basic_t)clr) | set;
> int num, i;
> - pmd_t *pmd = pmd_offset(pud_offset(pgd_offset(mm, addr), addr), addr);
> + pmd_t *pmd = pmd_offset(pud_offset(p4d_offset(pgd_offset(mm, addr),
> addr), addr), addr);
>
> if (!huge)
> num = PAGE_SIZE / SZ_4K;
> @@ -341,6 +337,10 @@ static inline int pte_young(pte_t pte)
> pfn_to_page((__pa(pmd_val(pmd)) >> PAGE_SHIFT))
> #endif
>
> +#define pte_offset_kernel(dir, addr) \
> + (pmd_bad(*(dir)) ? NULL : (pte_t *)pmd_page_vaddr(*(dir)) + \
> + pte_index(addr))
> +
> /*
> * Encode and decode a swap entry.
> * Note that the bits we use in a PTE for representing a swap entry
Sorry, that ended up:
diff --cc arch/powerpc/include/asm/nohash/32/pgtable.h
index 639f3b3713ec,eb8538c85077..1927e1b653f2
--- a/arch/powerpc/include/asm/nohash/32/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
@@@ -204,13 -205,6 +205,9 @@@ static inline void pmd_clear(pmd_t *pmd
*pmdp = __pmd(0);
}
-
- /* to find an entry in a kernel page-table-directory */
- #define pgd_offset_k(address) pgd_offset(&init_mm, address)
-
+/* to find an entry in a page-table-directory */
+#define pgd_index(address) ((address) >> PGDIR_SHIFT)
+#define pgd_offset(mm, address)((mm)->pgd + pgd_index(address))
/*
* PTE updates. This function is called whenever an existing
@@@ -240,7 -234,7 +237,7 @@@ static inline pte_basic_t pte_update(st
pte_basic_t old = pte_val(*p);
pte_basic_t new = (old & ~(pte_basic_t)clr) | set;
int num, i;
-- pmd_t *pmd = pmd_offset(pud_offset(pgd_offset(mm, addr), addr), addr);
++ pmd_t *pmd = pmd_offset(pud_offset(p4d_offset(pgd_offset(mm, addr),
addr), addr), addr);
if (!huge)
num = PAGE_SIZE / SZ_4K;
@@@ -342,15 -334,6 +337,10 @@@ static inline int pte_young(pte_t pte
pfn_to_page((__pa(pmd_val(pmd)) >> PAGE_SHIFT))
#endif
- /* Find an entry in the third-level page table.. */
- #define pte_index(address)\
- (((address) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
+#define pte_offset_kernel(dir, addr) \
+ (pmd_bad(*(dir)) ? NULL : (pte_t *)pmd_page_vaddr(*(dir)) + \
+pte_index(addr))
- #define pte_offset_map(dir, addr) pte_offset_kernel((dir), (addr))
- static inline void pte_unmap(pte_t *pte) { }
+
/*
* Encode and decode a swap entry.
* Note that the bits we use in a PTE for representing a swap entry
--
Cheers,
Stephen Rothwell
pgppWwhtI2sOU.pgp
Description: OpenPGP digital signature
Re: [PATCH v11 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Mon, Jun 01, 2020 at 12:14:09PM +0800, Hsin-Yi Wang wrote:
> On Fri, May 15, 2020 at 2:53 PM Xin Ji wrote:
>
> > +
> > +static int anx7625_bridge_attach(struct drm_bridge *bridge)
>
> Latest drm_bridge api:
>
> int (*attach)(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags);
>
> https://elixir.bootlin.com/linux/v5.7-rc7/source/include/drm/drm_bridge.h#L70
>
> > +{
> > + struct anx7625_data *ctx = bridge_to_anx7625(bridge);
> > + int err;
Hi Hsin-Yi, thanks for the comment, I'll fix it in the version v12
Thanks,
Xin
[PATCH v12 0/2] Add initial support for slimport anx7625
Hi all, The following series add support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the v12 version, any mistakes, please let me know, I will fix it in the next series. Change history: v12: Fix comments from Hsin-Yi Wang - Rebase the code on kernel 5.7, fix DRM interface not match issue. v11: Fix comments from Rob Herring - Update commit message. - Remove unused label. v10: Fix comments from Rob Herring, Daniel. - Fix dt_binding_check warning. - Update description. v9: Fix comments from Sam, Nicolas, Daniel - Remove extcon interface. - Remove DPI support. - Fix dt_binding_check complains. - Code clean up and update description. v8: Fix comments from Nicolas. - Fix several coding format. - Update description. v7: - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP .../bindings/display/bridge/analogix,anx7625.yaml | 95 + drivers/gpu/drm/bridge/analogix/Kconfig|9 + drivers/gpu/drm/bridge/analogix/Makefile |1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 1961 drivers/gpu/drm/bridge/analogix/anx7625.h | 397 5 files changed, 2463 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4
[PATCH v12 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
anx7625: MIPI to DP transmitter DT schema
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/analogix,anx7625.yaml | 95 ++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 000..60585a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: used for interrupt pin B8.
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description:
+ Video port for MIPI DSI input.
+
+ port@1:
+type: object
+description:
+ Video port for panel or connector.
+
+required:
+- port@0
+- port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi2dp_bridge_in: port@0 {
+reg = <0>;
+anx7625_in: endpoint {
+remote-endpoint = <&mipi_dsi>;
+};
+};
+
+mipi2dp_bridge_out: port@1 {
+reg = <1>;
+anx7625_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+};
+};
--
2.7.4
Re: [PATCH v6 5/5] drivers/tty/serial: add LiteUART driver
On Thu, Jun 04, 2020 at 09:16:25AM +0200, Mateusz Holenko wrote: > On Wed, May 27, 2020 at 6:27 PM Mateusz Holenko wrote: > > > > From: Filip Kokosinski > > > > This commit adds driver for the FPGA-based LiteUART serial controller > > from LiteX SoC builder. > > > > The current implementation supports LiteUART configured > > for 32 bit data width and 8 bit CSR bus width. > > > > It does not support IRQ. > > > > Signed-off-by: Filip Kokosinski > > Signed-off-by: Mateusz Holenko > > --- > > > > Notes: > > Changes in v6: > > - LiteUART ports now stored in xArray > > - removed PORT_LITEUART > > - fixed formatting > > - removed some unnecessary defines > > > > No changes in v5. > > > > Changes in v4: > > - fixed copyright header > > - removed a wrong dependency on UARTLITE from Kconfig > > - added a dependency on LITEX_SOC_CONTROLLER to LITEUART in Kconfig > > > > Changes in v3: > > - aliases made optional > > - used litex_get_reg/litex_set_reg functions instead of macros > > - SERIAL_LITEUART_NR_PORTS renamed to SERIAL_LITEUART_MAX_PORTS > > - PORT_LITEUART changed from 122 to 123 > > - added dependency on LITEX_SOC_CONTROLLER > > - patch number changed from 4 to 5 > > > > No changes in v2. > > > > MAINTAINERS | 1 + > > drivers/tty/serial/Kconfig| 31 +++ > > drivers/tty/serial/Makefile | 1 + > > drivers/tty/serial/liteuart.c | 404 ++ > > 4 files changed, 437 insertions(+) > > create mode 100644 drivers/tty/serial/liteuart.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 51d2d6a61fb0..d855fe807833 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9846,6 +9846,7 @@ M:Mateusz Holenko > > S: Maintained > > F: Documentation/devicetree/bindings/*/litex,*.yaml > > F: drivers/soc/litex/litex_soc_ctrl.c > > +F: drivers/tty/serial/liteuart.c > > F: include/linux/litex.h > > > > LIVE PATCHING > > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > > index adf9e80e7dc9..17aaf0afb27a 100644 > > --- a/drivers/tty/serial/Kconfig > > +++ b/drivers/tty/serial/Kconfig > > @@ -1562,6 +1562,37 @@ config SERIAL_MILBEAUT_USIO_CONSOLE > > receives all kernel messages and warnings and which allows logins > > in > > single user mode). > > > > +config SERIAL_LITEUART > > + tristate "LiteUART serial port support" > > + depends on HAS_IOMEM > > + depends on OF || COMPILE_TEST > > + depends on LITEX_SOC_CONTROLLER > > + select SERIAL_CORE > > + help > > + This driver is for the FPGA-based LiteUART serial controller from > > LiteX > > + SoC builder. > > + > > + Say 'Y' here if you wish to use the LiteUART serial controller. > > + Otherwise, say 'N'. > > + > > +config SERIAL_LITEUART_MAX_PORTS > > + int "Maximum number of LiteUART ports" > > + depends on SERIAL_LITEUART > > + default "1" > > + help > > + Set this to the maximum number of serial ports you want the driver > > + to support. > > + > > +config SERIAL_LITEUART_CONSOLE > > + bool "LiteUART serial port console support" > > + depends on SERIAL_LITEUART=y > > + select SERIAL_CORE_CONSOLE > > + help > > + Say 'Y' here if you wish to use the FPGA-based LiteUART serial > > controller > > + from LiteX SoC builder as the system console (the system console > > is the > > + device which receives all kernel messages and warnings and which > > allows > > + logins in single user mode). Otherwise, say 'N'. > > + > > endmenu > > > > config SERIAL_MCTRL_GPIO > > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile > > index d056ee6cca33..9f8ba419ff3b 100644 > > --- a/drivers/tty/serial/Makefile > > +++ b/drivers/tty/serial/Makefile > > @@ -89,6 +89,7 @@ obj-$(CONFIG_SERIAL_OWL) += owl-uart.o > > obj-$(CONFIG_SERIAL_RDA) += rda-uart.o > > obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o > > obj-$(CONFIG_SERIAL_SIFIVE)+= sifive.o > > +obj-$(CONFIG_SERIAL_LITEUART) += liteuart.o > > > > # GPIOLIB helpers for modem control lines > > obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o > > diff --git a/drivers/tty/serial/liteuart.c b/drivers/tty/serial/liteuart.c > > new file mode 100644 > > index ..22b7612c13ca > > --- /dev/null > > +++ b/drivers/tty/serial/liteuart.c > > @@ -0,0 +1,404 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * LiteUART serial controller (LiteX) Driver > > + * > > + * Copyright (C) 2019-2020 Antmicro > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > kbuild test robot reported problems with this patch, namely: implicit > declaration of function 'kzalloc' > This is caused b
Re: [PATCH 01/10] x86/mm/numa: Remove uninitialized_var() usage
Kees Cook writes:
> -#ifdef NODE_NOT_IN_PAGE_FLAGS
> - pfn_align = node_map_pfn_alignment();
> - if (pfn_align && pfn_align < PAGES_PER_SECTION) {
> - printk(KERN_WARNING "Node alignment %LuMB < min %LuMB,
> rejecting NUMA config\n",
> -PFN_PHYS(pfn_align) >> 20,
> -PFN_PHYS(PAGES_PER_SECTION) >> 20);
> - return -EINVAL;
> + if (IS_ENABLED(NODE_NOT_IN_PAGE_FLAGS)) {
Hrm, clever ...
> + unsigned long pfn_align = node_map_pfn_alignment();
> +
> + if (pfn_align && pfn_align < PAGES_PER_SECTION) {
> + pr_warn("Node alignment %LuMB < min %LuMB, rejecting
> NUMA config\n",
> + PFN_PHYS(pfn_align) >> 20,
> + PFN_PHYS(PAGES_PER_SECTION) >> 20);
> + return -EINVAL;
> + }
> }
> -#endif
> if (!numa_meminfo_cover_memory(mi))
> return -EINVAL;
>
> diff --git a/include/linux/page-flags-layout.h
> b/include/linux/page-flags-layout.h
> index 71283739ffd2..1a4cdec2bd29 100644
> --- a/include/linux/page-flags-layout.h
> +++ b/include/linux/page-flags-layout.h
> @@ -100,7 +100,7 @@
> * there. This includes the case where there is no node, so it is implicit.
> */
> #if !(NODES_WIDTH > 0 || NODES_SHIFT == 0)
> -#define NODE_NOT_IN_PAGE_FLAGS
> +#define NODE_NOT_IN_PAGE_FLAGS 1
but if we ever lose the 1 then the above will silently compile the code
within the IS_ENABLED() section out.
Thanks,
tglx
[PATCH v12 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/Kconfig |9 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 1961 +
drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
4 files changed, 2368 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e1fa7d8..024ea2a 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_ANX7625
+ tristate "Analogix Anx7625 MIPI to DP interface support"
+ depends on DRM
+ depends on OF
+ help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter
+ designed for portable devices. It converts MIPI/DPI to
+ DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index 97669b3..44da392 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..f1cc6bb
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,1961 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "anx7625.h"
+
+/*
+ * There is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+ u8 offset;
+ struct device *dev = &client->dev;
+ int ret;
+
+ if (client == ctx->last_client)
+ return 0;
+
+ ctx->last_client = client;
+
+ if (client == ctx->i2c.tcpc_client)
+ offset = RSVD_00_ADDR;
+ else if (client == ctx->i2c.tx_p0_client)
+ offset = RSVD_D1_ADDR;
+ else if (client == ctx->i2c.tx_p1_client)
+ offset = RSVD_60_ADDR;
+ else if (client == ctx->i2c.rx_p0_client)
+ offset = RSVD_39_ADDR;
+ else if (client == ctx->i2c.rx_p1_client)
+ offset = RSVD_7F_ADDR;
+ else
+ offset = RSVD_00_ADDR;
+
+ ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev,
+ "fail to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+ return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+ struct i2c_client *client, u8 reg_addr)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_byte_data(client, reg_addr);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_i2c_block_data(client, reg_addr, len, buf);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c block fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_write(struct anx7625_data *ctx,
+struct i2c_client *client,
+u8 reg_addr, u8 reg_val)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret
Re: [RFC PATCH] panic: fix deadlock in panic()
On (20/06/03 14:19), Cheng Jian wrote: > A deadlock caused by logbuf_lock occurs when panic: > > a) Panic CPU is running in non-NMI context > b) Panic CPU sends out shutdown IPI via NMI vector > c) One of the CPUs that we bring down via NMI vector holded logbuf_lock > d) Panic CPU try to hold logbuf_lock, then deadlock occurs. > > we try to re-init the logbuf_lock in printk_safe_flush_on_panic() > to avoid deadlock, but it does not work here, because : > > Firstly, it is inappropriate to check num_online_cpus() here. > When the CPU bring down via NMI vector, the panic CPU willn't > wait too long for other cores to stop, so when this problem > occurs, num_online_cpus() may be greater than 1. > > Secondly, printk_safe_flush_on_panic() is called after panic > notifier callback, so if printk() is called in panic notifier > callback, deadlock will still occurs. Eg, if ftrace_dump_on_oops > is set, we print some debug information, it will try to hold the > logbuf_lock. > > To avoid this deadlock, drop the num_online_cpus() check and call > the printk_safe_flush_on_panic() before panic_notifier_list callback, > attempt to re-init logbuf_lock from panic CPU. We hopefully will get rid of some of these locks (around 5.9 kernel maybe), so the deadlocks (at least in the printk-code) should become less common. -ss
[PATCH] iommu/mediatek: Use totalram_pages to setup enable_4GB
To build this driver as a kernel module, we cannot use the unexported symbol "max_pfn" to setup enable_4GB. Use totalram_pages() instead to setup enable_4GB. Suggested-by: Mike Rapoport Signed-off-by: Miles Chen Cc: David Hildenbrand Cc: Yong Wu Cc: Chao Hao --- drivers/iommu/mtk_iommu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index 5f4d6df59cf6..c2798a6e0e38 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -3,7 +3,6 @@ * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong Wu */ -#include #include #include #include @@ -626,8 +625,8 @@ static int mtk_iommu_probe(struct platform_device *pdev) return -ENOMEM; data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN); - /* Whether the current dram is over 4GB */ - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT)); + /* Whether the current dram is over 4GB, note: DRAM start at 1GB */ + data->enable_4GB = !!(totalram_pages() > ((SZ_2G + SZ_1G) >> PAGE_SHIFT)); if (!data->plat_data->has_4gb_mode) data->enable_4GB = false; -- 2.18.0
Re: [PATCH 2/9] rcu: Fixup noinstr warnings
On Wed, Jun 03, 2020 at 08:34:09PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 03, 2020 at 07:13:20PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 03, 2020 at 09:46:00AM -0700, Paul E. McKenney wrote:
> > > > @@ -313,7 +313,7 @@ static __always_inline bool rcu_dynticks
> > > > {
> > > > struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
> > > >
> > > > - return !(atomic_read(&rdp->dynticks) & RCU_DYNTICK_CTRL_CTR);
> > > > + return !(arch_atomic_read(&rdp->dynticks) &
> > > > RCU_DYNTICK_CTRL_CTR);
> >
> > The above is actually instrumented by KCSAN, due to arch_atomic_read()
> > being a READ_ONCE() and it now understanding volatile.
> >
> > > Also instrument_atomic_write(&rdp->dynticks, sizeof(rdp->dynticks)) as
>
> Right, this should instead be instrument_read(...).
>
> Though if KCSAN is unconditionally instrumenting volatile, how does
> this help? Or does KCSAN's instrumentation of volatile somehow avoid
> causing trouble?
As Marco already explained, when used inside noinstr no instrumentation
will be emitted, when used outside noinstr it will emit the right
instrumentation.
> > > o In theory in rcu_irq_exit_preempt(), but as this generates code
> > > only in lockdep builds, it might not be worth worrying about.
> > >
> > > o Ditto for rcu_irq_exit_check_preempt().
> > >
> > > o Ditto for __rcu_irq_enter_check_tick().
> >
> > Not these, afaict they're all the above arch_atomic_read(), which is
> > instrumented due to volatile in these cases.
I this case, the above call-sites are all not noinstr (double negative!)
and will thus cause instrumentation to be emitted.
This is all a 'special' case for arch_atomic_read() (and _set()),
because they're basically READ_ONCE() (and WRITE_ONCE() resp.). The
normal atomics are asm() and it doesn't do anything for those (although
I suppose clang could, since it has this internal assembler to parse the
inline asm, but afaiu that's not something GCC ever wants to do).
Re: [PATCH v6 10/12] mmap locking API: rename mmap_sem to mmap_lock
i build linux next kernel have the kernel/sys.c error. 2020-06-04 13:57 GMT+08:00, Michel Lespinasse : > On Wed, Jun 3, 2020 at 9:35 PM youling 257 wrote: >> I have build error about kernel/sys.c, >> >> kernel/sys.c: In function ‘prctl_set_vma’: >> kernel/sys.c:2392:18: error: >> ‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean >> ‘mmap_base’? >> 2392 | down_write(&mm->mmap_sem); >>| ^~~~ >>| mmap_base >> kernel/sys.c:2402:16: error: >> ‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean >> ‘mmap_base’? >> 2402 | up_write(&mm->mmap_sem); >>|^~~~ >>|mmap_base >> >> why not rename kernel/sys.c mmap_sem to mmap_lock? > > The proper fix would be to use the mmap locking apis defined in > include/linux/mmap_lock.h instead. > > However I would like more information about your report. Did you apply > the series yourself ? If so, what base tree did you apply it onto ? If > not, what tree did you use that already included the series ? > > Thanks, > > -- > Michel "Walken" Lespinasse > A program is never fully debugged until the last user dies. >
Re: [PATCH v12 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
Hello Xin,
Thank you for the patch.
On Thu, Jun 04, 2020 at 03:58:05PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig |9 +
> drivers/gpu/drm/bridge/analogix/Makefile |1 +
> drivers/gpu/drm/bridge/analogix/anx7625.c | 1961
> +
> drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
> 4 files changed, 2368 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e1fa7d8..024ea2a 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
> config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> +
> +config DRM_ANALOGIX_ANX7625
> + tristate "Analogix Anx7625 MIPI to DP interface support"
> + depends on DRM
> + depends on OF
> + help
> + ANX7625 is an ultra-low power 4K mobile HD transmitter
> + designed for portable devices. It converts MIPI/DPI to
> + DisplayPort1.3 4K.
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 97669b3..44da392 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> new file mode 100644
> index 000..f1cc6bb
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -0,0 +1,1961 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "anx7625.h"
> +
> +/*
> + * There is a sync issue while access I2C register between AP(CPU) and
> + * internal firmware(OCM), to avoid the race condition, AP should access
> + * the reserved slave address before slave address occurs changes.
> + */
> +static int i2c_access_workaround(struct anx7625_data *ctx,
> + struct i2c_client *client)
> +{
> + u8 offset;
> + struct device *dev = &client->dev;
> + int ret;
> +
> + if (client == ctx->last_client)
> + return 0;
> +
> + ctx->last_client = client;
> +
> + if (client == ctx->i2c.tcpc_client)
> + offset = RSVD_00_ADDR;
> + else if (client == ctx->i2c.tx_p0_client)
> + offset = RSVD_D1_ADDR;
> + else if (client == ctx->i2c.tx_p1_client)
> + offset = RSVD_60_ADDR;
> + else if (client == ctx->i2c.rx_p0_client)
> + offset = RSVD_39_ADDR;
> + else if (client == ctx->i2c.rx_p1_client)
> + offset = RSVD_7F_ADDR;
> + else
> + offset = RSVD_00_ADDR;
> +
> + ret = i2c_smbus_write_byte_data(client, offset, 0x00);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev,
> + "fail to access i2c id=%x\n:%x",
> + client->addr, offset);
> +
> + return ret;
> +}
> +
> +static int anx7625_reg_read(struct anx7625_data *ctx,
> + struct i2c_client *client, u8 reg_addr)
> +{
> + int ret;
> + struct device *dev = &client->dev;
> +
> + i2c_access_workaround(ctx, client);
> +
> + ret = i2c_smbus_read_byte_data(client, reg_addr);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
> + client->addr, reg_addr);
> +
> + return ret;
> +}
> +
> +static int anx7625_reg_block_read(struct anx7625_data *ctx,
> + struct i2c_client *client,
> + u8 reg_addr, u8 len, u8 *buf)
> +{
> + int ret;
> + struct device *dev = &client->dev;
> +
> + i2c_access_workaround(ctx, client);
> +
> + ret = i2c_smbus_read_i2c_block_data(client, reg_addr, len, buf);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "read i2c block fail id=%x:%x\n",
> + client->addr, reg_addr);
> +
> + retu
Re: [git pull] drm for 5.8-rc1
Am 03.06.20 um 22:13 schrieb Jason Gunthorpe:
On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote:
Hi Linus,
This is the main drm pull request for 5.8-rc1.
Highlights:
Core DRM had a lot of refactoring around managed drm resources to make
drivers simpler.
Intel Tigerlake support is on by default
amdgpu now support p2p PCI buffer sharing and encrypted GPU memory
Christoph Hellwig basically NAK'd this approach, why is it getting
merged all of a sudden??
Dave and Daniel explicitly said they want to have this and it is ok as
long as I open code it in the driver and keep it AMD internal.
We have that in discussion for years now and constructing/using the sg
table is actually only the very minor piece of it. On the other hand
there is a lot of work underway to get rid of abusing the sg tables as well.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fintel-gfx%2F20200311152838.GA24280%40infradead.org%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C55b238b9104d4a8d4feb08d807faa11c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637268120315706063&sdata=AgVJ45%2Ft%2FVYkyIGIGgMrop69XLQReLDpF0ahL5rjEjo%3D&reserved=0
Are we now OK with this same approach open coded in a driver?
Intel is apparently doing this as well for years, see the i915 driver
internals.
This wasn't Cc'd to the usual people doing work in this PCI P2P area??
I certainly prefer a common framework for this, but when my upstream
maintainer says he wants to take this who am I to object?
Christian.
See
commit f44ffd677fb3562ac0a1ff9c8ae52672be741f00
Author: Christian König
Date: Fri Mar 23 16:56:37 2018 +0100
drm/amdgpu: add support for exporting VRAM using DMA-buf v3
We should be able to do this now after checking all the prerequisites.
v2: fix entrie count in the sgt
v3: manually construct the sg
Signed-off-by: Christian König
Acked-by: Daniel Vetter
Acked-by: Sumit Semwal
Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F359295&data=02%7C01%7Cchristian.koenig%40amd.com%7C55b238b9104d4a8d4feb08d807faa11c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637268120315706063&sdata=YzNvxBVOf5hcUm5KjOzzV%2FcHG5jdGEYmrI76PQN9v3U%3D&reserved=0
[..]
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 82a3299e53c042..128a667ed8fa0d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -22,6 +22,7 @@
* Authors: Christian König
*/
+#include
#include "amdgpu.h"
#include "amdgpu_vm.h"
#include "amdgpu_atomfirmware.h"
@@ -458,6 +459,104 @@ static void amdgpu_vram_mgr_del(struct
ttm_mem_type_manager *man,
mem->mm_node = NULL;
}
+/**
+ * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
+ *
+ * @adev: amdgpu device pointer
+ * @mem: TTM memory object
+ * @dev: the other device
+ * @dir: dma direction
+ * @sgt: resulting sg table
+ *
+ * Allocate and fill a sg table from a VRAM allocation.
+ */
+int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
+ struct ttm_mem_reg *mem,
+ struct device *dev,
+ enum dma_data_direction dir,
+ struct sg_table **sgt)
+{
+ struct drm_mm_node *node;
+ struct scatterlist *sg;
+ int num_entries = 0;
+ unsigned int pages;
+ int i, r;
+
+ *sgt = kmalloc(sizeof(*sg), GFP_KERNEL);
+ if (!*sgt)
+ return -ENOMEM;
+
+ for (pages = mem->num_pages, node = mem->mm_node;
+pages; pages -= node->size, ++node)
+ ++num_entries;
+
+ r = sg_alloc_table(*sgt, num_entries, GFP_KERNEL);
+ if (r)
+ goto error_free;
+
+ for_each_sg((*sgt)->sgl, sg, num_entries, i)
+ sg->length = 0;
+
+ node = mem->mm_node;
+ for_each_sg((*sgt)->sgl, sg, num_entries, i) {
+ phys_addr_t phys = (node->start << PAGE_SHIFT) +
+ adev->gmc.aper_base;
+ size_t size = node->size << PAGE_SHIFT;
+ dma_addr_t addr;
+
+ ++node;
+ addr = dma_map_resource(dev, phys, size, dir,
+ DMA_ATTR_SKIP_CPU_SYNC);
+ r = dma_mapping_error(dev, addr);
+ if (r)
+ goto error_unmap;
+
+ sg_set_page(sg, NULL, size, 0);
+ sg_dma_address(sg) = addr;
+ sg_dma_len(sg) = size;
^^
Jason
[PATCH 15/18] drm/amdgpu: use dma-fence annotations for gpu reset code
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a027a8f7b281..ac0286a5f2fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4215,6 +4215,9 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
(amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) ?
true : false;
bool audio_suspended = false;
+ bool fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
/*
* Flush RAM to disk so that after reboot
@@ -4243,6 +4246,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another
already in progress",
job ? job->base.id : -1, hive->hive_id);
mutex_unlock(&hive->hive_lock);
+ dma_fence_end_signalling(fence_cookie);
return 0;
}
@@ -4253,8 +4257,10 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
*/
INIT_LIST_HEAD(&device_list);
if (adev->gmc.xgmi.num_physical_nodes > 1) {
- if (!hive)
+ if (!hive) {
+ dma_fence_end_signalling(fence_cookie);
return -ENODEV;
+ }
if (!list_is_first(&adev->gmc.xgmi.head, &hive->device_list))
list_rotate_to_front(&adev->gmc.xgmi.head,
&hive->device_list);
device_list_handle = &hive->device_list;
@@ -4269,6 +4275,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, as another
already in progress",
job ? job->base.id : -1);
mutex_unlock(&hive->hive_lock);
+ dma_fence_end_signalling(fence_cookie);
return 0;
}
@@ -4409,6 +4416,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
if (r)
dev_info(adev->dev, "GPU reset end with ret = %d\n", r);
+ dma_fence_end_signalling(fence_cookie);
return r;
}
--
2.26.2
[PATCH 06/18] drm/vblank: Annotate with dma-fence signalling section
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vblank.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 85e5f2db1608..93a5bba5f665 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -24,6 +24,7 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
@@ -1908,7 +1909,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
{
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
unsigned long irqflags;
- bool disable_irq;
+ bool disable_irq, fence_cookie;
if (drm_WARN_ON_ONCE(dev, !drm_dev_has_vblank(dev)))
return false;
@@ -1916,6 +1917,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return false;
+ fence_cookie = dma_fence_begin_signalling();
+
spin_lock_irqsave(&dev->event_lock, irqflags);
/* Need timestamp lock to prevent concurrent execution with
@@ -1928,6 +1931,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (!vblank->enabled) {
spin_unlock(&dev->vblank_time_lock);
spin_unlock_irqrestore(&dev->event_lock, irqflags);
+ dma_fence_end_signalling(fence_cookie);
return false;
}
@@ -1953,6 +1957,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (disable_irq)
vblank_disable_fn(&vblank->disable_timer);
+ dma_fence_end_signalling(fence_cookie);
+
return true;
}
EXPORT_SYMBOL(drm_handle_vblank);
--
2.26.2
[PATCH 01/18] mm: Track mmu notifiers in fs_reclaim_acquire/release
fs_reclaim_acquire/release nicely catch recursion issues when
allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
to use to keep the excessive caches in check). For mmu notifier
recursions we do have lockdep annotations since 23b68395c7c7
("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
But these only fire if a path actually results in some pte
invalidation - for most small allocations that's very rarely the case.
The other trouble is that pte invalidation can happen any time when
__GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
recursion.
I was pondering whether we should just do the general annotation, but
there's always the risk for false positives. Plus I'm assuming that
the core fs and io code is a lot better reviewed and tested than
random mmu notifier code in drivers. Hence why I decide to only
annotate for that specific case.
Furthermore even if we'd create a lockdep map for direct reclaim, we'd
still need to explicit pull in the mmu notifier map - there's a lot
more places that do pte invalidation than just direct reclaim, these
two contexts arent the same.
Note that the mmu notifiers needing their own independent lockdep map
is also the reason we can't hold them from fs_reclaim_acquire to
fs_reclaim_release - it would nest with the acquistion in the pte
invalidation code, causing a lockdep splat. And we can't remove the
annotations from pte invalidation and all the other places since
they're called from many other places than page reclaim. Hence we can
only do the equivalent of might_lock, but on the raw lockdep map.
With this we can also remove the lockdep priming added in 66204f1d2d1b
("mm/mmu_notifiers: prime lockdep") since the new annotations are
strictly more powerful.
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
This is part of a gpu lockdep annotation series simply because it
really helps to catch issues where gpu subsystem locks and primitives
can deadlock with themselves through allocations and mmu notifiers.
But aside from that motivation it should be completely free-standing,
and can land through -mm/-rdma/-hmm or any other tree really whenever.
-Daniel
---
mm/mmu_notifier.c | 7 ---
mm/page_alloc.c | 23 ++-
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 06852b896fa6..5d578b9122f8 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -612,13 +612,6 @@ int __mmu_notifier_register(struct mmu_notifier
*subscription,
lockdep_assert_held_write(&mm->mmap_sem);
BUG_ON(atomic_read(&mm->mm_users) <= 0);
- if (IS_ENABLED(CONFIG_LOCKDEP)) {
- fs_reclaim_acquire(GFP_KERNEL);
- lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
- lock_map_release(&__mmu_notifier_invalidate_range_start_map);
- fs_reclaim_release(GFP_KERNEL);
- }
-
if (!mm->notifier_subscriptions) {
/*
* kmalloc cannot be called under mm_take_all_locks(), but we
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 13cc653122b7..f8a222db4a53 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -4124,7 +4125,7 @@ should_compact_retry(struct alloc_context *ac, unsigned
int order, int alloc_fla
static struct lockdep_map __fs_reclaim_map =
STATIC_LOCKDEP_MAP_INIT("fs_reclaim", &__fs_reclaim_map);
-static bool __need_fs_reclaim(gfp_t gfp_mask)
+static bool __need_reclaim(gfp_t gfp_mask)
{
gfp_mask = current_gfp_context(gfp_mask);
@@ -4136,10 +4137,6 @@ static bool __need_fs_reclaim(gfp_t gfp_mask)
if (current->flags & PF_MEMALLOC)
return false;
- /* We're only interested __GFP_FS allocations for now */
- if (!(gfp_mask & __GFP_FS))
- return false;
-
if (gfp_mask & __GFP_NOLOCKDEP)
return false;
@@ -4158,15 +4155,23 @@ void __fs_reclaim_release(void)
void fs_reclaim_acquire(gfp_t gfp_mask)
{
- if (__need_fs_reclaim(gfp_mask))
- __fs_reclaim_acquire();
+ if (__need_reclaim(gfp_mask)) {
+ if (!(gfp_mask & __GFP_FS))
+ __fs_reclaim_acquire();
+
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
+
+ }
}
EXPORT_SYMBOL_GPL(fs_reclaim_acquire);
void fs_reclaim_release(gfp_t gfp_mask)
{
- if (__need_fs_reclaim(gfp_mask))
- __fs_reclaim_release();
+ if (__need_reclaim(gfp_mask)) {
+ if (!(gfp_mask & __GFP_FS))
+ __fs_reclaim_relea
[PATCH 16/18] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset"
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be held when we allocate memory, which
might never happen because the dma_fence_wait() is stuck waiting on
our gpu reset:
[ 136.763714] ==
[ 136.763714] WARNING: possible circular locking dependency detected
[ 136.763715] 5.7.0-rc3+ #346 Tainted: GW
[ 136.763716] --
[ 136.763716] kworker/2:3/682 is trying to acquire lock:
[ 136.763716] 8226f140 (console_lock){+.+.}-{0:0}, at:
drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763723]
but task is already holding lock:
[ 136.763724] 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 136.763726]
which lock already depends on the new lock.
[ 136.763726]
the existing dependency chain (in reverse order) is:
[ 136.763727]
-> #2 (dma_fence_map){}-{0:0}:
[ 136.763730]__dma_fence_might_wait+0x41/0xb0
[ 136.763732]dma_resv_lockdep+0x171/0x202
[ 136.763734]do_one_initcall+0x5d/0x2f0
[ 136.763736]kernel_init_freeable+0x20d/0x26d
[ 136.763738]kernel_init+0xa/0xfb
[ 136.763740]ret_from_fork+0x27/0x50
[ 136.763740]
-> #1 (fs_reclaim){+.+.}-{0:0}:
[ 136.763743]fs_reclaim_acquire.part.0+0x25/0x30
[ 136.763745]kmem_cache_alloc_trace+0x2e/0x6e0
[ 136.763747]device_create_groups_vargs+0x52/0xf0
[ 136.763747]device_create+0x49/0x60
[ 136.763749]fb_console_init+0x25/0x145
[ 136.763750]fbmem_init+0xcc/0xe2
[ 136.763750]do_one_initcall+0x5d/0x2f0
[ 136.763751]kernel_init_freeable+0x20d/0x26d
[ 136.763752]kernel_init+0xa/0xfb
[ 136.763753]ret_from_fork+0x27/0x50
[ 136.763753]
-> #0 (console_lock){+.+.}-{0:0}:
[ 136.763755]__lock_acquire+0x1241/0x23f0
[ 136.763756]lock_acquire+0xad/0x370
[ 136.763757]console_lock+0x47/0x70
[ 136.763761]drm_fb_helper_set_suspend_unlocked+0x7b/0xa0
[drm_kms_helper]
[ 136.763809]amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[ 136.763850]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 136.763851]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 136.763852]process_one_work+0x23c/0x580
[ 136.763853]worker_thread+0x50/0x3b0
[ 136.763854]kthread+0x12e/0x150
[ 136.763855]ret_from_fork+0x27/0x50
[ 136.763855]
other info that might help us debug this:
[ 136.763856] Chain exists of:
console_lock --> fs_reclaim --> dma_fence_map
[ 136.763857] Possible unsafe locking scenario:
[ 136.763857]CPU0CPU1
[ 136.763857]
[ 136.763857] lock(dma_fence_map);
[ 136.763858]lock(fs_reclaim);
[ 136.763858]lock(dma_fence_map);
[ 136.763858] lock(console_lock);
[ 136.763859]
*** DEADLOCK ***
[ 136.763860] 4 locks held by kworker/2:3/682:
[ 136.763860] #0: 8887fb81c938 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x1bc/0x580
[ 136.763862] #1: c9cafe58
((work_completion)(&(&sched->work_tdr)->work)){+.+.}-{0:0}, at:
process_one_work+0x1bc/0x580
[ 136.763863] #2: 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 136.763865] #3: 8887ab621748 (&adev->lock_reset){+.+.}-{3:3}, at:
amdgpu_device_gpu_recover.cold+0x5ab/0xe7b [amdgpu]
[ 136.763914]
stack backtrace:
[ 136.763915] CPU: 2 PID: 682 Comm: kworker/2:3 Tainted: GW
5.7.0-rc3+ #346
[ 136.763916] Hardware name: System manufacturer System Product Name/PRIME
X370-PRO, BIOS 4011 04/19/2018
[ 136.763918] Workqueue: events drm_sched_job_timedout [gpu_sched]
[ 136.763919] Call Trace:
[ 136.763922] dump_stack+0x8f/0xd0
[ 136.763924] check_noncircular+0x162/0x180
[ 136.763926] __lock_acquire+0x1241/0x23f0
[ 136.763927] lock_acquire+0xad/0x370
[ 136.763932] ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763933] ? mark_held_locks+0x2d/0x80
[ 136.763934] ? _raw_spin_unlock_irqrestore+0x46/0x60
[ 136.763936] console_lock+0x47/0x70
[ 136.763940] ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763944] drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763993] amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[ 136.764036] amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 136.764038] drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 136.764
[PATCH 18/18] drm/i915: Annotate dma_fence_work
i915 does tons of allocations from this worker, which lockdep catches.
Also generic infrastructure like this with big potential for how
dma_fence or other cross driver contracts work, really should be
reviewed on dri-devel. Implementing custom wheels for everything
within the driver is a classic case of "platform problem" [1]. Which in
upstream we really shouldn't have.
Since there's no quick way to solve these splats (dma_fence_work is
used a bunch in basic buffer management and command submission) like
for amdgpu, I'm giving up at this point here. Annotating i915
scheduler and gpu reset could would be interesting, but since lockdep
is one-shot we can't see what surprises would lurk there.
1: https://lwn.net/Articles/443531/
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index a3a81bb8f2c3..5b74acadaef5 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -17,12 +17,15 @@ static void fence_work(struct work_struct *work)
{
struct dma_fence_work *f = container_of(work, typeof(*f), work);
int err;
+ bool fence_cookie;
+ fence_cookie = dma_fence_begin_signalling();
err = f->ops->work(f);
if (err)
dma_fence_set_error(&f->dma, err);
fence_complete(f);
+ dma_fence_end_signalling(fence_cookie);
dma_fence_put(&f->dma);
}
--
2.26.2
[PATCH 13/18] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to bother, READ_ONCE is
equivalent. And avoids the locking issue.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c575e7394d03..04c11443b9ca 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6910,7 +6910,11 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* explicitly on fences instead
* and in general should be called for
* blocking commit to as per framework helpers
+*
+* Yes, this deadlocks, since you're calling dma_resv_lock in a
+* path that leads to a dma_fence_signal(). Don't do that.
*/
+#if 0
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0))
DRM_ERROR("failed to reserve buffer before flip\n");
@@ -6920,6 +6924,12 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
tmz_surface = amdgpu_bo_encrypted(abo);
amdgpu_bo_unreserve(abo);
+#endif
+ /*
+* this races anyway, so READ_ONCE isn't any better or worse
+* than the stuff above. Except the stuff above can deadlock.
+*/
+ tiling_flags = READ_ONCE(abo->tiling_flags);
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
--
2.26.2
Re: [git pull] drm for 5.8-rc1
On Thu, Jun 04, 2020 at 10:10:21AM +0200, Christian König wrote: > Dave and Daniel explicitly said they want to have this and it is ok as long > as I open code it in the driver and keep it AMD internal. But it fundamentally is broken, and we've been through all the arguments why it is broken, and it is not going to be any less broken because someone said they want this. I have to say I'm really pissed that you guys just sneaked it in. I've been hoping that graphics is getting a litter better, but this attitud of we sneak hacks into the driver code that just happen to work on some platform you care about instead because you're too lazy to do the proper thing has top stop right now. drm has been creating so much more maintainaince nightmares and buggy code than any other subsysem just because of that attitude.
[PATCH 17/18] drm/amdgpu: gpu recovery does full modesets
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] --
[ 132.586184] kworker/2:3/865 is trying to acquire lock:
[ 132.586857] c9677c70 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[ 132.587569]
but task is already holding lock:
[ 132.589044] 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 132.589803]
which lock already depends on the new lock.
[ 132.592009]
the existing dependency chain (in reverse order) is:
[ 132.593507]
-> #2 (dma_fence_map){}-{0:0}:
[ 132.595019]dma_fence_begin_signalling+0x50/0x60
[ 132.595767]drm_atomic_helper_commit+0xa1/0x180 [drm_kms_helper]
[ 132.596567]drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
[ 132.597420]drm_client_modeset_commit_locked+0x55/0x190 [drm]
[ 132.598178]drm_client_modeset_commit+0x24/0x40 [drm]
[ 132.598948]drm_fb_helper_restore_fbdev_mode_unlocked+0x4b/0xa0
[drm_kms_helper]
[ 132.599738]drm_fb_helper_set_par+0x30/0x40 [drm_kms_helper]
[ 132.600539]fbcon_init+0x2e8/0x660
[ 132.601344]visual_init+0xce/0x130
[ 132.602156]do_bind_con_driver+0x1bc/0x2b0
[ 132.602970]do_take_over_console+0x115/0x180
[ 132.603763]do_fbcon_takeover+0x58/0xb0
[ 132.604564]register_framebuffer+0x1ee/0x300
[ 132.605369]__drm_fb_helper_initial_config_and_unlock+0x36e/0x520
[drm_kms_helper]
[ 132.606187]amdgpu_fbdev_init+0xb3/0xf0 [amdgpu]
[ 132.607032]amdgpu_device_init.cold+0xe90/0x1677 [amdgpu]
[ 132.607862]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[ 132.608697]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[ 132.609511]local_pci_probe+0x42/0x80
[ 132.610324]pci_device_probe+0x104/0x1a0
[ 132.611130]really_probe+0x147/0x3c0
[ 132.611939]driver_probe_device+0xb6/0x100
[ 132.612766]device_driver_attach+0x53/0x60
[ 132.613593]__driver_attach+0x8c/0x150
[ 132.614419]bus_for_each_dev+0x7b/0xc0
[ 132.615249]bus_add_driver+0x14c/0x1f0
[ 132.616071]driver_register+0x6c/0xc0
[ 132.616902]do_one_initcall+0x5d/0x2f0
[ 132.617731]do_init_module+0x5c/0x230
[ 132.618560]load_module+0x2981/0x2bc0
[ 132.619391]__do_sys_finit_module+0xaa/0x110
[ 132.620228]do_syscall_64+0x5a/0x250
[ 132.621064]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[ 132.621903]
-> #1 (crtc_ww_class_mutex){+.+.}-{3:3}:
[ 132.623587]__ww_mutex_lock.constprop.0+0xcc/0x10c0
[ 132.624448]ww_mutex_lock+0x43/0xb0
[ 132.625315]drm_modeset_lock+0x44/0x120 [drm]
[ 132.626184]drmm_mode_config_init+0x2db/0x8b0 [drm]
[ 132.627098]amdgpu_device_init.cold+0xbd1/0x1677 [amdgpu]
[ 132.628007]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[ 132.628920]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[ 132.629804]local_pci_probe+0x42/0x80
[ 132.630690]pci_device_probe+0x104/0x1a0
[ 132.631583]really_probe+0x147/0x3c0
[ 132.632479]driver_probe_device+0xb6/0x100
[ 132.633379]device_driver_attach+0x53/0x60
[ 132.634275]__driver_attach+0x8c/0x150
[ 132.635170]bus_for_each_dev+0x7b/0xc0
[ 132.636069]bus_add_driver+0x14c/0x1f0
[ 132.636974]driver_register+0x6c/0xc0
[ 132.637870]do_one_initcall+0x5d/0x2f0
[ 132.638765]do_init_module+0x5c/0x230
[ 132.639654]load_module+0x2981/0x2bc0
[ 132.640522]__do_sys_finit_module+0xaa/0x110
[ 132.641372]do_syscall_64+0x5a/0x250
[ 132.642203]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[ 132.643022]
-> #0 (crtc_ww_class_acquire){+.+.}-{0:0}:
[ 132.644643]__lock_acquire+0x1241/0x23f0
[ 132.645469]lock_acquire+0xad/0x370
[ 132.646274]drm_modeset_acquire_init+0xd2/0x100 [drm]
[ 132.647071]drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[ 132.647902]dm_suspend+0x1c/0x60 [amdgpu]
[ 132.648698]amdgpu_device_ip_suspend_phase1+0x83/0xe0 [amdgpu]
[ 132.649498]amdgpu_device_ip_suspend+0x1c/0x60 [amdgpu]
[ 132.650300]amdgpu_device_gpu_recover.cold+0x4e6/0xe64 [amdgpu]
[ 132.651084]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 132.651825]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 132.652594]process_one_work+0x23c/0x580
[ 132.653402]worker_thread+0x50/0x3b0
[ 132.654139]kthread+0x12e/0x150
[ 132.654868]ret_from_fork+0x27/0x50
[ 132.655598]
[PATCH 09/18] drm/scheduler: use dma-fence annotations in main thread
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no expert on drm scheduler.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 2f319102ae9f..06a736e506ad 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -763,9 +763,12 @@ static int drm_sched_main(void *param)
struct sched_param sparam = {.sched_priority = 1};
struct drm_gpu_scheduler *sched = (struct drm_gpu_scheduler *)param;
int r;
+ bool fence_cookie;
sched_setscheduler(current, SCHED_FIFO, &sparam);
+ fence_cookie = dma_fence_begin_signalling();
+
while (!kthread_should_stop()) {
struct drm_sched_entity *entity = NULL;
struct drm_sched_fence *s_fence;
@@ -823,6 +826,9 @@ static int drm_sched_main(void *param)
wake_up(&sched->job_scheduled);
}
+
+ dma_fence_end_signalling(fence_cookie);
+
return 0;
}
--
2.26.2
[PATCH 14/18] drm/scheduler: use dma-fence annotations in tdr work
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this was part of the overall scheduler annotation patch.
But amdgpu has some glorious inversions here:
- grabs console_lock
- does a full modeset, which grabs all kinds of locks
(drm_modeset_lock, dma_resv_lock) which can deadlock with
dma_fence_wait held inside them.
- almost minor at that point, but the modeset code also allocates
memory
These all look like they'll be very hard to fix properly, the hardware
seems to require a full display reset with any gpu recovery.
Hence split out as a seperate patch.
Since amdgpu isn't the only hardware driver that needs to reset the
display (at least gen2/3 on intel have the same problem) we need a
generic solution for this. There's two tricks we could still from
drm/i915 and lift to dma-fence:
- The big whack, aka force-complete all fences. i915 does this for all
pending jobs if the reset is somehow stuck. Trouble is we'd need to
do this for all fences in the entire system, and just the
book-keeping for that will be fun. Plus lots of drivers use fences
for all kinds of internal stuff like memory management, so
unconditionally resetting all of them doesn't work.
I'm also hoping that with these fence annotations we could enlist
lockdep in finding the last offenders causing deadlocks, and we
could remove this get-out-of-jail trick.
- The more feasible approach (across drivers at least as part of the
dma_fence contract) is what drm/i915 does for gen2/3: When we need
to reset the display we wake up all dma_fence_wait_interruptible
calls, or well at least the equivalent of those in i915 internally.
Relying on ioctl restart we force all other threads to release their
locks, which means the tdr thread is guaranteed to be able to get
them. I think we could implement this at the dma_fence level,
including proper lockdep annotations.
dma_fence_begin_tdr():
- must be nested within a dma_fence_begin/end_signalling section
- will wake up all interruptible (but not the non-interruptible)
dma_fence_wait() calls and force them to complete with a
-ERESTARTSYS errno code. All new interrupitble calls to
dma_fence_wait() will immeidately fail with the same error code.
dma_fence_end_trdr():
- this will convert dma_fence_wait() calls back to normal.
Of course interrupting dma_fence_wait is only ok if the caller
specified that, which means we need to split the annotations into
interruptible and non-interruptible version. If we then make sure
that we only use interruptible dma_fence_wait() calls while holding
drm_modeset_lock we can grab them in tdr code, and allow display
resets. Doing the same for dma_resv_lock might be a lot harder, so
buffer updates must be avoided.
What's worse, we're not going to be able to make the dma_fence_wait
calls in mmu-notifiers interruptible, that doesn't work. So
allocating memory still wont' be allowed, even in tdr sections. Plus
obviously we can use this trick only in tdr, it is rather intrusive.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 06a736e506ad..e34a44376e87 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -279,9 +279,12 @@ static void drm_sched_job_timedout(struct work_struct
*work)
{
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+ bool fence_cookie;
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
+ fence_cookie = dma_fence_begin_signalling();
+
/* Protects against concurrent deletion in drm_sched_get_cleanup_job */
spin_lock(&sched->job_list_lock);
job = list_first_entry_or_null(&sched->ring_mirror_list,
@@ -313,6 +316,8 @@ static void drm_sched_job_timedout(struct work_struct *work)
spin_lock(&sched->job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(&sched->job_list_lock);
+
+ dma_fence_end_signalling(fence_cookie);
}
/**
--
2.26.2
[PATCH 10/18] drm/amdgpu: use dma-fence annotations in cs_submit()
This is a bit tricky, since ->notifier_lock is held while calling dma_fence_wait we must ensure that also the read side (i.e. dma_fence_begin_signalling) is on the same side. If we mix this up lockdep complaints, and that's again why we want to have these annotations. A nice side effect of this is that because of the fs_reclaim priming for dma_fence_enable lockdep now automatically checks for us that nothing in here allocates memory, without even running any userptr workloads. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index a25fb59c127c..e109666aec14 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1212,6 +1212,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, struct amdgpu_job *job; uint64_t seq; int r; + bool fence_cookie; job = p->job; p->job = NULL; @@ -1226,6 +1227,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, */ mutex_lock(&p->adev->notifier_lock); + fence_cookie = dma_fence_begin_signalling(); + /* If userptr are invalidated after amdgpu_cs_parser_bos(), return * -EAGAIN, drmIoctl in libdrm will restart the amdgpu_cs_ioctl. */ @@ -1262,12 +1265,14 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, amdgpu_vm_move_to_lru_tail(p->adev, &fpriv->vm); ttm_eu_fence_buffer_objects(&p->ticket, &p->validated, p->fence); + dma_fence_end_signalling(fence_cookie); mutex_unlock(&p->adev->notifier_lock); return 0; error_abort: drm_sched_job_cleanup(&job->base); + dma_fence_end_signalling(fence_cookie); mutex_unlock(&p->adev->notifier_lock); error_unlock: -- 2.26.2
[PATCH 05/18] drm/vkms: Annotate vblank timer
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..a53a40848a72 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
+#include
+
#include
#include
#include
@@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
struct drm_crtc *crtc = &output->crtc;
struct vkms_crtc_state *state;
u64 ret_overrun;
- bool ret;
+ bool ret, fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
output->period_ns);
@@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
DRM_DEBUG_DRIVER("Composer worker already queued\n");
}
+ dma_fence_end_signalling(fence_cookie);
+
return HRTIMER_RESTART;
}
--
2.26.2
[PATCH 11/18] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code
My dma-fence lockdep annotations caught an inversion because we allocate memory where we really shouldn't: kmem_cache_alloc+0x2b/0x6d0 amdgpu_fence_emit+0x30/0x330 [amdgpu] amdgpu_ib_schedule+0x306/0x550 [amdgpu] amdgpu_job_run+0x10f/0x260 [amdgpu] drm_sched_main+0x1b9/0x490 [gpu_sched] kthread+0x12e/0x150 Trouble right now is that lockdep only validates against GFP_FS, which would be good enough for shrinkers. But for mmu_notifiers we actually need !GFP_ATOMIC, since they can be called from any page laundering, even if GFP_NOFS or GFP_NOIO are set. I guess we should improve the lockdep annotations for fs_reclaim_acquire/release. Ofc real fix is to properly preallocate this fence and stuff it into the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of the way. v2: Two more allocations in scheduler paths. Frist one: __kmalloc+0x58/0x720 amdgpu_vmid_grab+0x100/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Second one: kmem_cache_alloc+0x2b/0x6d0 amdgpu_sync_fence+0x7e/0x110 [amdgpu] amdgpu_vmid_grab+0x86b/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c index d878fe7fee51..055b47241bb1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c @@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f, uint32_t seq; int r; - fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL); + fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC); if (fence == NULL) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c index fe92dcd94d4a..fdcd6659f5ad 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait)) return amdgpu_sync_fence(sync, ring->vmid_wait, false); - fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); + fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_ATOMIC); if (!fences) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c index b87ca171986a..330476cc0c86 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c @@ -168,7 +168,7 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f, if (amdgpu_sync_add_later(sync, f, explicit)) return 0; - e = kmem_cache_alloc(amdgpu_sync_slab, GFP_KERNEL); + e = kmem_cache_alloc(amdgpu_sync_slab, GFP_ATOMIC); if (!e) return -ENOMEM; -- 2.26.2
[PATCH 08/18] drm/amdgpu: add dma-fence annotations to atomic commit path
I need a canary in a ttm-based atomic driver to make sure the dma_fence_begin/end_signalling annotations actually work. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index bdba0bfd6df1..adabfa929f42 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -57,6 +57,7 @@ #include "ivsrcid/ivsrcid_vislands30.h" +#include #include #include #include @@ -7320,6 +7321,9 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) struct drm_connector_state *old_con_state, *new_con_state; struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; int crtc_disable_count = 0; + bool fence_cookie; + + fence_cookie = dma_fence_begin_signalling(); drm_atomic_helper_update_legacy_modeset_state(dev, state); @@ -7600,6 +7604,8 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) /* Signal HW programming completion */ drm_atomic_helper_commit_hw_done(state); + dma_fence_end_signalling(fence_cookie); + if (wait_for_vblank) drm_atomic_helper_wait_for_flip_done(dev, state); -- 2.26.2
[PATCH 03/18] dma-fence: basic lockdep annotations
Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't going to complain if the read-side isn't nested the same way under all circumstances, so ABBA deadlocks are ok. Which they are, since this is an annotation only. - We're using non-recursive lockdep read lock mode, since in recursive read lock mode lockdep does not catch read side hazards. And we _very_ much want read side hazards to be caught. For full details of this limitation see commit e91498589746065e3ae95d9a00b068e525eec34f Author: Peter Zijlstra Date: Wed Aug 23 13:13:11 2017 +0200 locking/lockdep/selftests: Add mixed read-write ABBA tests - To allow nesting of the read-side explicit annotations we explicitly keep track of the nesting. lock_is_held() allows us to do that. - The wait-side annotation is a write lock, and entirely done within dma_fence_wait() for everyone by default. - To be able to freely annotate helper functions I want to make it ok to call dma_fence_begin/end_signalling from soft/hardirq context. First attempt was using the hardirq locking context for the write side in lockdep, but this forces all normal spinlocks nested within dma_fence_begin/end_signalling to be spinlocks. That bollocks. The approach now is to simple check in_atomic(), and for these cases entirely rely on the might_sleep() check in dma_fence_wait(). That will catch any wrong nesting against spinlocks from soft/hardirq contexts. The idea here is that every code path that's critical for eventually signalling a dma_fence should be annotated with dma_fence_begin/end_signalling. The annotation ideally starts right after a dma_fence is published (added to a dma_resv, exposed as a sync_file fd, attached to a drm_syncobj fd, or anything else that makes the dma_fence visible to other kernel threads), up to and including the dma_fence_wait(). Examples are irq handlers, the scheduler rt threads, the tail of execbuf (after the corresponding fences are visible), any workers that end up signalling dma_fences and really anything else. Not annotated should be code paths that only complete fences opportunistically as the gpu progresses, like e.g. shrinker/eviction code. The main class of deadlocks this is supposed to catch are: Thread A: mutex_lock(A); mutex_unlock(A); dma_fence_signal(); Thread B: mutex_lock(A); dma_fence_wait(); mutex_unlock(A); Thread B is blocked on A signalling the fence, but A never gets around to that because it cannot acquire the lock A. Note that dma_fence_wait() is allowed to be nested within dma_fence_begin/end_signalling sections. To allow this to happen the read lock needs to be upgraded to a write lock, which means that any other lock is acquired between the dma_fence_begin_signalling() call and the call to dma_fence_wait(), and still held, this will result in an immediate lockdep complaint. The only other option would be to not annotate such calls, defeating the point. Therefore these annotations cannot be sprinkled over the code entirely mindless to avoid false positives. v2: handle soft/hardirq ctx better against write side and dont forget EXPORT_SYMBOL, drivers can't use this otherwise. v3: Kerneldoc. v4: Some spelling fixes from Mika Cc: Mika Kuoppala Cc: Thomas Hellstrom Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- Documentation/driver-api/dma-buf.rst | 12 +- drivers/dma-buf/dma-fence.c | 161 +++ include/linux/dma-fence.h| 12 ++ 3 files changed, 182 insertions(+), 3 deletions(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 63dec76d1d8d..05d856131140 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -100,11 +100,11 @@ CPU Access to DMA Buffer Objects .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: cpu access -Fence Poll Support -~~ +Implicit Fence Poll Support +~~~ .. kernel-doc:: drivers/dma-buf/dma-buf.c - :doc: fence polling + :doc: implicit fence polling Kernel Functions and Structures Reference ~ @@ -133,6 +133,12 @@ DMA Fences .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: DMA fences overview +DMA Fence Signalling Annotations + + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence signalling annotation + DMA Fences Functions Reference ~~ diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma
[PATCH 07/18] drm/atomic-helper: Add dma-fence annotations
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
implementations of this hook right now), so bad flag day. And also a
bit leaky abstraction.
Hence just do it function-by-function.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 7cd7fe0d57b4..bfcc7857a9a1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1549,6 +1549,7 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1560,6 +1561,8 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1579,6 +1582,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1591,6 +1595,8 @@ void drm_atomic_helper_commit_tail_rpm(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1606,6 +1612,9 @@ static void commit_tail(struct drm_atomic_state
*old_state)
ktime_t start;
s64 commit_time_ms;
unsigned int i, new_self_refresh_mask = 0;
+ bool fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
funcs = dev->mode_config.helper_private;
@@ -1634,6 +1643,8 @@ static void commit_tail(struct drm_atomic_state
*old_state)
if (new_crtc_state->self_refresh_active)
new_self_refresh_mask |= BIT(i);
+ dma_fence_end_signalling(fence_cookie);
+
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
@@ -1789,6 +1800,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
bool nonblock)
{
int ret;
+ bool fence_cookie;
if (state->async_update) {
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -1811,6 +1823,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
+ fence_cookie = dma_fence_begin_signalling();
+
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
@@ -1848,6 +1862,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
*/
drm_atomic_state_get(state);
+ dma_fence_end_signalling(fence_cookie);
if (nonblock)
queue_work(system_unbound_wq, &state->commit_work);
else
@@ -1856,6 +1871,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
return 0;
err:
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
}
--
2.26.2
[PATCH 02/18] dma-buf: minor doc touch-ups
Just some tiny edits: - fix link to struct dma_fence - give slightly more meaningful title - the polling here is about implicit fences, explicit fences (in sync_file or drm_syncobj) also have their own polling Signed-off-by: Daniel Vetter --- drivers/dma-buf/dma-buf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 01ce125f8e8d..e018ef80451e 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -161,11 +161,11 @@ static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence) } /** - * DOC: fence polling + * DOC: implicit fence polling * * To support cross-device and cross-driver synchronization of buffer access - * implicit fences (represented internally in the kernel with &struct fence) can - * be attached to a &dma_buf. The glue for that and a few related things are + * implicit fences (represented internally in the kernel with &struct dma_fence) + * can be attached to a &dma_buf. The glue for that and a few related things are * provided in the &dma_resv structure. * * Userspace can query the state of these implicitly tracked fences using poll() -- 2.26.2
[PATCH 00/18] dma-fence lockdep annotations, round 2
Hi all, Still very much early stuff, still very much looking for initial thoughts and maybe some ideas how this could all be rolled out across drivers. Full intro probably best from the RFC cover letter: https://lore.kernel.org/amd-gfx/20200512085944.222637-1-daniel.vet...@ffwll.ch/ Changes since last time around: - might_sleep annotation has landed already, I split that out as a stand-alone - now with an mm patch to improve direct reclaim annotations for mmu notifiers. This allows us to very easily catch issues in that area, no more need for exaustive testing and luck to make sure we're not leaving a GFP_NOFS or GPF_NOIO around which should be a GFP_ATOMIC - kerneldoc that explains all the reasoning behind the annotations and priming, hopefully Driver patches still largely just meant as examples to illustrate usage, but from various irc chats I think discussing them is really useful to gain clarity on the exact places the annotations should be put. Cheers, Daniel Daniel Vetter (18): mm: Track mmu notifiers in fs_reclaim_acquire/release dma-buf: minor doc touch-ups dma-fence: basic lockdep annotations dma-fence: prime lockdep annotations drm/vkms: Annotate vblank timer drm/vblank: Annotate with dma-fence signalling section drm/atomic-helper: Add dma-fence annotations drm/amdgpu: add dma-fence annotations to atomic commit path drm/scheduler: use dma-fence annotations in main thread drm/amdgpu: use dma-fence annotations in cs_submit() drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code drm/amdgpu: DC also loves to allocate stuff where it shouldn't drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail drm/scheduler: use dma-fence annotations in tdr work drm/amdgpu: use dma-fence annotations for gpu reset code Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset" drm/amdgpu: gpu recovery does full modesets drm/i915: Annotate dma_fence_work Documentation/driver-api/dma-buf.rst | 18 +- drivers/dma-buf/dma-buf.c | 6 +- drivers/dma-buf/dma-fence.c | 202 ++ drivers/dma-buf/dma-resv.c| 4 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 22 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- drivers/gpu/drm/amd/amdgpu/atom.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +- drivers/gpu/drm/drm_atomic_helper.c | 16 ++ drivers/gpu/drm/drm_vblank.c | 8 +- drivers/gpu/drm/i915/i915_sw_fence_work.c | 3 + drivers/gpu/drm/scheduler/sched_main.c| 11 + drivers/gpu/drm/vkms/vkms_crtc.c | 8 +- include/linux/dma-fence.h | 13 ++ mm/mmu_notifier.c | 7 - mm/page_alloc.c | 23 +- 20 files changed, 341 insertions(+), 35 deletions(-) -- 2.26.2
[PATCH 04/18] dma-fence: prime lockdep annotations
Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required. - it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mmu notifier callbacks (which amdgpu does, and which i915 sometimes also does, and probably always should, but that's kinda a debate). Also for stuff like HMM we really need to be able to do this, or things get real dicey. Consequence is that any critical path necessary to get to a dma_fence_signal for a fence must never a) call dma_resv_lock nor b) allocate memory with GFP_KERNEL. Also by implication of dma_resv_lock(), no userspace faulting allowed. That's some supremely obnoxious limitations, which is why we need to sprinkle the right annotations to all relevant paths. The one big locking context we're leaving out here is mmu notifiers, added in commit 23b68395c7c78a764e8963fc15a7cfd318bf187f Author: Daniel Vetter Date: Mon Aug 26 22:14:21 2019 +0200 mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end that one covers a lot of other callsites, and it's also allowed to wait on dma-fences from mmu notifiers. But there's no ready-made functions exposed to prime this, so I've left it out for now. v2: Also track against mmu notifier context. v3: kerneldoc to spec the cross-driver contract. Note that currently i915 throws in a hard-coded 10s timeout on foreign fences (not sure why that was done, but it's there), which is why that rule is worded with SHOULD instead of MUST. Also some of the mmu_notifier/shrinker rules might surprise SoC drivers, I haven't fully audited them all. Which is infeasible anyway, we'll need to run them with lockdep and dma-fence annotations and see what goes boom. v4: A spelling fix from Mika Cc: Mika Kuoppala Cc: Thomas Hellstrom Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- Documentation/driver-api/dma-buf.rst | 6 drivers/dma-buf/dma-fence.c | 41 drivers/dma-buf/dma-resv.c | 4 +++ include/linux/dma-fence.h| 1 + 4 files changed, 52 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 05d856131140..f8f6decde359 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -133,6 +133,12 @@ DMA Fences .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: DMA fences overview +DMA Fence Cross-Driver Contract +~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence cross-driver contract + DMA Fence Signalling Annotations diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 0005bc002529..754e6fb84fb7 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -64,6 +64,47 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); * &dma_buf.resv pointer. */ +/** + * DOC: fence cross-driver contract + * + * Since &dma_fence provide a cross driver contract, all drivers must follow the + * same rules: + * + * * Fences must complete in a reasonable time. Fences which represent kernels + * and shaders submitted by userspace, which could run forever, must be backed + * up by timeout and gpu hang recovery code. Minimally that code must prevent + * further command submission and force complete all in-flight fences, e.g. + * when the driver or hardware do not support gpu reset, or if the gpu reset + * failed for some reason. Ideally the driver supports gpu recovery which only + * affects the offending userspace context, and no other userspace + * submissions. + * + * * Drivers may have different ideas of what completion within a reasonable + * time means. Some hang recovery code uses a fixed timeout, others a mix + * between observing forward progress and increasingly strict timeouts. + * Drivers should not try to second guess timeout handling of fences from + * other drivers. + * + * * To ensure there's no deadlocks of dma_fence_wait() against other locks + * drivers should annotate all code required to reach dma_fence_signal(), + * which completes the fences, with dma_fence_begin_signalling() and + * dma_fence_end_signalling(). + * + * * Drivers are allowed to call dma_fence_wait() while holding dma_resv_lock(). + * This means any code required for fence completion cannot acquire a + * &dma_resv lock. Note that this also pulls in the entire established + * locking hierarchy around dma_resv_lock() and dma_resv_unlock(). + * + * * Drivers are allowed to call dma_fence_wait() from their &shrinker + * callbacks. This
[PATCH 12/18] drm/amdgpu: DC also loves to allocate stuff where it shouldn't
Not going to bother with a complete&pretty commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm_kms_helper]
drm_atomic_helper_commit+0x152/0x180 [drm_kms_helper]
drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
drm_client_modeset_commit_locked+0x55/0x190 [drm]
drm_client_modeset_commit+0x24/0x40 [drm]
v2: Found more in DC code, I'm just going to pile them all up.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 4cfc786699c7..1b0c674fab25 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -1226,7 +1226,7 @@ static int amdgpu_atom_execute_table_locked(struct
atom_context *ctx, int index,
ectx.abort = false;
ectx.last_jump = 0;
if (ws)
- ectx.ws = kcalloc(4, ws, GFP_KERNEL);
+ ectx.ws = kcalloc(4, ws, GFP_ATOMIC);
else
ectx.ws = NULL;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index adabfa929f42..c575e7394d03 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6833,7 +6833,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dc_stream_update stream_update;
} *bundle;
- bundle = kzalloc(sizeof(*bundle), GFP_KERNEL);
+ bundle = kzalloc(sizeof(*bundle), GFP_ATOMIC);
if (!bundle) {
dm_error("Failed to allocate update bundle\n");
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 45cfb7c45566..9a8e321a7a15 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1416,8 +1416,10 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
struct dc_state *dc_create_state(struct dc *dc)
{
+ /* No you really cant allocate random crap here this late in
+* atomic_commit_tail. */
struct dc_state *context = kvzalloc(sizeof(struct dc_state),
- GFP_KERNEL);
+ GFP_ATOMIC);
if (!context)
return NULL;
--
2.26.2
Re: [PATCH v6 10/12] mmap locking API: rename mmap_sem to mmap_lock
2020-06-04 13:57 GMT+08:00, Michel Lespinasse : > On Wed, Jun 3, 2020 at 9:35 PM youling 257 wrote: >> I have build error about kernel/sys.c, >> >> kernel/sys.c: In function ‘prctl_set_vma’: >> kernel/sys.c:2392:18: error: >> ‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean >> ‘mmap_base’? >> 2392 | down_write(&mm->mmap_sem); >>| ^~~~ >>| mmap_base >> kernel/sys.c:2402:16: error: >> ‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean >> ‘mmap_base’? >> 2402 | up_write(&mm->mmap_sem); >>|^~~~ >>|mmap_base >> >> why not rename kernel/sys.c mmap_sem to mmap_lock? > > The proper fix would be to use the mmap locking apis defined in > include/linux/mmap_lock.h instead. > > However I would like more information about your report. Did you apply > the series yourself ? If so, what base tree did you apply it onto ? If > not, what tree did you use that already included the series ? I build linux next-20200603 tree have the kernel/sys.c error. > Thanks, > > -- > Michel "Walken" Lespinasse > A program is never fully debugged until the last user dies. >
RE: [PATCH V2 2/3] firmware: imx: add resource management api
> From: Peng Fan
> Sent: Wednesday, June 3, 2020 11:32 AM
>
> Add resource management API, when we have multiple partition running
> together, resources not owned to current partition should not be used.
>
> Reviewed-by: Leonard Crestez
> Signed-off-by: Peng Fan
> ---
> drivers/firmware/imx/Makefile | 2 +-
> drivers/firmware/imx/rm.c | 45
> include/linux/firmware/imx/sci.h| 1 +
> include/linux/firmware/imx/svc/rm.h | 69
> +
> 4 files changed, 116 insertions(+), 1 deletion(-) create mode 100644
> drivers/firmware/imx/rm.c create mode 100644
> include/linux/firmware/imx/svc/rm.h
>
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 08bc9ddfbdfb..17ea3613e142 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_IMX_DSP)+= imx-dsp.o
> -obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o
> +obj-$(CONFIG_IMX_SCU)+= imx-scu.o misc.o imx-scu-irq.o rm.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new file
> mode 100644 index ..a12db6ff323b
> --- /dev/null
> +++ b/drivers/firmware/imx/rm.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + *
> + * File containing client-side RPC functions for the RM service. These
> + * function are ported to clients that communicate to the SC.
> + */
> +
> +#include
> +
> +struct imx_sc_msg_rm_rsrc_owned {
> + struct imx_sc_rpc_msg hdr;
> + u16 resource;
> +} __packed __aligned(4);
> +
> +/*
> + * This function check @resource is owned by current partition or not
> + *
> + * @param[in] ipc IPC handle
> + * @param[in] resourceresource the control is associated with
> + *
> + * @return Returns 0 for not owned and 1 for owned.
> + */
> +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
> +{
> + struct imx_sc_msg_rm_rsrc_owned msg;
> + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_RM;
> + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> + hdr->size = 2;
> +
> + msg.resource = resource;
> +
> + /*
> + * SCU firmware only returns value 0 or 1
> + * for resource owned check which means not owned or owned.
> + * So it is always successful.
> + */
> + imx_scu_call_rpc(ipc, &msg, true);
> +
> + return hdr->func;
> +}
> +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> diff --git a/include/linux/firmware/imx/sci.h
> b/include/linux/firmware/imx/sci.h
> index 3fa418a4ca67..3c459f54a88f 100644
> --- a/include/linux/firmware/imx/sci.h
> +++ b/include/linux/firmware/imx/sci.h
> @@ -14,6 +14,7 @@
>
> #include #include
>
> +#include
>
> int imx_scu_enable_general_irq_channel(struct device *dev); int
> imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> a/include/linux/firmware/imx/svc/rm.h b/include/linux/firmware/imx/svc/rm.h
> new file mode 100644
> index ..9924216f3e45
> --- /dev/null
> +++ b/include/linux/firmware/imx/svc/rm.h
> @@ -0,0 +1,69 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Copyright 2017-2020 NXP
> + *
> + * Header file containing the public API for the System Controller (SC)
> + * Power Management (PM) function. This includes functions for power
> +state
> + * control, clock control, reset control, and wake-up event control.
Fix the code comments.
Otherwise:
Dong Aisheng
Regards
Aisheng
Re: [PATCH] shmem, memcg: enable memcg aware shrinker
Yang Shi wrote:
> On Sun, May 31, 2020 at 8:22 PM Greg Thelen wrote:
>>
>> Since v4.19 commit b0dedc49a2da ("mm/vmscan.c: iterate only over charged
>> shrinkers during memcg shrink_slab()") a memcg aware shrinker is only
>> called when the per-memcg per-node shrinker_map indicates that the
>> shrinker may have objects to release to the memcg and node.
>>
>> shmem_unused_huge_count and shmem_unused_huge_scan support the per-tmpfs
>> shrinker which advertises per memcg and numa awareness. The shmem
>> shrinker releases memory by splitting hugepages that extend beyond
>> i_size.
>>
>> Shmem does not currently set bits in shrinker_map. So, starting with
>> b0dedc49a2da, memcg reclaim avoids calling the shmem shrinker under
>> pressure. This leads to undeserved memcg OOM kills.
>> Example that reliably sees memcg OOM kill in unpatched kernel:
>> FS=/tmp/fs
>> CONTAINER=/cgroup/memory/tmpfs_shrinker
>> mkdir -p $FS
>> mount -t tmpfs -o huge=always nodev $FS
>> # Create 1000 MB container, which shouldn't suffer OOM.
>> mkdir $CONTAINER
>> echo 1000M > $CONTAINER/memory.limit_in_bytes
>> echo $BASHPID >> $CONTAINER/cgroup.procs
>> # Create 4000 files. Ideally each file uses 4k data page + a little
>> # metadata. Assume 8k total per-file, 32MB (4000*8k) should easily
>> # fit within container's 1000 MB. But if data pages use 2MB
>> # hugepages (due to aggressive huge=always) then files consume 8GB,
>> # which hits memcg 1000 MB limit.
>> for i in {1..4000}; do
>> echo . > $FS/$i
>> done
>
> It looks all the inodes which have tail THP beyond i_size are on one
> single list, then the shrinker actually just splits the first
> nr_to_scan inodes. But since the list is not memcg aware, so it seems
> it may split the THPs which are not charged to the victim memcg and
> the victim memcg still may suffer from pre-mature oom, right?
Correct. shmem_unused_huge_shrink() is not memcg aware. In response to
memcg pressure it will split the post-i_size tails of nr_to_scan tmpfs
inodes regardless of if they're charged to the under-pressure memcg.
do_shrink_slab() looks like it'll repeatedly call
shmem_unused_huge_shrink(). So it will split tails of many inodes. So
I think it'll avoid the oom by over shrinking. This is not ideal. But
it seems better than undeserved oom kill.
I think the solution (as Kirill Tkhai suggested) a memcg-aware index
would solve both:
1) avoid premature oom by registering shrinker to responding to memcg
pressure
2) avoid shrinking/splitting inodes unrelated to the under-pressure
memcg
I can certainly look into that (thanks Kirill for the pointers). In the
short term I'm still interested in avoiding premature OOMs with the
original thread (i.e. restore pre-4.19 behavior to shmem shrinker for
memcg pressure). I plan to test and repost v2.
Re: [PATCH V2] mfd: sprd: Add wakeup capability for PMIC irq
Hi Lee,
On Wed, 27 May 2020 at 14:21, Chunyan Zhang wrote:
>
> From: Baolin Wang
>
> When changing to use suspend-to-idle to save power, the PMIC irq can not
> wakeup the system due to lack of wakeup capability, which will cause
> the sub-irqs (such as power key) of the PMIC can not wake up the system.
> Thus we can add the wakeup capability for PMIC irq to solve this issue,
> as well as removing the IRQF_NO_SUSPEND flag to allow PMIC irq to be
> a wakeup source.
>
> Reported-by: Chunyan Zhang
> Signed-off-by: Baolin Wang
> Tested-by: Chunyan Zhang
> ---
> Changes from v1:
> * addressed comments from Lee;
> * added tested-by from Chunyan.
> (This patch is rebased on branch for-mfd-next)
Could you please pick up this patch if there's no more comments :)
Thanks,
Chunyan
> ---
> drivers/mfd/sprd-sc27xx-spi.c | 28 +++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
> index 6cde4724..adb4a1b13332 100644
> --- a/drivers/mfd/sprd-sc27xx-spi.c
> +++ b/drivers/mfd/sprd-sc27xx-spi.c
> @@ -256,7 +256,7 @@ static int sprd_pmic_probe(struct spi_device *spi)
> }
>
> ret = devm_regmap_add_irq_chip(&spi->dev, ddata->regmap, ddata->irq,
> - IRQF_ONESHOT | IRQF_NO_SUSPEND, 0,
> + IRQF_ONESHOT, 0,
>&ddata->irq_chip, &ddata->irq_data);
> if (ret) {
> dev_err(&spi->dev, "Failed to add PMIC irq chip %d\n", ret);
> @@ -272,9 +272,34 @@ static int sprd_pmic_probe(struct spi_device *spi)
> return ret;
> }
>
> + device_init_wakeup(&spi->dev, true);
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int sprd_pmic_suspend(struct device *dev)
> +{
> + struct sprd_pmic *ddata = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(ddata->irq);
> +
> + return 0;
> +}
> +
> +static int sprd_pmic_resume(struct device *dev)
> +{
> + struct sprd_pmic *ddata = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(ddata->irq);
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(sprd_pmic_pm_ops, sprd_pmic_suspend,
> sprd_pmic_resume);
> +
> static const struct of_device_id sprd_pmic_match[] = {
> { .compatible = "sprd,sc2731", .data = &sc2731_data },
> {},
> @@ -285,6 +310,7 @@ static struct spi_driver sprd_pmic_driver = {
> .driver = {
> .name = "sc27xx-pmic",
> .of_match_table = sprd_pmic_match,
> + .pm = &sprd_pmic_pm_ops,
> },
> .probe = sprd_pmic_probe,
> };
> --
> 2.20.1
>
Acer TravelMate 5735Z: atkbd serio0: Unknown key pressed (translated set 2, code 0x93 on isa0060/serio0)
Dear Linux folks, Using Debian Sid/unstable with Linux 5.6.14 on an (old) Acer TravelMate 5735Z, pressing the WIFI enable/disable function key works, and GNOME even shows the OSD notification. But Linux still logs this key as unknown. [ 1595.795162] atkbd serio0: Unknown key pressed (translated set 2, code 0x93 on isa0060/serio0). [ 1595.795167] atkbd serio0: Use 'setkeycodes e013 ' to make it known. [ 1595.801375] atkbd serio0: Unknown key released (translated set 2, code 0x93 on isa0060/serio0). [ 1595.801380] atkbd serio0: Use 'setkeycodes e013 ' to make it known. Can this be fixed upstream, and if so, where, or should these messages be ignored? Kind regards, Paul [0.00] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [0.00] Linux version 5.6.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-13)) #1 SMP Debian 5.6.14-1 (2020-05-23) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.6.0-2-amd64 root=UUID=e17cec4f-d2b8-4cc3-bd39-39a10ed422f4 ro quiet noisapnp cryptomgr.notests random.trust_cpu=on acpi_backlight=native [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbb86bfff] usable [0.00] BIOS-e820: [mem 0xbb86c000-0xbb8befff] reserved [0.00] BIOS-e820: [mem 0xbb8bf000-0xbb981fff] usable [0.00] BIOS-e820: [mem 0xbb982000-0xbb9befff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb9bf000-0xbb9e8fff] usable [0.00] BIOS-e820: [mem 0xbb9e9000-0xbb9fefff] ACPI data [0.00] BIOS-e820: [mem 0xbb9ff000-0xbb9f] usable [0.00] BIOS-e820: [mem 0xbba0-0xbfff] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved [0.00] BIOS-e820: [mem 0xfed18000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Acer TravelMate 5735Z/BA51_MV, BIOS V1.14 07/26/2011 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 2294.219 MHz processor [0.004010] e820: update [mem 0x-0x0fff] usable ==> reserved [0.004012] e820: remove [mem 0x000a-0x000f] usable [0.004019] last_pfn = 0xbba00 max_arch_pfn = 0x4 [0.004026] MTRR default type: uncachable [0.004026] MTRR fixed ranges enabled: [0.004028] 0-9 write-back [0.004029] A-B uncachable [0.004031] C-D write-protect [0.004032] E-E uncachable [0.004033] F-F write-protect [0.004034] MTRR variable ranges enabled: [0.004035] 0 base 0FFE0 mask FFFE0 write-protect [0.004037] 1 base 0FFFC mask E uncachable [0.004038] 2 base 0 mask F8000 write-back [0.004040] 3 base 08000 mask FC000 write-back [0.004041] 4 base 0BC00 mask FFC00 uncachable [0.004042] 5 base 0BBC0 mask FFFC0 uncachable [0.004044] 6 base 0BBA0 mask FFFE0 uncachable [0.004044] 7 disabled [0.004603] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.017995] BRK [0xab201000, 0xab201fff] PGTABLE [0.017999] BRK [0xab202000, 0xab202fff] PGTABLE [0.018001] BRK [0xab203000, 0xab203fff] PGTABLE [0.018042] BRK [0xab204000, 0xab204fff] PGTABLE [0.018044] BRK [0xab205000, 0xab205fff] PGTABLE [0.018190] BRK [0xab206000, 0xab206fff] PGTABLE [0.018231] BRK [0xab207000, 0xab207fff] PGTABLE [0.018373] RAMDISK: [mem 0x370a1000-0x37847fff] [0.018381] ACPI: Early table checksum verification disabled [0.018386] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS) [0.018390] ACPI: XSDT 0xBB9FE120 64 (v01 ACRSYS ACRPRDCT 0001 0113) [0.018397] ACPI: FACP 0xBB9FD000 F4 (v04 ACRSYS ACRPRDCT 0001 1025 0113) [0.018404] ACPI: DSDT 0xBB9EB000 00C119 (v
Re: [PATCH] compiler.h: Move instrumentation_begin()/end() into new header
* Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Mon, Jun 1, 2020 at 6:08 AM Ingo Molnar wrote: > > > > > > include/linux/compiler.h| 53 +++ > > > > I have pulled this, but do we really want to add this to a header file > > that is _so_ core that it gets included for basically every single > > file built? > > > > I don't even see those instrumentation_begin/end() things used > > anywhere right now. > > > > It seems excessive. That 53 lines is maybe not a lot, but it pushed > > that header file to over 12kB, and while it's mostly comments, it's > > extra IO and parsing basically for _every_ single file compiled in the > > kernel. > > > > For what appears to be absolutely zero upside right now, and I really > > don't see why this should be in such a core header file! > > > > I don't even see this as having anything at all to do with > > "compiler.h" in the first place. > > > > I really think we should think twice about making core header files > > bigger like this. No, we're nowhere the disaster that C++ project > > headers are, but tokenization and parsing is actually a pretty big > > part of the build costs (which may surprise some people who think it's > > all the fancy optimizations that cost a lot of CPU time). > > Fully agreed - and I made the attached patch to address this. > > The code got cleaner and better structured, but it didn't help much in > terms of inclusion count: > >2616 total .o files > >2447 >2436 >2404 > > The reason is that is included almost everywhere as > well, and the instrumentation_begin()/end() annotations affect the > BUG*() and WARN*() primitives as well. > > At least non-x86 would have less instrumentation related noise, for > now at least. > arch/x86/include/asm/bug.h | 1 + > include/linux/compiler.h | 53 - > include/linux/context_tracking.h | 2 ++ > include/linux/instrumentation.h | 57 > > 4 files changed, 60 insertions(+), 53 deletions(-) The tested v2 version of the patch also needed the include in asm-generic/bug.h (see the fix attached below), because for completeness the generic version was annotated as well - even though only x86 has objtool support for now. The readability improvement is real though. Thanks, Ingo diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h index 384b5c835ced..c43b5906e0dc 100644 --- a/include/asm-generic/bug.h +++ b/include/asm-generic/bug.h @@ -3,6 +3,7 @@ #define _ASM_GENERIC_BUG_H #include +#include #define CUT_HERE "[ cut here ]\n"
Re: [PATCH] fbdev: geocode: Add the missed pci_disable_device() for gx1fb_map_video_memory()
On Wed, 3 Jun 2020 17:25:47 +0800
Chuhong Yuan wrote:
> Although gx1fb_probe() has handled the failure of gx1fb_map_video_memory()
> partly, it does not call pci_disable_device() as gx1fb_map_video_memory()
> calls pci_enable_device().
> Add the missed function call to fix the bug.
>
> Fixes: 53eed4ec8bcd ("[PATCH] fbdev: geode updates]")
> Signed-off-by: Chuhong Yuan
> ---
> drivers/video/fbdev/geode/gx1fb_core.c | 37 ++
> 1 file changed, 26 insertions(+), 11 deletions(-)
Hi,
there is a typo in the patch subject, the driver seems to be called
geode, not geocode.
Thanks,
pq
pgpbPultGvExD.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Thu, 4 Jun 2020 16:44:42 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> arch/powerpc/mm/ptdump/ptdump.c: In function 'walk_pagetables':
> arch/powerpc/mm/ptdump/ptdump.c:337:25: error: implicit declaration of
> function 'pgd_is_leaf'; did you mean 'p4d_is_leaf'?
> [-Werror=implicit-function-declaration]
> 337 | if (pgd_none(*pgd) || pgd_is_leaf(*pgd))
> | ^~~
> | p4d_is_leaf
>
> Caused by commit
>
>"powerpc: add support for folded p4d page tables"
>
> I applied the following fix up patch.
>
> From: Stephen Rothwell
> Date: Thu, 4 Jun 2020 16:33:01 +1000
> Subject: [PATCH] fixup for powerpc ptdump.c
>
> Signed-off-by: Stephen Rothwell
> ---
> arch/powerpc/mm/ptdump/ptdump.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> index 9b1c89b05622..de6e05ef871c 100644
> --- a/arch/powerpc/mm/ptdump/ptdump.c
> +++ b/arch/powerpc/mm/ptdump/ptdump.c
> @@ -334,12 +334,12 @@ static void walk_pagetables(struct pg_state *st)
> for (i = pgd_index(addr); i < PTRS_PER_PGD; i++, pgd++, addr +=
> PGDIR_SIZE) {
> p4d_t *p4d = p4d_offset(pgd, 0);
>
> - if (pgd_none(*pgd) || pgd_is_leaf(*pgd))
> + if (p4d_none(*p4d) || p4d_is_leaf(*p4d))
> note_page(st, addr, 1, p4d_val(*p4d), PGDIR_SIZE);
> else if (is_hugepd(__hugepd(p4d_val(*p4d
> - walk_hugepd(st, (hugepd_t *)pgd, addr, PGDIR_SHIFT, 1);
> + walk_hugepd(st, (hugepd_t *)p4d, addr, PGDIR_SHIFT, 1);
> else
> - /* pgd exists */
> + /* p4d exists */
> walk_pud(st, p4d, addr);
> }
> }
>
I have put that in linux-next (for tomorrow) as a fix up for
powerpc-add-support-for-folded-p4d-page-tables.
--
Cheers,
Stephen Rothwell
pgpad3T77XNxx.pgp
Description: OpenPGP digital signature
Re: [PATCH] iommu/mediatek: Use totalram_pages to setup enable_4GB
On 04.06.20 10:01, Miles Chen wrote: > To build this driver as a kernel module, we cannot use > the unexported symbol "max_pfn" to setup enable_4GB. > > Use totalram_pages() instead to setup enable_4GB. > > Suggested-by: Mike Rapoport > Signed-off-by: Miles Chen > Cc: David Hildenbrand > Cc: Yong Wu > Cc: Chao Hao > --- > drivers/iommu/mtk_iommu.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index 5f4d6df59cf6..c2798a6e0e38 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -3,7 +3,6 @@ > * Copyright (c) 2015-2016 MediaTek Inc. > * Author: Yong Wu > */ > -#include > #include > #include > #include > @@ -626,8 +625,8 @@ static int mtk_iommu_probe(struct platform_device *pdev) > return -ENOMEM; > data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN); > > - /* Whether the current dram is over 4GB */ > - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT)); > + /* Whether the current dram is over 4GB, note: DRAM start at 1GB */ > + data->enable_4GB = !!(totalram_pages() > ((SZ_2G + SZ_1G) >> > PAGE_SHIFT)); A similar thing seems to be done by drivers/media/platform/mtk-vpu/mtk_vpu.c: vpu->enable_4GB = !!(totalram_pages() > (SZ_2G >> PAGE_SHIFT)); I do wonder if some weird memory hotplug setups might give you false negatives. E.g., start a VM with 1GB and hotplug 1GB - it will be hotplugged on x86-64 above 4GB, turning max_pfn into 5GB. totalram_pages() should return something < 2GB. Same can happen when you have a VM and use ballooning to fake-unplug memory, making totalram_pages() return something < 4GB, but leaving usable pfns >= 4GB. but ... I don't know if I understood what "enable_4GB" needs/implies ... I don't know if this is applicable to VMs at all (on real HW such memory hotplug setups should not exist) ... I don't know how this code would react to memory hotplug, so if the condition changes after the driver loaded and enable_4GB would suddenly apply. Again, most probably not relevant on real HW, only for VMs. -- Thanks, David / dhildenb
