Re: [PATCH] iommu/amd: Fix IOMMU page flush when detach all devices from a domain
Hi Suravee, On Thu, Jan 24, 2019 at 03:25:19AM +, Suthikulpanit, Suravee wrote: > Actually, I just noticed that device_flush_dte() has already handled flushing > the DTE > for alias device as well. Please see the link below. > > https://elixir.bootlin.com/linux/latest/source/drivers/iommu/amd_iommu.c#L1219 > > So, we don't need to call device_flush_dte() for alias device in do_detach(). You are right, I missed that. Thanks, Joerg
Re: [PATCH] media: docs-rst: Document m2m stateless video decoder interface
On Wed, Jan 23, 2019 at 7:42 PM Paul Kocialkowski
wrote:
>
> Hi Alex,
>
> On Wed, 2019-01-23 at 18:43 +0900, Alexandre Courbot wrote:
> > On Tue, Jan 22, 2019 at 7:10 PM Paul Kocialkowski
> > wrote:
> > > Hi,
> > >
> > > On Tue, 2019-01-22 at 17:19 +0900, Tomasz Figa wrote:
> > > > Hi Paul,
> > > >
> > > > On Fri, Dec 7, 2018 at 5:30 PM Paul Kocialkowski
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > Thanks for this new version! I only have one comment left, see below.
> > > > >
> > > > > On Wed, 2018-12-05 at 19:01 +0900, Alexandre Courbot wrote:
> > > > > > Documents the protocol that user-space should follow when
> > > > > > communicating with stateless video decoders.
> > > > > >
> > > > > > The stateless video decoding API makes use of the new request and
> > > > > > tags
> > > > > > APIs. While it has been implemented with the Cedrus driver so far,
> > > > > > it
> > > > > > should probably still be considered staging for a short while.
> > > > > >
> > > > > > Signed-off-by: Alexandre Courbot
> > > > > > ---
> > > > > > Removing the RFC flag this time. Changes since RFCv3:
> > > > > >
> > > > > > * Included Tomasz and Hans feedback,
> > > > > > * Expanded the decoding section to better describe the use of
> > > > > > requests,
> > > > > > * Use the tags API.
> > > > > >
> > > > > > Documentation/media/uapi/v4l/dev-codec.rst| 5 +
> > > > > > .../media/uapi/v4l/dev-stateless-decoder.rst | 399
> > > > > > ++
> > > > > > 2 files changed, 404 insertions(+)
> > > > > > create mode 100644
> > > > > > Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > >
> > > > > > diff --git a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > index c61e938bd8dc..3e6a3e883f11 100644
> > > > > > --- a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > +++ b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > @@ -6,6 +6,11 @@
> > > > > > Codec Interface
> > > > > > ***
> > > > > >
> > > > > > +.. toctree::
> > > > > > +:maxdepth: 1
> > > > > > +
> > > > > > +dev-stateless-decoder
> > > > > > +
> > > > > > A V4L2 codec can compress, decompress, transform, or otherwise
> > > > > > convert
> > > > > > video data from one format into another format, in memory.
> > > > > > Typically
> > > > > > such devices are memory-to-memory devices (i.e. devices with the
> > > > > > diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > new file mode 100644
> > > > > > index ..7a781c89bd59
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > @@ -0,0 +1,399 @@
> > > > > > +.. -*- coding: utf-8; mode: rst -*-
> > > > > > +
> > > > > > +.. _stateless_decoder:
> > > > > > +
> > > > > > +**
> > > > > > +Memory-to-memory Stateless Video Decoder Interface
> > > > > > +**
> > > > > > +
> > > > > > +A stateless decoder is a decoder that works without retaining any
> > > > > > kind of state
> > > > > > +between processing frames. This means that each frame is decoded
> > > > > > independently
> > > > > > +of any previous and future frames, and that the client is
> > > > > > responsible for
> > > > > > +maintaining the decoding state and providing it to the decoder
> > > > > > with each
> > > > > > +decoding request. This is in contrast to the stateful video
> > > > > > decoder interface,
> > > > > > +where the hardware and driver maintain the decoding state and all
> > > > > > the client
> > > > > > +has to do is to provide the raw encoded stream.
> > > > > > +
> > > > > > +This section describes how user-space ("the client") is expected
> > > > > > to communicate
> > > > > > +with such decoders in order to successfully decode an encoded
> > > > > > stream. Compared
> > > > > > +to stateful codecs, the decoder/client sequence is simpler, but
> > > > > > the cost of
> > > > > > +this simplicity is extra complexity in the client which must
> > > > > > maintain a
> > > > > > +consistent decoding state.
> > > > > > +
> > > > > > +Stateless decoders make use of the request API and buffer tags. A
> > > > > > stateless
> > > > > > +decoder must thus expose the following capabilities on its queues
> > > > > > when
> > > > > > +:c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are
> > > > > > invoked:
> > > > > > +
> > > > > > +* The ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability must be set on
> > > > > > the
> > > > > > + ``OUTPUT`` queue,
> > > > > > +
> > > > > > +* The ``V4L2_BUF_CAP_SUPPORTS_TAGS`` capability must be set on the
> > > > > > ``OUTPUT``
> > > > > > + and ``CAPTURE`` queues,
> > > > > > +
> > > > >
> > > > > [...]
> > > > >
> > > > > > +Decoding
> > > > > > +
> > > > > > +
> > > > > > +For each frame, the client
Re: [PATCH 3/9] irq/irq_sim: provide irq_sim_get_type()
On Thu, Jan 24, 2019 at 08:46:56AM +0100, Bartosz Golaszewski wrote: > śr., 23 sty 2019 o 20:18 Uwe Kleine-König > napisał(a): > > > > Hello Bartosz, > > > > On Wed, Jan 23, 2019 at 03:15:32PM +0100, Bartosz Golaszewski wrote: > > > Provide a helper that allows users to retrieve the configured flow type > > > of dummy interrupts. That allows certain users to decide whether an irq > > > needs to be fired depending on its edge/level/... configuration. > > > > You don't talk about the .set_type callback here; is this intended? > > > > I wonder how you think this should be used. Assume the mockup-driver is > > directed to pull up a certain line, does it do something like that: > > > > def mockup_setval(self, val): > > irqtype = irq_sim_get_type(...) > > if irqtype == LEVEL_HIGH: > > if val: > > fire_irq() > > > > else if irqtype == EDGE_RISING: > > if val and not prev_val: > > fire_irq() > > > > else if irqtype == LEVEL_LOW: > > if not val: > > fire_irq() > > > > else if irqtype == EDGE_FALLING: > > if not val and prev_val: > > fire_irq() > > > > I wonder if that logic should be done in the same place as where the irq > > type is stored. Otherwise that .type member is only a data store > > provided by the irq simulator. So I suggest to either move the variable > > that mirrors the current level of the line into the irq simulator, or > > keep the irqtype variable in the mockup driver. Both approaches would > > make it unnecessary to provide an accessor function for the type member. > > > > Yeah, might be better to go back to my previous idea of adding > irq_sim_fire_edge(), but maybe it should be irq_sim_fire_type() > instead, so that irq_sim_fire() fires unconditionally and > irq_sim_fire_type() would fire only if the passed flag is the same as > the one previously configured by the set_type() callback. How (if at all) do you intend to support level sensitive irqs with this interface? It probably works (but I didn't thought it through completely), but firing a LEVEL_HIGH sensitive irq on irq_sim_fire_type(EDGE_RISING) might look at least surprising and needs proper comments and thoughts. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH v3 16/16] block: sed-opal: rename next to execute_steps
As the function is responsible for executing the individual steps supplied
in the steps argument, execute_steps is a more descriptive name than the
rather generic next.
Signed-off-by: David Kozub
---
block/sed-opal.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/block/sed-opal.c b/block/sed-opal.c
index 3362741dd198..c09149dd5e0a 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -401,8 +401,8 @@ static int execute_step(struct opal_dev *dev,
return error;
}
-static int next(struct opal_dev *dev, const struct opal_step *steps,
- size_t n_steps)
+static int execute_steps(struct opal_dev *dev,
+const struct opal_step *steps, size_t n_steps)
{
size_t state;
int error;
@@ -2034,7 +2034,7 @@ static int opal_secure_erase_locking_range(struct
opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, erase_steps, ARRAY_SIZE(erase_steps));
+ ret = execute_steps(dev, erase_steps, ARRAY_SIZE(erase_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2051,7 +2051,7 @@ static int opal_erase_locking_range(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, erase_steps, ARRAY_SIZE(erase_steps));
+ ret = execute_steps(dev, erase_steps, ARRAY_SIZE(erase_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2077,7 +2077,7 @@ static int opal_enable_disable_shadow_mbr(struct opal_dev
*dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
+ ret = execute_steps(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2099,7 +2099,7 @@ static int opal_mbr_status(struct opal_dev *dev, struct
opal_mbr_data *opal_mbr)
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
+ ret = execute_steps(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2122,7 +2122,7 @@ static int opal_write_shadow_mbr(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
+ ret = execute_steps(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2174,7 +2174,7 @@ static int opal_add_user_to_lr(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, steps, ARRAY_SIZE(steps));
+ ret = execute_steps(dev, steps, ARRAY_SIZE(steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2189,7 +2189,7 @@ static int opal_reverttper(struct opal_dev *dev, struct
opal_key *opal)
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, revert_steps, ARRAY_SIZE(revert_steps));
+ ret = execute_steps(dev, revert_steps, ARRAY_SIZE(revert_steps));
mutex_unlock(&dev->dev_lock);
/*
@@ -2217,10 +2217,11 @@ static int __opal_lock_unlock(struct opal_dev *dev,
};
if (lk_unlk->session.sum)
- return next(dev, unlock_sum_steps,
- ARRAY_SIZE(unlock_sum_steps));
+ return execute_steps(dev, unlock_sum_steps,
+ARRAY_SIZE(unlock_sum_steps));
else
- return next(dev, unlock_steps, ARRAY_SIZE(unlock_steps));
+ return execute_steps(dev, unlock_steps,
+ARRAY_SIZE(unlock_steps));
}
static int __opal_set_mbr_done(struct opal_dev *dev, struct opal_key *key)
@@ -2232,7 +2233,7 @@ static int __opal_set_mbr_done(struct opal_dev *dev,
struct opal_key *key)
{ end_opal_session, }
};
- return next(dev, mbrdone_step, ARRAY_SIZE(mbrdone_step));
+ return execute_steps(dev, mbrdone_step, ARRAY_SIZE(mbrdone_step));
}
static int opal_lock_unlock(struct opal_dev *dev,
@@ -2267,7 +2268,7 @@ static int opal_take_ownership(struct opal_dev *dev,
struct opal_key *opal)
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, owner_steps, ARRAY_SIZE(owner_steps));
+ ret = execute_steps(dev, owner_steps, ARRAY_SIZE(owner_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2288,7 +2289,7 @@ static int opal_activate_lsp(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, active_steps, ARRAY_SIZE(active_steps));
+ ret = execute_steps(dev, active_steps, ARRAY_SIZE(active_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2305,7 +2306,7 @@ static int opal_setup_locking_range(struct opal_dev *dev,
mutex_lock
[PATCH 16/16] block: sed-opal: rename next to execute_steps
As the function is responsible for executing the individual steps supplied
in the steps argument, execute_steps is a more descriptive name than the
rather generic next.
Signed-off-by: David Kozub
---
block/sed-opal.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/block/sed-opal.c b/block/sed-opal.c
index cedf4d12138d..f2bd16de8764 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -401,8 +401,8 @@ static int execute_step(struct opal_dev *dev,
return error;
}
-static int next(struct opal_dev *dev, const struct opal_step *steps,
- size_t n_steps)
+static int execute_steps(struct opal_dev *dev,
+const struct opal_step *steps, size_t n_steps)
{
size_t state;
int error;
@@ -2032,7 +2032,7 @@ static int opal_secure_erase_locking_range(struct
opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, erase_steps, ARRAY_SIZE(erase_steps));
+ ret = execute_steps(dev, erase_steps, ARRAY_SIZE(erase_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2049,7 +2049,7 @@ static int opal_erase_locking_range(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, erase_steps, ARRAY_SIZE(erase_steps));
+ ret = execute_steps(dev, erase_steps, ARRAY_SIZE(erase_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2075,7 +2075,7 @@ static int opal_enable_disable_shadow_mbr(struct opal_dev
*dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
+ ret = execute_steps(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2097,7 +2097,7 @@ static int opal_mbr_status(struct opal_dev *dev, struct
opal_mbr_data *opal_mbr)
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
+ ret = execute_steps(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2120,7 +2120,7 @@ static int opal_write_shadow_mbr(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
+ ret = execute_steps(dev, mbr_steps, ARRAY_SIZE(mbr_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2172,7 +2172,7 @@ static int opal_add_user_to_lr(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, steps, ARRAY_SIZE(steps));
+ ret = execute_steps(dev, steps, ARRAY_SIZE(steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2187,7 +2187,7 @@ static int opal_reverttper(struct opal_dev *dev, struct
opal_key *opal)
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, revert_steps, ARRAY_SIZE(revert_steps));
+ ret = execute_steps(dev, revert_steps, ARRAY_SIZE(revert_steps));
mutex_unlock(&dev->dev_lock);
/*
@@ -2215,10 +2215,11 @@ static int __opal_lock_unlock(struct opal_dev *dev,
};
if (lk_unlk->session.sum)
- return next(dev, unlock_sum_steps,
- ARRAY_SIZE(unlock_sum_steps));
+ return execute_steps(dev, unlock_sum_steps,
+ARRAY_SIZE(unlock_sum_steps));
else
- return next(dev, unlock_steps, ARRAY_SIZE(unlock_steps));
+ return execute_steps(dev, unlock_steps,
+ARRAY_SIZE(unlock_steps));
}
static int __opal_set_mbr_done(struct opal_dev *dev, struct opal_key *key)
@@ -2230,7 +2231,7 @@ static int __opal_set_mbr_done(struct opal_dev *dev,
struct opal_key *key)
{ end_opal_session, }
};
- return next(dev, mbrdone_step, ARRAY_SIZE(mbrdone_step));
+ return execute_steps(dev, mbrdone_step, ARRAY_SIZE(mbrdone_step));
}
static int opal_lock_unlock(struct opal_dev *dev,
@@ -2265,7 +2266,7 @@ static int opal_take_ownership(struct opal_dev *dev,
struct opal_key *opal)
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, owner_steps, ARRAY_SIZE(owner_steps));
+ ret = execute_steps(dev, owner_steps, ARRAY_SIZE(owner_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2286,7 +2287,7 @@ static int opal_activate_lsp(struct opal_dev *dev,
mutex_lock(&dev->dev_lock);
setup_opal_dev(dev);
- ret = next(dev, active_steps, ARRAY_SIZE(active_steps));
+ ret = execute_steps(dev, active_steps, ARRAY_SIZE(active_steps));
mutex_unlock(&dev->dev_lock);
return ret;
}
@@ -2303,7 +2304,7 @@ static int opal_setup_locking_range(struct opal_dev *dev,
mutex_lock
Re: [PATCH v3 0/2] Support for eMMC in AM65x-evm
Hi, On 17/01/19 3:14 PM, Faiz Abbas wrote: > The following patches add eMMC support on TI's AM65x-evm. > > v3: > 1. Fixed patch titles to only include eMMC > 2. Added dma-coherent to the sdhci0 node. > > v2: > 1. The SD card node is under debug for some usecases. > Only upstreaming eMMC support for now. > 2. Rebased to latest mainline. > 3. Removed status = "disabled" from dtsi patch > 4. Fixed node name to not include '_'s > > Faiz Abbas (2): > arm64: dts: ti: k3-am654: Add Support for eMMC host controller > arm64: dts: ti: k3-am654-base-board: Add eMMC Support > > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 14 +++ > .../arm64/boot/dts/ti/k3-am654-base-board.dts | 25 +++ > 2 files changed, 39 insertions(+) > Gentle ping. Thanks, Faiz
Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches
On Thu, Jan 24, 2019 at 07:55:51AM +1300, Kees Cook wrote:
> On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula
> wrote:
> >
> > On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> > > On Wed, 23 Jan 2019, Jani Nikula wrote:
> > >> On Wed, 23 Jan 2019, Greg KH wrote:
> > >> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > >> >> Variables declared in a switch statement before any case statements
> > >> >> cannot be initialized, so move all instances out of the switches.
> > >> >> After this, future always-initialized stack variables will work
> > >> >> and not throw warnings like this:
> > >> >>
> > >> >> fs/fcntl.c: In function ‘send_sigio_to_task’:
> > >> >> fs/fcntl.c:738:13: warning: statement will never be executed
> > >> >> [-Wswitch-unreachable]
> > >> >>siginfo_t si;
> > >> >> ^~
> > >> >
> > >> > That's a pain, so this means we can't have any new variables in { }
> > >> > scope except for at the top of a function?
>
> Just in case this wasn't clear: no, it's just the switch statement
> before the first "case". I cannot imagine how bad it would be if we
> couldn't have block-scoped variables! Heh. :)
Sorry, it was not clear at first glance. So no more objection from me
for this change.
greg k-h
Re: [PATCH v3 1/2] mm, oom: fix use-after-free in oom_kill_process
On Thu, Jan 24, 2019 at 08:35:27AM +0900, Tetsuo Handa wrote: > Shakeel Butt wrote: > > > How should we proceed with this patch? > > > > > > > We do want to backport this patch to stable kernels. However shouldn't > > we wait for this patch to be applied to Linus's tree first. Yes we will. > But since Andrew Morton seems to be offline since Jan 11, we don't know > when this patch will arrive at Linus's tree. That's fine, we can wait :) greg k-h
[PATCH v6 1/6] irqchip/mtk-sysirq: support 4 interrupt parameters for sysirq
From: Seiya Wang
To support partitioned PPIs, 4 interrupt parameters should be valid
for sysirq.
Signed-off-by: Seiya Wang
Signed-off-by: Erin Lo
---
drivers/irqchip/irq-mtk-sysirq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index 90aaf19..282736a 100644
--- a/drivers/irqchip/irq-mtk-sysirq.c
+++ b/drivers/irqchip/irq-mtk-sysirq.c
@@ -81,7 +81,7 @@ static int mtk_sysirq_domain_translate(struct irq_domain *d,
unsigned int *type)
{
if (is_of_node(fwspec->fwnode)) {
- if (fwspec->param_count != 3)
+ if (fwspec->param_count != 3 && fwspec->param_count != 4)
return -EINVAL;
/* No PPI should point to this domain */
@@ -104,7 +104,7 @@ static int mtk_sysirq_domain_alloc(struct irq_domain
*domain, unsigned int virq,
struct irq_fwspec *fwspec = arg;
struct irq_fwspec gic_fwspec = *fwspec;
- if (fwspec->param_count != 3)
+ if (fwspec->param_count != 3 && fwspec->param_count != 4)
return -EINVAL;
/* sysirq doesn't support PPI */
--
1.9.1
[PATCH v6 0/6] Add basic and clock support for Mediatek MT8183 SoC
MT8183 is a SoC based on 64bit ARMv8 architecture. It contains 4 CA53 and 4 CA73 cores. MT8183 share many HW IP with MT65xx series. This patchset was tested on MT8183 evaluation board and use correct clock to shell. This series contains document bindings, device tree including interrupt, uart, clock, pinctrl, spi, and pwrap. Based on v5.0-rc1 and http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016243.html Change in v6: 1. Remove power and iommu nodes 2. Fix dtb build warning 3. Fix pinctrl binding doc 4. Fix '_' in node names Change in v5: 1. Collect all device tree nodes to the last patch 2. Add PMU 3. Add Signed-off-by 4. Remove clock driver code and binding doc 5. Add pinctrl, iommu, spi, and pwrap nodes Change in v4: 1. Correct syntax error in dtsi 2. Add MT8183 clock support Change in v3: 1. Fill out GICC, GICH, GICV regions 2. Update Copyright to 2018 Change in v2: 1. Split dt-bindings into different patches 2. Correct bindings for supported SoCs (mtk-uart.txt) Ben Ho (1): arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile Erin Lo (3): dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183 dt-bindings: serial: Add compatible for Mediatek MT8183 Seiya Wang (1): irqchip/mtk-sysirq: support 4 interrupt parameters for sysirq Zhiyong Tao (1): dt-bindings: pinctrl: mt8183: add binding document Documentation/devicetree/bindings/arm/mediatek.txt |4 + .../interrupt-controller/mediatek,sysirq.txt |1 + .../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 115 ++ .../devicetree/bindings/serial/mtk-uart.txt|1 + arch/arm64/boot/dts/mediatek/Makefile |1 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts| 136 +++ arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h | 1120 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 408 +++ drivers/irqchip/irq-mtk-sysirq.c |4 +- 9 files changed, 1788 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi -- 1.9.1
[PATCH v6 6/6] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: Ben Ho
Add basic chip support for Mediatek 8183, include
pinctrl file, uart node with correct uart clocks, pwrap device
Add clock controller nodes, include topckgen, infracfg,
apmixedsys and subsystem.
Signed-off-by: Ben Ho
Signed-off-by: Erin Lo
Signed-off-by: Seiya Wang
Signed-off-by: Zhiyong Tao
Signed-off-by: Weiyi Lu
Signed-off-by: Mengqi Zhang
Signed-off-by: Hsin-Hsiung Wang
Signed-off-by: Eddie Huang
---
arch/arm64/boot/dts/mediatek/Makefile |1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 136 +++
arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h | 1120 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 408 +
4 files changed, 1665 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index e8f952f..458bbc4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -7,3 +7,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
new file mode 100644
index 000..b12c6ea
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+/dts-v1/;
+#include "mt8183.dtsi"
+
+/ {
+ model = "MediaTek MT8183 evaluation board";
+ compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x8000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+};
+
+&pio {
+ spi_pins_0: spi0{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_1: spi1{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_2: spi2{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_3: spi3{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_4: spi4{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_5: spi5{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_0>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_1>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_2>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_3>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_4>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_5>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
b/arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
new file mode 100644
index 000..768e41e
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
@@ -0,0 +1,1120 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Med
Re: [PATCH] misc: aspeed-lpc-ctrl: Correct return values
On Wed, Jan 23, 2019 at 03:06:34PM -0800, Vijay Khemka wrote:
> Corrected some of return values with appropriate meanings.
>
> Signed-off-by: Vijay Khemka
> ---
> drivers/misc/aspeed-lpc-ctrl.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
> index 332210e06e98..97ae341109d5 100644
> --- a/drivers/misc/aspeed-lpc-ctrl.c
> +++ b/drivers/misc/aspeed-lpc-ctrl.c
> @@ -68,7 +68,6 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> unsigned int cmd,
> unsigned long param)
> {
> struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
> - struct device *dev = file->private_data;
> void __user *p = (void __user *)param;
> struct aspeed_lpc_ctrl_mapping map;
> u32 addr;
> @@ -93,8 +92,8 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> unsigned int cmd,
>
> /* If memory-region is not described in device tree */
> if (!lpc_ctrl->mem_size) {
> - dev_err(dev, "Didn't find reserved memory\n");
> - return -EINVAL;
> + pr_err("aspeed_lpc_ctrl: ioctl: Didn't find reserved
> memory\n");
Why did you change from dev_err() to pr_err()? You just lost a lot of
information that the user previously was getting from dev_err() :(
> + return -ENXIO;
> }
>
> map.size = lpc_ctrl->mem_size;
> @@ -134,16 +133,16 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> unsigned int cmd,
>
> if (map.window_type == ASPEED_LPC_CTRL_WINDOW_FLASH) {
> if (!lpc_ctrl->pnor_size) {
> - dev_err(dev, "Didn't find host pnor flash\n");
> - return -EINVAL;
> + pr_err("aspeed_lpc_ctrl: ioctl: Didn't find
> host pnor flash\n");
Again, don't do that :(
thanks,
greg k-h
[PATCH v6 3/6] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183
This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo Acked-by: Rob Herring --- .../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index 33a98eb..91aa9ab 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -5,6 +5,7 @@ interrupt. Required properties: - compatible: should be + "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183 "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173 "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135 "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127 -- 1.9.1
[PATCH v6 4/6] dt-bindings: serial: Add compatible for Mediatek MT8183
This adds dt-binding documentation of uart for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo Acked-by: Rob Herring --- Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index 742cb47..bcfb131 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -16,6 +16,7 @@ Required properties: * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS + * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS * "mediatek,mt6577-uart" for MT6577 and all of the above - reg: The base address of the UART register bank. -- 1.9.1
[PATCH v6 2/6] dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform
This adds dt-binding documentation of cpu for Mediatek MT8183. Signed-off-by: Erin Lo Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/mediatek.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt index 8f260e5..f6d6ed3 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.txt +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -20,6 +20,7 @@ compatible: Must contain one of "mediatek,mt8127" "mediatek,mt8135" "mediatek,mt8173" + "mediatek,mt8183" Supported boards: @@ -77,3 +78,6 @@ Supported boards: - MTK mt8173 tablet EVB: Required root node properties: - compatible = "mediatek,mt8173-evb", "mediatek,mt8173"; +- Evaluation board for MT8183: +Required root node properties: + - compatible = "mediatek,mt8183-evb", "mediatek,mt8183"; -- 1.9.1
[PATCH v6 5/6] dt-bindings: pinctrl: mt8183: add binding document
From: Zhiyong Tao
The commit adds mt8183 compatible node in binding document.
Signed-off-by: Zhiyong Tao
Signed-off-by: Erin Lo
---
.../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 115 +
1 file changed, 115 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
new file mode 100644
index 000..364e673
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
@@ -0,0 +1,115 @@
+* Mediatek MT8183 Pin Controller
+
+The Mediatek's Pin controller is used to control SoC pins.
+
+Required properties:
+- compatible: value should be one of the following.
+ "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl.
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
+ binding is used, the amount of cells must be specified as 2. See the below
+ mentioned gpio binding representation for description of particular cells.
+- gpio-ranges : gpio valid number range.
+- reg: physicall address base for gpio base registers. There are nine
+ physicall address base in mt8183. They are 0x10005000, 0x11F2,
+ 0x11E8, 0x11E7, 0x11E9, 0x11D3, 0x11D2, 0x11C5,
+ 0x11F3.
+
+ Eg: <&pio 6 0>
+ <[phandle of the gpio controller node]
+ [line number within the gpio controller]
+ [flags]>
+
+ Values for gpio specifier:
+ - Line number: is a value between 0 to 202.
+ - Flags: bit field of flags, as defined in .
+Only the following flags are supported:
+0 - GPIO_ACTIVE_HIGH
+1 - GPIO_ACTIVE_LOW
+
+Optional properties:
+- reg-names: gpio base register names. There are nine gpio base register
+ names in mt8183. They are "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4",
+ "iocfg5", "iocfg6", "iocfg7", "iocfg8".
+- interrupt-controller: Marks the device node as an interrupt controller
+- #interrupt-cells: Should be two.
+- interrupts : The interrupt outputs from the controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+Subnode format
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, pullups, drive strength, input enable/disable and input schmitt.
+
+node {
+ pinmux = ;
+ GENERIC_PINCONFIG;
+};
+
+Required properties:
+- pinmux: integer array, represents gpio pin number and mux setting.
+Supported pin number and mux varies for different SoCs, and are defined
+as macros in boot/dts/-pinfunc.h directly.
+
+Optional properties:
+- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable,
+bias-pull-down, bias-pull-up, input-enable, input-disable, output-low,
output-high,
+input-schmitt-enable, input-schmitt-disable and drive-strength are valid.
+
+Some special pins have extra pull up strength, there are R0 and R1 pull-up
+resistors available, but for user, it's only need to set R1R0 as 00, 01,
10 or 11.
+So when config mediatek,pull-up-adv or mediatek,pull-down-adv,
+it support arguments for those special pins.
+
+When config drive-strength, it can support some arguments, such as
+MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h.
+
+Examples:
+
+#include "mt8183-pinfunc.h"
+
+...
+{
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt8183-pinctrl";
+ reg = <0 0x10005000 0 0x1000>,
+ <0 0x11F2 0 0x1000>,
+ <0 0x11E8 0 0x1000>,
+ <0 0x11E7 0 0x1000>,
+ <0 0x11E9 0 0x1000>,
+ <0 0x11D3 0 0x1000>,
+ <0 0x11D2 0 0x1000>,
+ <0 0x11C5 0 0x1000>,
+ <0 0x11F3 0 0x1000>;
+ reg-names = "iocfg0", "iocfg1", "iocfg2",
+ "iocfg3", "iocfg4", "iocfg5",
+ "iocfg6", "iocfg7", "iocfg8";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 192>;
+ interrupt-controller;
+ interrupts = ;
+ interrupt-parent = <&gic>;
+ #interrupt-cells = <2>;
+
+ i2c0_pins_a: i2c0 {
+ pins1 {
+ pinmux = ,
+;
+ mediatek,pull-up-adv = <11>;
+ };
+ };
+
+ i2c1_pins_a: i2c1 {
+ pins {
+
Re: [PATCH v7 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings
On 24.01.2019 4:40, masonccy...@mxic.com.tw wrote: > > @@ -0,0 +1,46 @@ > > +Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings > > + > > + > > +Required properties: > > +- compatible: should be an SoC-specific compatible value, followed by > > + "renesas,rcar-gen3-rpc" as a fallback, i.e., > > + "renesas,r8a77995-rpc", "renesas,rcar-gen3-rpc". > > + "renesas,r8a7795-rpc" (R-Car H3) > > + "renesas,r8a7796-rpc" (R-Car M3-W) > > + "renesas,r8a77965-rpc" (R-Car M3-N) > > + "renesas,r8a77970-rpc" (R-Car V3M) > > + "renesas,r8a77980-rpc" (R-Car V3H) > > + "renesas,r8a77990-rpc" (R-Car E3) > > + "renesas,r8a77995-rpc" (R-Car D3) > > +- reg: should contain three register areas: > > The driver now handles "dirmap" and "wbuf" resources as optional -- > you need to document that. > Why ? Because the driver treats "dirmap" and "wbuf" as optional resources. [...] best regards, Mason MBR, Sergei
[PATCH V4 4/6] misc/pvpanic: add pvpanic acpi driver
Make pvpanic acpi driver as separate file and modify code
in order to adapt the framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/Kconfig| 13 +++
drivers/misc/pvpanic/Makefile | 1 +
drivers/misc/pvpanic/pvpanic-acpi.c | 77 +
3 files changed, 91 insertions(+)
create mode 100644 drivers/misc/pvpanic/pvpanic-acpi.c
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
index 3e612c6..1dcfe20 100644
--- a/drivers/misc/pvpanic/Kconfig
+++ b/drivers/misc/pvpanic/Kconfig
@@ -5,3 +5,16 @@ config PVPANIC
This driver provides support for the pvpanic device. pvpanic is
a paravirtualized device provided by QEMU; it lets a virtual machine
(guest) communicate panic events to the host.
+
+if PVPANIC
+
+config PVPANIC_ACPI
+ tristate "pvpanic acpi driver"
+ depends on ACPI
+ default PVPANIC
+ help
+ This driver is one specific driver for pvpanic driver framework.
+ It provides an acpi device as pvpanic device.
+
+endif
+
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
index 6394224..c5b73ca 100644
--- a/drivers/misc/pvpanic/Makefile
+++ b/drivers/misc/pvpanic/Makefile
@@ -3,3 +3,4 @@
# Copyright (c) 2018 ZTE Ltd.
obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-$(CONFIG_PVPANIC_ACPI) += pvpanic-acpi.o
diff --git a/drivers/misc/pvpanic/pvpanic-acpi.c
b/drivers/misc/pvpanic/pvpanic-acpi.c
new file mode 100644
index 000..8d10924
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic-acpi.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * pvpanic acpi driver.
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ * Author: Peng Hao
+ */
+#include
+#include
+#include
+#include
+#include "pvpanic.h"
+
+static int pvpanic_add(struct acpi_device *device);
+static int pvpanic_remove(struct acpi_device *device);
+
+static const struct acpi_device_id pvpanic_device_ids[] = {
+ { "QEMU0001", 0 },
+ { "", 0 }
+};
+MODULE_DEVICE_TABLE(acpi, pvpanic_device_ids);
+
+static struct acpi_driver pvpanic_driver = {
+ .name = "pvpanic",
+ .class ="QEMU",
+ .ids = pvpanic_device_ids,
+ .ops = {
+ .add = pvpanic_add,
+ .remove = pvpanic_remove,
+ },
+ .owner =THIS_MODULE,
+};
+
+static acpi_status
+pvpanic_walk_resources(struct acpi_resource *res, void *context)
+{
+ struct resource r;
+ int ret = 0;
+ struct device *dev = context;
+
+ memset(&r, 0, sizeof(r));
+ if (acpi_dev_resource_io(res, &r) || acpi_dev_resource_memory(res, &r))
+ ret = pvpanic_add_device(dev, &r);
+
+ if (!ret)
+ return AE_OK;
+
+ return AE_ERROR;
+}
+static int pvpanic_add(struct acpi_device *device)
+{
+ int ret;
+ acpi_status status;
+
+ ret = acpi_bus_get_status(device);
+ if (ret < 0)
+ return ret;
+
+ if (!device->status.enabled || !device->status.functional)
+ return -ENODEV;
+
+ status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+pvpanic_walk_resources, &device->dev);
+
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+
+ return 0;
+}
+
+static int pvpanic_remove(struct acpi_device *device)
+{
+ pvpanic_remove_device();
+ return 0;
+}
+
+module_acpi_driver(pvpanic_driver);
--
1.8.3.1
[PATCH V4 5/6] misc/pvpanic: add pvpanic mmio driver
Make pvpanic mmio driver as separate file and modify code
in order to adapt the framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/Kconfig | 7 ++
drivers/misc/pvpanic/Makefile | 1 +
drivers/misc/pvpanic/pvpanic-of.c | 53 +++
3 files changed, 61 insertions(+)
create mode 100644 drivers/misc/pvpanic/pvpanic-of.c
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
index 1dcfe20..14074af 100644
--- a/drivers/misc/pvpanic/Kconfig
+++ b/drivers/misc/pvpanic/Kconfig
@@ -16,5 +16,12 @@ config PVPANIC_ACPI
This driver is one specific driver for pvpanic driver framework.
It provides an acpi device as pvpanic device.
+config PVPANIC_OF
+ tristate "pvpanic mmio driver"
+ depends on OF
+ help
+ This driver is one specific driver for pvpanic driver framework.
+ It provides a mmio device as pvpanic device.
+
endif
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
index c5b73ca..63ef0db 100644
--- a/drivers/misc/pvpanic/Makefile
+++ b/drivers/misc/pvpanic/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_PVPANIC_ACPI) += pvpanic-acpi.o
+obj-$(CONFIG_PVPANIC_OF) += pvpanic-of.o
diff --git a/drivers/misc/pvpanic/pvpanic-of.c
b/drivers/misc/pvpanic/pvpanic-of.c
new file mode 100644
index 000..73ca5f3
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic-of.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * pvpanic of driver.
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ * Author: Peng Hao
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pvpanic.h"
+
+static int pvpanic_mmio_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ ret = pvpanic_add_device(&pdev->dev, res);
+ if (ret)
+ return -ENODEV;
+
+ return 0;
+}
+
+static int pvpanic_mmio_remove(struct platform_device *pdev)
+{
+ pvpanic_remove_device();
+ return 0;
+}
+
+static const struct of_device_id pvpanic_mmio_match[] = {
+ { .compatible = "qemu,pvpanic-mmio", },
+ {}
+};
+
+static struct platform_driver pvpanic_mmio_driver = {
+ .driver = {
+ .name = "pvpanic-mmio",
+ .of_match_table = pvpanic_mmio_match,
+ },
+ .probe = pvpanic_mmio_probe,
+ .remove = pvpanic_mmio_remove,
+};
+
+module_platform_driver(pvpanic_mmio_driver);
--
1.8.3.1
[PATCH V4 0/6] add pvpanic driver framework
QEMU community requires additional PCI devices to simulate PVPANIC devices so that some architectures can not occupy precious less than 4G of memory space. Previously, I added PCI driver directly to the original version of the driver, which made the whole driver file look a bit cluttered. So Andy Shevchenko suggests: "I would recommend to split it in a way how it's done for ChipIdea USB driver, for example. (drivers/usb/chipidea if I'm not mistaken)". v3 ---> v4 : add help text info in Konfig from patch_0004 to patch_0006 adjust structure definition position in patch_0002 and patch_0003 v2 ---> v3 : add change infomation. v1 ---> v2 : add patch to descript the whole patch series. modify text infomation from patch_0002 to patch_0006. modify "SPDX-License-Identifier: GPL-2.0-or-later" to "SPDX-License-Identifier: GPL-2.0+" Peng Hao (6): misc/pvpanic: preparing for pvpanic driver framework misc/pvpanic: Add pvpanic driver framework misc/pvpanic: add API for pvpanic driver framework misc/pvpanic: add pvpanic acpi driver misc/pvpanic: add pvpanic mmio driver misc/pvpanic: add new pvpanic pci driver drivers/misc/Kconfig| 9 +- drivers/misc/Makefile | 2 +- drivers/misc/pvpanic.c | 192 drivers/misc/pvpanic/Kconfig| 34 ++ drivers/misc/pvpanic/Makefile | 8 ++ drivers/misc/pvpanic/pvpanic-acpi.c | 77 +++ drivers/misc/pvpanic/pvpanic-of.c | 53 ++ drivers/misc/pvpanic/pvpanic-pci.c | 56 +++ drivers/misc/pvpanic/pvpanic.c | 131 drivers/misc/pvpanic/pvpanic.h | 14 +++ 10 files changed, 366 insertions(+), 201 deletions(-) delete mode 100644 drivers/misc/pvpanic.c create mode 100644 drivers/misc/pvpanic/Kconfig create mode 100644 drivers/misc/pvpanic/Makefile create mode 100644 drivers/misc/pvpanic/pvpanic-acpi.c create mode 100644 drivers/misc/pvpanic/pvpanic-of.c create mode 100644 drivers/misc/pvpanic/pvpanic-pci.c create mode 100644 drivers/misc/pvpanic/pvpanic.c create mode 100644 drivers/misc/pvpanic/pvpanic.h -- 1.8.3.1
[PATCH V4 3/6] misc/pvpanic: add API for pvpanic driver framework
Add pvpanic_add/remove_device API. Follow-up patches will use them to
add/remove specific drivers into framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/pvpanic.c | 47 ++
drivers/misc/pvpanic/pvpanic.h | 15 ++
2 files changed, 58 insertions(+), 4 deletions(-)
create mode 100644 drivers/misc/pvpanic/pvpanic.h
diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
index f44a884..6225dfb 100644
--- a/drivers/misc/pvpanic/pvpanic.c
+++ b/drivers/misc/pvpanic/pvpanic.c
@@ -14,7 +14,11 @@
#include
#include
-static void __iomem *base;
+static struct {
+ struct platform_device *pdev;
+ void __iomem *base;
+ bool is_ioport;
+} pvpanic_data;
#define PVPANIC_PANICKED(1 << 0)
@@ -25,7 +29,7 @@
static void
pvpanic_send_event(unsigned int event)
{
- iowrite8(event, base);
+ iowrite8(event, pvpanic_data.base);
}
static int
@@ -41,10 +45,43 @@
.priority = 1, /* let this called before broken drm_fb_helper */
};
+int pvpanic_add_device(struct device *dev, struct resource *res)
+{
+ struct platform_device *pdev;
+ int ret;
+
+ pdev = platform_device_alloc("pvpanic", -1);
+ if (!pdev)
+ return -ENOMEM;
+
+ pdev->dev.parent = dev;
+
+ ret = platform_device_add_resources(pdev, res, 1);
+ if (ret)
+ goto err;
+
+ ret = platform_device_add(pdev);
+ if (ret)
+ goto err;
+ pvpanic_data.pdev = pdev;
+
+ return 0;
+err:
+ platform_device_put(pdev);
+ return -1;
+}
+
+void pvpanic_remove_device(void)
+{
+ platform_device_unregister(pvpanic_data.pdev);
+ pvpanic_data.pdev = NULL;
+}
+
static int pvpanic_platform_probe (struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct resource *res;
+ void __iomem *base;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res) {
@@ -59,8 +96,10 @@ static int pvpanic_platform_probe (struct platform_device
*pdev)
base = ioport_map(res->start, resource_size(res));
if (!base)
return -ENODEV;
+ pvpanic_data.is_ioport = true;
}
+ pvpanic_data.base = base;
atomic_notifier_chain_register(&panic_notifier_list,
&pvpanic_panic_nb);
@@ -71,8 +110,8 @@ static int pvpanic_platform_remove(struct platform_device
*pdev)
{
atomic_notifier_chain_unregister(&panic_notifier_list,
&pvpanic_panic_nb);
-
- iounmap(base);
+ if (pvpanic_data.is_ioport)
+ iounmap(pvpanic_data.base);
return 0;
}
diff --git a/drivers/misc/pvpanic/pvpanic.h b/drivers/misc/pvpanic/pvpanic.h
new file mode 100644
index 000..7fb6bb2
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* pvpanic driver framework header file
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ *
+ * Author: Peng Hao
+ */
+
+#ifndef __DRIVERS_MISC_PVPANIC_H
+#define __DRIVERS_MISC_PVPANIC_H
+
+extern int pvpanic_add_device(struct device *dev, struct resource *res);
+extern void pvpanic_remove_device(void);
+
+#endif
--
1.8.3.1
[PATCH V4 1/6] misc/pvpanic: preparing for pvpanic driver framework
Preparing for pvpanic driver framework. Create a pvpanic driver
directory and move current driver file to new directory.
Signed-off-by: Peng Hao
---
drivers/misc/Kconfig | 9 +
drivers/misc/Makefile| 2 +-
drivers/misc/pvpanic/Kconfig | 7 +++
drivers/misc/pvpanic/Makefile| 5 +
drivers/misc/{ => pvpanic}/pvpanic.c | 0
5 files changed, 14 insertions(+), 9 deletions(-)
create mode 100644 drivers/misc/pvpanic/Kconfig
create mode 100644 drivers/misc/pvpanic/Makefile
rename drivers/misc/{ => pvpanic}/pvpanic.c (100%)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f417b06..aa3a805 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -513,14 +513,7 @@ config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
-config PVPANIC
- tristate "pvpanic device support"
- depends on HAS_IOMEM && (ACPI || OF)
- help
- This driver provides support for the pvpanic device. pvpanic is
- a paravirtualized device provided by QEMU; it lets a virtual machine
- (guest) communicate panic events to the host.
-
+source "drivers/misc/pvpanic/Kconfig"
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e39ccbb..cfe20b3 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -58,4 +58,4 @@ obj-$(CONFIG_ASPEED_LPC_SNOOP)+= aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
obj-y += cardreader/
-obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-$(CONFIG_PVPANIC) += pvpanic/
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
new file mode 100644
index 000..3e612c6
--- /dev/null
+++ b/drivers/misc/pvpanic/Kconfig
@@ -0,0 +1,7 @@
+config PVPANIC
+ tristate "pvpanic device support"
+ depends on HAS_IOMEM && (ACPI || OF)
+ help
+ This driver provides support for the pvpanic device. pvpanic is
+ a paravirtualized device provided by QEMU; it lets a virtual machine
+ (guest) communicate panic events to the host.
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
new file mode 100644
index 000..6394224
--- /dev/null
+++ b/drivers/misc/pvpanic/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (c) 2018 ZTE Ltd.
+
+obj-$(CONFIG_PVPANIC) += pvpanic.o
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
similarity index 100%
rename from drivers/misc/pvpanic.c
rename to drivers/misc/pvpanic/pvpanic.c
--
1.8.3.1
[PATCH V4 6/6] misc/pvpanic: add new pvpanic pci driver
Add new pvpanic pci driver to pvpanic driver framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/Kconfig | 10 ++-
drivers/misc/pvpanic/Makefile | 1 +
drivers/misc/pvpanic/pvpanic-pci.c | 56 ++
3 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/pvpanic/pvpanic-pci.c
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
index 14074af..f24c488 100644
--- a/drivers/misc/pvpanic/Kconfig
+++ b/drivers/misc/pvpanic/Kconfig
@@ -1,6 +1,6 @@
config PVPANIC
tristate "pvpanic device support"
- depends on HAS_IOMEM && (ACPI || OF)
+ depends on HAS_IOMEM && (ACPI || OF || PCI)
help
This driver provides support for the pvpanic device. pvpanic is
a paravirtualized device provided by QEMU; it lets a virtual machine
@@ -23,5 +23,13 @@ config PVPANIC_OF
This driver is one specific driver for pvpanic driver framework.
It provides a mmio device as pvpanic device.
+config PVPANIC_PCI
+ tristate "pvpanic pci driver"
+ depends on PCI
+ default PVPANIC
+ help
+ This driver is one specific driver for pvpanic driver framework.
+ It provides a pci device as pvpanic device.
+
endif
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
index 63ef0db..7c71f85 100644
--- a/drivers/misc/pvpanic/Makefile
+++ b/drivers/misc/pvpanic/Makefile
@@ -5,3 +5,4 @@
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_PVPANIC_ACPI) += pvpanic-acpi.o
obj-$(CONFIG_PVPANIC_OF) += pvpanic-of.o
+obj-$(CONFIG_PVPANIC_PCI) += pvpanic-pci.o
diff --git a/drivers/misc/pvpanic/pvpanic-pci.c
b/drivers/misc/pvpanic/pvpanic-pci.c
new file mode 100644
index 000..1261710
--- /dev/null
+++ b/drivers/misc/pvpanic/pvpanic-pci.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * pvpanic acpi driver.
+ *
+ * Copyright (C) 2019 ZTE Ltd.
+ * Author: Peng Hao
+ */
+
+#include
+#include
+#include
+#include
+#include "pvpanic.h"
+
+#define PCI_VENDOR_ID_REDHAT 0x1b36
+#define PCI_DEVICE_ID_REDHAT_PVPANIC 0x0101
+
+static const struct pci_device_id pvpanic_pci_id_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PVPANIC),},
+ {}
+};
+
+static int pvpanic_pci_probe(struct pci_dev *pdev,
+const struct pci_device_id *ent)
+{
+ int ret;
+ struct resource res;
+
+ ret = pcim_enable_device(pdev);
+ if (ret < 0)
+ return ret;
+
+ memset(&res, 0, sizeof(res));
+ res.start = pci_resource_start(pdev, 0);
+ res.end = pci_resource_end(pdev, 0);
+ res.flags = IORESOURCE_MEM;
+ ret = pvpanic_add_device(&pdev->dev, &res);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static void pvpanic_pci_remove(struct pci_dev *pdev)
+{
+ pvpanic_remove_device();
+}
+
+static struct pci_driver pvpanic_pci_driver = {
+ .name = "pvpanic-pci",
+ .id_table = pvpanic_pci_id_tbl,
+ .probe =pvpanic_pci_probe,
+ .remove = pvpanic_pci_remove,
+};
+
+module_pci_driver(pvpanic_pci_driver);
--
1.8.3.1
[PATCH V4 2/6] misc/pvpanic: Add pvpanic driver framework
Add pvpanic driver framework. Follow-up patches will split the original
pvpanic acpi/of driver as the two separate files and modify code to
adapt the framework.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic/pvpanic.c | 158 +++--
1 file changed, 27 insertions(+), 131 deletions(-)
diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
index 595ac06..f44a884 100644
--- a/drivers/misc/pvpanic/pvpanic.c
+++ b/drivers/misc/pvpanic/pvpanic.c
@@ -8,11 +8,9 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include
+#include
#include
#include
-#include
-#include
#include
#include
@@ -43,59 +41,25 @@
.priority = 1, /* let this called before broken drm_fb_helper */
};
-#ifdef CONFIG_ACPI
-static int pvpanic_add(struct acpi_device *device);
-static int pvpanic_remove(struct acpi_device *device);
-
-static const struct acpi_device_id pvpanic_device_ids[] = {
- { "QEMU0001", 0 },
- { "", 0 }
-};
-MODULE_DEVICE_TABLE(acpi, pvpanic_device_ids);
-
-static struct acpi_driver pvpanic_driver = {
- .name = "pvpanic",
- .class ="QEMU",
- .ids = pvpanic_device_ids,
- .ops = {
- .add = pvpanic_add,
- .remove = pvpanic_remove,
- },
- .owner =THIS_MODULE,
-};
-
-static acpi_status
-pvpanic_walk_resources(struct acpi_resource *res, void *context)
+static int pvpanic_platform_probe(struct platform_device *pdev)
{
- struct resource r;
-
- if (acpi_dev_resource_io(res, &r)) {
- base = ioport_map(r.start, resource_size(&r));
- return AE_OK;
- } else if (acpi_dev_resource_memory(res, &r)) {
- base = ioremap(r.start, resource_size(&r));
- return AE_OK;
- }
-
- return AE_ERROR;
-}
-
-static int pvpanic_add(struct acpi_device *device)
-{
- int ret;
-
- ret = acpi_bus_get_status(device);
- if (ret < 0)
- return ret;
-
- if (!device->status.enabled || !device->status.functional)
- return -ENODEV;
-
- acpi_walk_resources(device->handle, METHOD_NAME__CRS,
- pvpanic_walk_resources, NULL);
-
- if (!base)
- return -ENODEV;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res) {
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return -ENODEV;
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (!res)
+ return -ENODEV;
+
+ base = ioport_map(res->start, resource_size(res));
+ if (!base)
+ return -ENODEV;
+ }
atomic_notifier_chain_register(&panic_notifier_list,
&pvpanic_panic_nb);
@@ -103,90 +67,22 @@ static int pvpanic_add(struct acpi_device *device)
return 0;
}
-static int pvpanic_remove(struct acpi_device *device)
+static int pvpanic_platform_remove(struct platform_device *pdev)
{
-
atomic_notifier_chain_unregister(&panic_notifier_list,
&pvpanic_panic_nb);
- iounmap(base);
-
- return 0;
-}
-
-static int pvpanic_register_acpi_driver(void)
-{
- return acpi_bus_register_driver(&pvpanic_driver);
-}
-
-static void pvpanic_unregister_acpi_driver(void)
-{
- acpi_bus_unregister_driver(&pvpanic_driver);
-}
-#else
-static int pvpanic_register_acpi_driver(void)
-{
- return -ENODEV;
-}
-static void pvpanic_unregister_acpi_driver(void) {}
-#endif
-
-static int pvpanic_mmio_probe(struct platform_device *pdev)
-{
- struct resource *mem;
-
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem)
- return -EINVAL;
-
- base = devm_ioremap_resource(&pdev->dev, mem);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- atomic_notifier_chain_register(&panic_notifier_list,
- &pvpanic_panic_nb);
-
- return 0;
-}
-
-static int pvpanic_mmio_remove(struct platform_device *pdev)
-{
-
- atomic_notifier_chain_unregister(&panic_notifier_list,
-&pvpanic_panic_nb);
+ iounmap(base);
return 0;
}
-static const struct of_device_id pvpanic_mmio_match[] = {
- { .compatible = "qemu,pvpanic-mmio", },
- {}
-};
-
-static struct platform_driver pvpanic_mmio_driver = {
+static struct platform_driver pvpanic_driver = {
+ .probe = pvpanic_platform_probe,
+ .remove = pvpanic_platform_remove,
.driver = {
- .name = "pvpanic-mmio",
- .of_match_table = pvpanic_mmio_match,
-
[PATCH 1/5] Documentation/kr: Update Korean translation to delete reference to the kernel-mentors mailing list
Translate this commit to Korean:
bc0ef4a7e4c3 ("Documentation: Delete reference to the kernel-mentors mailing
list")
Signed-off-by: SeongJae Park
---
Documentation/translations/ko_KR/howto.rst | 7 ---
1 file changed, 7 deletions(-)
diff --git a/Documentation/translations/ko_KR/howto.rst
b/Documentation/translations/ko_KR/howto.rst
index a8197e0..c8b0612 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -220,13 +220,6 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된
가지고 있지 않다면 다음에 무엇을 해야할지에 관한 방향을 배울 수 있을
것이다.
-여러분들이 이미 커널 트리에 반영하길 원하는 코드 묶음을 가지고 있지만
-올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해
-만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
-다음에서 참조할 수 있다.
-
- https://selenic.com/mailman/listinfo/kernel-mentors
-
리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의
도움을 빌려서라도 코드를 직접 읽는 것보다 좋은 것은 없다(대부분의
--
2.10.0
[PATCH 2/5] Documentation/process/howto/kr: Update Korean translation to remove outdated info about bugzilla mailing lists
Translate this commit to Korean:
bcd3cf0855c5 ("Documentation/process/howto: Remove outdated info about
bugzilla mailing lists")
Signed-off-by: SeongJae Park
---
Documentation/translations/ko_KR/howto.rst | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/Documentation/translations/ko_KR/howto.rst
b/Documentation/translations/ko_KR/howto.rst
index c8b0612..e88c426 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -370,15 +370,7 @@ https://bugzilla.kernel.org 는 리눅스 커널 개발자들이 커널의 버
다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org
-를 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
-bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
-bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
-에 등록하면 된다.
-
- https://lists.linux-foundation.org/mailman/listinfo/bugme-new
-
- https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
-
+를 참조하라.
메일링 리스트들
--
2.10.0
[PATCH 4/5] docs/kokr: Update Korean translation to tidy up TOCs and refs to license-rules.rst
Transalte this commit to Korean:
9799445af124 ("docs: tidy up TOCs and refs to license-rules.rst")
Signed-off-by: SeongJae Park
---
Documentation/translations/ko_KR/howto.rst | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/translations/ko_KR/howto.rst
b/Documentation/translations/ko_KR/howto.rst
index bda7a4f..cfd6a42 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -77,10 +77,12 @@ Documentation/process/howto.rst
리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인
디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는
-파일을 봐라. 여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면
-리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링
-리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여
-그들의 말에 의지해서는 안된다.
+파일을 봐라. 리눅스 커널 라이센싱 규칙과 소스 코드 안의 `SPDX
+
[PATCH 5/5] doc:process:kokr: Update Korean translation to add links where missing
Translate this commit to Korean:
f77af637f29d ("doc:process: add links where missing")
Signed-off-by: SeongJae Park
---
Documentation/translations/ko_KR/howto.rst | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/translations/ko_KR/howto.rst
b/Documentation/translations/ko_KR/howto.rst
index cfd6a42..1525243 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -298,9 +298,9 @@ Andrew Morton의 글이 있다.
4.x.y는 "stable" 팀에 의해 관리되며 거의 매번 격주로
배포된다.
-커널 트리 문서들 내에 Documentation/process/stable-kernel-rules.rst 파일은 어떤
-종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게
-진행되는지를 설명한다.
+커널 트리 문서들 내의 :ref:`Documentation/process/stable-kernel-rules.rst
`
+파일은 어떤 종류의 변경들이 -stable 트리로 들어왔는지와
+배포 프로세스가 어떻게 진행되는지를 설명한다.
4.x -git 패치들
~~~
@@ -355,9 +355,10 @@ https://bugzilla.kernel.org 는 리눅스 커널 개발자들이 커널의 버
https://bugzilla.kernel.org/page.cgi?id=faq.html
-메인 커널 소스 디렉토리에 있는 admin-guide/reporting-bugs.rst 파일은 커널 버그라고 생각되는
-것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널
-개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다.
+메인 커널 소스 디렉토리에 있는 :ref:`admin-guide/reporting-bugs.rst `
+파일은 커널 버그라고 생각되는 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를
+추적하기 위해서 커널 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고
+있다.
버그 리포트들의 관리
@@ -417,7 +418,8 @@ https://bugzilla.kernel.org 는 리눅스 커널 개발자들이 커널의 버
"John 커널해커는 작성했다"를 유지하며 여러분들의 의견을 그 메일의 윗부분에
작성하지 말고 각 인용한 단락들 사이에 넣어라.
-여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/process/submitting-patches.rst에
+여러분들이 패치들을 메일에 넣는다면 그것들은
+:ref:`Documentation/process/submitting-patches.rst ` 에
나와있는데로 명백히(plain) 읽을 수 있는 텍스트여야 한다. 커널 개발자들은
첨부파일이나 압축된 패치들을 원하지 않는다. 그들은 여러분들의 패치의
각 라인 단위로 코멘트를 하길 원하며 압축하거나 첨부하지 않고 보내는 것이
--
2.10.0
[PATCH 3/5] Documentation/process/howto.rst/kokr: Update Korean translation to add a missing cross-reference
Translate this commit to Korean:
dad051395413 ("Documentation/process/howto.rst: add a missing
cross-reference")
Signed-off-by: SeongJae Park
---
Documentation/translations/ko_KR/howto.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/translations/ko_KR/howto.rst
b/Documentation/translations/ko_KR/howto.rst
index e88c426..bda7a4f 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -99,7 +99,7 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.
- README
+ :ref:`Documentation/admin-guide/README.rst `
이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고
빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
시작해야 한다.
--
2.10.0
Re: [PATCH 2/2] mm: Consider subtrees in memory.events
On Wed 23-01-19 17:31:44, Chris Down wrote: > memory.stat and other files already consider subtrees in their output, > and we should too in order to not present an inconsistent interface. > > The current situation is fairly confusing, because people interacting > with cgroups expect hierarchical behaviour in the vein of memory.stat, > cgroup.events, and other files. For example, this causes confusion when > debugging reclaim events under low, as currently these always read "0" > at non-leaf memcg nodes, which frequently causes people to misdiagnose > breach behaviour. The same confusion applies to other counters in this > file when debugging issues. > > Aggregation is done at write time instead of at read-time since these > counters aren't hot (unlike memory.stat which is per-page, so it does it > at read time), and it makes sense to bundle this with the file > notifications. I do not think we can do that for two reasons. It breaks the existing semantic userspace might depend on and more importantly this is not a correct behavior IMO. You have to realize that stats are hierarchical because that is how we account. Events represent a way to inform that something has happened at the specific level of the tree though. If you do not setup low/high/max limit then you simply cannot expect to be informed those get hit because they cannot by definition. Or put it other way, if you are waiting for those events you really want to know the (sub)tree they happened and if you propagate the event up the hierarchy you have hard time to tell that (you would basically have to exclude all but the lowest one and that is an awkward semantic at best. Maybe we want to document this better but I do not see we are going to change the behavior. > Acked-by: Johannes Weiner btw. I do not see this patch posted anywhere yet it already comes with an ack. Have I just missed a previous version? -- Michal Hocko SUSE Labs
Re: [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
On Wed, Jan 23, 2019 at 10:28:13PM +0100, Christoph Hellwig wrote: > On Wed, Jan 23, 2019 at 05:30:45PM +0100, Joerg Roedel wrote: > > +extern size_t swiotlb_max_mapping_size(struct device *dev); > > No need for the extern keyword on function declarations in headers. Right, but all other function declarations in that header file have 'extern' too, so I added it also for that one. Regards, Joerg
Re: LTP case read_all_proc fails on qemux86-64 since 5.0-rc1
On 1/24/19 12:05 AM, Jens Axboe wrote: > On 1/22/19 8:39 PM, Jens Axboe wrote: >> On Jan 22, 2019, at 8:13 PM, He Zhe wrote: >>> LTP case read_all_proc(read_all -d /proc -q -r 10) often, but not every >>> time, fails with the following call traces, since 600335205b8d "ide: >>> convert to blk-mq"(5.0-rc1) till now(5.0-rc3). >>> >>> qemu-system-x86_64 -drive file=rootfs.ext4,if=virtio,format=raw -object >>> rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 >>> -nographic -m 16192 -smp cpus=12 -cpu core2duo -enable-kvm -serial >>> mon:stdio -serial null -kernel bzImage -append 'root=/dev/vda rw >>> highres=off console=ttyS0 mem=16192M' >>> >>> tst_test.c:1085: INFO: Timeout per run is 0h 05m 00s >>> [ 47.080156] Warning: /proc/ide/hd?/settings interface is obsolete, and >>> will be removed soon! >>> [ 47.085330] [ cut here ] >>> [ 47.085810] kernel BUG at block/blk-mq.c:767! >>> [ 47.086498] invalid opcode: [#1] PREEMPT SMP PTI >>> [ 47.087022] CPU: 5 PID: 146 Comm: kworker/5:1H Not tainted 5.0.0-rc3 #1 >>> [ 47.087858] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >>> rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 >>> [ 47.088992] Workqueue: kblockd blk_mq_run_work_fn >>> [ 47.089469] RIP: 0010:blk_mq_add_to_requeue_list+0xc1/0xd0 >>> [ 47.090035] Code: 48 8d 53 48 49 8b 8c 24 b8 04 00 00 48 89 51 08 48 89 >>> 4b 48 49 8d 8c 24 b8 04 00 00 48 89 4b 50 49 89 94 24 b8 04 00 008 >>> [ 47.091930] RSP: 0018:9e1ea4b43e40 EFLAGS: 00010002 >>> [ 47.092458] RAX: 9e1ea13c0048 RBX: 9e1ea13c RCX: >>> 0006 >>> [ 47.093181] RDX: RSI: 0001 RDI: >>> 9e1ea13c >>> [ 47.093906] RBP: 9e1ea4b43e68 R08: eb5bcf630680 R09: >>> >>> [ 47.094626] R10: 0001 R11: 0012 R12: >>> 9e1ea1033a40 >>> [ 47.095347] R13: 9e1ea13a8d00 R14: 9e1ea13a9000 R15: >>> 0046 >>> [ 47.096071] FS: () GS:9e1ea4b4() >>> knlGS: >>> [ 47.096898] CS: 0010 DS: ES: CR0: 80050033 >>> [ 47.097477] CR2: 003fda41fda0 CR3: 0003d8e6a000 CR4: >>> 06e0 >>> [ 47.098203] DR0: DR1: DR2: >>> >>> [ 47.098929] DR3: DR6: fffe0ff0 DR7: >>> 0400 >>> [ 47.099650] Call Trace: >>> [ 47.099910] >>> [ 47.100128] blk_mq_requeue_request+0x58/0x60 >>> [ 47.100576] ide_requeue_and_plug+0x20/0x50 >>> [ 47.101014] ide_intr+0x21a/0x230 >>> [ 47.101362] ? idecd_open+0xc0/0xc0 >>> [ 47.101735] __handle_irq_event_percpu+0x43/0x1e0 >>> [ 47.102214] handle_irq_event_percpu+0x32/0x80 >>> [ 47.102668] handle_irq_event+0x39/0x60 >>> [ 47.103074] handle_edge_irq+0xe8/0x1c0 >>> [ 47.103470] handle_irq+0x20/0x30 >>> [ 47.103819] do_IRQ+0x46/0xe0 >>> [ 47.104128] common_interrupt+0xf/0xf >>> [ 47.104505] >>> [ 47.104731] RIP: 0010:ide_output_data+0xbc/0x100 >>> [ 47.105201] Code: 74 22 8d 41 ff 85 c9 74 24 49 8d 54 40 02 41 0f b7 00 >>> 66 41 89 01 49 83 c0 02 49 39 d0 75 ef 5b 41 5c 5d c3 4c 89 c6 445 >>> [ 47.107092] RSP: 0018:bd508059bb18 EFLAGS: 00010246 ORIG_RAX: >>> ffdd >>> [ 47.107862] RAX: 9e1ea13a8800 RBX: 9e1ea13a9000 RCX: >>> >>> [ 47.108581] RDX: 0170 RSI: 9e1ea13c012c RDI: >>> >>> [ 47.109293] RBP: bd508059bb28 R08: 9e1ea13c0120 R09: >>> 0170 >>> [ 47.110016] R10: 000d R11: 000c R12: >>> 9e1ea13a8800 >>> [ 47.110731] R13: 000c R14: 9e1ea13c R15: >>> 7530 >>> [ 47.111446] ide_transfer_pc+0x216/0x310 >>> [ 47.111848] ? __const_udelay+0x3d/0x40 >>> [ 47.112236] ? ide_execute_command+0x85/0xb0 >>> [ 47.112668] ? ide_pc_intr+0x3f0/0x3f0 >>> [ 47.113051] ? ide_check_atapi_device+0x110/0x110 >>> [ 47.113524] ide_issue_pc+0x178/0x240 >>> [ 47.113901] ide_cd_do_request+0x15c/0x350 >>> [ 47.114314] ide_queue_rq+0x180/0x6b0 >>> [ 47.114686] ? blk_mq_get_driver_tag+0xa1/0x110 >>> [ 47.115153] blk_mq_dispatch_rq_list+0x90/0x550 >>> [ 47.115606] ? __queue_delayed_work+0x63/0x90 >>> [ 47.116054] ? deadline_fifo_request+0x41/0x90 >>> [ 47.116506] blk_mq_do_dispatch_sched+0x80/0x100 >>> [ 47.116976] blk_mq_sched_dispatch_requests+0xfc/0x170 >>> [ 47.117491] __blk_mq_run_hw_queue+0x6f/0xd0 >>> [ 47.117941] blk_mq_run_work_fn+0x1b/0x20 >>> [ 47.118342] process_one_work+0x14c/0x450 >>> [ 47.118747] worker_thread+0x4a/0x440 >>> [ 47.119125] kthread+0x105/0x140 >>> [ 47.119456] ? process_one_work+0x450/0x450 >>> [ 47.119880] ? kthread_park+0x90/0x90 >>> [ 47.120251] ret_from_fork+0x35/0x40 >>> [ 47.120619] Modules linked in: >>> [ 47.120952] ---[ end trace 4562f716e88fdefe ]--- >>> [ 47
[PATCH v2] drm/bridge: sil_sii8620: make remote control optional.
commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
of RC_CORE) changed the driver to select both RC_CORE and INPUT.
However, this causes problems with other drivers, in particular an input
driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate
commit):
drivers/clk/Kconfig:9:error: recursive dependency detected!
drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS
drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by
MFD_INTEL_LPSS_PCI
drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by
KEYBOARD_APPLESPI
drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on
INPUT
drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620
drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on
DRM_BRIDGE
drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by
DRM_PL111
drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK
According to the docs and general consensus, select should only be used
for non user-visible symbols, but both RC_CORE and INPUT are
user-visible. Furthermore almost all other references to INPUT
throughout the kernel config are depends, not selects. For this reason
the first part of this change reverts commit d6abe6df706c.
In order to address the original reason for commit d6abe6df706c, namely
that not all boards use the remote controller functionality and hence
should not need have to deal with RC_CORE, the second part of this
change now makes the remote control support in the driver optional and
contingent on RC_CORE being defined. And with this the hard dependency
on INPUT also goes away as that is only needed if RC_CORE is defined
(which in turn already depends on INPUT).
CC: Inki Dae
CC: Andrzej Hajda
CC: Laurent Pinchart
CC: Dmitry Torokhov
Signed-off-by: Ronald Tschalär
---
Changes in v2:
- completely remove dependencies on both RC_CORE and INPUT in Kconfig,
- make remote control functionality in driver contingent on RC_CORE
being defined
drivers/gpu/drm/bridge/Kconfig | 2 --
drivers/gpu/drm/bridge/sil-sii8620.c | 17 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..a11198a36005 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -85,8 +85,6 @@ config DRM_SIL_SII8620
depends on OF
select DRM_KMS_HELPER
imply EXTCON
- select INPUT
- select RC_CORE
help
Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 0cc293a6ac24..dee47752791e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -66,7 +66,9 @@ enum sii8620_mt_state {
struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+#if IS_ENABLED(CONFIG_RC_CORE)
struct rc_dev *rc_dev;
+#endif
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -1756,6 +1758,7 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
{
bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
@@ -1774,6 +1777,12 @@ static bool sii8620_rcp_consume(struct sii8620 *ctx, u8
scancode)
return true;
}
+#else
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
+{
+ return false;
+}
+#endif
static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
{
@@ -2097,6 +2106,7 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
{
struct rc_dev *rc_dev;
@@ -2126,6 +2136,11 @@ static void sii8620_init_rcp_input_dev(struct sii8620
*ctx)
}
ctx->rc_dev = rc_dev;
}
+#else
+static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
+{
+}
+#endif
static void sii8620_cable_out(struct sii8620 *ctx)
{
@@ -2214,9 +2229,11 @@ static int sii8620_attach(struct drm_bridge *bridge)
static void sii8620_detach(struct drm_bridge *bridge)
{
+#if IS_ENABLED(CONFIG_RC_CORE)
struct sii8620 *ctx = bridge_to_sii8620(bridge);
rc_unregister_device(ctx->rc_dev);
+#endif
}
static int sii8620_is_packing_required(struct sii8620 *ctx,
--
2.20.1
Re: [PATCH] arm64: dts: zcu100-revC: Give wifi some time after power-on
On Thu, 24 Jan 2019 at 08:54, Jan Kiszka wrote:
>
> From: Jan Kiszka
>
> Somewhere along recent changes to power control of the wl1835, power-on
> became very unreliable on the hikey, failing like this:
>
> wl1271_sdio: probe of mmc2:0001:1 failed with error -16
> wl1271_sdio: probe of mmc2:0001:2 failed with error -16
>
> After playing with some dt parameters and comparing to other users of
> this chip, it turned out we need some power-on delay to make things
> stable again. In contrast to those other users which define 200 ms,
> Ultra96 is already happy with 10 ms.
This changelog is talking about Hikey, while you do a fix a for the
zynqmp platform. Please rewords this accordingly.
>
> Fixes: ea452678734e ("arm64: dts: hikey: Fix WiFi support")
This is not the correct commit. Please change to:
Fixes: 5869ba0653b9 ("arm64: zynqmp: Add support for Xilinx zcu100-revC")
> Signed-off-by: Jan Kiszka
> Acked-by: Ulf Hansson
> ---
> arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> index 13a0a028df98..e5699d0d91e4 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> @@ -101,6 +101,7 @@
> sdio_pwrseq: sdio-pwrseq {
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <&gpio 7 GPIO_ACTIVE_LOW>; /* WIFI_EN */
> + post-power-on-delay-ms = <10>;
> };
> };
Kind regards
Uffe
Re: [PATCH] input: Fix the CONFIG_SPARC64 mixup
On Sun, Jan 20, 2019 at 05:49:14PM -0800, Deepa Dinamani wrote:
> Arnd Bergmann pointed out that CONFIG_* cannot be used
> in a uapi header. Override with an equivalent conditional.
>
> Fixes: 2e746942ebac ("Input: input_event - provide override for sparc64")
> Fixes: 152194fe9c3f ("Input: extend usable life of event timestamps to 2106
> on 32 bit systems")
> Signed-off-by: Deepa Dinamani
Applied, thank you.
> ---
> include/uapi/linux/input.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index ffab958bc512..f056b2a00d5c 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -32,7 +32,7 @@ struct input_event {
> #define input_event_usec time.tv_usec
> #else
> __kernel_ulong_t __sec;
> -#ifdef CONFIG_SPARC64
> +#if defined(__sparc__) && defined(__arch64__)
> unsigned int __usec;
> #else
> __kernel_ulong_t __usec;
> --
> 2.17.1
>
--
Dmitry
[PATCH v2] arm64: dts: zcu100-revC: Give wifi some time after power-on
From: Jan Kiszka
Somewhere along recent changes to power control of the wl1831, power-on
became very unreliable on the Ultra96, failing like this:
wl1271_sdio: probe of mmc2:0001:1 failed with error -16
wl1271_sdio: probe of mmc2:0001:2 failed with error -16
After playing with some dt parameters and comparing to other users of
this chip, it turned out we need some power-on delay to make things
stable again. In contrast to those other users which define 200 ms,
Ultra96 is already happy with 10 ms.
Fixes: 5869ba0653b9 ("arm64: zynqmp: Add support for Xilinx zcu100-revC")
Signed-off-by: Jan Kiszka
Acked-by: Ulf Hansson
---
Changes in v2:
- fix changelog
arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
index 13a0a028df98..e5699d0d91e4 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
@@ -101,6 +101,7 @@
sdio_pwrseq: sdio-pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpio 7 GPIO_ACTIVE_LOW>; /* WIFI_EN */
+ post-power-on-delay-ms = <10>;
};
};
--
2.16.4
Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
On Wed, Jan 23, 2019 at 10:27:55PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:46PM +0100, Joerg Roedel wrote:
> > +bool is_swiotlb_active(void)
> > +{
> > + return !no_iotlb_memory;
> > +}
>
> As I've just introduced and fixed a bug in this area in the current
> cycle - I don't think no_iotlb_memory is what your want (and maybe
> not useful at all): if the arch valls swiotlb_exit after previously
> initializing a buffer it won't be set. You probably want to check
> for non-zero io_tlb_start and/or io_tlb_end.
Okay, but that requires that I also set io_tlb_start and friends back to
zero in the failure path of swiotlb_init(). Otherwise it could be left
non-zero in case swiotlb_init_with_tbl() returns an error.
Regards,
Joerg
[PATCH v3 1/3] dt-bindings: PCI: dra7xx: Add SoC specific compatible strings
Add new compatible strings for dra74x SoC (also used by dra76x) and dra72x. This can be used to perform SoC specific configuration (like configuring PCIe in x2 lane mode). Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sekhar Nori Acked-by: Rob Herring --- Documentation/devicetree/bindings/pci/ti-pci.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt index 452fe48c4fdd..e03d23631f5b 100644 --- a/Documentation/devicetree/bindings/pci/ti-pci.txt +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -1,8 +1,12 @@ TI PCI Controllers PCIe DesignWare Controller - - compatible: Should be "ti,dra7-pcie" for RC - Should be "ti,dra7-pcie-ep" for EP + - compatible: Should be "ti,dra7-pcie" for RC (deprecated) + Should be "ti,dra7-pcie-ep" for EP (deprecated) + Should be "ti,dra746-pcie-rc" for dra74x/dra76 in RC mode + Should be "ti,dra746-pcie-ep" for dra74x/dra76 in EP mode + Should be "ti,dra726-pcie-rc" for dra72x in RC mode + Should be "ti,dra726-pcie-ep" for dra72x in EP mode - phys : list of PHY specifiers (used by generic PHY framework) - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the number of PHYs as specified in *phys* property. -- 2.17.1
[PATCH v3 2/3] dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
Add syscon properties required for configuring PCIe in x2 lane mode. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sekhar Nori --- Documentation/devicetree/bindings/pci/ti-pci.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt index e03d23631f5b..d5cbfe6b0d89 100644 --- a/Documentation/devicetree/bindings/pci/ti-pci.txt +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -13,6 +13,9 @@ PCIe DesignWare Controller - ti,hwmods : Name of the hwmod associated to the pcie, "pcie", where is the instance number of the pcie from the HW spec. - num-lanes as specified in ../designware-pcie.txt + - ti,syscon-lane-sel : phandle/offset pair. Phandle to the system control + module and the register offset to specify lane + selection. HOST MODE = -- 2.17.1
[PATCH v3 3/3] PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x
dra74x/dra76x and dra72x have separate compatible strings. Add support
for these compatible strings in pci-dra7xx driver to perform syscon
configurations required to get x2 mode working.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/dwc/pci-dra7xx.c | 77 +
1 file changed, 77 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c
b/drivers/pci/controller/dwc/pci-dra7xx.c
index b4fbb4be212f..efb26096ccb5 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -81,6 +81,10 @@
#define MSI_REQ_GRANT BIT(0)
#define MSI_VECTOR_SHIFT 7
+#define PCIE_1LANE_2LANE_SELECTION BIT(13)
+#define PCIE_B1C0_MODE_SEL BIT(2)
+#define PCIE_B0_B1_TSYNCEN BIT(0)
+
struct dra7xx_pcie {
struct dw_pcie *pci;
void __iomem*base; /* DT ti_conf */
@@ -93,6 +97,7 @@ struct dra7xx_pcie {
struct dra7xx_pcie_of_data {
enum dw_pcie_device_mode mode;
+ u32 b1co_mode_sel_mask;
};
#define to_dra7xx_pcie(x) dev_get_drvdata((x)->dev)
@@ -542,6 +547,26 @@ static const struct dra7xx_pcie_of_data
dra7xx_pcie_ep_of_data = {
.mode = DW_PCIE_EP_TYPE,
};
+static const struct dra7xx_pcie_of_data dra746_pcie_rc_of_data = {
+ .b1co_mode_sel_mask = BIT(2),
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static const struct dra7xx_pcie_of_data dra726_pcie_rc_of_data = {
+ .b1co_mode_sel_mask = GENMASK(3, 2),
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static const struct dra7xx_pcie_of_data dra746_pcie_ep_of_data = {
+ .b1co_mode_sel_mask = BIT(2),
+ .mode = DW_PCIE_EP_TYPE,
+};
+
+static const struct dra7xx_pcie_of_data dra726_pcie_ep_of_data = {
+ .b1co_mode_sel_mask = GENMASK(3, 2),
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static const struct of_device_id of_dra7xx_pcie_match[] = {
{
.compatible = "ti,dra7-pcie",
@@ -551,6 +576,22 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
.compatible = "ti,dra7-pcie-ep",
.data = &dra7xx_pcie_ep_of_data,
},
+ {
+ .compatible = "ti,dra746-pcie-rc",
+ .data = &dra746_pcie_rc_of_data,
+ },
+ {
+ .compatible = "ti,dra726-pcie-rc",
+ .data = &dra726_pcie_rc_of_data,
+ },
+ {
+ .compatible = "ti,dra746-pcie-ep",
+ .data = &dra746_pcie_ep_of_data,
+ },
+ {
+ .compatible = "ti,dra726-pcie-ep",
+ .data = &dra726_pcie_ep_of_data,
+ },
{},
};
@@ -596,6 +637,34 @@ static int dra7xx_pcie_unaligned_memaccess(struct device
*dev)
return ret;
}
+static int dra7xx_pcie_configure_two_lane(struct device *dev,
+ u32 b1co_mode_sel_mask)
+{
+ struct device_node *np = dev->of_node;
+ struct regmap *pcie_syscon;
+ unsigned int pcie_reg;
+ u32 mask;
+ u32 val;
+
+ pcie_syscon = syscon_regmap_lookup_by_phandle(np, "ti,syscon-lane-sel");
+ if (IS_ERR(pcie_syscon)) {
+ dev_err(dev, "unable to get ti,syscon-lane-sel\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32_index(np, "ti,syscon-lane-sel", 1,
+ &pcie_reg)) {
+ dev_err(dev, "couldn't get lane selection reg offset\n");
+ return -EINVAL;
+ }
+
+ mask = b1co_mode_sel_mask | PCIE_B0_B1_TSYNCEN;
+ val = PCIE_B1C0_MODE_SEL | PCIE_B0_B1_TSYNCEN;
+ regmap_update_bits(pcie_syscon, pcie_reg, mask, val);
+
+ return 0;
+}
+
static int __init dra7xx_pcie_probe(struct platform_device *pdev)
{
u32 reg;
@@ -616,6 +685,7 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
const struct of_device_id *match;
const struct dra7xx_pcie_of_data *data;
enum dw_pcie_device_mode mode;
+ u32 b1co_mode_sel_mask;
match = of_match_device(of_match_ptr(of_dra7xx_pcie_match), dev);
if (!match)
@@ -623,6 +693,7 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
data = (struct dra7xx_pcie_of_data *)match->data;
mode = (enum dw_pcie_device_mode)data->mode;
+ b1co_mode_sel_mask = data->b1co_mode_sel_mask;
dra7xx = devm_kzalloc(dev, sizeof(*dra7xx), GFP_KERNEL);
if (!dra7xx)
@@ -678,6 +749,12 @@ static int __init dra7xx_pcie_probe(struct platform_device
*pdev)
dra7xx->pci = pci;
dra7xx->phy_count = phy_count;
+ if (phy_count == 2) {
+ ret = dra7xx_pcie_configure_two_lane(dev, b1co_mode_sel_mask);
+ if (ret < 0)
+ dra7xx->phy_count = 1; /* Fallback to x1 lane mode */
+ }
+
ret = dra7xx_
[PATCH v3 0/3] PCI: dra7xx: Support PCIe x2 lane mode
Previous version of the patch series can be found here [1] Patch series adds support to enable x2 lane mode in dra74/dra76 and dra72 based boards in pci-dra7xx driver. It introduces new compatible strings in order to enable x2 lane mode support. Changes from v2: *) Have a single syscon dt property for configuring x2 lanes *) Fix minor comments given by Lorenzo (falling back to 1 lane mode, remove unused structure member). Changes from v1: *) Added ti prefix to syscon-lane-conf and syscon-lane-sel as suggested to Rob *) Merged "PCI: dwc: dra7xx: Add support for SoC specific compatible strings" and "PCI: dwc: pci-dra7xx: Enable x2 mode support" into a single patch. *) Fixed $subject as suggested by Bjorn *) Added x2 lane mode support for DRA72x The dts changes and phy changes will be sent as a separate series. [1] -> https://lkml.org/lkml/2017/12/19/175 Kishon Vijay Abraham I (3): dt-bindings: PCI: dra7xx: Add SoC specific compatible strings dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7 PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x .../devicetree/bindings/pci/ti-pci.txt| 11 ++- drivers/pci/controller/dwc/pci-dra7xx.c | 77 +++ 2 files changed, 86 insertions(+), 2 deletions(-) -- 2.17.1
Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
On Wed, Jan 23, 2019 at 10:31:39PM +0100, Christoph Hellwig wrote: > On Wed, Jan 23, 2019 at 05:30:49PM +0100, Joerg Roedel wrote: > > + max_size = virtio_max_dma_size(vdev); > > + > > /* Host can optionally specify maximum segment size and number of > > * segments. */ > > err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX, > >struct virtio_blk_config, size_max, &v); > > if (!err) > > - blk_queue_max_segment_size(q, v); > > - else > > - blk_queue_max_segment_size(q, -1U); > > + max_size = min(max_size, v); > > + > > + blk_queue_max_segment_size(q, max_size); > > I wonder if we should just move the dma max segment size check > into blk_queue_max_segment_size so that all block drivers benefit > from it. Even if not I think at least the SCSI midlayer should > be updated to support it. In that case the limit would also apply to virtio-blk even if it doesn't use the DMA-API. If that is acceptable we can move the check to blk_queue_max_segment_size(). Regards, Joerg
Re: [PATCH 1/3] PCI: iproc: Add feature to set order mode
Hi Bjorn,
Thanks for review, please see my comments below inline.
On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote:
>
> On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Mannam wrote:
> > Order mode in RX header of incoming pcie packets can be override to
> > strict or loose order based on requirement.
> > Sysfs entry is provided to set dynamic and default order modes of upstream
> > traffic.
>
> s/pcie/PCIe/
will change. Thanks.
>
> If this is two paragraphs, insert a blank line between. If it's one
> paragraph, reflow it so it reads like one paragraph.
>
will change. Thanks.
> Are you talking about the Relaxed Ordering bit in the TLP Attributes
> field? If so, please use the exact language used in the spec and
> include a reference, e.g., to PCIe r4.0, sec 2.2.6.4, 2.4, etc.
>
Yes Relax ordering bit in TLP. I will use spec reference. Thanks.
> I'm hesitant about a new sysfs file for this. That automatically
> creates a user-space dependency on this iProc feature. Who would use
> this file?
>
This is the specific feature given in iProc, used to improve
performance for the endpoints which does not support
ordering configuration at its end.
This is the reason we used sysfs file, which allows user to change
ordering based on endpoint used and requirement.
we are using these sysfs files to configure ordering to improve
performance in NVMe endpoints with SPDK/DPDK drivers.
If we enable this default in kernel, then it is applicable to all
endpoints connected. But it may not required for all endpoints.
> > To improve performance in few endpoints we required to modify the
> > ordering attributes. Using this feature we can override order modes of RX
> > packets at IPROC RC.
> >
> > Ex:
> > In PCIe based NVMe SSD endpoints data read/writes from disk is using
> > Queue pairs (submit/completion). After completion of block read/write,
> > EP writes completion command to completion queue to notify RC.
> > So that all data transfers before completion command write are not
> > required to strict order except completion command. It means previous all
> > packets before completion command write to RC should be written to memory
> > and acknowledged.
>
> IIUC, if Enable Relaxed Ordering in the endpoint's Device Control
> register is set, the device is permitted to set the Relaxed Ordering
> bit in TLPs it initiates. So I would think that if we set Enable
> Relaxed Ordering correctly, the NVMe endpoint should be able to
> use Relaxed Ordering for the data transfers and strict ordering (the
> default) for the completion command. What am I missing?
>
As per NVMe spec Enable Relaxed ordering is implementation specific all cards
may not support.
> This sysfs file apparently affects the Root Port/Root Complex
> behavior, not the Endpoint's behavior. Does that mean iProc ignores
> the Relaxed Ordering bit by default, and you're providing a knob that
With sysfs file setting, ordering attributes of all TLPs directed to
specific memory window
can be override iProc layer based on settings.
TLPs to one memory window can keep as strict order and other memory windows can
set to strict order.
Using sysfs file ordering settings can configure and revert back to default.
> makes it pay attention to it? If that's the case, why wouldn't you
> enable iProc support for Relaxed Ordering always, by default?
>
Option is given to user, because few endpoints may support ordering
configuration internally.
few EPs doesn't support. Based on requirement user can configure
ordering settings.
> > Signed-off-by: Srinath Mannam
> > Reviewed-by: Ray Jui
> > ---
> > drivers/pci/controller/pcie-iproc.c | 128
> >
> > drivers/pci/controller/pcie-iproc.h | 16 +
> > 2 files changed, 144 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c
> > b/drivers/pci/controller/pcie-iproc.c
> > index c20fd6b..13ce80f 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -57,6 +57,9 @@
> > #define PCIE_DL_ACTIVE_SHIFT 2
> > #define PCIE_DL_ACTIVE BIT(PCIE_DL_ACTIVE_SHIFT)
> >
> > +#define MPS_MRRS_CFG_MPS_SHIFT 0
> > +#define MPS_MRRS_CFG_MRRS_SHIFT 16
> > +
> > #define APB_ERR_EN_SHIFT 0
> > #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
> >
> > @@ -91,6 +94,14 @@
> >
> > #define IPROC_PCIE_REG_INVALID 0x
> >
> > +#define RO_FIELD(window) BIT((window) << 1)
> > +#define RO_VALUE(window) BIT(((window) << 1) + 1)
> > +/* All Windows are allowed */
> > +#define RO_ALL_WINDOW0x
> > +/* Wait on All Windows */
> > +#define RO_FIELD_ALL_WINDOW 0x
> > +#define DYNAMIC_ORDER_MODE 0x5
> > +
> > /**
> > * iProc PCIe outbound mapping controller specific parameters
> > *
> > @@ -295,6 +306,15 @@ enum iproc_pcie_reg {
> > /* enable APB error for unsupported requ
Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote: > > As I've just introduced and fixed a bug in this area in the current > > cycle - I don't think no_iotlb_memory is what your want (and maybe > > not useful at all): if the arch valls swiotlb_exit after previously > > initializing a buffer it won't be set. You probably want to check > > for non-zero io_tlb_start and/or io_tlb_end. > > Okay, but that requires that I also set io_tlb_start and friends back to > zero in the failure path of swiotlb_init(). Otherwise it could be left > non-zero in case swiotlb_init_with_tbl() returns an error. Indeed, and we'll need to do that anyway as otherwise the dma mapping path might cause problems similar to the one when swiotlb_exit is called that I fixed.
Re: [PATCH v2] KVM: x86: Fix single-step debugging
On 21.01.2019 15:48, Alexander Popov wrote:
> The single-step debugging of KVM guests on x86 is broken: if we run
> gdb 'stepi' command at the breakpoint when the guest interrupts are
> enabled, RIP always jumps to native_apic_mem_write(). Then other
> nasty effects follow.
>
> Long investigation showed that on Jun 7, 2017 the
> commit c8401dda2f0a00cd25c0 ("KVM: x86: fix singlestepping over syscall")
> introduced the kvm_run.debug corruption: kvm_vcpu_do_singlestep() can
> be called without X86_EFLAGS_TF set.
>
> Let's fix it. Please consider that for -stable.
Hello everyone!
Just a friendly ping about this fix.
Looking forward to the feedback.
Best regards,
Alexander
Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
On Thu, Jan 24, 2019 at 09:40:11AM +0100, Joerg Roedel wrote: > > I wonder if we should just move the dma max segment size check > > into blk_queue_max_segment_size so that all block drivers benefit > > from it. Even if not I think at least the SCSI midlayer should > > be updated to support it. > > In that case the limit would also apply to virtio-blk even if it doesn't > use the DMA-API. If that is acceptable we can move the check to > blk_queue_max_segment_size(). Yes. But more importantly it would fix the limit for all other block drivers that set large segment sizes when running over swiotlb.
Re: [f2fs-dev] [PATCH 2/2] f2fs: sync filesystem after roll-forward recovery
On 2019/1/23 8:02, Jaegeuk Kim wrote:
> Some works after roll-forward recovery can get an error which will release
> all the data structures. Let's flush them in order to make it clean.
>
> One possible corruption came from:
>
> [ 90.400500] list_del corruption. prev->next should be ffed1f566208,
> but was (null)
> [ 90.675349] Call trace:
> [ 90.677869] __list_del_entry_valid+0x94/0xb4
> [ 90.682351] remove_dirty_inode+0xac/0x114
> [ 90.686563] __f2fs_write_data_pages+0x6a8/0x6c8
> [ 90.691302] f2fs_write_data_pages+0x40/0x4c
> [ 90.695695] do_writepages+0x80/0xf0
> [ 90.699372] __writeback_single_inode+0xdc/0x4ac
> [ 90.704113] writeback_sb_inodes+0x280/0x440
> [ 90.708501] wb_writeback+0x1b8/0x3d0
> [ 90.712267] wb_workfn+0x1a8/0x4d4
> [ 90.715765] process_one_work+0x1c0/0x3d4
> [ 90.719883] worker_thread+0x224/0x344
> [ 90.723739] kthread+0x120/0x130
> [ 90.727055] ret_from_fork+0x10/0x18
>
> Reported-by: Sahitya Tummala
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/checkpoint.c | 5 +++--
> fs/f2fs/node.c | 4 +++-
> fs/f2fs/super.c | 42 +++---
> 3 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index f955cd3e0677..f0ce2f06 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -306,8 +306,9 @@ static int f2fs_write_meta_pages(struct address_space
> *mapping,
> goto skip_write;
>
> /* collect a number of dirty meta pages and write together */
> - if (wbc->for_kupdate ||
> - get_pages(sbi, F2FS_DIRTY_META) < nr_pages_to_skip(sbi, META))
> + if (wbc->sync_mode != WB_SYNC_ALL &&
> + get_pages(sbi, F2FS_DIRTY_META) <
> + nr_pages_to_skip(sbi, META))
> goto skip_write;
>
> /* if locked failed, cp will flush dirty pages instead */
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 4f450e573312..f6ff84e29749 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1920,7 +1920,9 @@ static int f2fs_write_node_pages(struct address_space
> *mapping,
> f2fs_balance_fs_bg(sbi);
>
> /* collect a number of dirty node pages and write together */
> - if (get_pages(sbi, F2FS_DIRTY_NODES) < nr_pages_to_skip(sbi, NODE))
> + if (wbc->sync_mode != WB_SYNC_ALL &&
> + get_pages(sbi, F2FS_DIRTY_NODES) <
> + nr_pages_to_skip(sbi, NODE))
> goto skip_write;
>
> if (wbc->sync_mode == WB_SYNC_ALL)
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 7998ff5418f2..2af0db2b738e 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1456,9 +1456,16 @@ static int f2fs_enable_quotas(struct super_block *sb);
>
> static int f2fs_disable_checkpoint(struct f2fs_sb_info *sbi)
> {
> + unsigned int s_flags = sbi->sb->s_flags;
> struct cp_control cpc;
> - int err;
> + int err = 0;
> + int ret;
>
> + if (s_flags & SB_RDONLY) {
> + f2fs_msg(sbi->sb, KERN_ERR,
> + "checkpoint=disable on readonly fs");
> + return -EINVAL;
> + }
> sbi->sb->s_flags |= SB_ACTIVE;
>
> f2fs_update_time(sbi, DISABLE_TIME);
> @@ -1466,18 +1473,24 @@ static int f2fs_disable_checkpoint(struct
> f2fs_sb_info *sbi)
> while (!f2fs_time_over(sbi, DISABLE_TIME)) {
> mutex_lock(&sbi->gc_mutex);
> err = f2fs_gc(sbi, true, false, NULL_SEGNO);
> - if (err == -ENODATA)
> + if (err == -ENODATA) {
> + err = 0;
> break;
> + }
> if (err && err != -EAGAIN)
> - return err;
> + break;
Should be?
if (err) {
if (err == -EAGAIN)
err = 0;
else
break;
}
Thanks,
> }
>
> - err = sync_filesystem(sbi->sb);
> - if (err)
> - return err;
> + ret = sync_filesystem(sbi->sb);
> + if (ret || err) {
> + err = ret ? ret: err;
> + goto restore_flag;
> + }
>
> - if (f2fs_disable_cp_again(sbi))
> - return -EAGAIN;
> + if (f2fs_disable_cp_again(sbi)) {
> + err = -EAGAIN;
> + goto restore_flag;
> + }
>
> mutex_lock(&sbi->gc_mutex);
> cpc.reason = CP_PAUSE;
> @@ -1486,7 +1499,9 @@ static int f2fs_disable_checkpoint(struct f2fs_sb_info
> *sbi)
>
> sbi->unusable_block_count = 0;
> mutex_unlock(&sbi->gc_mutex);
> - return 0;
> +restore_flag:
> + sbi->sb->s_flags = s_flags; /* Restore MS_RDONLY status */
> + return err;
> }
>
> static void f2fs_enable_checkpoint(struct f2fs_sb_info *sbi)
> @@ -3356,7 +3371,7 @@ static int f2fs_fill_super(struct super_block *sb, void
> *data, int silent)
> if (test_opt(sbi, DISABLE_CHE
Re: [PATCH 07/10] venus: helpers: add three more helper functions
On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
wrote:
>
> This adds three more helper functions:
> * for internal buffers reallocation, applicable when we are doing
> dynamic resolution change
> * for initial buffer processing of capture and output queue buffer
> types
>
> All of them will be needed for stateful Codec API support.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/helpers.c | 82 +
> drivers/media/platform/qcom/venus/helpers.h | 2 +
> 2 files changed, 84 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> b/drivers/media/platform/qcom/venus/helpers.c
> index f33bbfea3576..637ce7b82d94 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -322,6 +322,52 @@ int venus_helper_intbufs_free(struct venus_inst *inst)
> }
> EXPORT_SYMBOL_GPL(venus_helper_intbufs_free);
>
> +int venus_helper_intbufs_realloc(struct venus_inst *inst)
Does this function actually reallocate buffers? It seems to just free
what we had previously.
> +{
> + enum hfi_version ver = inst->core->res->hfi_version;
> + struct hfi_buffer_desc bd;
> + struct intbuf *buf, *n;
> + int ret;
> +
> + list_for_each_entry_safe(buf, n, &inst->internalbufs, list) {
> + if (buf->type == HFI_BUFFER_INTERNAL_PERSIST ||
> + buf->type == HFI_BUFFER_INTERNAL_PERSIST_1)
> + continue;
> +
> + memset(&bd, 0, sizeof(bd));
> + bd.buffer_size = buf->size;
> + bd.buffer_type = buf->type;
> + bd.num_buffers = 1;
> + bd.device_addr = buf->da;
> + bd.response_required = true;
> +
> + ret = hfi_session_unset_buffers(inst, &bd);
> +
> + dma_free_attrs(inst->core->dev, buf->size, buf->va, buf->da,
> + buf->attrs);
> +
> + list_del_init(&buf->list);
> + kfree(buf);
> + }
> +
> + ret = intbufs_set_buffer(inst, HFI_BUFFER_INTERNAL_SCRATCH(ver));
> + if (ret)
> + goto err;
> +
> + ret = intbufs_set_buffer(inst, HFI_BUFFER_INTERNAL_SCRATCH_1(ver));
> + if (ret)
> + goto err;
> +
> + ret = intbufs_set_buffer(inst, HFI_BUFFER_INTERNAL_SCRATCH_2(ver));
> + if (ret)
> + goto err;
> +
> + return 0;
> +err:
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(venus_helper_intbufs_realloc);
> +
> static u32 load_per_instance(struct venus_inst *inst)
> {
> u32 mbs;
> @@ -1050,6 +1096,42 @@ void venus_helper_vb2_stop_streaming(struct vb2_queue
> *q)
> }
> EXPORT_SYMBOL_GPL(venus_helper_vb2_stop_streaming);
>
> +int venus_helper_process_initial_cap_bufs(struct venus_inst *inst)
> +{
> + struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
> + struct v4l2_m2m_buffer *buf, *n;
> + int ret;
> +
> + v4l2_m2m_for_each_dst_buf_safe(m2m_ctx, buf, n) {
> + ret = session_process_buf(inst, &buf->vb);
> + if (ret) {
> + return_buf_error(inst, &buf->vb);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(venus_helper_process_initial_cap_bufs);
> +
> +int venus_helper_process_initial_out_bufs(struct venus_inst *inst)
> +{
> + struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
> + struct v4l2_m2m_buffer *buf, *n;
> + int ret;
> +
> + v4l2_m2m_for_each_src_buf_safe(m2m_ctx, buf, n) {
> + ret = session_process_buf(inst, &buf->vb);
> + if (ret) {
> + return_buf_error(inst, &buf->vb);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(venus_helper_process_initial_out_bufs);
> +
> int venus_helper_vb2_start_streaming(struct venus_inst *inst)
> {
> struct venus_core *core = inst->core;
> diff --git a/drivers/media/platform/qcom/venus/helpers.h
> b/drivers/media/platform/qcom/venus/helpers.h
> index 24faae5abd93..2ec1c1a8b416 100644
> --- a/drivers/media/platform/qcom/venus/helpers.h
> +++ b/drivers/media/platform/qcom/venus/helpers.h
> @@ -69,4 +69,6 @@ int venus_helper_intbufs_realloc(struct venus_inst *inst);
> int venus_helper_queue_dpb_bufs(struct venus_inst *inst);
> int venus_helper_unregister_bufs(struct venus_inst *inst);
> int venus_helper_load_scale_clocks(struct venus_core *core);
> +int venus_helper_process_initial_cap_bufs(struct venus_inst *inst);
> +int venus_helper_process_initial_out_bufs(struct venus_inst *inst);
> #endif
> --
> 2.17.1
>
Re: [PATCH 00/10] Venus stateful Codec API
Hi Stanimir, On Fri, Jan 18, 2019 at 1:20 AM Stanimir Varbanov wrote: > > Hello, > > This aims to make Venus decoder compliant with stateful Codec API [1]. > The patches 1-9 are preparation for the cherry on the cake patch 10 > which implements the decoder state machine similar to the one in the > stateful codec API documentation. Thanks *a lot* for this series! I am still stress-testing it against the Chromium decoder tests, but so far it has been rock-solid. I have a few inline comments on some patches ; I will also want to review the state machine more thoroughly after refreshing my mind on Tomasz doc, but this looks pretty promising already. Cheers, Alex. > > There few things which are still TODO: > - V4L2_DEC_CMD_START implementation as per decoder documentation. > - Dynamic resolution change V4L2_BUF_FLAG_LAST for the last buffer >before the resolution change. > > The patches are tested with chromium VDA unittests at [2]. > > Note that the patchset depends on Venus various fixes at [3]. > > Comments are welcome! > > regards, > Stan > > [1] https://patchwork.kernel.org/patch/10652199/ > [2] > https://chromium.googlesource.com/chromium/src/+/lkgr/docs/media/gpu/vdatest_usage.md > [3] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1894510.html > > Stanimir Varbanov (10): > venus: hfi_cmds: add more not-implemented properties > venus: helpers: fix dynamic buffer mode for v4 > venus: helpers: export few helper functions > venus: hfi: add type argument to hfi flush function > venus: hfi: export few HFI functions > venus: hfi: return an error if session_init is already called > venus: helpers: add three more helper functions > venus: vdec_ctrls: get real minimum buffers for capture > venus: vdec: allow bigger sizeimage set by clients > venus: dec: make decoder compliant with stateful codec API > > drivers/media/platform/qcom/venus/core.h | 20 +- > drivers/media/platform/qcom/venus/helpers.c | 141 +- > drivers/media/platform/qcom/venus/helpers.h | 14 + > drivers/media/platform/qcom/venus/hfi.c | 11 +- > drivers/media/platform/qcom/venus/hfi.h | 2 +- > drivers/media/platform/qcom/venus/hfi_cmds.c | 2 + > drivers/media/platform/qcom/venus/vdec.c | 467 ++ > .../media/platform/qcom/venus/vdec_ctrls.c| 7 +- > 8 files changed, 535 insertions(+), 129 deletions(-) > > -- > 2.17.1 >
Re: [PATCH 09/10] venus: vdec: allow bigger sizeimage set by clients
On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
wrote:
>
> In most of the cases the client will know better what could be
> the maximum size for compressed data buffers. Change the driver
> to permit the user to set bigger size for the compressed buffer
> but make reasonable sanitation.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/vdec.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/vdec.c
> b/drivers/media/platform/qcom/venus/vdec.c
> index 282de21cf2e1..7a9370df7515 100644
> --- a/drivers/media/platform/qcom/venus/vdec.c
> +++ b/drivers/media/platform/qcom/venus/vdec.c
> @@ -142,6 +142,7 @@ vdec_try_fmt_common(struct venus_inst *inst, struct
> v4l2_format *f)
> struct v4l2_pix_format_mplane *pixmp = &f->fmt.pix_mp;
> struct v4l2_plane_pix_format *pfmt = pixmp->plane_fmt;
> const struct venus_format *fmt;
> + u32 szimage;
>
> memset(pfmt[0].reserved, 0, sizeof(pfmt[0].reserved));
> memset(pixmp->reserved, 0, sizeof(pixmp->reserved));
> @@ -170,14 +171,18 @@ vdec_try_fmt_common(struct venus_inst *inst, struct
> v4l2_format *f)
> pixmp->num_planes = fmt->num_planes;
> pixmp->flags = 0;
>
> - pfmt[0].sizeimage = venus_helper_get_framesz(pixmp->pixelformat,
> -pixmp->width,
> -pixmp->height);
> + szimage = venus_helper_get_framesz(pixmp->pixelformat, pixmp->width,
> + pixmp->height);
>
> - if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
> + if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + pfmt[0].sizeimage = szimage;
> pfmt[0].bytesperline = ALIGN(pixmp->width, 128);
> - else
> + } else {
> + pfmt[0].sizeimage = clamp_t(u32, pfmt[0].sizeimage, 0, SZ_4M);
> + if (szimage > pfmt[0].sizeimage)
> + pfmt[0].sizeimage = szimage;
pfmt[0].sizeimage = max(clamp_t(u32, pfmt[0].sizeimage, 0, SZ_4M),
szimage)?
> pfmt[0].bytesperline = 0;
> + }
>
> return fmt;
> }
> @@ -275,6 +280,7 @@ static int vdec_s_fmt(struct file *file, void *fh, struct
> v4l2_format *f)
> inst->ycbcr_enc = pixmp->ycbcr_enc;
> inst->quantization = pixmp->quantization;
> inst->xfer_func = pixmp->xfer_func;
> + inst->input_buf_size = pixmp->plane_fmt[0].sizeimage;
> }
>
> memset(&format, 0, sizeof(format));
> @@ -737,6 +743,8 @@ static int vdec_queue_setup(struct vb2_queue *q,
> sizes[0] = venus_helper_get_framesz(inst->fmt_out->pixfmt,
> inst->out_width,
> inst->out_height);
> + if (inst->input_buf_size > sizes[0])
> + sizes[0] = inst->input_buf_size;
sizes[0] = max(venus_helper_get_framesz(inst->fmt_out->pixfmt,
inst->out_width,
inst->out_height),
inst->input_buf_size)?
> inst->input_buf_size = sizes[0];
> *num_buffers = max(*num_buffers, in_num);
> inst->num_input_bufs = *num_buffers;
> --
> 2.17.1
>
Re: [PATCH 03/10] venus: helpers: export few helper functions
On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
wrote:
>
> Here we export few helper function to use them from decoder to
> implement more granular control needed for stateful Codec API
> compliance.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/helpers.c | 29 -
> drivers/media/platform/qcom/venus/helpers.h | 7 +
> 2 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> b/drivers/media/platform/qcom/venus/helpers.c
> index 86105de81af2..f33bbfea3576 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -88,7 +88,7 @@ bool venus_helper_check_codec(struct venus_inst *inst, u32
> v4l2_pixfmt)
> }
> EXPORT_SYMBOL_GPL(venus_helper_check_codec);
>
> -static int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
> +int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
> {
> struct intbuf *buf;
> int ret = 0;
> @@ -109,6 +109,7 @@ static int venus_helper_queue_dpb_bufs(struct venus_inst
> *inst)
> fail:
> return ret;
> }
> +EXPORT_SYMBOL_GPL(venus_helper_queue_dpb_bufs);
>
> int venus_helper_free_dpb_bufs(struct venus_inst *inst)
> {
> @@ -287,7 +288,7 @@ static const unsigned int intbuf_types_4xx[] = {
> HFI_BUFFER_INTERNAL_PERSIST_1,
> };
>
> -static int intbufs_alloc(struct venus_inst *inst)
> +int venus_helper_intbufs_alloc(struct venus_inst *inst)
> {
> const unsigned int *intbuf;
> size_t arr_sz, i;
> @@ -313,11 +314,13 @@ static int intbufs_alloc(struct venus_inst *inst)
> intbufs_unset_buffers(inst);
> return ret;
> }
> +EXPORT_SYMBOL_GPL(venus_helper_intbufs_alloc);
>
> -static int intbufs_free(struct venus_inst *inst)
> +int venus_helper_intbufs_free(struct venus_inst *inst)
> {
> return intbufs_unset_buffers(inst);
> }
> +EXPORT_SYMBOL_GPL(venus_helper_intbufs_free);
>
> static u32 load_per_instance(struct venus_inst *inst)
> {
> @@ -348,7 +351,7 @@ static u32 load_per_type(struct venus_core *core, u32
> session_type)
> return mbs_per_sec;
> }
>
> -static int load_scale_clocks(struct venus_core *core)
> +int venus_helper_load_scale_clocks(struct venus_core *core)
> {
> const struct freq_tbl *table = core->res->freq_tbl;
> unsigned int num_rows = core->res->freq_tbl_size;
> @@ -397,6 +400,7 @@ static int load_scale_clocks(struct venus_core *core)
> dev_err(dev, "failed to set clock rate %lu (%d)\n", freq, ret);
> return ret;
> }
> +EXPORT_SYMBOL_GPL(venus_helper_load_scale_clocks);
>
> static void fill_buffer_desc(const struct venus_buffer *buf,
> struct hfi_buffer_desc *bd, bool response)
> @@ -481,7 +485,7 @@ static bool is_dynamic_bufmode(struct venus_inst *inst)
> return caps->cap_bufs_mode_dynamic;
> }
>
> -static int session_unregister_bufs(struct venus_inst *inst)
> +int venus_helper_unregister_bufs(struct venus_inst *inst)
> {
> struct venus_buffer *buf, *n;
> struct hfi_buffer_desc bd;
> @@ -498,6 +502,7 @@ static int session_unregister_bufs(struct venus_inst
> *inst)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(venus_helper_unregister_bufs);
>
> static int session_register_bufs(struct venus_inst *inst)
> {
> @@ -1018,8 +1023,8 @@ void venus_helper_vb2_stop_streaming(struct vb2_queue
> *q)
> if (inst->streamon_out & inst->streamon_cap) {
> ret = hfi_session_stop(inst);
> ret |= hfi_session_unload_res(inst);
> - ret |= session_unregister_bufs(inst);
> - ret |= intbufs_free(inst);
> + ret |= venus_helper_unregister_bufs(inst);
> + ret |= venus_helper_intbufs_free(inst);
> ret |= hfi_session_deinit(inst);
>
> if (inst->session_error || core->sys_error)
> @@ -1030,7 +1035,7 @@ void venus_helper_vb2_stop_streaming(struct vb2_queue
> *q)
>
> venus_helper_free_dpb_bufs(inst);
>
> - load_scale_clocks(core);
> + venus_helper_load_scale_clocks(core);
> INIT_LIST_HEAD(&inst->registeredbufs);
> }
>
> @@ -1050,7 +1055,7 @@ int venus_helper_vb2_start_streaming(struct venus_inst
> *inst)
> struct venus_core *core = inst->core;
> int ret;
>
> - ret = intbufs_alloc(inst);
> + ret = venus_helper_intbufs_alloc(inst);
> if (ret)
> return ret;
>
> @@ -1058,7 +1063,7 @@ int venus_helper_vb2_start_streaming(struct venus_inst
> *inst)
> if (ret)
> goto err_bufs_free;
>
> - load_scale_clocks(core);
> + venus_helper_load_scale_clocks(core);
>
> ret = hfi_session_load_res(inst);
> if (ret)
> @@ -1079,9 +1084,9 @@ int venus_helper_vb2_start_streaming(struct venus_inst
> *inst)
> err_unload_res:
> hfi_session_unload_res(inst);
> err_un
Re: [PATCH 2/3] PCI: iproc: CRS state check in config request
Hi Bjorn,
Thanks for review, please see my comments below inline.
On Fri, Jan 18, 2019 at 8:38 PM Bjorn Helgaas wrote:
>
> On Fri, Jan 18, 2019 at 09:53:22AM +0530, Srinath Mannam wrote:
> > In the current implementation, config read of 0x0001 data
> > is assumed as CRS completion. but sometimes 0x0001 can be
> > a valid data.
> > IPROC PCIe RC has a register to show config request status flags
> > like SC, UR, CRS and CA.
> > So that extra check is added in the code to confirm the CRS
> > state using this register before reissue config request.
>
> s/. but/. But/ (Sentences start with a capital letter.)
will change. Thanks.
>
> Please wrap this text correctly. If it's a single paragraph, wrap it so
> the lines are filled. It *looks* like it's intended to be separate
> paragraphs; they should be separated by blank lines.
will change. Thanks.
>
> > Signed-off-by: Srinath Mannam
> > Reviewed-by: Ray Jui
> > ---
> > drivers/pci/controller/pcie-iproc.c | 23 +--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c
> > b/drivers/pci/controller/pcie-iproc.c
> > index 13ce80f..ee89d56 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -63,6 +63,10 @@
> > #define APB_ERR_EN_SHIFT 0
> > #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
> >
> > +#define CFG_RD_SUCCESS 0
> > +#define CFG_RD_UR1
> > +#define CFG_RD_CRS 2
> > +#define CFG_RD_CA3
> > #define CFG_RETRY_STATUS 0x0001
> > #define CFG_RETRY_STATUS_TIMEOUT_US 50 /* 500 milliseconds */
> >
> > @@ -300,6 +304,9 @@ enum iproc_pcie_reg {
> > IPROC_PCIE_IARR4,
> > IPROC_PCIE_IMAP4,
> >
> > + /* config read status */
> > + IPROC_PCIE_CFG_RD_STATUS,
> > +
> > /* link status */
> > IPROC_PCIE_LINK_STATUS,
> >
> > @@ -370,6 +377,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
> > [IPROC_PCIE_IMAP3] = 0xe08,
> > [IPROC_PCIE_IARR4] = 0xe68,
> > [IPROC_PCIE_IMAP4] = 0xe70,
> > + [IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
> > [IPROC_PCIE_LINK_STATUS]= 0xf0c,
> > [IPROC_PCIE_APB_ERR_EN] = 0xf40,
> > [IPROC_PCIE_ORDERING_CFG] = 0x2000,
> > @@ -501,10 +509,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct
> > iproc_pcie *pcie,
> > return (pcie->base + offset);
> > }
> >
> > -static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
> > +static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
> > + void __iomem *cfg_data_p)
> > {
> > int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
> > unsigned int data;
> > + u32 status;
> >
> > /*
> >* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
> > @@ -525,6 +535,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem
> > *cfg_data_p)
> >*/
> > data = readl(cfg_data_p);
> > while (data == CFG_RETRY_STATUS && timeout--) {
> > + /*
> > + * CRS state is set in CFG_RD status register
> > + * This will handle the case where CFG_RETRY_STATUS is
> > + * valid config data.
> > + */
> > + status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
> > + if (status != CFG_RD_CRS)
> > + return data;
> > +
> > udelay(1);
> > data = readl(cfg_data_p);
> > }
> > @@ -603,7 +622,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
> > unsigned int devfn,
> > if (!cfg_data_p)
> > return PCIBIOS_DEVICE_NOT_FOUND;
> >
> > - data = iproc_pcie_cfg_retry(cfg_data_p);
> > + data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
> >
> > *val = data;
> > if (size <= 2)
> > --
> > 2.7.4
> >
Re: [RFC PATCH] mm: vmscan: do not iterate all mem cgroups for global direct reclaim
On Wed 23-01-19 12:24:38, Yang Shi wrote: > > > On 1/23/19 1:59 AM, Michal Hocko wrote: > > On Wed 23-01-19 04:09:42, Yang Shi wrote: > > > In current implementation, both kswapd and direct reclaim has to iterate > > > all mem cgroups. It is not a problem before offline mem cgroups could > > > be iterated. But, currently with iterating offline mem cgroups, it > > > could be very time consuming. In our workloads, we saw over 400K mem > > > cgroups accumulated in some cases, only a few hundred are online memcgs. > > > Although kswapd could help out to reduce the number of memcgs, direct > > > reclaim still get hit with iterating a number of offline memcgs in some > > > cases. We experienced the responsiveness problems due to this > > > occassionally. > > Can you provide some numbers? > > What numbers do you mean? How long did it take to iterate all the memcgs? > For now I don't have the exact number for the production environment, but > the unresponsiveness is visible. Yeah, I would be interested in the worst case direct reclaim latencies. You can get that from our vmscan tracepoints quite easily. > I had some test number with triggering direct reclaim with 8k memcgs > artificially, which has just one clean page charged for each memcg, so the > reclaim is cheaper than real production environment. > > perf shows it took around 220ms to iterate 8k memcgs: > > dd 13873 [011] 578.542919: > vmscan:mm_vmscan_direct_reclaim_begin > dd 13873 [011] 578.758689: > vmscan:mm_vmscan_direct_reclaim_end > > So, iterating 400K would take at least 11s in this artificial case. The > production environment is much more complicated, so it would take much > longer in fact. Having real world numbers would definitely help with the justification. > > > Here just break the iteration once it reclaims enough pages as what > > > memcg direct reclaim does. This may hurt the fairness among memcgs > > > since direct reclaim may awlays do reclaim from same memcgs. But, it > > > sounds ok since direct reclaim just tries to reclaim SWAP_CLUSTER_MAX > > > pages and memcgs can be protected by min/low. > > OK, this makes some sense to me. The purpose of the direct reclaim is > > to reclaim some memory and throttle the allocation pace. The iterator is > > cached so the next reclaimer on the same hierarchy will simply continue > > so the fairness should be more or less achieved. > > Yes, you are right. I missed this point. > > > > > Btw. is there any reason to keep !global_reclaim() check in place? Why > > is it not sufficient to exclude kswapd? > > Iterating all memcgs in kswapd is still useful to help to reduce those > zombie memcgs. Yes, but for that you do not need to check for global_reclaim right? -- Michal Hocko SUSE Labs
Re: [PATCH 08/10] venus: vdec_ctrls: get real minimum buffers for capture
On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
wrote:
>
> Until now we returned num_output_bufs set during reqbuf but
> that could be wrong when we implement stateful Codec API. So
> get the minimum buffers for capture from HFI. This is supposed
> to be called after stream header parsing, i.e. after dequeue
> v4l2 event for change resolution.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/vdec_ctrls.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/vdec_ctrls.c
> b/drivers/media/platform/qcom/venus/vdec_ctrls.c
> index f4604b0cd57e..e1da87bf52bc 100644
> --- a/drivers/media/platform/qcom/venus/vdec_ctrls.c
> +++ b/drivers/media/platform/qcom/venus/vdec_ctrls.c
> @@ -16,6 +16,7 @@
> #include
>
> #include "core.h"
> +#include "helpers.h"
> #include "vdec.h"
>
> static int vdec_op_s_ctrl(struct v4l2_ctrl *ctrl)
> @@ -47,7 +48,9 @@ static int vdec_op_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> {
> struct venus_inst *inst = ctrl_to_inst(ctrl);
> struct vdec_controls *ctr = &inst->controls.dec;
> + struct hfi_buffer_requirements bufreq;
> union hfi_get_property hprop;
> + enum hfi_version ver = inst->core->res->hfi_version;
> u32 ptype = HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT;
> int ret;
>
> @@ -71,7 +74,9 @@ static int vdec_op_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> ctrl->val = ctr->post_loop_deb_mode;
> break;
> case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
> - ctrl->val = inst->num_output_bufs;
> + ret = venus_helper_get_bufreq(inst, HFI_BUFFER_OUTPUT,
> &bufreq);
> + if (!ret)
> + ctrl->val = HFI_BUFREQ_COUNT_MIN(&bufreq, ver);
What happens if venus_helper_get_bufreq() returns an error? It seems
that we just happily continue with whatever the previous value of
ctrl->val was. It seems like we do the same with other controls as
well.
I think you can fix this globally by initializing ret to 0 at the
beginning of the function, and then returning ret instead of 0 at the
end. That way all errors would be propagated. Of course please check
that this is relevant for other controls following this scheme before
doing so. :)
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
wrote:
>
> This refactored code for start/stop streaming vb2 operations and
s/refactored/refactors?
> adds a state machine handling similar to the one in stateful codec
> API documentation. One major change is that now the HFI session is
> started on STREAMON(OUTPUT) and stopped on REQBUF(OUTPUT,count=0),
> during that time streamoff(cap,out) just flush buffers but doesn't
streamoff(cap,out) should probably be in capitals for consistency.
> stop the session. The other major change is that now the capture
> and output queues are completely separated.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/core.h| 20 +-
> drivers/media/platform/qcom/venus/helpers.c | 23 +-
> drivers/media/platform/qcom/venus/helpers.h | 5 +
> drivers/media/platform/qcom/venus/vdec.c| 449
> 4 files changed, 389 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.h
> b/drivers/media/platform/qcom/venus/core.h
> index 79c7e816c706..5a133c203455 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -218,6 +218,15 @@ struct venus_buffer {
>
> #define to_venus_buffer(ptr) container_of(ptr, struct venus_buffer, vb)
>
> +#define DEC_STATE_UNINIT 0
Not sure about "uninit", DEC_STATE_DEINIT may be more explicit here?
> +#define DEC_STATE_INIT 1
> +#define DEC_STATE_CAPTURE_SETUP2
> +#define DEC_STATE_STOPPED 3
> +#define DEC_STATE_SEEK 4
> +#define DEC_STATE_DRAIN5
> +#define DEC_STATE_DECODING 6
> +#define DEC_STATE_DRC 7
How about defining these as an enum, for better type safety? I'd also
prefix with VENUS_ to avoid possible (if unlikely) name collisions.
> +
> /**
> * struct venus_inst - holds per instance paramerters
> *
> @@ -241,6 +250,10 @@ struct venus_buffer {
> * @colorspace:current color space
> * @quantization: current quantization
> * @xfer_func: current xfer function
> + * @codec_state: current codec API state (see DEC/ENC_STATE_)
> + * @reconf_wait: wait queue for resolution change event
> + * @ten_bits: does new stream is 10bits depth
"is new stream 10 bits deep" maybe?
> + * @buf_count: used to count number number of buffers (reqbuf(0))
"number" written twice here.
> * @fps: holds current FPS
> * @timeperframe: holds current time per frame structure
> * @fmt_out: a reference to output format structure
> @@ -255,8 +268,6 @@ struct venus_buffer {
> * @opb_buftype: output picture buffer type
> * @opb_fmt: output picture buffer raw format
> * @reconfig: a flag raised by decoder when the stream resolution changed
> - * @reconfig_width:holds the new width
> - * @reconfig_height: holds the new height
> * @hfi_codec: current codec for this instance in HFI space
> * @sequence_cap: a sequence counter for capture queue
> * @sequence_out: a sequence counter for output queue
> @@ -296,6 +307,9 @@ struct venus_inst {
> u8 ycbcr_enc;
> u8 quantization;
> u8 xfer_func;
> + unsigned int codec_state;
As mentioned above, with an enum the type of this member would make it
obvious which values it can accept.
> + wait_queue_head_t reconf_wait;
> + int buf_count;
> u64 fps;
> struct v4l2_fract timeperframe;
> const struct venus_format *fmt_out;
> @@ -310,8 +324,6 @@ struct venus_inst {
> u32 opb_buftype;
> u32 opb_fmt;
> bool reconfig;
> - u32 reconfig_width;
> - u32 reconfig_height;
> u32 hfi_codec;
> u32 sequence_cap;
> u32 sequence_out;
> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> b/drivers/media/platform/qcom/venus/helpers.c
> index 637ce7b82d94..25d8cceccae4 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -1030,16 +1030,15 @@ void venus_helper_vb2_buf_queue(struct vb2_buffer *vb)
>
> v4l2_m2m_buf_queue(m2m_ctx, vbuf);
>
> - if (!(inst->streamon_out & inst->streamon_cap))
> - goto unlock;
> -
> - ret = is_buf_refed(inst, vbuf);
> - if (ret)
> - goto unlock;
> + if (IS_OUT(vb->vb2_queue, inst) || IS_CAP(vb->vb2_queue, inst)) {
> + ret = is_buf_refed(inst, vbuf);
> + if (ret)
> + goto unlock;
>
> - ret = session_process_buf(inst, vbuf);
> - if (ret)
> - return_buf_error(inst, vbuf);
> + ret = session_process_buf(inst, vbuf);
> + if (ret)
> + return_buf_error(inst, vbuf);
> + }
>
> unlock:
> mutex_unlock(&inst->lock);
> @@ -1155,14 +1154,8 @@ int venus_helper_
Re: [PATCH 03/10] venus: helpers: export few helper functions
Hi Alex,
Thanks for the review!
On 1/24/19 10:43 AM, Alexandre Courbot wrote:
> On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
> wrote:
>>
>> Here we export few helper function to use them from decoder to
>> implement more granular control needed for stateful Codec API
>> compliance.
>>
>> Signed-off-by: Stanimir Varbanov
>> ---
>> drivers/media/platform/qcom/venus/helpers.c | 29 -
>> drivers/media/platform/qcom/venus/helpers.h | 7 +
>> 2 files changed, 24 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/helpers.c
>> b/drivers/media/platform/qcom/venus/helpers.c
>> index 86105de81af2..f33bbfea3576 100644
>> --- a/drivers/media/platform/qcom/venus/helpers.c
>> +++ b/drivers/media/platform/qcom/venus/helpers.c
>> @@ -88,7 +88,7 @@ bool venus_helper_check_codec(struct venus_inst *inst, u32
>> v4l2_pixfmt)
>> }
>> EXPORT_SYMBOL_GPL(venus_helper_check_codec);
>>
>> -static int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
>> +int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
>> {
>> struct intbuf *buf;
>> int ret = 0;
>> @@ -109,6 +109,7 @@ static int venus_helper_queue_dpb_bufs(struct venus_inst
>> *inst)
>> fail:
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(venus_helper_queue_dpb_bufs);
>>
>> int venus_helper_free_dpb_bufs(struct venus_inst *inst)
>> {
>> @@ -287,7 +288,7 @@ static const unsigned int intbuf_types_4xx[] = {
>> HFI_BUFFER_INTERNAL_PERSIST_1,
>> };
>>
>> -static int intbufs_alloc(struct venus_inst *inst)
>> +int venus_helper_intbufs_alloc(struct venus_inst *inst)
>> {
>> const unsigned int *intbuf;
>> size_t arr_sz, i;
>> @@ -313,11 +314,13 @@ static int intbufs_alloc(struct venus_inst *inst)
>> intbufs_unset_buffers(inst);
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(venus_helper_intbufs_alloc);
>>
>> -static int intbufs_free(struct venus_inst *inst)
>> +int venus_helper_intbufs_free(struct venus_inst *inst)
>> {
>> return intbufs_unset_buffers(inst);
>> }
>> +EXPORT_SYMBOL_GPL(venus_helper_intbufs_free);
>>
>> static u32 load_per_instance(struct venus_inst *inst)
>> {
>> @@ -348,7 +351,7 @@ static u32 load_per_type(struct venus_core *core, u32
>> session_type)
>> return mbs_per_sec;
>> }
>>
>> -static int load_scale_clocks(struct venus_core *core)
>> +int venus_helper_load_scale_clocks(struct venus_core *core)
>> {
>> const struct freq_tbl *table = core->res->freq_tbl;
>> unsigned int num_rows = core->res->freq_tbl_size;
>> @@ -397,6 +400,7 @@ static int load_scale_clocks(struct venus_core *core)
>> dev_err(dev, "failed to set clock rate %lu (%d)\n", freq, ret);
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(venus_helper_load_scale_clocks);
>>
>> static void fill_buffer_desc(const struct venus_buffer *buf,
>> struct hfi_buffer_desc *bd, bool response)
>> @@ -481,7 +485,7 @@ static bool is_dynamic_bufmode(struct venus_inst *inst)
>> return caps->cap_bufs_mode_dynamic;
>> }
>>
>> -static int session_unregister_bufs(struct venus_inst *inst)
>> +int venus_helper_unregister_bufs(struct venus_inst *inst)
>> {
>> struct venus_buffer *buf, *n;
>> struct hfi_buffer_desc bd;
>> @@ -498,6 +502,7 @@ static int session_unregister_bufs(struct venus_inst
>> *inst)
>>
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(venus_helper_unregister_bufs);
>>
>> static int session_register_bufs(struct venus_inst *inst)
>> {
>> @@ -1018,8 +1023,8 @@ void venus_helper_vb2_stop_streaming(struct vb2_queue
>> *q)
>> if (inst->streamon_out & inst->streamon_cap) {
>> ret = hfi_session_stop(inst);
>> ret |= hfi_session_unload_res(inst);
>> - ret |= session_unregister_bufs(inst);
>> - ret |= intbufs_free(inst);
>> + ret |= venus_helper_unregister_bufs(inst);
>> + ret |= venus_helper_intbufs_free(inst);
>> ret |= hfi_session_deinit(inst);
>>
>> if (inst->session_error || core->sys_error)
>> @@ -1030,7 +1035,7 @@ void venus_helper_vb2_stop_streaming(struct vb2_queue
>> *q)
>>
>> venus_helper_free_dpb_bufs(inst);
>>
>> - load_scale_clocks(core);
>> + venus_helper_load_scale_clocks(core);
>> INIT_LIST_HEAD(&inst->registeredbufs);
>> }
>>
>> @@ -1050,7 +1055,7 @@ int venus_helper_vb2_start_streaming(struct venus_inst
>> *inst)
>> struct venus_core *core = inst->core;
>> int ret;
>>
>> - ret = intbufs_alloc(inst);
>> + ret = venus_helper_intbufs_alloc(inst);
>> if (ret)
>> return ret;
>>
>> @@ -1058,7 +1063,7 @@ int venus_helper_vb2_start_streaming(struct venus_inst
>> *inst)
>> if (ret)
>> goto err_bufs_free;
>>
>> - load_scale_clocks(core);
>> + venus_helper_load_scale_clocks(core);
>>
>
Re: [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
On Thu, Jan 24, 2019 at 09:24:31AM +0100, Joerg Roedel wrote: > On Wed, Jan 23, 2019 at 10:28:13PM +0100, Christoph Hellwig wrote: > > On Wed, Jan 23, 2019 at 05:30:45PM +0100, Joerg Roedel wrote: > > > +extern size_t swiotlb_max_mapping_size(struct device *dev); > > > > No need for the extern keyword on function declarations in headers. > > Right, but all other function declarations in that header file have > 'extern' too, so I added it also for that one. Your patch 3 also doesn't use an extern. And I have to say I much prefer it that way..
Re: [PATCH 2/2] Input: st1232 - add support for st1633
Hi Martin,
On Wed, Jan 23, 2019 at 08:26:51AM +0100, Martin Kepplinger wrote:
> From: Martin Kepplinger
>
> Add support for the Sitronix ST1633 touchscreen controller to the st1232
> driver.
>
> Signed-off-by: Martin Kepplinger
> ---
> drivers/input/touchscreen/Kconfig | 6 +-
> drivers/input/touchscreen/st1232.c | 130 +
> 2 files changed, 98 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 068dbbc610fc..7c597a49c265 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1168,11 +1168,11 @@ config TOUCHSCREEN_SIS_I2C
> module will be called sis_i2c.
>
> config TOUCHSCREEN_ST1232
> - tristate "Sitronix ST1232 touchscreen controllers"
> + tristate "Sitronix ST1232 or ST1633 touchscreen controllers"
> depends on I2C
> help
> - Say Y here if you want to support Sitronix ST1232
> - touchscreen controller.
> + Say Y here if you want to support the Sitronix ST1232
> + or ST1633 touchscreen controller.
>
> If unsure, say N.
>
> diff --git a/drivers/input/touchscreen/st1232.c
> b/drivers/input/touchscreen/st1232.c
> index 11ff32c68025..dc0288f37fda 100644
> --- a/drivers/input/touchscreen/st1232.c
> +++ b/drivers/input/touchscreen/st1232.c
> @@ -18,18 +18,21 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
> #define ST1232_TS_NAME "st1232-ts"
> +#define ST1633_TS_NAME "st1633-ts"
> +
> +enum {
> + st1232,
> + st1633,
> +};
>
> #define MIN_X0x00
> #define MIN_Y0x00
> -#define MAX_X0x31f /* (800 - 1) */
> -#define MAX_Y0x1df /* (480 - 1) */
> -#define MAX_AREA 0xff
> -#define MAX_FINGERS 2
>
> struct st1232_ts_finger {
> u16 x;
> @@ -38,12 +41,24 @@ struct st1232_ts_finger {
> bool is_valid;
> };
>
> +struct st_chip_info {
> + u8 id;
It should be the enum, not u8, but I do not think you need id here at
all. You only check id when you decide whether to report
ABS_MT_TOUCH_MAJOR, I think having a boolean to indicate that fact would
be more in line with the spirit of this patch.
> + u16 max_x;
> + u16 max_y;
> + u16 max_area;
> + u16 max_fingers;
> + u8 start_reg;
> +};
> +
> struct st1232_ts_data {
> struct i2c_client *client;
> struct input_dev *input_dev;
> - struct st1232_ts_finger finger[MAX_FINGERS];
> struct dev_pm_qos_request low_latency_req;
> int reset_gpio;
> + const struct st_chip_info *chip_info;
> + int read_buf_len;
> + u8 *read_buf;
> + struct st1232_ts_finger *finger;
> };
>
> static int st1232_ts_read_data(struct st1232_ts_data *ts)
> @@ -52,40 +67,35 @@ static int st1232_ts_read_data(struct st1232_ts_data *ts)
> struct i2c_client *client = ts->client;
> struct i2c_msg msg[2];
> int error;
> - u8 start_reg;
> - u8 buf[10];
> + int i, y;
> + u8 start_reg = ts->chip_info->start_reg;
> + u8 *buf = ts->read_buf;
>
> - /* read touchscreen data from ST1232 */
> + /* read touchscreen data */
> msg[0].addr = client->addr;
> msg[0].flags = 0;
> msg[0].len = 1;
> msg[0].buf = &start_reg;
> - start_reg = 0x10;
>
> msg[1].addr = ts->client->addr;
> msg[1].flags = I2C_M_RD;
> - msg[1].len = sizeof(buf);
> + msg[1].len = ts->read_buf_len;
> msg[1].buf = buf;
>
> error = i2c_transfer(client->adapter, msg, 2);
> if (error < 0)
> return error;
>
> - /* get "valid" bits */
> - finger[0].is_valid = buf[2] >> 7;
> - finger[1].is_valid = buf[5] >> 7;
> + for (i = 0, y = 0; i < ts->chip_info->max_fingers; i++, y += 3) {
> + finger[i].is_valid = buf[i + y] >> 7;
> + if (finger[i].is_valid) {
> + finger[i].x = ((buf[i + y] & 0x0070) << 4) | buf[i + 1];
> + finger[i].y = ((buf[i + y] & 0x0007) << 8) | buf[i + 2];
>
> - /* get xy coordinate */
> - if (finger[0].is_valid) {
> - finger[0].x = ((buf[2] & 0x0070) << 4) | buf[3];
> - finger[0].y = ((buf[2] & 0x0007) << 8) | buf[4];
> - finger[0].t = buf[8];
> - }
> -
> - if (finger[1].is_valid) {
> - finger[1].x = ((buf[5] & 0x0070) << 4) | buf[6];
> - finger[1].y = ((buf[5] & 0x0007) << 8) | buf[7];
> - finger[1].t = buf[9];
> + /* st1232 includes a z-axis / touch strength */
> + if (ts->chip_info->id == st1232)
> + finger[i].t = buf[i + 6];
> + }
> }
>
> return 0;
> @@ -104,11 +114,14 @@ static irqreturn_t st1232_ts_irq_handler(int irq, void
> *dev_id)
> goto end;
>
> /* multi touch
Re: [RFC/RFT PATCH 00/15] crypto: improved skcipher, aead, and hash tests
On Wed, Jan 23, 2019 at 02:49:11PM -0800, Eric Biggers wrote: > Hello, > > Crypto algorithms must produce the same output for the same input > regardless of data layout, i.e. how the src and dst scatterlists are > divided into chunks and how each chunk is aligned. Request flags such > as CRYPTO_TFM_REQ_MAY_SLEEP must not affect the result either. > > However, testing of this currently has many gaps. For example, > individual algorithms are responsible for providing their own chunked > test vectors. But many don't bother to do this or test only one or two > cases, providing poor test coverage. Also, other things such as > misaligned IVs and CRYPTO_TFM_REQ_MAY_SLEEP are never tested at all. > > Test code is also duplicated between the chunked and non-chunked cases, > making it difficult to make other improvements. > > To improve the situation, this patch series basically moves the chunk > descriptions into the testmgr itself so that they are shared by all > algorithms. However, it's done in an extensible way via a new struct > 'testvec_config', which describes not just the scaled chunk lengths but > also all other aspects of the crypto operation besides the data itself > such as the buffer alignments, the request flags, whether the operation > is in-place or not, the IV alignment, and for hash algorithms when to do > each update() and when to use finup() vs. final() vs. digest(). > > Then, this patch series makes skcipher, aead, and hash algorithms be > tested against a list of default testvec_configs, replacing the current > test code. This improves overall test coverage, without reducing test > performance too much. Note that the test vectors themselves are not > changed, except for removing the chunk lists. > > This series also adds randomized fuzz tests, enabled by a new kconfig > option intended for developer use only, where skcipher, aead, and hash > algorithms are tested against many randomly generated testvec_configs. > This provides much more comprehensive test coverage. > > These improved tests have already found many bugs. Patches 1-7 fix the > bugs found so far (*). However, I've only tested implementations that I > can easily test. There will be more bugs found, especially in > hardware-specific drivers. Anyone reading this can help by applying > these patches on your system (especially if it's non-x86 and/or has > crypto accelerators), enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS, and > reporting or fixing any test failures. On an arm64 system with the crypto extensions, crct10dif-arm64-ce and ccm-aes-ce are failing too: [1.632623] alg: hash: crct10dif-arm64-ce test failed (wrong result) on test vector 0, cfg="init+update+update+final two even splits" [ 15.377921] alg: aead: ccm-aes-ce decryption failed with err -74 on test vector 11, cfg="uneven misaligned splits, may sleep" Ard, I'll fix these when I have time but feel free to get to them first. > > This patch series can also be found in git at > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git > branch "testmgr-improvements". > > (*) Except that many AEADs incorrectly change aead_request::base.tfm. > I've left fixing that for later patches. > > Eric Biggers (15): > crypto: aegis - fix handling chunked inputs > crypto: morus - fix handling chunked inputs > crypto: x86/aegis - fix handling chunked inputs and MAY_SLEEP > crypto: x86/morus - fix handling chunked inputs and MAY_SLEEP > crypto: x86/aesni-gcm - fix crash on empty plaintext > crypto: ahash - fix another early termination in hash walk > crypto: arm64/aes-neonbs - fix returning final keystream block > crypto: testmgr - add testvec_config struct and helper functions > crypto: testmgr - introduce CONFIG_CRYPTO_MANAGER_EXTRA_TESTS > crypto: testmgr - implement random testvec_config generation > crypto: testmgr - convert skcipher testing to use testvec_configs > crypto: testmgr - convert aead testing to use testvec_configs > crypto: testmgr - convert hash testing to use testvec_configs > crypto: testmgr - check for skcipher_request corruption > crypto: testmgr - check for aead_request corruption > > arch/arm64/crypto/aes-neonbs-core.S|8 +- > arch/x86/crypto/aegis128-aesni-glue.c | 38 +- > arch/x86/crypto/aegis128l-aesni-glue.c | 38 +- > arch/x86/crypto/aegis256-aesni-glue.c | 38 +- > arch/x86/crypto/aesni-intel_glue.c | 13 +- > arch/x86/crypto/morus1280_glue.c | 40 +- > arch/x86/crypto/morus640_glue.c| 39 +- > crypto/Kconfig | 10 + > crypto/aegis128.c | 14 +- > crypto/aegis128l.c | 14 +- > crypto/aegis256.c | 14 +- > crypto/ahash.c | 14 +- > crypto/morus1280.c | 13 +- > crypto/morus640.c | 13 +- > crypto/testmgr.c | 2552 +--- > crypto/testmgr.h
Re: [PATCH 2/2] Input: st1232 - add support for st1633
On Wed, Jan 23, 2019 at 11:07:55AM +0100, Martin Kepplinger wrote: > On 23.01.19 08:26, Martin Kepplinger wrote: > > From: Martin Kepplinger > > > > Add support for the Sitronix ST1633 touchscreen controller to the st1232 > > driver. > > > > FYI, here's a protocol spec: > www.ampdisplay.com/documents/pdf/AM-320480B6TZQW-TC0H.pdf > > Let me know if you want that link in the commit message. Sure, please add it. Thanks. -- Dmitry
Re: [RFC/RFT PATCH 00/15] crypto: improved skcipher, aead, and hash tests
On Thu, 24 Jan 2019 at 09:48, Eric Biggers wrote: > > On Wed, Jan 23, 2019 at 02:49:11PM -0800, Eric Biggers wrote: > > Hello, > > > > Crypto algorithms must produce the same output for the same input > > regardless of data layout, i.e. how the src and dst scatterlists are > > divided into chunks and how each chunk is aligned. Request flags such > > as CRYPTO_TFM_REQ_MAY_SLEEP must not affect the result either. > > > > However, testing of this currently has many gaps. For example, > > individual algorithms are responsible for providing their own chunked > > test vectors. But many don't bother to do this or test only one or two > > cases, providing poor test coverage. Also, other things such as > > misaligned IVs and CRYPTO_TFM_REQ_MAY_SLEEP are never tested at all. > > > > Test code is also duplicated between the chunked and non-chunked cases, > > making it difficult to make other improvements. > > > > To improve the situation, this patch series basically moves the chunk > > descriptions into the testmgr itself so that they are shared by all > > algorithms. However, it's done in an extensible way via a new struct > > 'testvec_config', which describes not just the scaled chunk lengths but > > also all other aspects of the crypto operation besides the data itself > > such as the buffer alignments, the request flags, whether the operation > > is in-place or not, the IV alignment, and for hash algorithms when to do > > each update() and when to use finup() vs. final() vs. digest(). > > > > Then, this patch series makes skcipher, aead, and hash algorithms be > > tested against a list of default testvec_configs, replacing the current > > test code. This improves overall test coverage, without reducing test > > performance too much. Note that the test vectors themselves are not > > changed, except for removing the chunk lists. > > > > This series also adds randomized fuzz tests, enabled by a new kconfig > > option intended for developer use only, where skcipher, aead, and hash > > algorithms are tested against many randomly generated testvec_configs. > > This provides much more comprehensive test coverage. > > > > These improved tests have already found many bugs. Patches 1-7 fix the > > bugs found so far (*). However, I've only tested implementations that I > > can easily test. There will be more bugs found, especially in > > hardware-specific drivers. Anyone reading this can help by applying > > these patches on your system (especially if it's non-x86 and/or has > > crypto accelerators), enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS, and > > reporting or fixing any test failures. > > On an arm64 system with the crypto extensions, crct10dif-arm64-ce and > ccm-aes-ce > are failing too: > > [1.632623] alg: hash: crct10dif-arm64-ce test failed (wrong result) on > test vector 0, cfg="init+update+update+final two even splits" > [ 15.377921] alg: aead: ccm-aes-ce decryption failed with err -74 on test > vector 11, cfg="uneven misaligned splits, may sleep" > > Ard, I'll fix these when I have time but feel free to get to them first. > Hi Eric, Thanks for yet another round of cleanup I'll look into these, but I'd like to clarify one thing first. IIUC, you are trying to deal with the case where a single scatterlist element describes a range that strides two pages, and I wonder if that is a valid use of scatterlists in the first place. Herbert?
Re: [PATCH v5 2/7] nfc: pn532_uart: Add NXP PN532 to devicetree docs
On Tue, Jan 15, 2019 at 01:59:02PM -0600, Rob Herring wrote: > On Fri, 11 Jan 2019 17:18:05 +0100, Lars Poeschel wrote: > > Add a simple binding doc for the pn532. > > > > Cc: Johan Hovold > > Signed-off-by: Lars Poeschel > > --- > > Changes in v4: > > - Add documentation about reg property in case of i2c > > > > Changes in v3: > > - seperate binding doc instead of entry in trivial-devices.txt > > > > .../devicetree/bindings/nfc/pn532.txt | 33 +++ > > 1 file changed, 33 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/nfc/pn532.txt > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. Thanks for the clarification! To be clear: It was not intentional to not add your tag. It was unknowingness. Thanks again, Lars
Re: [PATCH 00/22] Increase success rates and reduce latency of compaction v3
On Fri, Jan 18, 2019 at 05:51:14PM +, Mel Gorman wrote: > This is a drop-in replacement for the series currently in Andrews tree that > incorporates static checking and compile warning fixes (Dan, YueHaibing) > and extensive review feedback from Vlastimil. Big thanks to Vlastimil as > the review was extremely detailed and a number of issues were caught. Not > all the patches have been acked but I think an update is still worthwhile. > > Andrew, please drop the series you have and replace it with the following > on the off-chance we get bug reports that are fixed already. Doing this > with -fix patches would be relatively painful for little gain. > Andrew? -- Mel Gorman SUSE Labs
Re: [PATCH 07/10] venus: helpers: add three more helper functions
Hi Alex,
Thanks for the review!
On 1/24/19 10:43 AM, Alexandre Courbot wrote:
> On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
> wrote:
>>
>> This adds three more helper functions:
>> * for internal buffers reallocation, applicable when we are doing
>> dynamic resolution change
>> * for initial buffer processing of capture and output queue buffer
>> types
>>
>> All of them will be needed for stateful Codec API support.
>>
>> Signed-off-by: Stanimir Varbanov
>> ---
>> drivers/media/platform/qcom/venus/helpers.c | 82 +
>> drivers/media/platform/qcom/venus/helpers.h | 2 +
>> 2 files changed, 84 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/venus/helpers.c
>> b/drivers/media/platform/qcom/venus/helpers.c
>> index f33bbfea3576..637ce7b82d94 100644
>> --- a/drivers/media/platform/qcom/venus/helpers.c
>> +++ b/drivers/media/platform/qcom/venus/helpers.c
>> @@ -322,6 +322,52 @@ int venus_helper_intbufs_free(struct venus_inst *inst)
>> }
>> EXPORT_SYMBOL_GPL(venus_helper_intbufs_free);
>>
>> +int venus_helper_intbufs_realloc(struct venus_inst *inst)
>
> Does this function actually reallocate buffers? It seems to just free
> what we had previously.
The function free all internal buffers except PERSIST. After that the
buffers are allocated in intbufs_set_buffer function (I know that the
function name is misleading).
>
>
>> +{
>> + enum hfi_version ver = inst->core->res->hfi_version;
>> + struct hfi_buffer_desc bd;
>> + struct intbuf *buf, *n;
>> + int ret;
>> +
>> + list_for_each_entry_safe(buf, n, &inst->internalbufs, list) {
>> + if (buf->type == HFI_BUFFER_INTERNAL_PERSIST ||
>> + buf->type == HFI_BUFFER_INTERNAL_PERSIST_1)
>> + continue;
>> +
>> + memset(&bd, 0, sizeof(bd));
>> + bd.buffer_size = buf->size;
>> + bd.buffer_type = buf->type;
>> + bd.num_buffers = 1;
>> + bd.device_addr = buf->da;
>> + bd.response_required = true;
>> +
>> + ret = hfi_session_unset_buffers(inst, &bd);
>> +
>> + dma_free_attrs(inst->core->dev, buf->size, buf->va, buf->da,
>> + buf->attrs);
>> +
>> + list_del_init(&buf->list);
>> + kfree(buf);
>> + }
>> +
>> + ret = intbufs_set_buffer(inst, HFI_BUFFER_INTERNAL_SCRATCH(ver));
>> + if (ret)
>> + goto err;
>> +
>> + ret = intbufs_set_buffer(inst, HFI_BUFFER_INTERNAL_SCRATCH_1(ver));
>> + if (ret)
>> + goto err;
>> +
>> + ret = intbufs_set_buffer(inst, HFI_BUFFER_INTERNAL_SCRATCH_2(ver));
>> + if (ret)
>> + goto err;
>> +
>> + return 0;
>> +err:
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(venus_helper_intbufs_realloc);
>> +
--
regards,
Stan
Re: [PATCH net-next 02/10] net: macsec: convert to SPDX
Hi Andrew,
On Wed, Jan 23, 2019 at 06:03:06PM +0100, Andrew Lunn wrote:
> On Wed, Jan 23, 2019 at 04:56:30PM +0100, Antoine Tenart wrote:
> > This cosmetic patch converts the macsec implementation license header to
> > the now recommended format, SPDX.
> >
> > Signed-off-by: Antoine Tenart
> > ---
> > drivers/net/macsec.c | 6 +-
> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
> > index 64a982563d59..56e354305f76 100644
> > --- a/drivers/net/macsec.c
> > +++ b/drivers/net/macsec.c
> > @@ -1,12 +1,8 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > /*
> > * drivers/net/macsec.c - MACsec device
> > *
> > * Copyright (c) 2015 Sabrina Dubroca
> > - *
> > - * This program is free software; you can redistribute it and/or modify
> > - * it under the terms of the GNU General Public License as published by
> > - * the Free Software Foundation; either version 2 of the License, or
> > - * (at your option) any later version.
> > */
> >
> > #include
>
> linux$ tail -4 drivers/net/macsec.c
> MODULE_ALIAS_GENL_FAMILY("macsec");
>
> MODULE_DESCRIPTION("MACsec IEEE 802.1AE");
> MODULE_LICENSE("GPL v2");
>
> The license text and the MODULE_LICENSE() don't agree with each other.
> It would be good to fix this as well.
That's right, I'll fix it in v2. In such cases, the license text takes
precedence over the MODULE_LICENSE() definition ?
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH net-next 05/10] net: phy: introduce a phy_driver macsec helper
Hi Andrew,
On Wed, Jan 23, 2019 at 06:08:16PM +0100, Andrew Lunn wrote:
> > +int phy_macsec(struct phy_device *phydev, struct netdev_macsec *macsec)
> > +{
> > + int ret = -EOPNOTSUPP;
> > +
> > + if (!phydev->drv)
> > + return -EIO;
> > +
> > + mutex_lock(&phydev->lock);
> > +
> > + if (phydev->drv->macsec)
> > + ret = phydev->drv->macsec(phydev, macsec);
> > +
> > + mutex_unlock(&phydev->lock);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(phy_macsec);
> > +
>
> > @@ -630,6 +634,10 @@ struct phy_driver {
> > struct ethtool_tunable *tuna,
> > const void *data);
> > int (*set_loopback)(struct phy_device *dev, bool enable);
> > +
> > +#ifdef CONFIG_MACSEC
> > + int (*macsec)(struct phy_device *dev, struct netdev_macsec *macsec);
> > +#endif
>
>
> So the member only exists if CONFIG_MACSEC is defined. So i think you
> need similar protection in phy_macsec() or you are going to try to
> access a member which sometimes does not exist.
Right, I'll fix that and protect the phy_macsec definition within an
'#ifdef CONFIG_MACSEC'.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH] clocksource: sun5i: fail gracefully when clock rate is unavailable
On Thu, Jan 10, 2019 at 5:19 PM Daniel Lezcano
wrote:
>
> On 10/01/2019 07:22, Chen-Yu Tsai wrote:
> > If the clock tree is not fully populated when the timer-sun5i init code
> > is called, attempts to get the clock rate for the timer would fail and
> > return 0.
> >
> > Make the init code for both clock events and clocksource check the
> > returned clock rate and fail gracefully if the result is 0, instead of
> > causing a divide by 0 exception later on.
> >
> > Fixes: 4a59058f0b09 ("clocksource/drivers/sun5i: Refactor the current code")
> > Signed-off-by: Chen-Yu Tsai
> > ---
>
> Applied thanks.
I'm not seeing this in linux-next, nor the patch
arm64: arch_timer: Workaround for Allwinner A64 timer instability
Any idea where these ended up?
Thanks
ChenYu
Re: [PATCH] mm: Move maxable seq_file logic into a single place
On Thu 24-01-19 01:17:18, Chris Down wrote:
> memcg has a significant number of files exposed to kernfs where their
> value is either exposed directly or is "max" in the case of
> PAGE_COUNTER_MAX.
>
> There's a fair amount of duplicated code here, since each file involves
> turning a seq_file to a css, getting the memcg from the css, safely
> reading the counter value, and then doing the right thing depending on
> whether the value is PAGE_COUNTER_MAX or not.
>
> This patch adds the macro DEFINE_MEMCG_MAX_OR_VAL, which defines and
> implements a generic way to do this work, avoiding fragmenting logic.
I am not a huge fan of macro defined functions but it is true this will
save more LOC than a simple helper used by each $foo_show function.
> Signed-off-by: Chris Down
> Cc: Andrew Morton
> Cc: Johannes Weiner
> Cc: Tejun Heo
> Cc: Roman Gushchin
> Cc: linux-kernel@vger.kernel.org
> Cc: cgro...@vger.kernel.org
> Cc: linux...@kvack.org
> Cc: kernel-t...@fb.com
Acked-by: Michal Hocko
Thanks!
> ---
> mm/memcontrol.c | 78 -
> 1 file changed, 18 insertions(+), 60 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 18f4aefbe0bf..90e2e0ff5ed9 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -261,6 +261,19 @@ struct cgroup_subsys_state *vmpressure_to_css(struct
> vmpressure *vmpr)
> return &container_of(vmpr, struct mem_cgroup, vmpressure)->css;
> }
>
> +/* Convenience macro to define seq_file mutators that can return "max" */
> +#define DEFINE_MEMCG_MAX_OR_VAL(name, key) \
> + static int name(struct seq_file *m, void *v)\
> + { \
> + struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m)); \
> + unsigned long val = READ_ONCE(memcg->key); \
> + if (val == PAGE_COUNTER_MAX)\
> + seq_puts(m, "max\n"); \
> + else\
> + seq_printf(m, "%llu\n", (u64)val * PAGE_SIZE); \
> + return 0; \
> + }
> +
> #ifdef CONFIG_MEMCG_KMEM
> /*
> * This will be the memcg's index in each cache's ->memcg_params.memcg_caches.
> @@ -5383,18 +5396,7 @@ static u64 memory_current_read(struct
> cgroup_subsys_state *css,
> return (u64)page_counter_read(&memcg->memory) * PAGE_SIZE;
> }
>
> -static int memory_min_show(struct seq_file *m, void *v)
> -{
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> - unsigned long min = READ_ONCE(memcg->memory.min);
> -
> - if (min == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)min * PAGE_SIZE);
> -
> - return 0;
> -}
> +DEFINE_MEMCG_MAX_OR_VAL(memory_min_show, memory.min)
>
> static ssize_t memory_min_write(struct kernfs_open_file *of,
> char *buf, size_t nbytes, loff_t off)
> @@ -5413,18 +5415,7 @@ static ssize_t memory_min_write(struct
> kernfs_open_file *of,
> return nbytes;
> }
>
> -static int memory_low_show(struct seq_file *m, void *v)
> -{
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> - unsigned long low = READ_ONCE(memcg->memory.low);
> -
> - if (low == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)low * PAGE_SIZE);
> -
> - return 0;
> -}
> +DEFINE_MEMCG_MAX_OR_VAL(memory_low_show, memory.low)
>
> static ssize_t memory_low_write(struct kernfs_open_file *of,
> char *buf, size_t nbytes, loff_t off)
> @@ -5443,18 +5434,7 @@ static ssize_t memory_low_write(struct
> kernfs_open_file *of,
> return nbytes;
> }
>
> -static int memory_high_show(struct seq_file *m, void *v)
> -{
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> - unsigned long high = READ_ONCE(memcg->high);
> -
> - if (high == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)high * PAGE_SIZE);
> -
> - return 0;
> -}
> +DEFINE_MEMCG_MAX_OR_VAL(memory_high_show, high)
>
> static ssize_t memory_high_write(struct kernfs_open_file *of,
>char *buf, size_t nbytes, loff_t off)
> @@ -5480,18 +5460,7 @@ static ssize_t memory_high_write(struct
> kernfs_open_file *of,
> return nbytes;
> }
>
> -static int memory_max_show(struct seq_file *m, void *v)
> -{
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> - unsigned long max = READ_ONCE(memcg->memory.max);
> -
> - if (max == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)max * PAGE_SI
Re: [PATCH net-next 03/10] net: macsec: move some definitions in a dedicated header
Hi Florian, On Wed, Jan 23, 2019 at 12:11:37PM -0800, Florian Fainelli wrote: > On 1/23/19 7:56 AM, Antoine Tenart wrote: > > This patch moves some structure, type and identifier definitions into a > > MACsec specific header. This patch does not modify how the MACsec code > > is running and only move things around. This is a preparation for the > > future MACsec hardware offloading support, which will re-use those > > definitions outside macsec.c. > > > > Signed-off-by: Antoine Tenart > > --- > > drivers/net/macsec.c | 164 +-- > > include/net/macsec.h | 178 +++ > > 2 files changed, 179 insertions(+), 163 deletions(-) > > create mode 100644 include/net/macsec.h > > > > diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c > > index 56e354305f76..c3a138dd4386 100644 > > --- a/drivers/net/macsec.c > > +++ b/drivers/net/macsec.c > > @@ -17,10 +17,9 @@ > > #include > > #include > > > > +#include > > #include > > I would probably go with include/linux/if_macsec.h and have > uapi/linux/if_macsec.h include that file directly. This would be > consistent with other types of network interfaces: bridge, vlan etc. It's always a good idea to stay consistent with what's already done. I'll update in v2. Thanks! Antoine -- Antoine Ténart, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v4 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller
On Mon, Jan 21, 2019 at 8:29 PM Rob Herring wrote:
>
> On Mon, Jan 21, 2019 at 03:50:42PM +0530, Yash Shah wrote:
> > DT documentation for PWM controller added.
> >
> > Signed-off-by: Wesley W. Terpstra
> > [Atish: Compatible string update]
> > Signed-off-by: Atish Patra
> > Signed-off-by: Yash Shah
> > ---
> > .../devicetree/bindings/pwm/pwm-sifive.txt | 37
> > ++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > new file mode 100644
> > index 000..b207908
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > @@ -0,0 +1,37 @@
> > +SiFive PWM controller
> > +
> > +Unlike most other PWM controllers, the SiFive PWM controller currently only
> > +supports one period for all channels in the PWM. This is set globally in
> > DTS.
> > +The period also has significant restrictions on the values it can achieve,
> > +which the driver rounds to the nearest achievable frequency.
> > +
> > +Required properties:
> > +- compatible: Should be "sifive,pwmX" and "sifive,$socname-pwm".
>
> The order here is wrong.
Will fix the order.
>
> You still need to enumeration valid version numbers. Is 'sifive,pwm20'
> valid?
Yes
>
> > + Please refer to sifive-blocks-ip-versioning.txt for details.
> > +- reg: physical base address and length of the controller's registers
> > +- clocks: Should contain a clock identifier for the PWM's parent clock.
> > +- #pwm-cells: Should be 2.
> > + Refer to bindings/pwm/pwm.txt for details.
> > +- sifive,period-ns: the driver will get as close to this period as it can
> > +- interrupts: one interrupt per PWM channel
>
> How many channels? If variable, is the a max number?
Max 4 channels.
>
> > +
> > +PWM RTL that corresponds to the IP block version numbers can be found
> > +here:
> > +
> > +https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
>
> Put this in the description at the top.
Sure.
>
> > +
> > +Further information on the format of the IP
> > +block-specific version numbers can be found in
> > +Documentation/devicetree/bindings/sifive/sifive-blocks-ip-versioning.txt
>
> You already said this.
Will remove redundant info.
>
> > +
> > +Examples:
> > +
> > +pwm: pwm@1002 {
> > + compatible = "sifive,fu540-c000-pwm","sifive,pwm0";
>
> Space after the ',' needed.
Sure
>
> > + reg = <0x0 0x1002 0x0 0x1000>;
> > + clocks = <&tlclk>;
> > + interrupt-parent = <&plic>;
> > + interrupts = <42 43 44 45>;
> > + #pwm-cells = <2>;
> > + sifive,period-ns = <100>;
> > +};
> > --
> > 1.9.1
> >
Thanks for the feedback
Re: [PATCH] media: docs-rst: Document m2m stateless video decoder interface
Hi,
On Thu, 2019-01-24 at 17:07 +0900, Tomasz Figa wrote:
> On Wed, Jan 23, 2019 at 7:42 PM Paul Kocialkowski
> wrote:
> > Hi Alex,
> >
> > On Wed, 2019-01-23 at 18:43 +0900, Alexandre Courbot wrote:
> > > On Tue, Jan 22, 2019 at 7:10 PM Paul Kocialkowski
> > > wrote:
> > > > Hi,
> > > >
> > > > On Tue, 2019-01-22 at 17:19 +0900, Tomasz Figa wrote:
> > > > > Hi Paul,
> > > > >
> > > > > On Fri, Dec 7, 2018 at 5:30 PM Paul Kocialkowski
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Thanks for this new version! I only have one comment left, see
> > > > > > below.
> > > > > >
> > > > > > On Wed, 2018-12-05 at 19:01 +0900, Alexandre Courbot wrote:
> > > > > > > Documents the protocol that user-space should follow when
> > > > > > > communicating with stateless video decoders.
> > > > > > >
> > > > > > > The stateless video decoding API makes use of the new request and
> > > > > > > tags
> > > > > > > APIs. While it has been implemented with the Cedrus driver so
> > > > > > > far, it
> > > > > > > should probably still be considered staging for a short while.
> > > > > > >
> > > > > > > Signed-off-by: Alexandre Courbot
> > > > > > > ---
> > > > > > > Removing the RFC flag this time. Changes since RFCv3:
> > > > > > >
> > > > > > > * Included Tomasz and Hans feedback,
> > > > > > > * Expanded the decoding section to better describe the use of
> > > > > > > requests,
> > > > > > > * Use the tags API.
> > > > > > >
> > > > > > > Documentation/media/uapi/v4l/dev-codec.rst| 5 +
> > > > > > > .../media/uapi/v4l/dev-stateless-decoder.rst | 399
> > > > > > > ++
> > > > > > > 2 files changed, 404 insertions(+)
> > > > > > > create mode 100644
> > > > > > > Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > >
> > > > > > > diff --git a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > index c61e938bd8dc..3e6a3e883f11 100644
> > > > > > > --- a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > +++ b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > @@ -6,6 +6,11 @@
> > > > > > > Codec Interface
> > > > > > > ***
> > > > > > >
> > > > > > > +.. toctree::
> > > > > > > +:maxdepth: 1
> > > > > > > +
> > > > > > > +dev-stateless-decoder
> > > > > > > +
> > > > > > > A V4L2 codec can compress, decompress, transform, or otherwise
> > > > > > > convert
> > > > > > > video data from one format into another format, in memory.
> > > > > > > Typically
> > > > > > > such devices are memory-to-memory devices (i.e. devices with the
> > > > > > > diff --git
> > > > > > > a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > > b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > > new file mode 100644
> > > > > > > index ..7a781c89bd59
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > > @@ -0,0 +1,399 @@
> > > > > > > +.. -*- coding: utf-8; mode: rst -*-
> > > > > > > +
> > > > > > > +.. _stateless_decoder:
> > > > > > > +
> > > > > > > +**
> > > > > > > +Memory-to-memory Stateless Video Decoder Interface
> > > > > > > +**
> > > > > > > +
> > > > > > > +A stateless decoder is a decoder that works without retaining
> > > > > > > any kind of state
> > > > > > > +between processing frames. This means that each frame is decoded
> > > > > > > independently
> > > > > > > +of any previous and future frames, and that the client is
> > > > > > > responsible for
> > > > > > > +maintaining the decoding state and providing it to the decoder
> > > > > > > with each
> > > > > > > +decoding request. This is in contrast to the stateful video
> > > > > > > decoder interface,
> > > > > > > +where the hardware and driver maintain the decoding state and
> > > > > > > all the client
> > > > > > > +has to do is to provide the raw encoded stream.
> > > > > > > +
> > > > > > > +This section describes how user-space ("the client") is expected
> > > > > > > to communicate
> > > > > > > +with such decoders in order to successfully decode an encoded
> > > > > > > stream. Compared
> > > > > > > +to stateful codecs, the decoder/client sequence is simpler, but
> > > > > > > the cost of
> > > > > > > +this simplicity is extra complexity in the client which must
> > > > > > > maintain a
> > > > > > > +consistent decoding state.
> > > > > > > +
> > > > > > > +Stateless decoders make use of the request API and buffer tags.
> > > > > > > A stateless
> > > > > > > +decoder must thus expose the following capabilities on its
> > > > > > > queues when
> > > > > > > +:c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are
> > > > > > > invoked:
> > > > > > > +
> > > > > > > +* The ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability must be set
> > > > > > > on the
> > > > > > > + ``
Re: [RFC PATCH v3 2/2] pwm: imx: Configure output to GPIO in disabled state
On 12.12.2018 13:12, Uwe Kleine-König wrote: On Wed, Dec 12, 2018 at 11:42:17AM +, Vokáč Michal wrote: On 12.12.2018 09:01, Uwe Kleine-König wrote: On Thu, Dec 06, 2018 at 01:41:31PM +, Vokáč Michal wrote: Normally the PWM output is held LOW when PWM is disabled. This can cause problems when inverted PWM signal polarity is needed. With this behavior the connected circuit is fed by 100% duty cycle instead of being shut-off. Allow users to define a "pwm" and a "gpio" pinctrl states. The pwm pinctrl state is selected when PWM is enabled and the gpio pinctrl state is selected when PWM is disabled. In the gpio state the new pwm-gpios GPIO is configured as input and the internal pull-up resistor is used to pull the output level high. If all the pinctrl states and the pwm-gpios GPIO are not correctly specified in DT the PWM work as usual. As an example, with this patch a PWM controlled backlight with inversed signal polarity can be used in full brightness range. Without this patch the backlight can not be turned off as brightness = 0 disables the PWM and that in turn set PWM output LOW, that is full brightness. Inverted output of the PWM with "default" and with "pwm"+"gpio" pinctrl: +--++---+--- +-+ | After reset | Bootloader | PWM probe | PWM| PWM | | 100k pull-up || | enable 30% | disable | +--++---++-+ | pinctrl |none|default| default | default | | out H __ __ __ | | out L \_/ \_/ \_/\ | | ^^^| +--++---++-+ | pinctrl |none| gpio | pwm| gpio| | out H __ __ __ _ | | out L \_/ \_/ \_/ | | ^^^| +--+ Signed-off-by: Michal Vokáč --- Changes in v3: - Commit message update. - Minor fix in code comment (Uwe) - Align function arguments to the opening parentheses. (Uwe) - Do not test devm_pinctrl_get for NULL. (Thierry) - Convert all messages to dev_dbg() (Thierry) - Do not actively drive the pin in gpio state. Configure it as input and rely solely on the internal pull-up. (Thierry) Changes in v2: - Utilize the "pwm" and "gpio" pinctrl states. - Use the pwm-gpios signal to drive the output in "gpio" pinctrl state. - Select the right pinctrl state in probe. drivers/pwm/pwm-imx.c | 77 +++ 1 file changed, 77 insertions(+) [ snip ] On thing I noticed while looking at the rcar driver is: This doesn't wait for the current period to end. Is this supposed to happen? Also for the enable case the hardware is configured for the desired duty cycle and only then the pinctrl is switched to pwm. Both might result in a spike that is not desired. The behavior should not change from how imx-pwm was working before. When PWM is disabled the output is immediately gated off (put into the idle state) independently on the period. I measured this. Oh really, I wasn't aware of that. This is another bug in the imx pwm then (I think). I kind of expect that when hit a disable button the output is immediately put into the idle state. To me it does not seem appropriate to wait the whole period, or even just the active part of the period. If duty=100% and period=4s (current maximum), in the worst case you would have to wait 4s until you stop the PWM. Quite a long time of driving something you actually wanted to be shut off. For the enable case you would certainly not get any additional spikes. Yes, there is a possibility for a spike: If you configure for say 40%: __ pwm output : ___/ \__/ \__ muxing : GPIO| PWM_ actual output: /\__/ \__ OK, you are right. The worst thing that may happen is that the first period will be slightly shorter depending on how long it takes to test the pinctrl and switch the muxing. And this is unavoidable, it would happen even if you wait for the start of a period. The test + muxing still takes some time. You could first configure for duty_cycle 0 and a short period, then mux to PWM and then configure the correct duty cycle. Ditto for disable. I agree it can be solved for the enable case but I do not see the point in doing so for the disable case. Can you elaborate on how it could be useful? This is what I came up with: diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c index 55666cc..f76a326 100644 --- a/drivers/pwm/pwm-imx27.c +++ b/drivers/pwm/pwm-imx27.c @@
Re: [RFC PATCH v4 2/2] pwm: imx: Configure output to GPIO in disabled state
On 13.12.2018 09:56, Uwe Kleine-König wrote: On Wed, Dec 12, 2018 at 12:04:51PM +, Vokáč Michal wrote: Normally the PWM output is held LOW when PWM is disabled. This can cause problems when inverted PWM signal polarity is needed. With this behavior the connected circuit is fed by 100% duty cycle instead of being shut-off. Allow users to define a "pwm" and a "gpio" pinctrl states. The pwm pinctrl state is selected when PWM is enabled and the gpio pinctrl state is selected when PWM is disabled. In the gpio state the new pwm-gpios GPIO is configured as input and the internal pull-up resistor is used to pull the output level high. If all the pinctrl states and the pwm-gpios GPIO are not correctly specified in DT the PWM work as usual. As an example, with this patch a PWM controlled backlight with inversed signal polarity can be used in full brightness range. Without this patch the backlight can not be turned off as brightness = 0 disables the PWM and that in turn set PWM output LOW, that is full brightness. Inverted output of the PWM with "default" and with "pwm"+"gpio" pinctrl: +--++---+--- +-+ | After reset | Bootloader | PWM probe | PWM| PWM | | 100k pull-up || | enable 30% | disable | +--++---++-+ | pinctrl |none|default| default | default | | out H __ __ __ | | out L \_/ \_/ \_/\ | | ^^^| +--++---++-+ | pinctrl |none| gpio | pwm| gpio| | out H __ __ __ _ | | out L \_/ \_/ \_/ | | ^^^| +--+ Just for the record: My last concern against this patch set (that I sent for v3) and v4 of the series criss-crossed. So the problem with the peaks that could happen is still unaddressed. Hi Uwe et al. Sorry for the huge delay. I hope we will be able to refresh our memories and continue on the discussion. I will react to your comments in the appropriate v3 thread. And sorry for this v4. I was too fast on the trigger back then.. Michal
Re: [PATCH] media: docs-rst: Document m2m stateless video decoder interface
On Thu, Jan 24, 2019 at 5:59 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Thu, 2019-01-24 at 17:07 +0900, Tomasz Figa wrote:
> > On Wed, Jan 23, 2019 at 7:42 PM Paul Kocialkowski
> > wrote:
> > > Hi Alex,
> > >
> > > On Wed, 2019-01-23 at 18:43 +0900, Alexandre Courbot wrote:
> > > > On Tue, Jan 22, 2019 at 7:10 PM Paul Kocialkowski
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 2019-01-22 at 17:19 +0900, Tomasz Figa wrote:
> > > > > > Hi Paul,
> > > > > >
> > > > > > On Fri, Dec 7, 2018 at 5:30 PM Paul Kocialkowski
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Thanks for this new version! I only have one comment left, see
> > > > > > > below.
> > > > > > >
> > > > > > > On Wed, 2018-12-05 at 19:01 +0900, Alexandre Courbot wrote:
> > > > > > > > Documents the protocol that user-space should follow when
> > > > > > > > communicating with stateless video decoders.
> > > > > > > >
> > > > > > > > The stateless video decoding API makes use of the new request
> > > > > > > > and tags
> > > > > > > > APIs. While it has been implemented with the Cedrus driver so
> > > > > > > > far, it
> > > > > > > > should probably still be considered staging for a short while.
> > > > > > > >
> > > > > > > > Signed-off-by: Alexandre Courbot
> > > > > > > > ---
> > > > > > > > Removing the RFC flag this time. Changes since RFCv3:
> > > > > > > >
> > > > > > > > * Included Tomasz and Hans feedback,
> > > > > > > > * Expanded the decoding section to better describe the use of
> > > > > > > > requests,
> > > > > > > > * Use the tags API.
> > > > > > > >
> > > > > > > > Documentation/media/uapi/v4l/dev-codec.rst| 5 +
> > > > > > > > .../media/uapi/v4l/dev-stateless-decoder.rst | 399
> > > > > > > > ++
> > > > > > > > 2 files changed, 404 insertions(+)
> > > > > > > > create mode 100644
> > > > > > > > Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > > >
> > > > > > > > diff --git a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > > b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > > index c61e938bd8dc..3e6a3e883f11 100644
> > > > > > > > --- a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > > +++ b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > > > @@ -6,6 +6,11 @@
> > > > > > > > Codec Interface
> > > > > > > > ***
> > > > > > > >
> > > > > > > > +.. toctree::
> > > > > > > > +:maxdepth: 1
> > > > > > > > +
> > > > > > > > +dev-stateless-decoder
> > > > > > > > +
> > > > > > > > A V4L2 codec can compress, decompress, transform, or otherwise
> > > > > > > > convert
> > > > > > > > video data from one format into another format, in memory.
> > > > > > > > Typically
> > > > > > > > such devices are memory-to-memory devices (i.e. devices with
> > > > > > > > the
> > > > > > > > diff --git
> > > > > > > > a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > > > b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > > > new file mode 100644
> > > > > > > > index ..7a781c89bd59
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > > > @@ -0,0 +1,399 @@
> > > > > > > > +.. -*- coding: utf-8; mode: rst -*-
> > > > > > > > +
> > > > > > > > +.. _stateless_decoder:
> > > > > > > > +
> > > > > > > > +**
> > > > > > > > +Memory-to-memory Stateless Video Decoder Interface
> > > > > > > > +**
> > > > > > > > +
> > > > > > > > +A stateless decoder is a decoder that works without retaining
> > > > > > > > any kind of state
> > > > > > > > +between processing frames. This means that each frame is
> > > > > > > > decoded independently
> > > > > > > > +of any previous and future frames, and that the client is
> > > > > > > > responsible for
> > > > > > > > +maintaining the decoding state and providing it to the decoder
> > > > > > > > with each
> > > > > > > > +decoding request. This is in contrast to the stateful video
> > > > > > > > decoder interface,
> > > > > > > > +where the hardware and driver maintain the decoding state and
> > > > > > > > all the client
> > > > > > > > +has to do is to provide the raw encoded stream.
> > > > > > > > +
> > > > > > > > +This section describes how user-space ("the client") is
> > > > > > > > expected to communicate
> > > > > > > > +with such decoders in order to successfully decode an encoded
> > > > > > > > stream. Compared
> > > > > > > > +to stateful codecs, the decoder/client sequence is simpler,
> > > > > > > > but the cost of
> > > > > > > > +this simplicity is extra complexity in the client which must
> > > > > > > > maintain a
> > > > > > > > +consistent decoding state.
> > > > > > > > +
> > > > > > > > +Stateless decoders make use of the request API and buffer
> > > > > > > > tags. A stateless
> > > > > > > > +decoder must thus expose the followin
Re: [PATCH] media: docs-rst: Document m2m stateless video decoder interface
On Wed, Jan 23, 2019 at 7:42 PM Paul Kocialkowski
wrote:
>
> Hi Alex,
>
> On Wed, 2019-01-23 at 18:43 +0900, Alexandre Courbot wrote:
> > On Tue, Jan 22, 2019 at 7:10 PM Paul Kocialkowski
> > wrote:
> > > Hi,
> > >
> > > On Tue, 2019-01-22 at 17:19 +0900, Tomasz Figa wrote:
> > > > Hi Paul,
> > > >
> > > > On Fri, Dec 7, 2018 at 5:30 PM Paul Kocialkowski
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > Thanks for this new version! I only have one comment left, see below.
> > > > >
> > > > > On Wed, 2018-12-05 at 19:01 +0900, Alexandre Courbot wrote:
> > > > > > Documents the protocol that user-space should follow when
> > > > > > communicating with stateless video decoders.
> > > > > >
> > > > > > The stateless video decoding API makes use of the new request and
> > > > > > tags
> > > > > > APIs. While it has been implemented with the Cedrus driver so far,
> > > > > > it
> > > > > > should probably still be considered staging for a short while.
> > > > > >
> > > > > > Signed-off-by: Alexandre Courbot
> > > > > > ---
> > > > > > Removing the RFC flag this time. Changes since RFCv3:
> > > > > >
> > > > > > * Included Tomasz and Hans feedback,
> > > > > > * Expanded the decoding section to better describe the use of
> > > > > > requests,
> > > > > > * Use the tags API.
> > > > > >
> > > > > > Documentation/media/uapi/v4l/dev-codec.rst| 5 +
> > > > > > .../media/uapi/v4l/dev-stateless-decoder.rst | 399
> > > > > > ++
> > > > > > 2 files changed, 404 insertions(+)
> > > > > > create mode 100644
> > > > > > Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > >
> > > > > > diff --git a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > index c61e938bd8dc..3e6a3e883f11 100644
> > > > > > --- a/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > +++ b/Documentation/media/uapi/v4l/dev-codec.rst
> > > > > > @@ -6,6 +6,11 @@
> > > > > > Codec Interface
> > > > > > ***
> > > > > >
> > > > > > +.. toctree::
> > > > > > +:maxdepth: 1
> > > > > > +
> > > > > > +dev-stateless-decoder
> > > > > > +
> > > > > > A V4L2 codec can compress, decompress, transform, or otherwise
> > > > > > convert
> > > > > > video data from one format into another format, in memory.
> > > > > > Typically
> > > > > > such devices are memory-to-memory devices (i.e. devices with the
> > > > > > diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > new file mode 100644
> > > > > > index ..7a781c89bd59
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
> > > > > > @@ -0,0 +1,399 @@
> > > > > > +.. -*- coding: utf-8; mode: rst -*-
> > > > > > +
> > > > > > +.. _stateless_decoder:
> > > > > > +
> > > > > > +**
> > > > > > +Memory-to-memory Stateless Video Decoder Interface
> > > > > > +**
> > > > > > +
> > > > > > +A stateless decoder is a decoder that works without retaining any
> > > > > > kind of state
> > > > > > +between processing frames. This means that each frame is decoded
> > > > > > independently
> > > > > > +of any previous and future frames, and that the client is
> > > > > > responsible for
> > > > > > +maintaining the decoding state and providing it to the decoder
> > > > > > with each
> > > > > > +decoding request. This is in contrast to the stateful video
> > > > > > decoder interface,
> > > > > > +where the hardware and driver maintain the decoding state and all
> > > > > > the client
> > > > > > +has to do is to provide the raw encoded stream.
> > > > > > +
> > > > > > +This section describes how user-space ("the client") is expected
> > > > > > to communicate
> > > > > > +with such decoders in order to successfully decode an encoded
> > > > > > stream. Compared
> > > > > > +to stateful codecs, the decoder/client sequence is simpler, but
> > > > > > the cost of
> > > > > > +this simplicity is extra complexity in the client which must
> > > > > > maintain a
> > > > > > +consistent decoding state.
> > > > > > +
> > > > > > +Stateless decoders make use of the request API and buffer tags. A
> > > > > > stateless
> > > > > > +decoder must thus expose the following capabilities on its queues
> > > > > > when
> > > > > > +:c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are
> > > > > > invoked:
> > > > > > +
> > > > > > +* The ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability must be set on
> > > > > > the
> > > > > > + ``OUTPUT`` queue,
> > > > > > +
> > > > > > +* The ``V4L2_BUF_CAP_SUPPORTS_TAGS`` capability must be set on the
> > > > > > ``OUTPUT``
> > > > > > + and ``CAPTURE`` queues,
> > > > > > +
> > > > >
> > > > > [...]
> > > > >
> > > > > > +Decoding
> > > > > > +
> > > > > > +
> > > > > > +For each frame, the client
Re: [PATCH v7 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings
Hi Mason,
On Thu, Jan 24, 2019 at 3:39 AM wrote:
> > "Marek Vasut"
> > 2019/01/24 上午 09:54
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-
> > rpc.txt b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> > > new file mode 100644
> > > index 000..305bd10
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> > > @@ -0,0 +1,46 @@
> > > +Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
> > > +
> > > +
> > > +Required properties:
> > > +- compatible: should be an SoC-specific compatible value, followed by
> > > + "renesas,rcar-gen3-rpc" as a fallback, i.e.,
> > > + "renesas,r8a77995-rpc", "renesas,rcar-gen3-rpc".
> > > + "renesas,r8a7795-rpc" (R-Car H3)
> > > + "renesas,r8a7796-rpc" (R-Car M3-W)
> > > + "renesas,r8a77965-rpc" (R-Car M3-N)
> > > + "renesas,r8a77970-rpc" (R-Car V3M)
> > > + "renesas,r8a77980-rpc" (R-Car V3H)
> > > + "renesas,r8a77990-rpc" (R-Car E3)
> > > + "renesas,r8a77995-rpc" (R-Car D3)
> >
> > Was it tested on all of those SoCs and do we already handle all the
> > quirks of those ?
>
> These are R-Car Gen3 series and I list these by Geert's comments,
> or I misunderstand Geert's comments ?
I think you misunderstood. Typically we only list the SoC-specific
compatible values for SoCs that have been tested with the driver.
So for now I'd go with:
- compatible: should be an SoC-specific compatible value, followed by
"renesas,rcar-gen3-rpc" as a fallback.
Supported SoC-specific values are:
- "renesas,r8a77995-rpc" (R-Car D3)
The list can be extended when the driver has been tested/enhanced to
support more SoC types.
Does that sound OK?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] media: docs-rst: Document memory-to-memory video decoder interface
On Wed, Jan 23, 2019 at 2:27 PM Tomasz Figa wrote: > > On Tue, Jan 22, 2019 at 11:47 PM Hans Verkuil wrote: > > > > On 01/22/19 11:02, Tomasz Figa wrote: [snip] > > >>> + one ``CAPTURE`` buffer, the following cases are defined: > > >>> + > > >>> + * one ``OUTPUT`` buffer generates multiple ``CAPTURE`` buffers: the > > >>> same > > >>> + ``OUTPUT`` timestamp will be copied to multiple ``CAPTURE`` > > >>> buffers, > > >>> + > > >>> + * multiple ``OUTPUT`` buffers generate one ``CAPTURE`` buffer: > > >>> timestamp of > > >>> + the ``OUTPUT`` buffer queued last will be copied, > > >>> + > > >>> + * the decoding order differs from the display order (i.e. the > > >>> + ``CAPTURE`` buffers are out-of-order compared to the ``OUTPUT`` > > >>> buffers): > > >>> + ``CAPTURE`` timestamps will not retain the order of ``OUTPUT`` > > >>> timestamps > > >>> + and thus monotonicity of the timestamps cannot be guaranteed. > > > > I think this last point should be rewritten. The timestamp is just a value > > that > > is copied, there are no monotonicity requirements for m2m devices in > > general. > > > > Actually I just realized the last point might not even be achievable > for some of the decoders (s5p-mfc, mtk-vcodec), as they don't report > which frame originates from which bitstream buffer and the driver just > picks the most recently consumed OUTPUT buffer to copy the timestamp > from. (s5p-mfc actually "forgets" to set the timestamp in some cases > too...) > > I need to think a bit more about this. Actually I misread the code. Both s5p-mfc and mtk-vcodec seem to correctly match the buffers. Best regards, Tomasz
Re: [PATCH v7 2/2] sched/fair: update scale invariance of PELT
Sorry; trying to get back to this and re-reading the old conversations. On Thu, Nov 29, 2018 at 03:13:16PM +, Patrick Bellasi wrote: > On 29-Nov 13:53, Peter Zijlstra wrote: > > On Wed, Nov 28, 2018 at 11:53:36AM +, Patrick Bellasi wrote: > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > index ac855b2f4774..93e0cf5d8a76 100644 > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -3661,6 +3661,10 @@ util_est_dequeue(struct cfs_rq *cfs_rq, struct > > > task_struct *p, bool task_sleep) > > > if (!task_sleep) > > > return; > > > > > > + /* Skip samples which do not represent an actual utilization */ > > > + if (unlikely(task_util(p) > capacity_of(task_cpu(p > > > + return; > > > + > > > /* > > >* If the PELT values haven't changed since enqueue time, > > >* skip the util_est update. > > > > Would you not want something like: > > > > min(task_util(p), capacity_of(task_cpu(p))) > > > > And is this the only place where we need this? > > Mmm... even this could be an over-estimation: > > I've just posted an example in my last reply to Vincent, end of: > >Message-ID: <20181129150020.GF23094@e110439-lin> >https://lore.kernel.org/lkml/20181129150020.GF23094@e110439-lin/ In particular this bit: | Seems we agree that, when there is no idle time: | - the two 15% tasks will be overestimated | - their utilization will reach 50% after a while Right? > > OTOH, if the task is always running, it will be always running > > irrespective of where it runs. > > That's not what I'm concerned about. I'm concerned about small tasks > which are running on limited capacity (e.g. due to thermal capping) > without idle time. In this case, the new "utilization" signal could > overestimate the real task needs. > > > Not storing these samples seems weird though; this is the exact > > condition you want to record -- the task is very active, if we skip > > these, we'll come back at a low frequency on the next wakeup. > > When there is not idle time, we don't know if the reported > utilization, above the cpu capacity, is due to the task being bigger... > or just the new utilization signal converging towards: > > 100% / RUNNABLE_TASKS_COUNT So if I'm not mistaken we then have 3 cases: 1) runnable == util <= capacity no contention, idle 2) runnable == util > capacity no contention, no idle 3) runnable > util contention, no idle For 1) we can use: 'util' For 2) we can use: 'capacity' For 3) we can use: 'util * capacity >> 10' (note that 2 is a special case of 3 when u=1) This should work right? Now, instead of doing complicated things like that, you instead figure that when there's no idle there's also no dequeue happening and we can simply short-cut by skipping the entire thing, forgetting everything about 2,3. Did I get that right?
Re: [PATCH v9 1/4] clk: meson: add one based divider support for sclk divider
Hi Jerome,
On 2019/1/22 17:25, Jerome Brunet wrote:
> On Tue, 2019-01-08 at 21:50 +0800, Jianxin Pan wrote:
>> When CLK_DIVIDER_ONE_BASED flag is set, the sclk divider will be:
>> one based divider (div = val), and zero value gates the clock
>>
>> Signed-off-by: Jianxin Pan
>> ---
>> drivers/clk/meson/Makefile | 3 ++-
>> drivers/clk/meson/clkc-audio.h | 8 --
>> drivers/clk/meson/clkc.h | 10 ++-
>> drivers/clk/meson/sclk-div.c | 59 ---
>> ---
>> 4 files changed, 50 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index a849aa8..acd8694 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -4,7 +4,8 @@
>>
>> obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o vid-
>> pll-div.o
>> obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-input.o
>> -obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO) += clk-triphase.o sclk-div.o
>> +obj-$(CONFIG_COMMON_CLK_AMLOGIC) += sclk-div.o
>> +obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO) += clk-triphase.o
>> obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>> obj-$(CONFIG_COMMON_CLK_GXBB)+= gxbb.o gxbb-aoclk.o gxbb-aoclk-
>> 32k.o
>> diff --git a/drivers/clk/meson/clkc-audio.h b/drivers/clk/meson/clkc-audio.h
>> index 0a7c157..286ff12 100644
>> --- a/drivers/clk/meson/clkc-audio.h
>> +++ b/drivers/clk/meson/clkc-audio.h
>> @@ -15,14 +15,6 @@ struct meson_clk_triphase_data {
>> struct parm ph2;
>> };
>>
>> -struct meson_sclk_div_data {
>> -struct parm div;
>> -struct parm hi;
>> -unsigned int cached_div;
>> -struct clk_duty cached_duty;
>> -};
>> -
>> extern const struct clk_ops meson_clk_triphase_ops;
>> -extern const struct clk_ops meson_sclk_div_ops;
>>
>> #endif /* __MESON_CLKC_AUDIO_H */
>> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
>> index 6183b22..00b3320 100644
>> --- a/drivers/clk/meson/clkc.h
>> +++ b/drivers/clk/meson/clkc.h
>> @@ -27,6 +27,14 @@ struct parm {
>> u8 width;
>> };
>>
>> +struct meson_sclk_div_data {
>> +struct parm div;
>> +struct parm hi;
>> +unsigned int cached_div;
>> +struct clk_duty cached_duty;
>> +u8 flags;
>> +};
>> +
>> static inline unsigned int meson_parm_read(struct regmap *map, struct parm
>> *p)
>> {
>> unsigned int val;
>> @@ -118,10 +126,10 @@ struct clk_regmap _name = {
>> \
>> extern const struct clk_ops meson_clk_mpll_ops;
>> extern const struct clk_ops meson_clk_phase_ops;
>> extern const struct clk_ops meson_vid_pll_div_ro_ops;
>> +extern const struct clk_ops meson_sclk_div_ops;
>>
>> struct clk_hw *meson_clk_hw_register_input(struct device *dev,
>> const char *of_name,
>> const char *clk_name,
>> unsigned long flags);
>> -
>> #endif /* __CLKC_H */
>> diff --git a/drivers/clk/meson/sclk-div.c b/drivers/clk/meson/sclk-div.c
>> index bc64019..a6c425b 100644
>> --- a/drivers/clk/meson/sclk-div.c
>> +++ b/drivers/clk/meson/sclk-div.c
>> @@ -4,42 +4,60 @@
>> * Author: Jerome Brunet
>> *
>> * Sample clock generator divider:
>> - * This HW divider gates with value 0 but is otherwise a zero based
>> divider:
>> + * This HW divider gates with value 0
>> *
>> * val >= 1
>> - * divider = val + 1
>> + * divider = val + 1 if ONE_BASED is not set, otherwise divider = val.
>> *
>> * The duty cycle may also be set for the LR clock variant. The duty cycle
>> * ratio is:
>> *
>> * hi = [0 - val]
>> - * duty_cycle = (1 + hi) / (1 + val)
>> + * duty_cycle = (1 + hi) / (1 + val) if ONE_BASED is not set, otherwise:
>> + * duty_cycle = hi / (1 + val)
>> */
>>
>> -#include "clkc-audio.h"
>> +#include "clkc.h"
>>
>> -static inline struct meson_sclk_div_data *
>> -meson_sclk_div_data(struct clk_regmap *clk)
>> +static inline int get_reg(int val, unsigned char flag)
>
> s/get_reg/sclk_get_reg
OK, I will rename get_reg and get_value in next version.
Thank you for the review.
>
>> {
>> -return (struct meson_sclk_div_data *)clk->data;
>> +WARN_ON(val < 1);
>
> I don't think this WARN is justified, especially since you are using this
> function to set the hi value.
OK, it will remove it. Thank you.
>
>> +if ((flag & CLK_DIVIDER_ONE_BASED) || !val)
>
> I don't like that you make a dependency on the generic divider just for this.
> Please make your own flag like MESON_SCLK_ONE_BASED
OK, I will define a new flag MESON_SCLK_ONE_BASED in drivers/clk/meson/clkc.h.
>
>> +return val;
>> +else
>> +return val - 1;
>> +}
>> +
>> +static inline int get_value(int reg, unsigned char flag)
>
> s/get_value/sclk_get_divider
OK, I will rename it.
>
>> +{
>> +if (flag & CLK_DIVIDER_ONE_BASED)
>> +return reg;
>> +else
>> +
Re: [PATCH v4 2/3] dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs
Hi Andrey, On Wed, 2019-01-23 at 21:33 -0800, Andrey Smirnov wrote: > On Wed, Jan 23, 2019 at 2:52 AM Philipp Zabel wrote: > > > > On Thu, 2019-01-17 at 14:38 -0800, Andrey Smirnov wrote: > > [...] > > > > To be honest, I don't like these two, I'm not convinced anymore that > > > > they actually qualify as reset signals. To me it looks like this is > > > > something that the PCIe glue code should handle via syscon like i.MX6. > > > > Leonard, Lucas, what do you think? > > > > > > OK, one thing to keep in mind about this is that those bits are > > > already exposed for i.MX7D and I think (correct me if I am wrong) > > > there's no going back there. > > > > That's not a reason to repeat the same mistake for i.MX8QM, but at the > > moment I'm still trying to figure out if it actually was a mistake. > > > > It absolutely is. Ok, that was a sloppy expression. I'm glad you got my meaning anyway. Of course it is a reason, but it's not a good one. > Removing those resets will not meaningfully simplify > maintenance burden for this driver (a one line change), I'm less worried about the maintenance burden on this reset driver and more about lying in the device tree description and possibly setting a bad precedent. > but it will cause additional code churn on PCI side of things. > You may not agree with me that it is a _good_ reason to not to remove > those resets, but it is a reason nonetheless. Exactly. Code churn in one driver implementation should not stop us from fixing device tree bindings (in a backwards compatible fashion). Mind you, this is all under my assumption that the bits in question do not control resets and should never have been described as resets in the device tree. regards Philipp
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote: > But my concern is that it seems likely that non-cache coherent > implementations are relying on this hack as well. There must be a > reason that this hack is only disabled for PowerPC platforms if they > are cache coherent, for instance, and I suspect that that reason is > that the hack is the only thing ensuring that the CPU mapping > attributes match the device ones used for these buffers (the vmap()ed > ones), whereas the rings and other consistent data structures are > using the DMA API as intended, and thus getting uncached attributes in > the correct way. Dave, who added that commit is on Cc together with just about everyone involved in the review chain. Based on the previous explanation that idea what we might want an uncached mapping for some non-coherent architectures for this to work at all makes sense, but then again the way to create those mappings is entirely architecture specific, and also need a cache flushing before creating the mapping to work properly. So my working theory is that this code never properly worked on architectures without DMA coherent for PCIe at all, but I'd love to be corrected by concrete examples including an explanation of how it actually ends up working.
Re: [PATCH v7 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver
Hi Mason,
On Thu, Jan 24, 2019 at 3:07 AM wrote:
> > "Sergei Shtylyov"
> > 2019/01/24 上午 02:04
> > > +static const struct of_device_id rpc_spi_of_ids[] = {
> > > + { .compatible = "renesas,r8a77995-rpc", },
> >
> >Why (if it has no differences with the generic gen3 value below)?
> > Please remove.
>
> By Geert's comments in dts,
>
> rpc: rpc@ee20 {
> compatible = "renesas,r8a7795-rpc", "renesas,rcar-gen3-rpc";
> reg = <0 0xee20 0 0x200>, <0 0x0800 0 0x400>,
> <0 0xee208000 0 0x100>;
>
> I modified it to "renesas,r8a77995-rpc" because this is Soc I developed and
> validated.
There's a difference between compatible values in DT and in drivers:
- DT should list all compatible values that are applicable, from
most-specific to least-specific,
- Drivers should match against the least-specific compatible value that
is sufficient to get the job done.
In this case, that's "renesas,rcar-gen3-rpc".
The driver will probably have to be extended to match against
"renesas,r8a77970-rpc" when R-Car V3M support is added, as RPC on V3M
has an extra register that must be set, and thus cannot be declared
compatible with "renesas,rcar-gen3-rpc".
I hope this explanation makes it clearer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[GIT PULL] sound fixes for 5.0-rc4
Linus, please pull sound fixes for v5.0-rc4 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-5.0-rc4 The topmost commit is 699390381a7bae2fab01a22f742a17235c44ed8a sound fixes for 5.0-rc4 A significant amount of fixes at this time, mostly for covering the recent ASoC issues. - Fixes for the missing ASoC driver initialization with non-deferred probes; these triggered other problems in chain, which resulted in yet more fix commits - DaVinci runtime PM fix; the diff looks large but it's just a code shuffling - Various fixes for ASoC Intel drivers: a regression in HD-A HDMI, Kconfig dependency, machine driver adjustments, PLL fix. - Other ASoC driver-specific stuff including the trivial fixes caught by static analysis - Usual HD-audio quirks Ajit Pandey (1): ASoC: soc-core: defer card probe until all component is added to list Anthony Wong (1): ALSA: hda - Add mute LED support for HP ProBook 470 G5 Curtis Malainey (1): ASoC: soc-core: fix init platform memory handling Dan Carpenter (6): ASoC: dma-sh7760: cleanup a debug printk ASoC: pcm512x: Fix a double unlock in pcm512x_digital_mute() ASoC: qdsp6: q6asm-dai: Off by one in of_q6asm_parse_dai_data() ASoC: qdsp6: q6asm-dai: Fix a NULL vs IS_ERR() bug ASoC: qdsp6: q6asm-dai: Fix a small memory leak ALSA: compress: prevent potential divide by zero bugs Geert Uytterhoeven (1): ASoC: xlnx: Grammar s/the the/the/ Gustavo A. R. Silva (2): ASoC: rt5514-spi: Fix potential NULL pointer dereference ASoC: amd: Fix potential NULL pointer dereference Kailang Yang (1): ALSA: hda/realtek - Fix typo for ALC225 model Kangjie Lu (1): ASoC: atom: fix a missing check of snd_pcm_lib_malloc_pages Mac Chiang (1): ASoC: Intel: Boards: move the codec PLL configuration to _init Mark Brown (1): ASoC: core: Make snd_soc_find_component() more robust Maruthi Srinivas Bayyavarapu (1): ASoC: xlnx: change license header format style Matthias Reichl (1): ASoC: core: Don't defer probe on optional, NULL components Peter Ujfalusi (1): ASoC: ti: davinci-mcasp: Move context save/restore to runtime_pm callbacks Rander Wang (1): ASoC: Intel: Haswell/Broadwell: fix setting for .dynamic field Rohit kumar (2): ASoC: sdm845: set jack only for a specific backend ASoC: soc-core: Hold client_mutex around soc_init_dai_link() Shuming Fan (2): ASoC: rt5682: Fix recording no sound issue ASoC: rt5682: Fix PLL source register definitions Silvio Cesare (2): ASoC: dapm: change snprintf to scnprintf for possible overflow ASoC: imx-audmux: change snprintf to scnprintf for possible overflow Sinan Kaya (1): ASoC: Intel: atom: Make PCI dependency explicit Takashi Iwai (1): ASoC: intel: skl: Fix display power regression Yizhuo (1): ASoC: Variable "val" in function rt274_i2c_probe() could be uninitialized b-ak (1): ASoC: tlv320aic32x4: Kernel OOPS while entering DAPM standby mode --- include/sound/soc.h | 6 ++ sound/core/compress_offload.c | 3 +- sound/pci/hda/patch_conexant.c| 1 + sound/pci/hda/patch_realtek.c | 2 +- sound/soc/amd/raven/acp3x-pcm-dma.c | 6 +- sound/soc/codecs/hdac_hdmi.c | 116 +++--- sound/soc/codecs/pcm512x.c| 11 +-- sound/soc/codecs/rt274.c | 5 +- sound/soc/codecs/rt5514-spi.c | 2 + sound/soc/codecs/rt5682.c | 1 + sound/soc/codecs/rt5682.h | 24 ++--- sound/soc/codecs/tlv320aic32x4.c | 4 + sound/soc/fsl/imx-audmux.c| 24 ++--- sound/soc/intel/Kconfig | 2 +- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 8 +- sound/soc/intel/boards/broadwell.c| 2 +- sound/soc/intel/boards/glk_rt5682_max98357a.c | 45 ++--- sound/soc/intel/boards/haswell.c | 2 +- sound/soc/intel/skylake/skl.c | 13 +-- sound/soc/qcom/qdsp6/q6asm-dai.c | 17 +++- sound/soc/qcom/sdm845.c | 31 -- sound/soc/sh/dma-sh7760.c | 2 +- sound/soc/soc-core.c | 34 +-- sound/soc/soc-dapm.c | 10 +- sound/soc/ti/davinci-mcasp.c | 136 -- sound/soc/xilinx/Kconfig | 2 +- sound/soc/xilinx/xlnx_i2s.c | 15 ++- 27 files changed, 227 insertions(+), 297 deletions(-)
Re: [PATCH] drm/bridge: sil_sii8620: depend on INPUT instead of selecting it.
On Wed, Jan 23, 2019 at 11:21:25PM -0800, Life is hard, and then you die wrote: > Since the two changes (the change here + the new driver) seem to be > best submitted through different trees, I'm trying to figure out how > best to handle this. I suppose I could temporarily change the driver > Kconfig to not trigger the conflict, and then once the change here has > been upstreamed (not sure at what point exactly that would be > considered the case, e.g. if in linux-next is sufficient, or has to > wait for Linus' merge, or something else) submit another change to > change the driver's Kconfig to the desired one. If a series touches multiple subsystems and its patches are interdependent, the pull requests sent to Linus would have to be merged in a specific order. In practice that's too cumbersome, so either the series is split in multiple parts and merged across multiple releases (which obviously can take a long time) or, if the change to other subsystems is smallish (as is the case here), the entire series is merged through a single subsystem tree and those patches touching other subsystems need to have an Acked-by or Reviewed-by tag from a maintainer of those other subsystems. If a case can be made that the change to the other subsystem (e.g. DRM) is actually a bug fix, then that change can go in immediately and will appear in one of Linus' next -rc releases. The rest of the series can then go through the appropriate subsystem (e.g. input) and will land in Linus' tree in the next merge window. Either way, the correct patch order is preserved and it's guaranteed that the build is not broken for someone ending up on an in-between commit while bisecting. HTH, Lukas
[PATCH] f2fs: fix to document inline_xattr_size option
We missed to add document for inline_xattr_size mount option in f2fs.txt, add it. Signed-off-by: Chao Yu --- Documentation/filesystems/f2fs.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index e46c2147ddf8..f7b5e4ff0de3 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -126,6 +126,8 @@ disable_ext_identify Disable the extension list configured by mkfs, so f2fs does not aware of cold files such as media files. inline_xattr Enable the inline xattrs feature. noinline_xattr Disable the inline xattrs feature. +inline_xattr_size=%u Support configuring inline xattr size, it depends on + flexible inline xattr feature. inline_dataEnable the inline data feature: New created small(<~3.4k) files can be written into inode block. inline_dentry Enable the inline dir feature: data in new created -- 2.18.0.rc1
Re: [RFC PATCH v3 2/2] pwm: imx: Configure output to GPIO in disabled state
On Thu, Jan 24, 2019 at 09:59:47AM +0100, Michal Vokáč wrote: > On 12.12.2018 13:12, Uwe Kleine-König wrote: > > On Wed, Dec 12, 2018 at 11:42:17AM +, Vokáč Michal wrote: > > > On 12.12.2018 09:01, Uwe Kleine-König wrote: > > > > On Thu, Dec 06, 2018 at 01:41:31PM +, Vokáč Michal wrote: > > > > > Normally the PWM output is held LOW when PWM is disabled. This can > > > > > cause > > > > > problems when inverted PWM signal polarity is needed. With this > > > > > behavior > > > > > the connected circuit is fed by 100% duty cycle instead of being > > > > > shut-off. > > > > > > > > > > Allow users to define a "pwm" and a "gpio" pinctrl states. The pwm > > > > > pinctrl > > > > > state is selected when PWM is enabled and the gpio pinctrl state is > > > > > selected when PWM is disabled. In the gpio state the new pwm-gpios > > > > > GPIO is > > > > > configured as input and the internal pull-up resistor is used to pull > > > > > the > > > > > output level high. > > > > > > > > > > If all the pinctrl states and the pwm-gpios GPIO are not correctly > > > > > specified in DT the PWM work as usual. > > > > > > > > > > As an example, with this patch a PWM controlled backlight with > > > > > inversed > > > > > signal polarity can be used in full brightness range. Without this > > > > > patch > > > > > the backlight can not be turned off as brightness = 0 disables the PWM > > > > > and that in turn set PWM output LOW, that is full brightness. > > > > > > > > > > Inverted output of the PWM with "default" and with "pwm"+"gpio" > > > > > pinctrl: > > > > > > > > > > +--++---+--- > > > > > +-+ > > > > > | After reset | Bootloader | PWM probe | PWM| PWM > > > > > | > > > > > | 100k pull-up || | enable 30% | disable > > > > > | > > > > > +--++---++-+ > > > > > | pinctrl |none|default| default | default > > > > > | > > > > > | out H __ __ __ > > > > > | > > > > > | out L \_/ \_/ > > > > > \_/\ | > > > > > | ^^^ > > > > > | > > > > > +--++---++-+ > > > > > | pinctrl |none| gpio | pwm| gpio > > > > > | > > > > > | out H __ __ __ > > > > > _ | > > > > > | out L \_/ \_/ \_/ > > > > > | > > > > > | ^^^ > > > > > | > > > > > +--+ > > > > > > > > > > Signed-off-by: Michal Vokáč > > > > > --- > > > > > Changes in v3: > > > > >- Commit message update. > > > > >- Minor fix in code comment (Uwe) > > > > >- Align function arguments to the opening parentheses. (Uwe) > > > > >- Do not test devm_pinctrl_get for NULL. (Thierry) > > > > >- Convert all messages to dev_dbg() (Thierry) > > > > >- Do not actively drive the pin in gpio state. Configure it as > > > > > input > > > > > and rely solely on the internal pull-up. (Thierry) > > > > > > > > > > Changes in v2: > > > > >- Utilize the "pwm" and "gpio" pinctrl states. > > > > >- Use the pwm-gpios signal to drive the output in "gpio" pinctrl > > > > > state. > > > > >- Select the right pinctrl state in probe. > > > > > > > > > >drivers/pwm/pwm-imx.c | 77 > > > > > +++ > > > > >1 file changed, 77 insertions(+) > > > > > > > > > > > [ snip ] > > > > > > > On thing I noticed while looking at the rcar driver is: This doesn't > > > > wait for the current period to end. Is this supposed to happen? Also for > > > > the enable case the hardware is configured for the desired duty cycle > > > > and only then the pinctrl is switched to pwm. Both might result in a > > > > spike that is not desired. > > > > > > The behavior should not change from how imx-pwm was working before. > > > When PWM is disabled the output is immediately gated off (put into > > > the idle state) independently on the period. I measured this. > > > > Oh really, I wasn't aware of that. This is another bug in the imx pwm > > then (I think). > > I kind of expect that when hit a disable button the output is immediately > put into the idle state. To me it does not seem appropriate to wait the > whole period, or even just the active part of the period. If duty=100% > and period=4s (current maximum), in the worst case you would have to wait > 4s until you stop the PWM. Quite a long time of driving something you > actually wanted to be shut off. I think it might be beneficial to allow (or require) that disable acts
Re: [PATCH 2/7] scsi: csiostor: no need to check return value of debugfs_create functions
Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [RFC/RFT PATCH 00/15] crypto: improved skcipher, aead, and hash tests
On Thu, Jan 24, 2019 at 09:50:35AM +0100, Ard Biesheuvel wrote: > > Thanks for yet another round of cleanup > > I'll look into these, but I'd like to clarify one thing first. > > IIUC, you are trying to deal with the case where a single scatterlist > element describes a range that strides two pages, and I wonder if that > is a valid use of scatterlists in the first place. > > Herbert? Yes it is valid. IIRC the network stack may generate such a scatterlist. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH net-next 06/10] net: introduce a net_device_ops macsec helper
Hi Florian,
On Wed, Jan 23, 2019 at 12:16:08PM -0800, Florian Fainelli wrote:
> On 1/23/19 7:56 AM, Antoine Tenart wrote:
> > This patch introduces a net_device_ops MACsec helper to allow net device
> > drivers to implement a MACsec offloading solution.
> >
> > Signed-off-by: Antoine Tenart
> > ---
> > include/linux/netdevice.h | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index e675ef97a426..ee2f40dca515 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -53,6 +53,10 @@
> > #include
> > #include
> >
> > +#ifdef CONFIG_MACSEC
> > +#include
> > +#endif
>
> You can provide a forward declaration for struct netdev_macsec and not
> have to include that header file.
OK.
> > +
> > struct netpoll_info;
> > struct device;
> > struct phy_device;
> > @@ -1441,6 +1445,10 @@ struct net_device_ops {
> > u32 flags);
> > int (*ndo_xsk_async_xmit)(struct net_device *dev,
> > u32 queue_id);
> > +#ifdef CONFIG_MACSEC
> > + int (*ndo_macsec)(struct net_device *dev,
> > + struct netdev_macsec *macsec);
>
> You would really want to define an API which is more oriented towards
> configuring/deconfiguring a MACsec association here, e.g.: similar to
> what the IPsec offload ndos offer.
This means mostly moving from a single function using a command field to
multiple specialized functions to add/remove each element of MACsec
configuration.
I don't have strong opinion on the single helper vs a structure
containing pointers to specialized ones, but out of curiosity what's the
benefit of such a move? Future additions and maintainability?
> It is not clear to me whether after your patch series we still need to
> create a macsec virtual device, and that gets offloaded onto its real
> device/PHY device, or if we don't need that all?
After this series, we will still need the virtual MACsec interface. When
using hardware offloading this interface isn't doing much, but it's the
interface used to configure all the MACsec connexions.
This is because, and that's specific to MACsec (vs IPsec), a software
implementation is already supported and it's using a virtual interface
to perform all the MACsec related operations (vs hooks in the Rx/Tx
paths). I really wanted to avoid having two interfaces and ways of
configuring MACsec depending on if the offloading is used.
This should also allow in the future to disable at run-time the
offloading on a given interface, and to still have MACsec working in
software (or the opposite, with extra work). For this to work, the
virtual interface still has to provide an Rx and a Tx functions so that
programs can bind onto the same interface, regardless of if the
offloading is enabled.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
Am 24.01.19 um 10:13 schrieb Christoph Hellwig: > On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote: >> But my concern is that it seems likely that non-cache coherent >> implementations are relying on this hack as well. There must be a >> reason that this hack is only disabled for PowerPC platforms if they >> are cache coherent, for instance, and I suspect that that reason is >> that the hack is the only thing ensuring that the CPU mapping >> attributes match the device ones used for these buffers (the vmap()ed >> ones), whereas the rings and other consistent data structures are >> using the DMA API as intended, and thus getting uncached attributes in >> the correct way. > Dave, who added that commit is on Cc together with just about everyone > involved in the review chain. Based on the previous explanation > that idea what we might want an uncached mapping for some non-coherent > architectures for this to work at all makes sense, but then again > the way to create those mappings is entirely architecture specific, > and also need a cache flushing before creating the mapping to work > properly. So my working theory is that this code never properly > worked on architectures without DMA coherent for PCIe at all, but > I'd love to be corrected by concrete examples including an explanation > of how it actually ends up working. Cache coherency is mandatory for modern GPU operation. Otherwise you can't implement a bunch of the requirements of the userspace APIs. In other words the applications doesn't inform the driver that the GPU or the CPU is accessing data, it just does it and assumes that it works. Regards, Christian.
Re: [PATCH RFC 07/24] userfaultfd: wp: add the writeprotect API to userfaultfd ioctl
On Thu, Jan 24, 2019 at 09:27:07AM +0200, Mike Rapoport wrote:
> On Thu, Jan 24, 2019 at 12:56:15PM +0800, Peter Xu wrote:
> > On Mon, Jan 21, 2019 at 12:42:33PM +0200, Mike Rapoport wrote:
> >
> > [...]
> >
> > > > @@ -1343,7 +1344,7 @@ static int userfaultfd_register(struct
> > > > userfaultfd_ctx *ctx,
> > > >
> > > > /* check not compatible vmas */
> > > > ret = -EINVAL;
> > > > - if (!vma_can_userfault(cur))
> > > > + if (!vma_can_userfault(cur, vm_flags))
> > > > goto out_unlock;
> > > >
> > > > /*
> > > > @@ -1371,6 +1372,8 @@ static int userfaultfd_register(struct
> > > > userfaultfd_ctx *ctx,
> > > > if (end & (vma_hpagesize - 1))
> > > > goto out_unlock;
> > > > }
> > > > + if ((vm_flags & VM_UFFD_WP) && !(cur->vm_flags &
> > > > VM_WRITE))
> > > > + goto out_unlock;
> > >
> > > This is problematic for the non-cooperative use-case. Way may still want
> > > to
> > > monitor a read-only area because it may eventually become writable, e.g.
> > > if
> > > the monitored process runs mprotect().
> >
> > Firstly I think I should be able to change it to VM_MAYWRITE which
> > seems to suite more.
> >
> > Meanwhile, frankly speaking I didn't think a lot about how to nest the
> > usages of uffd-wp and mprotect(), so far I was only considering it as
> > a replacement of mprotect(). But indeed it can happen that the
> > monitored process calls mprotect(). Is there an existing scenario of
> > such usage?
> >
> > The problem is I'm uncertain about whether this scenario can work
> > after all. Say, the monitor process A write protected process B's
> > page P, so logically A will definitely receive a message before B
> > writes to page P. However here if we allow process B to do
> > mprotect(PROT_WRITE) upon page P and grant write permission to it on
> > its own, then A will not be able to capture the write operation at
> > all? Then I don't know how it can work here... or whether we should
> > fail the mprotect() at least upon uffd-wp ranges?
>
> The use-case we've discussed a while ago was to use uffd-wp instead of
> soft-dirty for tracking memory changes in CRIU for pre-copy migration.
> Currently, we enable soft-dirty for the migrated process and monitor
> /proc/pid/pagemap between memory dump iterations to see what memory pages
> have been changed.
> With uffd-wp we thought to register all the process memory with uffd-wp and
> then track changes with uffd-wp notifications. Back then it was considered
> only at the very general level without paying much attention to details.
>
> So my initial thought was that we do register the entire memory with
> uffd-wp. If an area changes from RO to RW at some point, uffd-wp will
> generate notifications to the monitor, it would be able to notice the
> change and the write will continue normally.
>
> If we are to limit uffd-wp register only to VMAs with VM_WRITE and even
> VM_MAYWRITE, we'd need a way to handle the possible changes of VMA
> protection and an ability to add monitoring for areas that changed from RO
> to RW.
>
> Can't say I have a clear picture in mind at the moment, will continue to
> think about it.
Thanks for these details. Though I have a question about how it's
used.
Since we're talking about replacing soft dirty with uffd-wp here, I
noticed that there's a major interface difference between soft-dirty
and uffd-wp: the soft-dirty was all about /proc operations so a
monitor process can easily monitor mostly any process on the system as
long as knowing its PID. However I'm unsure about uffd-wp since
userfaultfd was always bound to a mm_struct. For example, the syscall
userfaultfd() will always attach the current process mm_struct to the
newly created userfaultfd but it cannot be attached to another random
mm_struct of other processes. Or is there any way that the CRIU
monitor process can gain an userfaultfd of any process of the system
somehow?
>
> > > Particularity, for using uffd-wp as a replacement for soft-dirty would
> > > require it.
> > >
> > > >
> > > > /*
> > > > * Check that this vma isn't already owned by a
> > > > @@ -1400,7 +1403,7 @@ static int userfaultfd_register(struct
> > > > userfaultfd_ctx *ctx,
> > > > do {
> > > > cond_resched();
> > > >
> > > > - BUG_ON(!vma_can_userfault(vma));
> > > > + BUG_ON(!vma_can_userfault(vma, vm_flags));
> > > > BUG_ON(vma->vm_userfaultfd_ctx.ctx &&
> > > >vma->vm_userfaultfd_ctx.ctx != ctx);
> > > > WARN_ON(!(vma->vm_flags & VM_MAYWRITE));
> > > > @@ -1535,7 +1538,7 @@ static int userfaultfd_unregister(struct
> > > > userfaultfd_ctx *ctx,
> > > > * provides for more strict behavior to notice
> > > >
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On Thu, 24 Jan 2019 at 10:25, Koenig, Christian wrote: > > Am 24.01.19 um 10:13 schrieb Christoph Hellwig: > > On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote: > >> But my concern is that it seems likely that non-cache coherent > >> implementations are relying on this hack as well. There must be a > >> reason that this hack is only disabled for PowerPC platforms if they > >> are cache coherent, for instance, and I suspect that that reason is > >> that the hack is the only thing ensuring that the CPU mapping > >> attributes match the device ones used for these buffers (the vmap()ed > >> ones), whereas the rings and other consistent data structures are > >> using the DMA API as intended, and thus getting uncached attributes in > >> the correct way. > > Dave, who added that commit is on Cc together with just about everyone > > involved in the review chain. Based on the previous explanation > > that idea what we might want an uncached mapping for some non-coherent > > architectures for this to work at all makes sense, but then again > > the way to create those mappings is entirely architecture specific, > > and also need a cache flushing before creating the mapping to work > > properly. So my working theory is that this code never properly > > worked on architectures without DMA coherent for PCIe at all, but > > I'd love to be corrected by concrete examples including an explanation > > of how it actually ends up working. > > Cache coherency is mandatory for modern GPU operation. > > Otherwise you can't implement a bunch of the requirements of the > userspace APIs. > > In other words the applications doesn't inform the driver that the GPU > or the CPU is accessing data, it just does it and assumes that it works. > Wonderful! In that case, do you have any objections to the patch proposed by Christoph above?
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
>>
>> I think we just want a driver-local check for those combinations
>> where we know this hack actually works, which really just seems
>> to be x86-64 with PAT. Something like the patch below, but maybe with
>> even more strong warnings to not do something like this elsewhere:
>
> I agree that your patch seems like the right way to ensure that the WC
> optimization hack is only used where we know it works.
>
> But my concern is that it seems likely that non-cache coherent
> implementations are relying on this hack as well.
I've been trying to tell you they can't rely on that, because the amdgpu
driver doesn't use this functionality for fundamentals such as ring
buffers used for feeding the hardware with commands. Instead, for those
it relies on snooped PCIe transfers being coherent with the CPU caches.
>> -#elif defined(CONFIG_X86) && !defined(CONFIG_X86_PAT)
>> - /* Don't try to enable write-combining when it can't work, or things
>> -* may be slow
>> -* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
>> -*/
>> -
>> -#ifndef CONFIG_COMPILE_TEST
>> -#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better
>> performance \
>> -thanks to write-combining
>> -#endif
>> -
>> - if (bo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
>> - DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT
>> for "
>> - "better performance thanks to
>> write-combining\n");
FWIW, please don't drop these compile and build time warnings where we
continue to take advantage of PAT.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Re: [PATCH v5] add support for Mediatek Command-Queue DMA controller on MT6765 SoC
Hi Shun-Chih, the driver seems already be applied since v5.0-rc1 I suggest these improvements you made in the recent version can be split into several patches and then be applied on the top of the base driver. On Wed, Jan 23, 2019 at 11:15 PM wrote: > > This patchset introduces support for MediaTek Command-Queue DMA controller. > > MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated to > memory-to-memory transfer through queue-based descriptor management. > > There are only 3 physical channels inside CQDMA, while the driver is extended > to support 32 virtual channels for multiple dma users to issue dma requests > onto the CQDMA simultaneously. > > dmatest result: > dmatest: dma0chan0-copy2: summary 5000 tests, 0 failures 3500 iops 28037 KB/s > (0) > dmatest: dma0chan0-copy4: summary 5000 tests, 0 failures 3494 iops 27612 KB/s > (0) > dmatest: dma0chan0-copy1: summary 5000 tests, 0 failures 3491 iops 27749 KB/s > (0) > dmatest: dma0chan0-copy7: summary 5000 tests, 0 failures 3673 iops 29092 KB/s > (0) > dmatest: dma0chan0-copy6: summary 5000 tests, 0 failures 3763 iops 30237 KB/s > (0) > dmatest: dma0chan0-copy0: summary 5000 tests, 0 failures 3730 iops 30131 KB/s > (0) > dmatest: dma0chan0-copy3: summary 5000 tests, 0 failures 3717 iops 29569 KB/s > (0) > dmatest: dma0chan0-copy5: summary 5000 tests, 0 failures 3699 iops 29302 KB/s > (0) > > Changes since v4: > - remove redundant queue structure in mtk_cqdma_pchan > - remove redundant completion management > - fix wrong residue assignment in mtk_cqdma_tx_status > - fix typos > > Changes since v3: > - simplify the ISR and management on descriptors by removing tasklet and > ASYNC_TX_ENABLE_CHANNEL_SWITCH > - remove useless field in mtk_cqdma_vdesc structure > - change dev_info to dev_dbg > - fix typos > > Changes since v2: > - fix build warning for kernel with DMA address in 32-bit > > Changes since v1: > - remove unused macros, typos > - leverage ASYNC_TX_ENABLE_CHANNEL_SWITCH to maintain DMA descriptor list > > Shun-Chih Yu (2): > dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller > bindings > dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for > MT6765 SoC > > .../devicetree/bindings/dma/mtk-cqdma.txt | 31 + > drivers/dma/mediatek/Kconfig | 12 + > drivers/dma/mediatek/Makefile |1 + > drivers/dma/mediatek/mtk-cqdma.c | 748 > > 4 files changed, 792 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt > create mode 100644 drivers/dma/mediatek/mtk-cqdma.c > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v5 3/4] Bluetooth: Allow driver specific cmd timeout handling
Hi Rajat,
> Add a hook to allow the BT driver to do device or command specific
> handling in case of timeouts. This is to be used by Intel driver to
> reset the device after certain number of timeouts.
>
> Signed-off-by: Rajat Jain
> ---
> v5: Drop the quirk, and rename the hook function to cmd_timeout()
> v4: same as v1
> v3: same as v1
> v2: same as v1
>
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_core.c | 10 --
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h
> b/include/net/bluetooth/hci_core.h
> index e5ea633ea368..624d5f2b1f36 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -437,6 +437,7 @@ struct hci_dev {
> int (*post_init)(struct hci_dev *hdev);
> int (*set_diag)(struct hci_dev *hdev, bool enable);
> int (*set_bdaddr)(struct hci_dev *hdev, const bdaddr_t *bdaddr);
> + void (*cmd_timeout)(struct hci_dev *hdev, struct hci_command_hdr *cmd);
> };
>
> #define HCI_PHY_HANDLE(handle)(handle & 0xff)
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 7352fe85674b..c6917f57581a 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2568,16 +2568,22 @@ static void hci_cmd_timeout(struct work_struct *work)
> {
> struct hci_dev *hdev = container_of(work, struct hci_dev,
> cmd_timer.work);
> + struct hci_command_hdr *sent = NULL;
>
> if (hdev->sent_cmd) {
> - struct hci_command_hdr *sent = (void *) hdev->sent_cmd->data;
> - u16 opcode = __le16_to_cpu(sent->opcode);
> + u16 opcode;
> +
> + sent = (void *) hdev->sent_cmd->data;
> + opcode = __le16_to_cpu(sent->opcode);
>
> bt_dev_err(hdev, "command 0x%4.4x tx timeout", opcode);
> } else {
> bt_dev_err(hdev, "command tx timeout");
> }
>
> + if (hdev->cmd_timeout)
> + hdev->cmd_timeout(hdev, sent);
> +
drop the sent parameter. You are not using it and if at some point in the
future you might want to use it, then we add it and fix up all users.
And frankly, I would move the hdev->cmd_timeout call into the hdev->sent_cmd
block since I do not even know if it makes sense to deal with the fallback case
where hdev->sent_cmd is not available. Unless you have that kind of error case,
but that is only possible if you have external injection of HCI commands.
Regards
Marcel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On Thu, 24 Jan 2019 at 10:31, Michel Dänzer wrote:
>
> On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
> >>
> >> I think we just want a driver-local check for those combinations
> >> where we know this hack actually works, which really just seems
> >> to be x86-64 with PAT. Something like the patch below, but maybe with
> >> even more strong warnings to not do something like this elsewhere:
> >
> > I agree that your patch seems like the right way to ensure that the WC
> > optimization hack is only used where we know it works.
> >
> > But my concern is that it seems likely that non-cache coherent
> > implementations are relying on this hack as well.
>
> I've been trying to tell you they can't rely on that, because the amdgpu
> driver doesn't use this functionality for fundamentals such as ring
> buffers used for feeding the hardware with commands. Instead, for those
> it relies on snooped PCIe transfers being coherent with the CPU caches.
>
I understand it does not use this functionality for the ring. Instead,
it uses the DMA API, no?
On non-cache coherent systems, that DMA API will allocate memory and
map it uncached for the CPU so that it is coherent with the non-cache
coherent device.
In any case, if non-cache coherent systems are unlikely to work, and
unsupported in case they do, I am fine with disabling this
optimization unconditionally for non-X86 architectures.
>
> >> -#elif defined(CONFIG_X86) && !defined(CONFIG_X86_PAT)
> >> - /* Don't try to enable write-combining when it can't work, or
> >> things
> >> -* may be slow
> >> -* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
> >> -*/
> >> -
> >> -#ifndef CONFIG_COMPILE_TEST
> >> -#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better
> >> performance \
> >> -thanks to write-combining
> >> -#endif
> >> -
> >> - if (bo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
> >> - DRM_INFO_ONCE("Please enable CONFIG_MTRR and
> >> CONFIG_X86_PAT for "
> >> - "better performance thanks to
> >> write-combining\n");
>
> FWIW, please don't drop these compile and build time warnings where we
> continue to take advantage of PAT.
>
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
Re: [PATCH] clocksource: sun5i: fail gracefully when clock rate is unavailable
On 24/01/2019 09:56, Chen-Yu Tsai wrote:
> On Thu, Jan 10, 2019 at 5:19 PM Daniel Lezcano
> wrote:
>>
>> On 10/01/2019 07:22, Chen-Yu Tsai wrote:
>>> If the clock tree is not fully populated when the timer-sun5i init code
>>> is called, attempts to get the clock rate for the timer would fail and
>>> return 0.
>>>
>>> Make the init code for both clock events and clocksource check the
>>> returned clock rate and fail gracefully if the result is 0, instead of
>>> causing a divide by 0 exception later on.
>>>
>>> Fixes: 4a59058f0b09 ("clocksource/drivers/sun5i: Refactor the current code")
>>> Signed-off-by: Chen-Yu Tsai
>>> ---
>>
>> Applied thanks.
>
> I'm not seeing this in linux-next, nor the patch
>
> arm64: arch_timer: Workaround for Allwinner A64 timer instability
>
> Any idea where these ended up?
Yeah, I have a rough idea. They are now in linux-next via the
clockevents/next branch.
--
Facebook |
Twitter |
Re: [PATCH 0/7] Port am335 and am437 devices to sdhci-omap
Hi, On 11/01/19 4:38 PM, Faiz Abbas wrote: > The following add driver patches for porting TI's am335x and am437x > devices to the sdhci-omap driver. > > This involves adding external DMA support to sdhci (first 3 patches from > Chunyan) plus some miscellaneous patches to take care of deviations of > the controllers from the sdhci model. > > DT changes will be posted in a separate series. > > Untested versions of Chunyan's patches were posted before[1]. > > Tested on: am335x-evm, am335x-boneblack, am335x-sk, am437x-gpevm, > am43xx-gpevm, am437x-idk, dra7xx-evm, dra72x-evm > > [1] https://patchwork.kernel.org/project/linux-mmc/list/?series=54897 > > Chunyan Zhang (3): > mmc: sdhci: add support for using external DMA devices > mmc: sdhci-omap: Add using external dma > dt-bindings: sdhci-omap: Add example for using external dma > > Faiz Abbas (4): > mmc: sdhci: Add quirk for disabling DTO during erase command > mmc: sdhci_omap: Add DISABLE_DTO_FOR_ERASE Quirk > dt-bindings: sdhci-omap: Add am335x and am437x specific bindings > mmc: sdhci-omap: Add am335x and am437x specific compatibles > > .../devicetree/bindings/mmc/sdhci-omap.txt| 9 + > drivers/mmc/host/Kconfig | 4 + > drivers/mmc/host/sdhci-omap.c | 27 +- > drivers/mmc/host/sdhci.c | 274 +- > drivers/mmc/host/sdhci.h | 10 + > 5 files changed, 319 insertions(+), 5 deletions(-) > Gentle ping. Thanks, Faiz
Re: [PATCH v3 1/3] firmware: xilinx: Add reset API's
On Fri, 2019-01-25 at 13:16 +0530, Nava kishore Manne wrote: > This Patch Adds reset API's to support release, assert > and status functionalities by using firmware interface. > > Signed-off-by: Nava kishore Manne Michal, Should I merge this through the reset tree together with the reset driver? regards Philipp
Re: [PATCH reset/next] reset: Add Broadcom STB SW_INIT reset controller driver
Hi Florian, On Wed, 2019-01-23 at 14:54 -0800, Florian Fainelli wrote: > Add support for resetting blocks through the Linux reset controller > subsystem when reset lines are provided through a SW_INIT-style reset > controller on Broadcom STB SoCs. > > Signed-off-by: Florian Fainelli > Signed-off-by: Philipp Zabel > --- > Philipp, > > This is a replacement patch for what is currently in your reset/next > branch. > > Thank you! Applied to reset/next, thank you. regards Philipp
