Age | Commit message (Collapse) | Author |
|
Fix the parent-child power domain dependency to handle different
PCIE usecases.
Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
|
|
Current i2c4/uart1 clocks ID have conflict with pwm2/pwm3,
correct them.
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
|
|
As we would support some non-native prefetch engine pixel formats
soon later with some coming patches, hot-switch from native pixel
formats to non-native ones(on-the-fly PRG bypass) is inevitable.
Basically, dprc_disable() is called to do the switch. If a follow-up
modeset is done to enable the prefetch engine again, we see prefetch
engine fail-over issue. So, a reset is needed in dprc_disable()
in the need_modeset case. It appears that PRG reset is enough.
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 52450396e492b555cd965b046e8982c77cdcafee)
(cherry picked from commit 8045c5046812a81e530d123d2ee78ef2c9376b8b)
|
|
This patch adds helper dprc_is_repeat_en() support so that
callers may know whether DPRC REPEAT_EN bit is enabled or not.
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 029d6ec7d4e73f4c2876d4b0d3c2d1504bb9293a)
(cherry picked from commit cbcac4fa968da56d2cedae4e2186659d0706b6cd)
|
|
dprc_gasket_shadow_enable/disable() support
The start/aux_start arguments of dprc_configure() are not clearly
defined. Currently, they would impact both DPRC SYSTEM_CTRL0 register
and PRG SHADOW_EN bit in PRG_CTRL register. However, we need to control
the PRG SHADOW_EN bit separately from the DPRC register. So, this patch
adds helper dprc_gasket_shadow_enable/disable() support so that caller
may enable or disable DPRC's gasket(PRG) SHADOW_EN bit only.
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 830c4d99445aa9620e28929aa2323c07f859c81d)
(cherry picked from commit 34505c98243c85bf2b1d0a6ef70092f008887004)
|
|
This patch adds helper prg_shadow_disable() support so that callers
may disable PRG SHADOW_EN bit.
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit d0c6de11268ced25dd7e33111914bdd76c70ab84)
(cherry picked from commit c346809d39662dbe43d8a23635a60a439949774b)
|
|
This patch adds helper dprc_disable_repeat_en() so that callers
may disable DPRC repeat_en.
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 618a40a421987c31335485ba02fbc5476c224e4b)
(cherry picked from commit ca93dcd5bb678716d4e9f30c228b796ad7136062)
|
|
No one is using pin-off operations, so let's remove them.
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 24d75f3118895fbbec9e5b5e6e42d54d20db27f1)
(cherry picked from commit 7a827f219fe5c9e8dc33c0cedf8e77e2c4060a19)
|
|
Driver to communicate with SECO over messaging unit.
Expose a char device to user-space so user can write messages that
will be sent to SECO and read messages received from it.
Data that should be exchanged with SECO through shared memory are
indicated to this driver through ioctl calls.
Signed-off-by: Stephane Dion <stephane.dion_1@nxp.com>
(cherry picked from commit eb721810fdc309b6a32a7a64c7686eaa6052cdc7)
(cherry picked from commit db41bf52c2edf7c0936686d806eb4b2373b385a0)
|
|
The driver register an IRQ handle to SCU for security
violation interrupt.
When an interruption is fired, the driver inform the user.
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
|
|
The function sc_seco_secvio_dgo_config is not declared in
the header.
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
|
|
Sync SCFW API to commit 6dcd0242ae
Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
|
|
Sync SCFW API to commit 6dcd0242ae
Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
|
|
Remove below audio clocks from clk tree.
IMX8QXP_ACM_AUD_CLK0_CLK
IMX8QXP_ACM_AUD_CLK1_CLK,
IMX8QXP_ACM_ASRC0_MUX_CLK_SEL
IMX8QXP_ACM_ASRC0_MUX_CLK_CLK
IMX8QXP_ACM_ASRC1_MUX_CLK_CLK
IMX8QXP_ACM_ASRC1_MUX_CLK_SEL
There are no these clocks physically. which are added
wrongly before, so remove them.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
|
|
Remove below audio clocks from clk tree.
IMX8QM_ACM_AUD_CLK0_CLK
IMX8QM_ACM_AUD_CLK1_CLK,
IMX8QM_ACM_ASRC1_MUX_CLK_CLK
IMX8QM_ACM_ASRC1_MUX_CLK_SEL
There are no these clocks physically. which are added
wrongly before, so remove them.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
|
|
Add new pmic pca9450 driver for i.mx8mn-evk board.
Signed-off-by: John Lee <john.lee@nxp.com>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
|
|
As DPU fetchunits support ITU601(limited range)/ITU601_FR(full range)
and ITU709(limited range) YUV to RGB color space conversions, we may
add color encoding and color range properties support for planes.
Considering software backward compatibility, the default color encoding
is set to ITU601 with full color range.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit f491e24e65cb360fb0b3ce56f74d04fd80da77ab)
|
|
This patch adds mulitple pixel blend modes for DPU plane.
The modes are "None", "Pre-multiplied" and "Coverage".
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 1259fedbcf2a54f58b47e8531a09b35cc60a43f7)
|
|
Without the new blend modes("None", "Pre-multiplied" and "Coverage")
introduced in the below commit, the old userspace assumes alpha in
pixel is per-premultiplied by default. So, let's support the default
blend mode properly.
commit 468dba6432ca ("drm: Add per-plane pixel blend mode property")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit ebb7b4874493a8fb42de636e9421877a54399177)
|
|
Pixel blend modes represent the alpha blending equation
selection, describing how the pixels from the current
plane are composited with the background.
Adds a pixel_blend_mode to drm_plane_state and a
blend_mode_property to drm_plane, and related support
functions.
Defines three blend modes in drm_blend.h.
Changes since v1:
- Moves the blending equation into the DOC comment
- Refines the comments of drm_plane_create_blend_mode_property to not
enumerate the #defines, but instead the string values
- Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
Changes since v2:
- Refines the comments of drm_plane_create_blend_mode_property:
1) Puts the descriptions (after the ":") on a new line
2) Adds explaining why @supported_modes need PREMUL as default
Changes since v3:
- Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
can calculate the index itself just fine, so no point in having the
caller pass it in.
- Since the current DRM assumption is that alpha is premultiplied
as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
- Refines some comments.
Changes since v4:
- Adds comments in drm_blend.h.
- Removes setting default value in drm_plane_create_blend_mode_property()
as it is already in __drm_atomic_helper_plane_reset().
- Fixes to use state->pixel_blend_mode instead of using
plane->state->pixel_blend_mode in reset function.
- Rebases on drm-misc-next.
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Lowry Li <lowry.li@arm.com>
Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/245734/
(cherry picked from commit a5ec8332d4280500544e316f76c04a7adc02ce03)
|
|
drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316190420.26734-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit 30e9db6d046ba667070e5a011a13951830d60a6e)
|
|
Using a flexible array for the blob data was a mistake by me. It
forces all users of the blob data to cast blob->data to something
else. void* is clearly superior so let's go back to the original
scheme.
Not a clean revert as the code has moved.
This reverts commit d63f5e6bf6f2a1573ea39c9937cdf5ab0b3a4b77.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-1-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 9c60583c0b0fd6f3a5b61fda3eb604ce218b9d25)
|
|
The property flags are part of the uabi and we have 32 bits for them.
Pass them around as u32 internally as well, instead of a signed int.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-5-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 51abc97658b954d357f6107885a3b069f497c7ff)
|
|
There are a lot of drivers that subclass drm_plane_state, all of them
duplicate the code that links together the plane with plane_state.
On top of that, drivers that enable core properties also have to
duplicate the code for initializing the properties to their default
values, which in all cases are the same as the defaults from core.
Change since v1:
- Make it consistent with the other helpers and require that both
plane and state not be NULL, suggested by Boris Brezillon and
Philipp Zabel.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180804161530.12275-2-alexandru-cosmin.gheorghe@arm.com
(cherry picked from commit 7f4de521001f4ea705d505c9f91f58d0f56a0e6d)
|
|
Add a standard optional properties to support different non RGB color
encodings in DRM planes. COLOR_ENCODING select the supported non RGB
color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
the value ranges within the selected color encoding. The properties
are stored to drm_plane object to allow different set of supported
encoding for different planes on the device.
v2: Add/fix kerneldocs, verify bitmasks (danvet)
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
[vsyrjala v2: Add/fix kerneldocs, verify bitmasks]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219202823.10508-1-ville.syrjala@linux.intel.com
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 80f690e9e3a60f628de61748be4dd2fd6baf5cc8)
|
|
Some drivers duplicate the logic to create a property to store a per-plane
alpha.
This is especially useful if we ever want to support extra protocols for
Wayland like:
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
Let's create a helper in order to move that to the core.
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6e1ce0db78fcfc407e94913c64819e65109d034d.1523432341.git-series.maxime.ripard@bootlin.com
(cherry picked from commit ae0e28265e216dad11d4cbde42fc15e92919af78)
|
|
The CRTC background should be full screen instead of partial
screen, because the DRM core is likely to add configurable
background color support in the future. We may cover the full
screen with ConstFrame0/1, upon which builds planes. With this,
it is easier to compute each plane's layer offset vs CRTC start
point and all ConstFrame units can be controlled by CRTC.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit ba18a9874cf010032413ca70f9b358399a143037)
|
|
commit b617158dc096709d8600c53b6052144d12b89fab upstream.
Some applications set tiny SO_SNDBUF values and expect
TCP to just work. Recent patches to address CVE-2019-11478
broke them in case of losses, since retransmits might
be prevented.
We should allow these flows to make progress.
This patch allows the first and last skb in retransmit queue
to be split even if memory limits are hit.
It also adds the some room due to the fact that tcp_sendmsg()
and tcp_sendpage() might overshoot sk_wmem_queued by about one full
TSO skb (64KB size). Note this allowance was already present
in stable backports for kernels < 4.15
Note for < 4.15 backports :
tcp_rtx_queue_tail() will probably look like :
static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
{
struct sk_buff *skb = tcp_send_head(sk);
return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
}
Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrew Prout <aprout@ll.mit.edu>
Tested-by: Andrew Prout <aprout@ll.mit.edu>
Tested-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Tested-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Christoph Paasch <cpaasch@apple.com>
Cc: Jonathan Looney <jtl@netflix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 8c3088f895a0cfdf630973a9cd32f5e085eb973c)
|
|
[ Upstream commit 8d650cdedaabb33e85e9b7c517c0c71fcecc1de9 ]
Neal reported incorrect use of ns_capable() from bpf hook.
bpf_setsockopt(...TCP_CONGESTION...)
-> tcp_set_congestion_control()
-> ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN)
-> ns_capable_common()
-> current_cred()
-> rcu_dereference_protected(current->cred, 1)
Accessing 'current' in bpf context makes no sense, since packets
are processed from softirq context.
As Neal stated : The capability check in tcp_set_congestion_control()
was written assuming a system call context, and then was reused from
a BPF call site.
The fix is to add a new parameter to tcp_set_congestion_control(),
so that the ns_capable() call is only performed under the right
context.
Fixes: 91b5b21c7c16 ("bpf: Add support for changing congestion control")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Lawrence Brakmo <brakmo@fb.com>
Reported-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Lawrence Brakmo <brakmo@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit adcac7370d7d9c6c8f58c590fff117d95c65fb61)
|
|
commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream.
Some TCP peers announce a very small MSS option in their SYN and/or
SYN/ACK messages.
This forces the stack to send packets with a very high network/cpu
overhead.
Linux has enforced a minimal value of 48. Since this value includes
the size of TCP options, and that the options can consume up to 40
bytes, this means that each segment can include only 8 bytes of payload.
In some cases, it can be useful to increase the minimal value
to a saner value.
We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility
reasons.
Note that TCP_MAXSEG socket option enforces a minimal value
of (TCP_MIN_MSS). David Miller increased this minimal value
in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.")
from 64 to 88.
We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS.
CVE-2019-11479 -- tcp mss hardcoded to 48
Signed-off-by: Eric Dumazet <edumazet@google.com>
Suggested-by: Jonathan Looney <jtl@netflix.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Bruce Curtis <brucec@netflix.com>
Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cd6f35b8421ff20365ff711c0ac7647fd70e9af7)
|
|
commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.
Jonathan Looney reported that a malicious peer can force a sender
to fragment its retransmit queue into tiny skbs, inflating memory
usage and/or overflow 32bit counters.
TCP allows an application to queue up to sk_sndbuf bytes,
so we need to give some allowance for non malicious splitting
of retransmit queue.
A new SNMP counter is added to monitor how many times TCP
did not allow to split an skb if the allowance was exceeded.
Note that this counter might increase in the case applications
use SO_SNDBUF socket option to lower sk_sndbuf.
CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the
socket is already using more than half the allowed space
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jonathan Looney <jtl@netflix.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Cc: Bruce Curtis <brucec@netflix.com>
Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9daf226ff92679d09aeca1b5c1240e3607153336)
|
|
commit 3b4929f65b0d8249f19a50245cd88ed1a2f78cff upstream.
Jonathan Looney reported that TCP can trigger the following crash
in tcp_shifted_skb() :
BUG_ON(tcp_skb_pcount(skb) < pcount);
This can happen if the remote peer has advertized the smallest
MSS that linux TCP accepts : 48
An skb can hold 17 fragments, and each fragment can hold 32KB
on x86, or 64KB on PowerPC.
This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs
can overflow.
Note that tcp_sendmsg() builds skbs with less than 64KB
of payload, so this problem needs SACK to be enabled.
SACK blocks allow TCP to coalesce multiple skbs in the retransmit
queue, thus filling the 17 fragments to maximal capacity.
CVE-2019-11477 -- u16 overflow of TCP_SKB_CB(skb)->tcp_gso_segs
Backport notes, provided by Joao Martins <joao.m.martins@oracle.com>
v4.15 or since commit 737ff314563 ("tcp: use sequence distance to
detect reordering") had switched from the packet-based FACK tracking and
switched to sequence-based.
v4.14 and older still have the old logic and hence on
tcp_skb_shift_data() needs to retain its original logic and have
@fack_count in sync. In other words, we keep the increment of pcount with
tcp_skb_pcount(skb) to later used that to update fack_count. To make it
more explicit we track the new skb that gets incremented to pcount in
@next_pcount, and we get to avoid the constant invocation of
tcp_skb_pcount(skb) all together.
Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK processing")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jonathan Looney <jtl@netflix.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Bruce Curtis <brucec@netflix.com>
Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d632920554c5aec81d8a79c23dac07efcbabbd54)
|
|
[ Upstream commit 04c03114be82194d4a4858d41dba8e286ad1787c ]
soukjin bae reported a crash in tcp_v4_err() handling
ICMP_DEST_UNREACH after tcp_write_queue_head(sk)
returned a NULL pointer.
Current logic should have prevented this :
if (seq != tp->snd_una || !icsk->icsk_retransmits ||
!icsk->icsk_backoff || fastopen)
break;
Problem is the write queue might have been purged
and icsk_backoff has not been cleared.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: soukjin bae <soukjin.bae@samsung.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3a493b762f31fc0c571051cdfb0d80f49498e5fd)
|
|
On some imx host, if USB PHY is active when bus suspended, host may
have problem on taking over resume signal of remote wakeup from usb
device, resolve this by making PHY enter low power mode right after
bus suspended.
Acked-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
(cherry picked from commit 704c710f6d0267558c7443a7afbf63767b623947)
|
|
Update i.MX8MM pinctrl head file according to reference manual
Rev.1, 03/2019.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
|
|
This is an reset driver to implement a reset controller
device DISPMIX on IMX8MM and IMX8MN platforms. Dispmix
reset is used to reset or enable related buses and clks
for the submodules in DISPMIX.
All the dispmix resets are divided into three subgroups:
sft_rstn, clk_en and mipi_rst, and each of them contains
several reset lines to control several different modules
on and off in DISPMIX which doesn't require the standard
reset flow, but only line assert and deassert operations.
Signed-off-by: Fancy Fang <chen.fang@nxp.com>
|
|
It ported from below patch, and change for v4.14.
https://www.spinics.net/lists/linux-usb/msg177137.html
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
|
|
Instead of just raising irq0 for all the cores, we mask the irq0 for all the
non-target cores, this way waking up only the core we want. All of this
is done now in TF-A.
Also, since this new workaround doesn't need the IOMUX_GPR1 register here
in kernel, the IOMUX_GPR reg entry inside the gic dts node can be removed.
In order for this to work, the following commit is needed in TF-A:
0e91ff59720d0756 ("MLK-21399 plat: imx8mq: gpc: Workaround for ERR11171")
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
|
|
In order to support the new ASRC in i.MX815, we update the
user api file mxc_asrc.h.
The reason is that the new ASRC support more sample width, and
support endianness, sign, float format, iec958 format setting,
All these type can be expressed by snd_pcm_format_t type.
So we use the in(out)put_format to instead the in(out)put_word_width.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
|
|
This is a large change but realigns us with upstream is useful and make
git diff useful.
This was already done on imx8mq after that SOC was upstreamed.
Mixing dts and driver changes is intentional because changes only
compile together.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
(cherry picked from commit 29845d2ebf6708ef87213328a4ce0f29cef7722a)
|
|
Add i.MX8MN clock and pin definition.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
|
|
The added format is V4L2_PIX_FMT_YUV24, this is a packed
YUV 4:4:4 format, with 8 bits for each component, 24 bits
per sample.
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
Acked-by: Leonard Crestez <leonard.crestez@nxp.com>
|
|
elv_unregister_queue()"
This reverts commit 83d016ac86428dbca8a62d3e4fdc29e3ea39e535.
Reverting the patch will solve the issue introduced by MLK-18870 fix
The fix is adding the following patch on 4.14 bsp kernel
83d016ac86428("block: Unexport elv_register_queue()
and elv_unregister_queue()")
The upstream patch that remove the correlation with
export elv_register_queue() is not applied on IMX kernel BSP.
c100ec49fdd22("dm: fix incomplete request_queue initialization")
Having missing patch a compilation issue will be generated if DM is enabled
Decision not to cherry-pick the c100ec49fdd22("dm:fix incomplete
request_queue initialization") from upstream because the patch adds
new DM Crypt functionalities and to revoke the patch that remove the export.
Signed-off-by: Mircea Pop <mircea.pop@nxp.com>
|
|
DRBG is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.
The code now also passes CRYPTO_TFM_REQ_MAY_SLEEP flag indicating
crypto request memory allocation may use GFP_KERNEL which should
be perfectly fine as the code is obviously sleeping for the
completion of the request any way.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 85a2dea4bdbfa7565818ca094d08e838cf62da77)
|
|
algif starts several async crypto ops and waits for their completion.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 2c3f8b162106a7d12097d02eb22459f57fab8247)
|
|
Invoking a possibly async. crypto op and waiting for completion
while correctly handling backlog processing is a common task
in the crypto API implementation and outside users of it.
This patch adds a generic implementation for doing so in
preparation for using it across the board instead of hand
rolled versions.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
CC: Eric Biggers <ebiggers3@gmail.com>
CC: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit ada69a1639eca54ff74d839a6513c43db8d57d70)
|
|
Tcon mode
As suggested by the design team, there is rigorous timing requirement
to address TKT320590, that is, we need to turn Tcon(s) from bypass mode
into operation mode as soon as the first dumb frame is generated by DPU.
When dual stream is used, we should look at the first dumb frame generated
by the master FrameGen. If we cannot ensure the timing requirement, say
the Tcon mode switching takes place after the second frame is generated
by DPU, the hardware could run into malfunction sometimes. Based on
stress tests, the content shadow load done event for the first time we call
->atomic_flush() may not come after the CRTC enablement in the single
stream case and it looks like display data is not generated to the
down-stream encoder(hence, black screen). This patch tunes enablement
sequence to correctly switch Tcon mode, according to the design team's
suggestions. During the switching, we don't relinquish CPU to ensure the
sequence is straightforward to meet the timing requirement. As we cannot
sleep during the switching, we take the pixel link enablement/disablement
operations(wrapped by a mutex in RPC call) out of framegen_enable/disable()
functions and put them at appropriate place. This introduces additional
sequence modifications but should be safe.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit ec323921dc2173128f071d0238e6439f5536aca1)
|
|
add the prepare/unprepare functions in hbmc ops
Signed-off-by: Han Xu <han.xu@nxp.com>
|
|
Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate
Bus interface between a host system master and one or more slave
interfaces. HyperBus is used to connect microprocessor, microcontroller,
or ASIC devices with random access NOR flash memory (called HyperFlash)
or self refresh DRAM (called HyperRAM).
Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS)
signal and either Single-ended clock(3.0V parts) or Differential clock
(1.8V parts). It uses ChipSelect lines to select b/w multiple slaves.
At bus level, it follows a separate protocol described in HyperBus
specification[1].
HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar
to that of existing parallel NORs. Since HyperBus is x8 DDR bus,
its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But
HyperBus operates at >166MHz frequencies.
HyperRAM provides direct random read/write access to flash memory
array.
But, HyperBus memory controllers seem to abstract implementation details
and expose a simple MMIO interface to access connected flash.
Add support for registering HyperFlash devices with MTD framework. MTD
maps framework along with CFI chip support framework are used to support
communicating with flash.
Framework is modelled along the lines of spi-nor framework. HyperBus
memory controller (HBMC) drivers calls hyperbus_register_device() to
register a single HyperFlash device. HyperFlash core parses MMIO access
information from DT, sets up the map_info struct, probes CFI flash and
registers it with MTD framework.
Some HBMC masters need calibration/training sequence[3] to be carried
out, in order for DLL inside the controller to lock, by reading a known
string/pattern. This is done by repeatedly reading CFI Query
Identification String. Calibration needs to be done before trying to detect
flash as part of CFI flash probe.
HyperRAM is not supported at the moment.
HyperBus specification can be found at[1]
HyperFlash datasheet can be found at[2]
[1] https://www.cypress.com/file/213356/download
[2] https://www.cypress.com/file/213346/download
[3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf
Table 12-5741. HyperFlash Access Sequence
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c
can be used as is. But these devices do not support DQ polling method of
determining chip ready/good status. These flashes provide Status
Register whose bits can be polled to know status of flash operation.
Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu
Extended Query version 1.5. Bit 0 of "Software Features supported" field
of CFI Primary Vendor-Specific Extended Query table indicates
presence/absence of status register and Bit 1 indicates whether or not
DQ polling is supported. Using these bits, its possible to determine
whether flash supports DQ polling or need to use Status Register.
Add support for polling Status Register to know device ready/status of
erase/write operations when DQ polling is not supported.
Print error messages on erase/program failure by looking at related
Status Register bits.
[1] https://www.cypress.com/file/213346/download
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|