On Thu 23 May 12:44 PDT 2019, Niklas Cassel wrote:
> Currently, there is only a 1 ms sleep after asserting PERST.
>
> Reading the datasheets for different endpoints, some require PERST to be
> asserted for 10 ms in order for the endpoint to perform a reset, others
> require it to be asserted for
On 2019-05-25, Linus Torvalds wrote:
> In fact, I think resolveat() as a model is fundamentally wrong for yet
> another reason: O_CREAT. If you want to _create_ a new file, and you
> want to still have the path resolution modifiers in place, the
> resolveat() model is broken, because it only
On Sat 25 May 13:42 PDT 2019, Colin King wrote:
> From: Colin Ian King
>
> The spelling of configured is incorrect in the documentation. Fix it.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Bjorn Andersson
Thanks,
Bjorn
> ---
> .../devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
Add PCIe host controller driver for DesignWare core based
PCIe controller IP present in Tegra194.
Signed-off-by: Vidya Sagar
---
Changes since [v7]:
* None
Changes since [v6]:
* None
Changes since [v5]:
* None
Changes since [v4]:
* None
Changes since [v3]:
* None
Changes since [v2]:
* None
Add support for Synopsys DesignWare core IP based PCIe host controller
present in Tegra194 SoC.
Signed-off-by: Vidya Sagar
---
Changes since [v7]:
* Addressed review comments from Thierry
Changes since [v6]:
* Removed code around "nvidia,disable-aspm-states" DT property
* Refactored code to
Some host controllers need to know the existence of clkreq signal routing to
downstream devices to be able to advertise low power features like ASPM L1
substates. Without clkreq signal routing being present, enabling ASPM L1 sub
states might lead to downstream devices falling off the bus. Hence a
Synopsys DesignWare core based PCIe controllers in Tegra 194 SoC interface
with Universal PHY (UPHY) module through a PIPE2UPHY (P2U) module.
For each PCIe lane of a controller, there is a P2U unit instantiated at
hardware level. This driver provides support for the programming required
for each
Add support for Tegra194 P2U (PIPE to UPHY) module block which is a glue
module instantiated one for each PCIe lane between Synopsys DesignWare core
based PCIe IP and Universal PHY block.
Signed-off-by: Vidya Sagar
Reviewed-by: Rob Herring
Acked-by: Thierry Reding
---
Changes since [v7]:
*
Enable PCIe controller nodes to enable respective PCIe slots on
P2972- board. Following is the ownership of slots by different
PCIe controllers.
Controller-0 : M.2 Key-M slot
Controller-1 : On-board Marvell eSATA controller
Controller-3 : M.2 Key-E slot
Signed-off-by: Vidya Sagar
---
Changes
Add P2U (PIPE to UPHY) and PCIe controller nodes to device tree.
The Tegra194 SoC contains six PCIe controllers and twenty P2U instances
grouped into two different PHY bricks namely High-Speed IO (HSIO-12 P2Us)
and NVIDIA High Speed (NVHS-8 P2Us) respectively.
Signed-off-by: Vidya Sagar
---
Add support for Tegra194 PCIe controllers. These controllers are based
on Synopsys DesignWare core IP.
Signed-off-by: Vidya Sagar
Reviewed-by: Rob Herring
---
Changes since [v7]:
* Addressed review comments from Thierry
* Modified DT example to reflect new changes
Changes since [v6]:
* Changed
Move PCIe config space capability search API to common DesignWare file
as this can be used by both host and ep mode codes.
Signed-off-by: Vidya Sagar
Acked-by: Gustavo Pimentel
Reviewed-by: Thierry Reding
---
Changes since [v7]:
* Changed comment to explicitly state their mere resemblance to
Tegra194 has six PCIe controllers based on Synopsys DesignWare core.
There are two Universal PHY (UPHY) blocks with each supporting 12(HSIO:
Hisg Speed IO) and 8(NVHS: NVIDIA High Speed) lanes respectively.
Controllers:0~4 use UPHY lanes from HSIO brick whereas Controller:5 uses
UPHY lanes from
Add #defines only for the Data Link Feature and Physical Layer 16.0 GT/s
features.
Signed-off-by: Vidya Sagar
Reviewed-by: Thierry Reding
---
Changes since [v7]:
* None
Changes since [v6]:
* None
Changes since [v5]:
* None
Changes since [v4]:
* None
Changes since [v3]:
* None
Changes since
Add support to enable CDM (Configuration Dependent Module) register check
for any data corruption based on the device-tree flag 'snps,enable-cdm-check'.
Signed-off-by: Vidya Sagar
Acked-by: Gustavo Pimentel
Reviewed-by: Thierry Reding
---
Changes since [v7]:
* None
Changes since [v6]:
*
Tegra194 rootports don't generate MSI interrupts for PME and AER events.
Since PCIe spec (Ref: r4.0 sec 7.7.1.2 and 7.7.2.2) doesn't support using
a mix of INTx and MSI/MSI-X, MSI needs to be disabled to avoid root ports
service drivers registering their respective ISRs with MSI interrupt and
to
Add extended configuration space capability search API using struct dw_pcie *
pointer
Signed-off-by: Vidya Sagar
Acked-by: Gustavo Pimentel
---
Changes since [v7]:
* Changed data types of return and arguments to be inline with data being
returned
and passed.
Changes since [v6]:
* None
Add support to enable CDM (Configuration Dependent Module) registers check
for any data corruption. CDM registers include standard PCIe configuration
space registers, Port Logic registers and iATU and DMA registers.
Refer Section S.4 of Synopsys DesignWare Cores PCI Express Controller Databook
Remove multiple write enable and disable sequences of dbi registers as
Tegra194 implements writes to BAR-0 register (offset: 0x10) controlled by
DBI write-lock enable bit thereby not allowing any further writes to BAR-0
register in config space to take place. Hence enabling write permission at
the
Thanks, a bunch Greg!
On 18:58 Sat 25 May , Greg KH wrote:
I'm announcing the release of the 5.1.5 kernel.
All users of the 5.1 kernel series must upgrade.
The updated 5.1.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-5.1.y
In dlpar_parse_cc_property(), 'prop->name' is allocated by kstrdup().
kstrdup() may return NULL, so it should be checked and handle error.
And prop should be freed if 'prop->name' is NULL.
Signed-off-by: Gen Zhang
---
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
On Sat, May 25, 2019 at 07:06:48AM +0200, Willy Tarreau wrote:
> On Sat, May 25, 2019 at 10:12:41AM +0800, Gen Zhang wrote:
> > On Fri, May 24, 2019 at 04:21:36PM -0700, Randy Dunlap wrote:
> > > On 5/22/19 6:17 PM, Gen Zhang wrote:
> > > > Hi Andrew,
> > > > I am starting submitting patches these
Hello Yangtao,
On Sun, May 26, 2019 at 02:48:13AM +0800, Frank Lee wrote:
> On Sun, May 19, 2019 at 10:22 PM Ondřej Jirman wrote:
> >
> > I know, I don't think it needs to be per-soc. These actions are all shared
> > by
> > all SoCs. Maybe with an exception that some SoCs may need one more
The kpc2000_i2c.c file contains instances of unnecessary consecutive
newlines which impact the readability of the file. Remove these
unnecessary newlines.
Signed-off-by: Geordan Neukum
---
drivers/staging/kpc2000/kpc2000_i2c.c | 5 -
1 file changed, 5 deletions(-)
diff --git
The kpc2000 driver does not verify whether or not mapping the I/O
space succeeded during probe time. Make the driver verify that the
mapping operation was successful before potentially using that area
in the future.
Signed-off-by: Geordan Neukum
---
drivers/staging/kpc2000/kpc2000_i2c.c | 2 ++
The kpc_i2c driver stashes private state data in the platform_data
member of its device structure. In general, the platform_data structure
is used for passing data to the driver during probe() rather than as a
storage area for runtime state data. Instead, use the drvdata member
for all state info
The FEATURES_* symbols use bit shifting of the style (1 << k) in order
to assign a certain meaning to the value of inividual bits being set
in the value of a given variable. Instead, use the BIT() macro in
order to improve readability and maintain consistency with the rest
of the kernel.
The kpc_i2c driver does not unmap its I/O space upon error cases in the
probe() function or upon remove(). Make the driver clean up after itself
more maintainably by using the managed resource API.
Signed-off-by: Geordan Neukum
---
drivers/staging/kpc2000/kpc2000_i2c.c | 4 +++-
1 file changed,
The kpc_i2c driver attempts to map its I/O space without verifying
whether or not the result of platform_get_resource() is NULL. Make the
driver check that platform_get_resource did not return NULL before
attempting to use the value returned to map an I/O space.
Signed-off-by: Geordan Neukum
---
This series contains some patches aimed toward:
- cleaning up unused/unneeded parts of driver state
- a couple of small style fixups
- a couple of API changes
- better error handling in probe()
in the kpc2000 i2c driver.
Geordan Neukum (8):
staging: kpc2000: kpc_i2c: Remove unused rw_sem
In pi2c_probe, a rw_sem is initialized and stashed off in the
i2c_device private runtime state struct. This rw_sem is never used
after initialization. Remove the rw_sem and cleanup unneeded header
inclusion.
Signed-off-by: Geordan Neukum
---
drivers/staging/kpc2000/kpc2000_i2c.c | 3 ---
1 file
The i2c_device structure contains a member used to stash a pointer to
a platform_device. The driver contains no cases of this member being
used after initialization. Remove the unnecessary struct member and
the initialization of this member in the sole instance where the
driver creates a variable
On 5/25/19 1:37 PM, rwar...@gmx.de wrote:
> hallo
>
> I today I got a regression
>
> see the attached dmesg
>
> --
>
> Ronald
[adding netdev + TIPC maintainers]
[4.953673] [ cut here ]
[4.953674] kernel BUG at lib/list_debug.c:29!
[4.953678] invalid
On Sat, May 25, 2019 at 3:40 PM Xing, Cedric wrote:
>
> > From: Andy Lutomirski [mailto:l...@amacapital.net]
> > Sent: Friday, May 24, 2019 4:42 PM
> >
> > > On May 24, 2019, at 3:41 PM, Sean Christopherson
> > > wrote:
> > >
> > >> On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski
From: Maxime Chevallier
Date: Fri, 24 May 2019 12:05:49 +0200
> Here is a set of updates for the PPv2 classifier, the main feature being
> the support for steering to RSS contexts, to leverage all the available
> RSS tables in the controller.
>
> The first two patches are non-critical fixes for
From: Maxime Chevallier
Date: Fri, 24 May 2019 12:05:30 +0200
> ethtool ops get_rxfh_context and set_rxfh_context are used to create,
> remove and access parameters associated to RSS contexts, in a similar
> fashion to get_rxfh and set_rxfh.
>
> Add a small descritopn of these callbacks in the
On Thu, May 23, 2019 at 05:19:05PM +0100, David Howells wrote:
> out_no_data:
> - dfprintk(MOUNT, "NFS: mount program didn't pass any mount data\n");
> - return -EINVAL;
> + if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE) {
> + ctx->skip_reconfig_option_check = true;
> +
With due respect, I am inviting you for a business deal of Eleven Million Three
hundred thousand united states dollars where this money can be shared between
us.
By indicating your interest I will send you the full details on how the
business will be executed.
Please send your reply to my
The pull request you sent on Sat, 25 May 2019 17:07:14 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> tags/ext4_for_linus_stable
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/35efb51eee2241a970dcf70ed950f9db7e5351f7
Thank you!
--
On Sat, May 25, 2019 at 3:39 PM Steven Rostedt wrote:
> You mean this one:
Yes.
> I have it in my queue for the next merge window, but I can cherry pick
> it and send it to you directly now.
Oh, "next merge window" is *way* too late.
This is a serious problem that causes tens of lines of
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Friday, May 24, 2019 4:42 PM
>
> > On May 24, 2019, at 3:41 PM, Sean Christopherson
> > wrote:
> >
> >> On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski wrote:
> >> On Fri, May 24, 2019 at 1:03 PM Sean Christopherson
> >>
On Sat, 25 May 2019 10:09:19 -0700
Linus Torvalds wrote:
> On Fri, May 24, 2019 at 8:11 PM Steven Rostedt wrote:
> >
> > Tom Zanussi sent me some small fixes and cleanups to the histogram
> > code and I forgot to incorporate them.
> >
> > I also added a small clean up patch that was sent to me
On Sat, 25 May 2019 09:57:58 -0700
Cong Wang wrote:
> This patchset introduces trace event injection, the first 3 patches
> are some trivial prerequisites, the last one implements the trace
> event injection. Please check each patch for details.
>
> I have tested them with both valid and
On Fri, 24 May 2019 17:49:18 +0200 Vitaly Wool wrote:
> For each page scheduled for compaction (e. g. by z3fold_free()),
> try to apply inter-page compaction before running the traditional/
> existing intra-page compaction. That means, if the page has only one
> buddy, we treat that buddy as a
On Fri, 24 May 2019 13:50:45 -0400 Daniel Jordan
wrote:
> locked_vm accounting is done roughly the same way in five places, so
> unify them in a helper. Standardize the debug prints, which vary
> slightly, but include the helper's caller to disambiguate between
> callsites.
>
> Error codes
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
> load_flat_shared_library() is broken: It only calls load_flat_file() if
> prepare_binprm() returns zero, but prepare_binprm() returns the number of
> bytes read - so this only happens if the file is empty.
ouch.
> Instead, call into
The following changes since commit 2c1d0e3631e5732dba98ef49ac0bec1388776793:
ext4: avoid panic during forced reboot due to aborted journal (2019-05-17
17:37:18 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
On Tue, 16 Apr 2019 20:38:34 +0200 Christian König wrote:
> + /**
> + * @unpin_dma_buf:
> + *
> + * This is called by dma_buf_unpin and lets the exporter know that an
> + * importer doesn't need to the DMA-buf to stay were it is any more.
> + *
s/need to/need/
On Tue, 16 Apr 2019 20:38:35 +0200 Christian König wrote:
> @ -331,14 +282,19 @@ EXPORT_SYMBOL(drm_gem_map_dma_buf);
> * @sgt: scatterlist info of the buffer to unmap
> * @dir: direction of DMA transfer
> *
> - * Not implemented. The unmap is done at drm_gem_map_detach(). This can be
> - *
On Tue, 16 Apr 2019 20:38:32 +0200 Christian König wrote:
> @@ -688,9 +689,9 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> if (attach->sgt)
> return attach->sgt;
>
> - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>
On Tue, 16 Apr 2019 20:38:33 +0200 Christian König wrote:
> Each importer can now provide an invalidate_mappings callback.
>
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
>
> v2: don't try to invalidate mappings when the callback is NULL,
>
On Tue, 16 Apr 2019 20:38:31 +0200 Christian König wrote:
> Add function variants which can be called with the reservation lock
> already held.
>
> v2: reordered, add lockdep asserts, fix kerneldoc
> v3: rebased on sgt caching
>
> Signed-off-by: Christian König
> ---
>
> On May 23, 2019, at 2:59 PM, Willem de Bruijn
> wrote:what exactly is the issue with IP_TOS?
>
> If I understand correctly, the issue here is that the new 'P' option
> that polls on the error queue times out. This is unrelated to
> specifying TOS bits? Without zerocopy or timestamps, no
> On May 23, 2019, at 2:39 PM, Willem de Bruijn
> wrote:
> Zerocopy notification reference count is managed in skb_segment. That
> should work.
>
I’m trying to understand the context of reference counting in skb_segment. I
assume that
there is an opportunity to optimize the count of
From: Colin Ian King
The spelling of configured is incorrect in the documentation. Fix it.
Signed-off-by: Colin Ian King
---
.../devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt| 6 +++---
.../devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt| 6 +++---
On 5/22/19 6:24 AM, Thierry Reding wrote:
On Tue, May 21, 2019 at 04:31:21PM -0700, Sowjanya Komatineni wrote:
The GPIO controller doesn't have any controls to enable the system to
wake up from low power states based on activity on GPIO pins. An extra
hardware block that is part of the power
hallo
I today I got a regression
see the attached dmesg
--
Ronald
[0.00] microcode: microcode updated early to revision 0xcc, date =
2019-04-01
[0.00] Linux version 5.1.5_MY (r...@obelix.fritz.box) (gcc version
9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)) #1 SMP PREEMPT Sat May
From: Colin Ian King
There is a spelling mistake in a dev_err error message. Fit it.
Signed-off-by: Colin Ian King
---
sound/soc/codecs/cx2072x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cx2072x.c b/sound/soc/codecs/cx2072x.c
index
> On May 23, 2019, at 2:59 PM, Willem de Bruijn
> wrote:
> what exactly is the issue with IP_TOS?
>
> If I understand correctly, the issue here is that the new 'P' option
> that polls on the error queue times out. This is unrelated to
> specifying TOS bits? Without zerocopy or timestamps, no
On Sat, May 25, 2019 at 11:48 AM Frank Lee wrote:
>
> HI Ondřej,
>
> On Sun, May 19, 2019 at 10:22 PM Ondřej Jirman wrote:
> >
> > Hello Yangtao,
> >
> > On Sat, May 18, 2019 at 12:34:57AM +0800, Frank Lee wrote:
> > > HI,
> > >
> > > On Fri, May 17, 2019 at 2:29 AM Ondřej Jirman wrote:
> > > >
On 5/25/19 2:02 AM, Hariprasad Kelam wrote:
> fix below warning reported by coccicheck
>
> /tools/lib/bpf/libbpf.c:3461:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Signed-off-by: Hariprasad Kelam
Acked-by: Yonghong Song
> ---
> tools/lib/bpf/libbpf.c | 4 +---
> 1 file changed, 1
The VDDEE regulator is basically a copy of the VCCK regulator. VDDEE
supplies for example the Mali GPU and is controlled by PWM_D instead of
PWM_C.
Add the VDDEE PWM regulator and make it the supply of the Mali GPU.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b-mxq.dts | 26
The VDDEE regulator is basically a copy of the VCCK regulator. VDDEE
supplies for example the Mali GPU and is controlled by PWM_D instead of
PWM_C.
Add the VDDEE PWM regulator and make it the supply of the Mali GPU.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b-ec100.dts |
EC-100 and Odroid-C1 use a "copy" of the VCCK regulator as "VDDEE"
regulator. VDDEE supplies the Mali GPU and various other bits within
the SoC.
The VDDEE regulator is not exclusive to the Mali GPU so it must not
change it's voltage. The GPU OPP table has a fixed voltage for all
frequencies of
The VDDEE regulator is basically a copy of the VCCK regulator. VDDEE
supplies for example the Mali GPU and is controlled by PWM_D instead of
PWM_C.
Add the VDDEE PWM regulator and make it the supply of the Mali GPU.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b-odroidc1.dts
The PWM_D output is used for the VDDEE PWM regulator which supplies for
example the Mali GPU on the EC-100 and Odroid-C1 boards. Add the output
pin the VDDEE regulators can be added.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b.dtsi | 8
1 file changed, 8
HI,
Following the discussion above, I made some changes.
I think it's time to consider V3 and see what else needs to be modified.
Thx,
Yangtao
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the
HI Ondřej,
On Sun, May 19, 2019 at 10:22 PM Ondřej Jirman wrote:
>
> Hello Yangtao,
>
> On Sat, May 18, 2019 at 12:34:57AM +0800, Frank Lee wrote:
> > HI,
> >
> > On Fri, May 17, 2019 at 2:29 AM Ondřej Jirman wrote:
> > >
> > > Hi Yangtao,
> > >
> > > thank you for work on this driver.
> > >
>
> On May 25, 2019, at 8:20 AM, Willem de Bruijn
> wrote:
>
> On Fri, May 24, 2019 at 6:01 PM Fred Klassen wrote:
>>
>>
>>
>>> On May 24, 2019, at 12:29 PM, Willem de Bruijn
>>> wrote:
>>>
>>> It is the last moment that a timestamp can be generated for the last
>>> byte, I don't see
Commit 9fba738a53dda2 ("clk: add duty cycle support") added support for
getting and setting the duty cycle of a clock. This implements the
get_duty_cycle callback for PWM based clocks so the duty cycle is shown
in the debugfs output (/sys/kernel/debug/clk/clk_summary).
Signed-off-by: Martin
This is a patch that I had lying around in my tree for a while. I was
planning to use it back when I was debugging CPU clock issues on
Meson8b a while ago but it turned out that PWM was not related to that.
Feel free to apply or drop this patch, depending on whether it might or
might not be
This brings the kernel doc in line with the function signature.
Signed-off-by: Yangtao Li
---
kernel/time/alarmtimer.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 0519a8805aab..57518efc3810 100644
--- a/kernel/time/alarmtimer.c
(Cc Vlastimil)
On Sat, 25 May 2019 15:07:23 +0800 zhong jiang wrote:
> We bind an different node to different vma, Unluckily,
> it will bind different vma to same node by checking the /proc/pid/numa_maps.
>
> Commit 213980c0f23b ("mm, mempolicy: simplify rebinding mempolicies when
>
On Sat 25 May 10:53 PDT 2019, Sai Prakash Ranjan wrote:
> On 5/1/2019 10:07 AM, Bjorn Andersson wrote:
> > The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver
> > is used to communicate with the AOSS for certain side-channel requests,
> > that are not available through the
This patch adds the support for allwinner thermal sensor, within
allwinner SoC. It will register sensors for thermal framework
and use device tree to bind cooling device.
Signed-off-by: Yangtao Li
---
MAINTAINERS | 7 +
drivers/thermal/Kconfig | 14 +
This patch adds binding document for allwinner h6 thermal controller.
Signed-off-by: Yangtao Li
---
.../bindings/thermal/sun8i-thermal.yaml | 71 +++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
diff
To unify code style.
Signed-off-by: Yangtao Li
---
drivers/thermal/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index fa6f8b206281..d7eafb5ef8ef 100644
--- a/drivers/thermal/Makefile
+++
This patchset add support for H6 thermal sensor.
BWY, do a cleanup in thermal makfile.
Yangtao Li (3):
thermal: sun8i: add thermal driver for h6
dt-bindings: thermal: add binding document for h6 thermal controller
thermal: fix indentation in makefile
MISC_CLK_SEL_WIDTH is only used in one place where it's converted into
a bit-mask. Rename and change the macro to be a bit-mask so that
conversion is not needed anymore. No functional changes intended.
Signed-off-by: Martin Blumenstingl
---
drivers/pwm/pwm-meson.c | 4 ++--
1 file changed, 2
Replace the loop to calculate the pre-divider and count with two
separate div64_u64() calculations. This makes the code easier to read
and improves the precision.
Two example cases:
1) 32.768kHz LPO clock for the SDIO wifi chip on Khadas VIM
clock input: 500MHz (FCLK_DIV4)
period: 30518ns
All existing PWM drivers (except pwm-meson and two other ones) call
pwm_set_chip_data() from their pwm_ops.request() callback. Now that we
can access the struct meson_pwm_channel from struct meson_pwm we can do
the same.
Move the call to pwm_set_chip_data() to meson_pwm_request() and drop the
Update the meson_pwm_get_state() implementation to take care of all
information in the registers instead of only reading the "enabled"
state.
The PWM output is only enabled if two conditions are met:
1. the per-channel clock is enabled
2. the PWM output is enabled
Calculate the PWM period and
meson_pwm_calc() is the last function that accepts a struct
meson_pwm_channel. meson_pwm_enable(), meson_pwm_disable() and
meson_pwm_apply() for example are all taking a struct pwm_device as
parameter. When they need the struct meson_pwm_channel these functions
simply call pwm_get_chip_data()
This is a preparation for a future cleanup. Pass struct pwm_device
instead of passing the individual values required by each function as
these can be obtained for each struct pwm_device instance.
As a nice side-effect the driver now uses "switch (pwm->hwpwm)"
everywhere. Before some functions
meson_pwm_calc() ensures that "lo" is always less than 16 bits wide
(otherwise it would overflow into the "hi" part of the REG_PWM_{A,B}
register).
Use GENMASK and FIELD_PREP for the lo and hi values to make it easier to
spot how wide these are internally. Additionally this is a preparation
step
meson_pwm_apply() has to consider the PWM polarity when disabling the
output.
With enabled=false and polarity=PWM_POLARITY_NORMAL the output needs to
be LOW. The driver already supports this.
With enabled=false and polarity=PWM_POLARITY_INVERSED the output needs
to be HIGH. Implement this in the
Add a link to the datasheet and a short summary how the hardware works.
The goal is to make it easier for other developers to understand why the
pwm-meson driver is implemented the way it is.
Suggested-by: Uwe Kleine-König
Co-authored-by: Neil Armstrong
Signed-off-by: Martin Blumenstingl
---
Introduce struct meson_pwm_channel_data which contains the per-channel
offsets for the PWM register and REG_MISC_AB bits. Replace the existing
switch (pwm->hwpwm) statements with an access to the new struct.
This simplifies the code and will make it easier to implement
pwm_ops.get_state() because
Simplify the code which fetches the input clock for a PWM channel by
using devm_clk_get_optional().
This comes with a small functional change: previously all errors except
EPROBE_DEFER were ignored. Now all other errors are also treated as
errors. If no input clock is present
The PWM core already caches the "current struct pwm_state" as the
"current state of the hardware registers" inside struct pwm_device.
Drop the struct pwm_state from struct meson_pwm_channel in favour of the
struct pwm_state in struct pwm_device. While here also drop any checks
based on the
This series consists of various cleanups and improvements for the
pwm-meson driver.
Patches 1 to 6 are small code cleanups with the goal of making the code
easier to read.
Patches 7 to 9 are reworking the way the per-channel settings are
accessed. This is a first preparation step for adding full
Let meson_pwm_calc() use the polarity from struct pwm_state directly.
This removes a level of indirection where meson_pwm_apply() first had to
set a driver-internal inverter mask which was then only used by
meson_pwm_calc().
Instead of adding the polarity as parameter to meson_pwm_calc() switch
Make struct meson_pwm_channel accessible from struct meson_pwm.
PWM core has a limitation: per-channel data can only be set after
pwmchip_add() is called. However, pwmchip_add() internally calls
pwm_ops.get_state(). If pwm_ops.get_state() needs access to the
per-channel data it has to obtain it
A31 have a different memory mapping so add the compatible
we will need it later.
Signed-off-by: Clément Péron
---
drivers/media/rc/sunxi-cir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 307e44714ea0..29ac33b68596 100644
Since A31 memory mapping of the IR driver has changed.
Prefer the A31 bindings instead of A13.
Signed-off-by: Clément Péron
---
arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
arch/arm/boot/dts/sunxi-h3-h5.dtsi |
There is some minor differences between A31 and A64 driver.
But A31 IR driver is compatible with A64.
Signed-off-by: Clément Péron
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
From: Jernej Skrabec
OrangePi Win board contains IR receiver. Enable it.
Signed-off-by: Jernej Skrabec
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 4
1 file changed, 4 insertions(+)
diff --git
Allwiner H6 IR is similar to A31 and can use same driver.
Add support for it.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
From: Igors Makejevs
IR peripheral is completely compatible with A31 one.
Signed-off-by: Igors Makejevs
Signed-off-by: Jernej Skrabec
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git
1 - 100 of 275 matches
Mail list logo
