Hi Prabhakar,
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Monday, September 3, 2018 3:24 PM
> To: Yogesh Narayan Gaur ; linux-
> m...@lists.infradead.org; boris.brezil...@bootlin.com; marek.va...@gmail.com;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org
> Cc:
Hi Prabhakar,
> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Monday, September 3, 2018 3:24 PM
> To: Yogesh Narayan Gaur ; linux-
> m...@lists.infradead.org; boris.brezil...@bootlin.com; marek.va...@gmail.com;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org
> Cc:
Hi,
On 11 August 2018 at 09:34, Baolin Wang wrote:
> Remove the unused reg_backup structure.
>
> Signed-off-by: Baolin Wang
> ---
Do you have any comments for this patch set? Thanks.
--
Baolin Wang
Best Regards
Hi,
On 11 August 2018 at 09:34, Baolin Wang wrote:
> Remove the unused reg_backup structure.
>
> Signed-off-by: Baolin Wang
> ---
Do you have any comments for this patch set? Thanks.
--
Baolin Wang
Best Regards
On Mon, Sep 03, 2018 at 05:42:21PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 03, 2018 at 06:48:38PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.154 release.
> > There are 80 patches in this series, all will be posted as a response
> > to this
On Mon, Sep 03, 2018 at 05:42:21PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 03, 2018 at 06:48:38PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.154 release.
> > There are 80 patches in this series, all will be posted as a response
> > to this
On Tue, Sep 04, 2018 at 10:08:13AM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:26, Greg Kroah-Hartman
> wrote:
> > 4.18-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Peter Zijlstra
> >
> > commit
On Tue, Sep 04, 2018 at 10:08:13AM +0530, Naresh Kamboju wrote:
> On 3 September 2018 at 22:26, Greg Kroah-Hartman
> wrote:
> > 4.18-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Peter Zijlstra
> >
> > commit
On Thu, Aug 30, 2018 at 11:00:14AM -0400, Martin K. Petersen wrote:
> Introduce a facility that can be used to receive a notification
> callback when a new algorithm becomes available. This can be used by
> existing crypto registrations to trigger a switch from a software-only
> algorithm to a
On Thu, Aug 30, 2018 at 11:00:14AM -0400, Martin K. Petersen wrote:
> Introduce a facility that can be used to receive a notification
> callback when a new algorithm becomes available. This can be used by
> existing crypto registrations to trigger a switch from a software-only
> algorithm to a
On Mon, Aug 27, 2018 at 05:38:10PM +0200, Ard Biesheuvel wrote:
> The current arm64 CRC-T10DIF code only runs on cores that implement the
> 64x64 bit PMULL instructions that are part of the optional Crypto
> Extensions, and falls back to the highly inefficient C code otherwise.
>
> Let's provide
On Mon, Aug 27, 2018 at 05:38:10PM +0200, Ard Biesheuvel wrote:
> The current arm64 CRC-T10DIF code only runs on cores that implement the
> 64x64 bit PMULL instructions that are part of the optional Crypto
> Extensions, and falls back to the highly inefficient C code otherwise.
>
> Let's provide
On Mon, Aug 27, 2018 at 01:02:45PM +0200, Ard Biesheuvel wrote:
> Now that the scalar fallbacks have been moved out of this driver into
> the core crc32()/crc32c() routines, we are left with a CRC32 crypto API
> driver for arm64 that is based only on 64x64 polynomial multiplication,
> which is an
On Mon, Aug 27, 2018 at 01:02:45PM +0200, Ard Biesheuvel wrote:
> Now that the scalar fallbacks have been moved out of this driver into
> the core crc32()/crc32c() routines, we are left with a CRC32 crypto API
> driver for arm64 that is based only on 64x64 polynomial multiplication,
> which is an
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
> v8 cover letter:
>
> I continue to hope this can land in v4.19, but I realize that's unlikely.
> It would be nice, though, if some of the "trivial" patches could get taken
> (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep
On 09/03/18 at 09:13pm, H. Peter Anvin wrote:
> On 09/03/18 20:44, Baoquan He wrote:
> >
> > 1) in arch/x86/kernel/relocate_kernel_64.S, we set X86_CR4_LA57 into cr4
> > if the 1st kernel is in 5-level mode. Then in
> > arch/x86/boot/compressed/head_64.S, paging_prepare() is called to decide
> >
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
> v8 cover letter:
>
> I continue to hope this can land in v4.19, but I realize that's unlikely.
> It would be nice, though, if some of the "trivial" patches could get taken
> (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep
On 09/03/18 at 09:13pm, H. Peter Anvin wrote:
> On 09/03/18 20:44, Baoquan He wrote:
> >
> > 1) in arch/x86/kernel/relocate_kernel_64.S, we set X86_CR4_LA57 into cr4
> > if the 1st kernel is in 5-level mode. Then in
> > arch/x86/boot/compressed/head_64.S, paging_prepare() is called to decide
> >
On Wed, Aug 22, 2018 at 10:51:44AM +0200, Ard Biesheuvel wrote:
> As it turns out, the AVX2 multibuffer SHA routines are currently
> broken [0], in a way that would have likely been noticed if this
> code were in wide use. Since the code is too complicated to be
> maintained by anyone except the
On Wed, Aug 22, 2018 at 10:51:44AM +0200, Ard Biesheuvel wrote:
> As it turns out, the AVX2 multibuffer SHA routines are currently
> broken [0], in a way that would have likely been noticed if this
> code were in wide use. Since the code is too complicated to be
> maintained by anyone except the
On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote:
> Currently, the CCP driver assumes that the SEV command issued to the PSP
> will always return (i.e. it will never hang). But recently, firmware bugs
> have shown that a command can hang. Since of the SEV commands are used
> in
On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote:
> Currently, the CCP driver assumes that the SEV command issued to the PSP
> will always return (i.e. it will never hang). But recently, firmware bugs
> have shown that a command can hang. Since of the SEV commands are used
> in
From: Alexandre Belloni
Date: Mon, 3 Sep 2018 15:45:22 +0200
> On 03/09/2018 15:34:15+0200, Andrew Lunn wrote:
>> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through
>> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem.
>>
>> Hi Quentin
>>
>>
From: Alexandre Belloni
Date: Mon, 3 Sep 2018 15:45:22 +0200
> On 03/09/2018 15:34:15+0200, Andrew Lunn wrote:
>> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through
>> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem.
>>
>> Hi Quentin
>>
>>
From: Salil Mehta
Date: Mon, 3 Sep 2018 11:21:45 +0100
> This patch-set presents some fixes and minor enhancements to HNS3
> Driver
Series applied, thank you.
From: Salil Mehta
Date: Mon, 3 Sep 2018 11:21:45 +0100
> This patch-set presents some fixes and minor enhancements to HNS3
> Driver
Series applied, thank you.
Add pon, coincell and rtc to the first pm8998 sid.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 31
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
b/arch/arm64/boot/dts/qcom/pm8998.dtsi
index
Add pon, coincell and rtc to the first pm8998 sid.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 31
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
b/arch/arm64/boot/dts/qcom/pm8998.dtsi
index
Hi,
Raise my point.
The case here is that we have multiple sensors connected to CIO2. The sensors
work independently. So failure on one sensor should not block the function of
the other.
That is, we should not rely on that all sensors are ready before allowing user
to operate on the ready
Hi,
Raise my point.
The case here is that we have multiple sensors connected to CIO2. The sensors
work independently. So failure on one sensor should not block the function of
the other.
That is, we should not rely on that all sensors are ready before allowing user
to operate on the ready
From: Joonwoo Park
Add initial device tree support for the Qualcomm MSM8998 SoC and
MTP8998 evaluation board.
Signed-off-by: Joonwoo Park
Signed-off-by: Imran Khan
Signed-off-by: Rajendra Nayak
[bjorn: Restructured, removed its node and moved to SPDX headers]
Signed-off-by: Bjorn Andersson
From: Joonwoo Park
Add initial device tree support for the Qualcomm MSM8998 SoC and
MTP8998 evaluation board.
Signed-off-by: Joonwoo Park
Signed-off-by: Imran Khan
Signed-off-by: Rajendra Nayak
[bjorn: Restructured, removed its node and moved to SPDX headers]
Signed-off-by: Bjorn Andersson
Add the two tsens instances and the thermal zones for CPUs, GPUs,
battery and skin sensors.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 38 +
arch/arm64/boot/dts/qcom/msm8998.dtsi | 193 ++
2 files
Add nodes for RPM communication for MSM8998 and the regulator nodes for
the MTP.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Moved regulators to MTP, as the choice of PMICs can be device specifc
- Updated names of regulators
- Corrected the supply tree of the regulators
Add reserve-memory nodes, tcsr-mutex nodes and the smem node.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
Add the two tsens instances and the thermal zones for CPUs, GPUs,
battery and skin sensors.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 38 +
arch/arm64/boot/dts/qcom/msm8998.dtsi | 193 ++
2 files
Add nodes for RPM communication for MSM8998 and the regulator nodes for
the MTP.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Moved regulators to MTP, as the choice of PMICs can be device specifc
- Updated names of regulators
- Corrected the supply tree of the regulators
Add reserve-memory nodes, tcsr-mutex nodes and the smem node.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
Add the QFPROM nvmem node to msm8998
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index
Add the QFPROM nvmem node to msm8998
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index
Add new dtsi file for the PMI8998, with its gpios and include all three
PMICs in the MSM8998 MTP dts.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 3 ++
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 40 +++
2
Add the firmware and scm nodes for msm8998
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index
Add new dtsi file for the PMI8998, with its gpios and include all three
PMICs in the MSM8998 MTP dts.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 3 ++
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 40 +++
2
Add the firmware and scm nodes for msm8998
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index
This series introduces the MSM8998 platform and the MTP device for this
platform. Including additional 6 patches that has been waiting for the initial
submission to be accepted.
Bjorn Andersson (7):
arm64: dts: qcom: msm8998: Add RPM and regulators for MTP
arm64: dts: qcom: msm8998: Add tsens
Add the adsp, modem and slpi smp2p nodes to msm8998.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 64 +++
1 file changed, 64 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
This series introduces the MSM8998 platform and the MTP device for this
platform. Including additional 6 patches that has been waiting for the initial
submission to be accepted.
Bjorn Andersson (7):
arm64: dts: qcom: msm8998: Add RPM and regulators for MTP
arm64: dts: qcom: msm8998: Add tsens
Add the adsp, modem and slpi smp2p nodes to msm8998.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New patch
arch/arm64/boot/dts/qcom/msm8998.dtsi | 64 +++
1 file changed, 64 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit fd09b7d3b352105f08b8e02f7afecf7e816380ef upstream.
An earlier commit had a typo which prevented the
optimization from working:
commit 18dd8e1a65dd ("Do not send SMB3
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit fd09b7d3b352105f08b8e02f7afecf7e816380ef upstream.
An earlier commit had a typo which prevented the
optimization from working:
commit 18dd8e1a65dd ("Do not send SMB3
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Thumshirn
[ Upstream commit 63d0e3dffda311e77b9a8c500d59084e960a824a ]
Drop the frames in the ELS LOGO error path instead of just returning an
error.
This fixes the following
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Thumshirn
[ Upstream commit 63d0e3dffda311e77b9a8c500d59084e960a824a ]
Drop the frames in the ELS LOGO error path instead of just returning an
error.
This fixes the following
On Tue, Aug 07, 2018 at 08:22:25AM +0200, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. While originally proposed for disk encryption on low-end
> devices,
On Tue, Aug 07, 2018 at 08:22:25AM +0200, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. While originally proposed for disk encryption on low-end
> devices,
From: Ivan Mikhaylov
Date: Mon, 3 Sep 2018 10:26:28 +0300
> __emac_calc_base_mr1 was used instead of __emac4_calc_base_mr1
> by copy-paste mistake for emac4syn.
>
> Fixes: 45d6e545505fd32edb812f085be7de45b6a5c0af ("net/ibm/emac: add 8192
> rx/tx fifo size")
> Signed-off-by: Ivan Mikhaylov
From: Ivan Mikhaylov
Date: Mon, 3 Sep 2018 10:26:28 +0300
> __emac_calc_base_mr1 was used instead of __emac4_calc_base_mr1
> by copy-paste mistake for emac4syn.
>
> Fixes: 45d6e545505fd32edb812f085be7de45b6a5c0af ("net/ibm/emac: add 8192
> rx/tx fifo size")
> Signed-off-by: Ivan Mikhaylov
From: Jagan Teki
The HDMI controller on Allwinner A64 is similar on the one on
H3/H5/A83T (although the PHY is different with A83T).
Add A64 compatible and append A83T compatible as fallback.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
[Icenowy: refactor commit log]
Signed-off-by:
From: Jagan Teki
The HDMI controller on Allwinner A64 is similar on the one on
H3/H5/A83T (although the PHY is different with A83T).
Add A64 compatible and append A83T compatible as fallback.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
[Icenowy: refactor commit log]
Signed-off-by:
Hi Jaejoong.
> Change return type for tty functions. Patch No.01
> tty: Change return type to void
Adding this patch first will generate a lot of warnings
until all users are updated.
It is usual practice to prepare all users
and then apply the infrastructure changes as the
last patch.
Then
From: Jernej Skrabec
Some boards have HDMI VCC pin connected to voltage regulator which may
not be turned on by default.
Add support for such boards by adding voltage regulator handling code to
HDMI driver.
Signed-off-by: Jernej Skrabec
[Icenowy: change supply name to "hvcc"]
Signed-off-by:
The system call tables are in different format in all
architecture and it will be difficult to manually add or
modify the system calls in the respective files. To make
it easy by keeping a script and which'll generate the
header file and syscall table file so this change will
unify them across all
System call table generation script must be run to generate
unistd_32/64.h and syscall_table_32/64/c32.h files. This patch
will have changes which will invokes the script.
This patch will generate unistd_32/64.h and syscall_table_
32/64/c32.h files by the syscall table generation script
invoked
From: Jagan Teki
Enable all necessary device tree nodes and add connector node to device
trees for all supported A64 boards with HDMI.
Signed-off-by: Jagan Teki
[Icenowy: squash all board patches altogether and change supply name]
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Rebase some
Allwiner SoCs with DesignWare HDMI controller all come with a "HVCC"
pin, which is the VCC of HDMI part.
Add a supply property to specify HVCC's regulator in the device tree.
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Rename the supply name to "hvcc".
Changes in v3.1:
- New patch.
Hi Jaejoong.
> Change return type for tty functions. Patch No.01
> tty: Change return type to void
Adding this patch first will generate a lot of warnings
until all users are updated.
It is usual practice to prepare all users
and then apply the infrastructure changes as the
last patch.
Then
From: Jernej Skrabec
Some boards have HDMI VCC pin connected to voltage regulator which may
not be turned on by default.
Add support for such boards by adding voltage regulator handling code to
HDMI driver.
Signed-off-by: Jernej Skrabec
[Icenowy: change supply name to "hvcc"]
Signed-off-by:
The system call tables are in different format in all
architecture and it will be difficult to manually add or
modify the system calls in the respective files. To make
it easy by keeping a script and which'll generate the
header file and syscall table file so this change will
unify them across all
System call table generation script must be run to generate
unistd_32/64.h and syscall_table_32/64/c32.h files. This patch
will have changes which will invokes the script.
This patch will generate unistd_32/64.h and syscall_table_
32/64/c32.h files by the syscall table generation script
invoked
From: Jagan Teki
Enable all necessary device tree nodes and add connector node to device
trees for all supported A64 boards with HDMI.
Signed-off-by: Jagan Teki
[Icenowy: squash all board patches altogether and change supply name]
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Rebase some
Allwiner SoCs with DesignWare HDMI controller all come with a "HVCC"
pin, which is the VCC of HDMI part.
Add a supply property to specify HVCC's regulator in the device tree.
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Rename the supply name to "hvcc".
Changes in v3.1:
- New patch.
From: Jagan Teki
Allwinner A64 HDMI PHY clock has PLL_VIDEO0 as a parent.
Include the macro on dt-bindings so-that the same can be used
while defining CCU clock phandles.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
Signed-off-by: Icenowy Zheng
---
Changes for v4:
- Dropped PLL_VIDEO1
From: Jagan Teki
Allwinner A64 have a display pipeline with 2 mixers/TCONs, the first
TCON is connected to LCD and the second is to HDMI.
The HDMI controller/PHY pair is similar to the one on H3/H5.
Add all required device tree nodes of the display pipeline, including
the TCON0 LCD one and the
NR_syscalls macro holds the number of system call exist in SPARC
architecture. This macro is currently the part of uapi/asm/unistd.h
file. We have to change the value of NR_syscalls, if we add or
delete a system call.
One of the patch in this patch series has a script which will generate
a uapi
From: Jagan Teki
Allwinner A64 HDMI PHY clock has PLL_VIDEO0 as a parent.
Include the macro on dt-bindings so-that the same can be used
while defining CCU clock phandles.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
Signed-off-by: Icenowy Zheng
---
Changes for v4:
- Dropped PLL_VIDEO1
From: Jagan Teki
Allwinner A64 have a display pipeline with 2 mixers/TCONs, the first
TCON is connected to LCD and the second is to HDMI.
The HDMI controller/PHY pair is similar to the one on H3/H5.
Add all required device tree nodes of the display pipeline, including
the TCON0 LCD one and the
NR_syscalls macro holds the number of system call exist in SPARC
architecture. This macro is currently the part of uapi/asm/unistd.h
file. We have to change the value of NR_syscalls, if we add or
delete a system call.
One of the patch in this patch series has a script which will generate
a uapi
From: Jagan Teki
Display Engine(DE2) in Allwinner A64 has two mixers and tcons.
The routing for mixer0 is through tcon0 and connected to
LVDS/RGB/MIPI-DSI controller.
The routing for mixer1 is through tcon1 and connected to HDMI.
Signed-off-by: Jagan Teki
Signed-off-by: Icenowy Zheng
---
All the __IGNORE* entries are resides in the uapi header
file and it is not used by any user space applications.
One of the patch in this patch series will generate the
uapi header file and system call table file. So if we move
all the __IGNORE* entries to non uapi header, it will simplify
the
From: Jagan Teki
Mixers in Allwinner have similar capabilities as others SoCs with DE2.
Add support for them.
Signed-off-by: Jagan Teki
[Icenowy: Add mixer1]
Signed-off-by: Icenowy Zheng
Reviewed-by: Jernej Skrabec
---
Changes for v4:
- none
Changes for v3.1:
- Add mixer0
Changes for v3:
-
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
The system call tables are in different format in
From: Jagan Teki
Display Engine(DE2) in Allwinner A64 has two mixers and tcons.
The routing for mixer0 is through tcon0 and connected to
LVDS/RGB/MIPI-DSI controller.
The routing for mixer1 is through tcon1 and connected to HDMI.
Signed-off-by: Jagan Teki
Signed-off-by: Icenowy Zheng
---
All the __IGNORE* entries are resides in the uapi header
file and it is not used by any user space applications.
One of the patch in this patch series will generate the
uapi header file and system call table file. So if we move
all the __IGNORE* entries to non uapi header, it will simplify
the
From: Jagan Teki
Mixers in Allwinner have similar capabilities as others SoCs with DE2.
Add support for them.
Signed-off-by: Jagan Teki
[Icenowy: Add mixer1]
Signed-off-by: Icenowy Zheng
Reviewed-by: Jernej Skrabec
---
Changes for v4:
- none
Changes for v3.1:
- Add mixer0
Changes for v3:
-
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
The system call tables are in different format in
From: Jagan Teki
According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.
Because of that, set minimal rate to both A64 video PLLs to 192 MHz.
Signed-off-by: Jagan Teki
Signed-off-by: Icenowy Zheng
From: Jagan Teki
Allwinner A64 has a DE2 display pipeline. The TCONs are similar to the
ones in A83T, but the mixers are new (similar to the later R40 SoC).
This patch adds dt-binding documentation for A64 DE2 display pipeline.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
[Icenowy:
Video PLLs on A64 can be set to higher rate that it is actually
supported by HW.
Limit maximum rate to 1008 MHz. This is the maximum allowed rate by BSP
clock driver. Interestengly, user manual specifies maximum frequency to
be 600 MHz. Historically, this data was wrong in some user manuals for
From: Jagan Teki
According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.
Because of that, set minimal rate to both A64 video PLLs to 192 MHz.
Signed-off-by: Jagan Teki
Signed-off-by: Icenowy Zheng
From: Jagan Teki
Allwinner A64 has a DE2 display pipeline. The TCONs are similar to the
ones in A83T, but the mixers are new (similar to the later R40 SoC).
This patch adds dt-binding documentation for A64 DE2 display pipeline.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
[Icenowy:
Video PLLs on A64 can be set to higher rate that it is actually
supported by HW.
Limit maximum rate to 1008 MHz. This is the maximum allowed rate by BSP
clock driver. Interestengly, user manual specifies maximum frequency to
be 600 MHz. Historically, this data was wrong in some user manuals for
Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5.
A64 behaviour similar to Allwinner A83T where
Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
Mixer1 => TCON1 => HDMI
as per Display System Block Diagram from the A64 user manual.
This patchset adds support for the two display
Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5.
A64 behaviour similar to Allwinner A83T where
Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
Mixer1 => TCON1 => HDMI
as per Display System Block Diagram from the A64 user manual.
This patchset adds support for the two display
On 3 September 2018 at 22:26, Greg Kroah-Hartman
wrote:
> 4.18-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Peter Zijlstra
>
> commit d86564a2f085b79ec046a5cba90188e612352806 upstream.
>
> Jann reported that x86 was missing required TLB
On 3 September 2018 at 22:26, Greg Kroah-Hartman
wrote:
> 4.18-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Peter Zijlstra
>
> commit d86564a2f085b79ec046a5cba90188e612352806 upstream.
>
> Jann reported that x86 was missing required TLB
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (C) 2015 Microchip Technology */
Can we merge both in single comment line?
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/* Copyright (C) 2015 Microchip Technology */
Here too.
Thanks,
-Raghu
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (C) 2015 Microchip Technology */
Can we merge both in single comment line?
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/* Copyright (C) 2015 Microchip Technology */
Here too.
Thanks,
-Raghu
On 4 September 2018 at 02:46, François Valenduc
wrote:
> Le 3/09/18 à 20:39, Holger Hoffstätte a écrit :
>> On 09/03/18 18:55, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.18.6 release.
>>
>> Unfortunately this is busted. First blamed my custom patches, but
On 4 September 2018 at 02:46, François Valenduc
wrote:
> Le 3/09/18 à 20:39, Holger Hoffstätte a écrit :
>> On 09/03/18 18:55, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.18.6 release.
>>
>> Unfortunately this is busted. First blamed my custom patches, but
From: "Michael S. Tsirkin"
Date: Mon, 3 Sep 2018 23:11:11 -0400
> On Tue, Sep 04, 2018 at 11:08:40AM +0800, Jason Wang wrote:
>>
>>
>> On 2018年09月04日 10:22, Michael S. Tsirkin wrote:
>> > On Mon, Sep 03, 2018 at 08:59:13PM +0300, Gleb Fotengauer-Malinovskiy
>> > wrote:
>> > > The _IOC_READ
From: "Michael S. Tsirkin"
Date: Mon, 3 Sep 2018 23:11:11 -0400
> On Tue, Sep 04, 2018 at 11:08:40AM +0800, Jason Wang wrote:
>>
>>
>> On 2018年09月04日 10:22, Michael S. Tsirkin wrote:
>> > On Mon, Sep 03, 2018 at 08:59:13PM +0300, Gleb Fotengauer-Malinovskiy
>> > wrote:
>> > > The _IOC_READ
1 - 100 of 2130 matches
Mail list logo
