Re: [PATCH net-next 4/6] net: qualcomm: rmnet: use field masks instead of C bit-fields
On Thu 04 Mar 16:34 CST 2021, Alex Elder wrote:
> The actual layout of bits defined in C bit-fields (e.g. int foo : 3)
> is implementation-defined. Structures defined in
> address this by specifying all bit-fields twice, to cover two
> possible layouts.
>
> I think this pattern is repetitive and noisy, and I find the whole
> notion of compiler "bitfield endianness" to be non-intuitive.
>
> Stop using C bit-fields for the command/data flag and the pad length
> fields in the rmnet_map structure. Instead, define a single-byte
> flags field, and use the functions defined in ,
> along with field mask constants to extract or assign values within
> that field.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Alex Elder
> ---
> .../ethernet/qualcomm/rmnet/rmnet_handlers.c | 5 ++--
> .../ethernet/qualcomm/rmnet/rmnet_map_data.c | 4 +++-
> include/linux/if_rmnet.h | 23 ---
> 3 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> index 2a6b2a609884c..30f8e2f02696b 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> @@ -4,6 +4,7 @@
> * RMNET Data ingress/egress handler
> */
>
> +#include
> #include
> #include
> #include
> @@ -61,7 +62,7 @@ __rmnet_map_ingress_handler(struct sk_buff *skb,
> u16 len, pad;
> u8 mux_id;
>
> - if (map_header->cd_bit) {
> + if (u8_get_bits(map_header->flags, MAP_CMD_FMASK)) {
> /* Packet contains a MAP command (not data) */
> if (port->data_format & RMNET_FLAGS_INGRESS_MAP_COMMANDS)
> return rmnet_map_command(skb, port);
> @@ -70,7 +71,7 @@ __rmnet_map_ingress_handler(struct sk_buff *skb,
> }
>
> mux_id = map_header->mux_id;
> - pad = map_header->pad_len;
> + pad = u8_get_bits(map_header->flags, MAP_PAD_LEN_FMASK);
> len = ntohs(map_header->pkt_len) - pad;
>
> if (mux_id >= RMNET_MAX_LOGICAL_EP)
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> index fd55269c2ce3c..3291f252d81b0 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> @@ -4,6 +4,7 @@
> * RMNET Data MAP protocol
> */
>
> +#include
> #include
> #include
> #include
> @@ -299,7 +300,8 @@ struct rmnet_map_header *rmnet_map_add_map_header(struct
> sk_buff *skb,
>
> done:
> map_header->pkt_len = htons(map_datalen + padding);
> - map_header->pad_len = padding & 0x3F;
> + /* This is a data packet, so the CMD bit is 0 */
> + map_header->flags = u8_encode_bits(padding, MAP_PAD_LEN_FMASK);
>
> return map_header;
> }
> diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
> index 8c7845baf3837..4824c6328a82c 100644
> --- a/include/linux/if_rmnet.h
> +++ b/include/linux/if_rmnet.h
> @@ -6,21 +6,18 @@
> #define _LINUX_IF_RMNET_H_
>
> struct rmnet_map_header {
> -#if defined(__LITTLE_ENDIAN_BITFIELD)
> - u8 pad_len:6;
> - u8 reserved_bit:1;
> - u8 cd_bit:1;
> -#elif defined (__BIG_ENDIAN_BITFIELD)
> - u8 cd_bit:1;
> - u8 reserved_bit:1;
> - u8 pad_len:6;
> -#else
> -#error "Please fix "
> -#endif
> - u8 mux_id;
> - __be16 pkt_len;
> + u8 flags; /* MAP_*_FMASK */
> + u8 mux_id;
> + __be16 pkt_len; /* Length of packet, including pad */
> } __aligned(1);
>
> +/* rmnet_map_header flags field:
> + * CMD: 1 = packet contains a MAP command; 0 = packet contains data
> + * PAD_LEN: number of pad bytes following packet data
> + */
> +#define MAP_CMD_FMASKGENMASK(7, 7)
> +#define MAP_PAD_LEN_FMASKGENMASK(5, 0)
> +
> struct rmnet_map_dl_csum_trailer {
> u8 reserved1;
> #if defined(__LITTLE_ENDIAN_BITFIELD)
> --
> 2.20.1
>
Re: [PATCH net-next 3/6] net: qualcomm: rmnet: kill RMNET_MAP_GET_*() accessor macros
On Thu 04 Mar 16:34 CST 2021, Alex Elder wrote:
> The following macros, defined in "rmnet_map.h", assume a socket
> buffer is provided as an argument without any real indication this
> is the case.
> RMNET_MAP_GET_MUX_ID()
> RMNET_MAP_GET_CD_BIT()
> RMNET_MAP_GET_PAD()
> RMNET_MAP_GET_CMD_START()
> RMNET_MAP_GET_LENGTH()
> What they hide is pretty trivial accessing of fields in a structure,
> and it's much clearer to see this if we do these accesses directly.
>
> So rather than using these accessor macros, assign a local
> variable of the map header pointer type to the socket buffer data
> pointer, and derereference that pointer variable.
>
> In "rmnet_map_data.c", use sizeof(object) rather than sizeof(type)
> in one spot. Also,there's no need to byte swap 0; it's all zeros
> irrespective of endianness.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Alex Elder
> ---
> drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 10 ++
> drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h | 12
> .../net/ethernet/qualcomm/rmnet/rmnet_map_command.c | 11 ---
> drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 4 ++--
> 4 files changed, 16 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> index 3d00b32323084..2a6b2a609884c 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> @@ -56,20 +56,22 @@ static void
> __rmnet_map_ingress_handler(struct sk_buff *skb,
> struct rmnet_port *port)
> {
> + struct rmnet_map_header *map_header = (void *)skb->data;
> struct rmnet_endpoint *ep;
> u16 len, pad;
> u8 mux_id;
>
> - if (RMNET_MAP_GET_CD_BIT(skb)) {
> + if (map_header->cd_bit) {
> + /* Packet contains a MAP command (not data) */
> if (port->data_format & RMNET_FLAGS_INGRESS_MAP_COMMANDS)
> return rmnet_map_command(skb, port);
>
> goto free_skb;
> }
>
> - mux_id = RMNET_MAP_GET_MUX_ID(skb);
> - pad = RMNET_MAP_GET_PAD(skb);
> - len = RMNET_MAP_GET_LENGTH(skb) - pad;
> + mux_id = map_header->mux_id;
> + pad = map_header->pad_len;
> + len = ntohs(map_header->pkt_len) - pad;
>
> if (mux_id >= RMNET_MAX_LOGICAL_EP)
> goto free_skb;
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
> index 576501db2a0bc..2aea153f42473 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
> @@ -32,18 +32,6 @@ enum rmnet_map_commands {
> RMNET_MAP_COMMAND_ENUM_LENGTH
> };
>
> -#define RMNET_MAP_GET_MUX_ID(Y) (((struct rmnet_map_header *) \
> - (Y)->data)->mux_id)
> -#define RMNET_MAP_GET_CD_BIT(Y) (((struct rmnet_map_header *) \
> - (Y)->data)->cd_bit)
> -#define RMNET_MAP_GET_PAD(Y) (((struct rmnet_map_header *) \
> - (Y)->data)->pad_len)
> -#define RMNET_MAP_GET_CMD_START(Y) ((struct rmnet_map_control_command *) \
> - ((Y)->data + \
> - sizeof(struct rmnet_map_header)))
> -#define RMNET_MAP_GET_LENGTH(Y) (ntohs(((struct rmnet_map_header *) \
> - (Y)->data)->pkt_len))
> -
> #define RMNET_MAP_COMMAND_REQUEST 0
> #define RMNET_MAP_COMMAND_ACK 1
> #define RMNET_MAP_COMMAND_UNSUPPORTED 2
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
> index beaee49621287..add0f5ade2e61 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
> @@ -12,12 +12,13 @@ static u8 rmnet_map_do_flow_control(struct sk_buff *skb,
> struct rmnet_port *port,
> int enable)
> {
> + struct rmnet_map_header *map_header = (void *)skb->data;
> struct rmnet_endpoint *ep;
> struct net_device *vnd;
> u8 mux_id;
> int r;
>
> - mux_id = RMNET_MAP_GET_MUX_ID(skb);
> + mux_id = map_header->mux_id;
>
> if (mux_id >= RMNET_MAX_LOGICAL_EP) {
> kfree_skb(skb);
> @@ -49,6 +50,7 @@ static void rmnet_map_send_ack(struct sk_buff *skb,
>
Re: [PATCH net-next 2/6] net: qualcomm: rmnet: simplify some byte order logic
On Thu 04 Mar 16:34 CST 2021, Alex Elder wrote:
> In rmnet_map_ipv4_ul_csum_header() and rmnet_map_ipv6_ul_csum_header()
> the offset within a packet at which checksumming should commence is
> calculated. This calculation involves byte swapping and a forced type
> conversion that makes it hard to understand.
>
> Simplify this by computing the offset in host byte order, then
> converting the result when assigning it into the header field.
>
> Signed-off-by: Alex Elder
> ---
> .../ethernet/qualcomm/rmnet/rmnet_map_data.c | 22 ++-
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> index 21d38167f9618..bd1aa11c9ce59 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> @@ -197,12 +197,13 @@ rmnet_map_ipv4_ul_csum_header(void *iphdr,
> struct rmnet_map_ul_csum_header *ul_header,
> struct sk_buff *skb)
> {
> - struct iphdr *ip4h = (struct iphdr *)iphdr;
> - __be16 *hdr = (__be16 *)ul_header, offset;
> + __be16 *hdr = (__be16 *)ul_header;
> + struct iphdr *ip4h = iphdr;
> + u16 offset;
> +
> + offset = skb_transport_header(skb) - (unsigned char *)iphdr;
> + ul_header->csum_start_offset = htons(offset);
>
> - offset = htons((__force u16)(skb_transport_header(skb) -
Just curious, why does this require a __force, or even a cast?
Regardless, your proposed way of writing it is easier to read.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> - (unsigned char *)iphdr));
> - ul_header->csum_start_offset = offset;
> ul_header->csum_insert_offset = skb->csum_offset;
> ul_header->csum_enabled = 1;
> if (ip4h->protocol == IPPROTO_UDP)
> @@ -239,12 +240,13 @@ rmnet_map_ipv6_ul_csum_header(void *ip6hdr,
> struct rmnet_map_ul_csum_header *ul_header,
> struct sk_buff *skb)
> {
> - struct ipv6hdr *ip6h = (struct ipv6hdr *)ip6hdr;
> - __be16 *hdr = (__be16 *)ul_header, offset;
> + __be16 *hdr = (__be16 *)ul_header;
> + struct ipv6hdr *ip6h = ip6hdr;
> + u16 offset;
> +
> + offset = skb_transport_header(skb) - (unsigned char *)ip6hdr;
> + ul_header->csum_start_offset = htons(offset);
>
> - offset = htons((__force u16)(skb_transport_header(skb) -
> - (unsigned char *)ip6hdr));
> - ul_header->csum_start_offset = offset;
> ul_header->csum_insert_offset = skb->csum_offset;
> ul_header->csum_enabled = 1;
>
> --
> 2.20.1
>
Re: [PATCH net-next 1/6] net: qualcomm: rmnet: mark trailer field endianness
On Thu 04 Mar 16:34 CST 2021, Alex Elder wrote:
> The fields in the checksum trailer structure used for QMAP protocol
> RX packets are all big-endian format, so define them that way.
>
> It turns out these fields are never actually used by the RMNet code.
> The start offset is always assumed to be zero, and the length is
> taken from the other packet headers. So making these fields
> explicitly big endian has no effect on the behavior of the code.
>
> Signed-off-by: Alex Elder
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> include/linux/if_rmnet.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
> index 9661416a9bb47..8c7845baf3837 100644
> --- a/include/linux/if_rmnet.h
> +++ b/include/linux/if_rmnet.h
> @@ -32,8 +32,8 @@ struct rmnet_map_dl_csum_trailer {
> #else
> #error "Please fix "
> #endif
> - u16 csum_start_offset;
> - u16 csum_length;
> + __be16 csum_start_offset;
> + __be16 csum_length;
> __be16 csum_value;
> } __aligned(1);
>
> --
> 2.20.1
>
Re: [PATCH] pinctrl: qcom: lpass lpi: use default pullup/strength values
On Thu 04 Mar 13:48 CST 2021, Jonathan Marek wrote:
> If these fields are not set in dts, the driver will use these variables
> uninitialized to set the fields. Not only will it set garbage values for
> these fields, but it can overflow into other fields and break those.
>
> In the current sm8250 dts, the dmic01 entries do not have a pullup setting,
> and might not work without this change.
>
Perhaps you didn't see it, but Dan reported this a few days back. So
unless you object I would suggest that we include:
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver")
> Signed-off-by: Jonathan Marek
> ---
> drivers/pinctrl/qcom/pinctrl-lpass-lpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-lpass-lpi.c
> b/drivers/pinctrl/qcom/pinctrl-lpass-lpi.c
> index 369ee20a7ea95..2f19ab4db7208 100644
> --- a/drivers/pinctrl/qcom/pinctrl-lpass-lpi.c
> +++ b/drivers/pinctrl/qcom/pinctrl-lpass-lpi.c
> @@ -392,7 +392,7 @@ static int lpi_config_set(struct pinctrl_dev *pctldev,
> unsigned int group,
> unsigned long *configs, unsigned int nconfs)
> {
> struct lpi_pinctrl *pctrl = dev_get_drvdata(pctldev->dev);
> - unsigned int param, arg, pullup, strength;
> + unsigned int param, arg, pullup = LPI_GPIO_BIAS_DISABLE, strength = 2;
> bool value, output_enabled = false;
> const struct lpi_pingroup *g;
> unsigned long sval;
> --
> 2.26.1
>
Re: [PATCH] remoteproc: sysfs: Use scnprintf instead of sprintf
On Wed 03 Mar 14:01 CST 2021, Siddharth Gupta wrote:
> From: Raghavendra Rao Ananta
>
> For security reasons scnprintf() is preferred over sprintf().
> Hence, convert the remoteproc's sysfs show functions accordingly.
>
Thanks for the patch Siddharth.
There's no possibility for these calls to generate more than PAGE_SIZE
amount of data, so this isn't really necessary. But if you insist,
please let's use sysfs_emit() instead.
Regards,
Bjorn
> Signed-off-by: Raghavendra Rao Ananta
> Signed-off-by: Siddharth Gupta
> ---
> drivers/remoteproc/remoteproc_sysfs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c
> b/drivers/remoteproc/remoteproc_sysfs.c
> index 1dbef89..853f569 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -15,7 +15,8 @@ static ssize_t recovery_show(struct device *dev,
> {
> struct rproc *rproc = to_rproc(dev);
>
> - return sprintf(buf, "%s", rproc->recovery_disabled ? "disabled\n" :
> "enabled\n");
> + return scnprintf(buf, PAGE_SIZE, "%s",
> + rproc->recovery_disabled ? "disabled\n" : "enabled\n");
> }
>
> /*
> @@ -82,7 +83,7 @@ static ssize_t coredump_show(struct device *dev,
> {
> struct rproc *rproc = to_rproc(dev);
>
> - return sprintf(buf, "%s\n", rproc_coredump_str[rproc->dump_conf]);
> + return scnprintf(buf, PAGE_SIZE, "%s\n",
> rproc_coredump_str[rproc->dump_conf]);
> }
>
> /*
> --
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
[PATCH] usb: dwc3: Flip condition guarding power_supply_put()
The condition guarding the power_supply_put() calls in error and
removal paths are backwards, resulting in a guaranteed NULL pointer
dereference if no power supply was acquired.
Fixes: 59fa3def35de ("usb: dwc3: add a power supply for current control")
Signed-off-by: Bjorn Andersson
---
drivers/usb/dwc3/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d15f065849cd..94fdbe502ce9 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1628,7 +1628,7 @@ static int dwc3_probe(struct platform_device *pdev)
assert_reset:
reset_control_assert(dwc->reset);
- if (!dwc->usb_psy)
+ if (dwc->usb_psy)
power_supply_put(dwc->usb_psy);
return ret;
@@ -1653,7 +1653,7 @@ static int dwc3_remove(struct platform_device *pdev)
dwc3_free_event_buffers(dwc);
dwc3_free_scratch_buffers(dwc);
- if (!dwc->usb_psy)
+ if (dwc->usb_psy)
power_supply_put(dwc->usb_psy);
return 0;
--
2.29.2
Re: drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:458 lpi_config_set() error: uninitialized symbol 'strength'.
On Tue 02 Mar 09:47 CST 2021, Linus Walleij wrote: > On Sat, Feb 27, 2021 at 10:22 AM Dan Carpenter > wrote: > > > New smatch warnings: > > drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:458 lpi_config_set() error: > > uninitialized symbol 'strength'. > > > > Old smatch warnings: > > drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:457 lpi_config_set() error: > > uninitialized symbol 'pullup'. > > I don't think these are real problems, but maybe there is some way to > explicitly > express that so that smatch knows as well? > Perhaps I'm reading it wrong, but wouldn't a state that doesn't specify drive-strength or bias cause these properties to be written out as some undefined/uninitialized value? (I.e. isn't the report correct?) Regards, Bjorn
Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier
On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote: > On Fri, Feb 26, 2021 at 9:24 AM Bjorn Andersson > wrote: > > > > On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote: > > > > > Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU > > > both implement "arm,mmu-500" in some QTI SoCs and to run through > > > adreno smmu specific implementation such as enabling split pagetables > > > support, we need to match the "qcom,adreno-smmu" compatible first > > > before apss smmu or else we will be running apps smmu implementation > > > for adreno smmu and the additional features for adreno smmu is never > > > set. For ex: we have "qcom,sc7280-smmu-500" compatible for both apps > > > and adreno smmu implementing "arm,mmu-500", so the adreno smmu > > > implementation is never reached because the current sequence checks > > > for apps smmu compatible(qcom,sc7280-smmu-500) first and runs that > > > specific impl and we never reach adreno smmu specific implementation. > > > > > > > So you're saying that you have a single SMMU instance that's compatible > > with both an entry in qcom_smmu_impl_of_match[] and "qcom,adreno-smmu"? > > > > Per your proposed change we will pick the adreno ops _only_ for this > > component, essentially disabling the non-Adreno quirks selected by the > > qcom impl. As such keeping the non-adreno compatible in the > > qcom_smmu_impl_init[] seems to only serve to obfuscate the situation. > > > > Don't we somehow need the combined set of quirks? (At least if we're > > running this with a standard UEFI based boot flow?) > > > > are you thinking of the apps-smmu handover of display context bank? > That shouldn't change, the only thing that changes is that gpu-smmu > becomes an mmu-500, whereas previously only apps-smmu was.. > The current logic picks one of: 1) is the compatible mentioned in qcom_smmu_impl_of_match[] 2) is the compatible an adreno 3) no quirks needed The change flips the order of these, so the only way I can see this change affecting things is if we expected a match on #2, but we got one on #1. Which implies that the instance that we want to act according to the adreno impl was listed in qcom_smmu_impl_of_match[] - which either is wrong, or there's a single instance that needs both behaviors. (And I believe Jordan's answer confirms the latter - there's a single SMMU instance that needs all them quirks at once) Regards, Bjorn
Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier
On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:
> Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> both implement "arm,mmu-500" in some QTI SoCs and to run through
> adreno smmu specific implementation such as enabling split pagetables
> support, we need to match the "qcom,adreno-smmu" compatible first
> before apss smmu or else we will be running apps smmu implementation
> for adreno smmu and the additional features for adreno smmu is never
> set. For ex: we have "qcom,sc7280-smmu-500" compatible for both apps
> and adreno smmu implementing "arm,mmu-500", so the adreno smmu
> implementation is never reached because the current sequence checks
> for apps smmu compatible(qcom,sc7280-smmu-500) first and runs that
> specific impl and we never reach adreno smmu specific implementation.
>
So you're saying that you have a single SMMU instance that's compatible
with both an entry in qcom_smmu_impl_of_match[] and "qcom,adreno-smmu"?
Per your proposed change we will pick the adreno ops _only_ for this
component, essentially disabling the non-Adreno quirks selected by the
qcom impl. As such keeping the non-adreno compatible in the
qcom_smmu_impl_init[] seems to only serve to obfuscate the situation.
Don't we somehow need the combined set of quirks? (At least if we're
running this with a standard UEFI based boot flow?)
Regards,
Bjorn
> Suggested-by: Akhil P Oommen
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index bea3ee0dabc2..03f048aebb80 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -345,11 +345,17 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct
> arm_smmu_device *smmu)
> {
> const struct device_node *np = smmu->dev->of_node;
>
> - if (of_match_node(qcom_smmu_impl_of_match, np))
> - return qcom_smmu_create(smmu, _smmu_impl);
> -
> + /*
> + * Do not change this order of implementation, i.e., first adreno
> + * smmu impl and then apss smmu since we can have both implementing
> + * arm,mmu-500 in which case we will miss setting adreno smmu specific
> + * features if the order is changed.
> + */
> if (of_device_is_compatible(np, "qcom,adreno-smmu"))
> return qcom_smmu_create(smmu, _adreno_smmu_impl);
>
> + if (of_match_node(qcom_smmu_impl_of_match, np))
> + return qcom_smmu_create(smmu, _smmu_impl);
> +
> return smmu;
> }
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
[GIT PULL] rpmsg updates for v5.12
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git tags/rpmsg-v5.12 for you to fetch changes up to 3e35772bc1e42287c8f4c70055deb5e3f5a3e8b5: rpmsg: glink: add include of header file (2021-01-05 22:22:40 -0600) rpmsg updates for v5.12 This fixes two build issues in the GLINK driver and corrects some kerneldoc in the same. Alex Elder (2): rpmsg: glink: fix some kerneldoc comments rpmsg: glink: add include of header file Bjorn Andersson (1): rpmsg: glink: Guard qcom_glink_ssr_notify() with correct config drivers/rpmsg/qcom_glink_ssr.c | 17 + include/linux/rpmsg/qcom_glink.h | 8 ++-- 2 files changed, 15 insertions(+), 10 deletions(-)
[GIT PULL] remoteproc updates for v5.12
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git tags/rproc-v5.12 for you to fetch changes up to e8b4e9a21af77b65ea68bd698acf4abe04afd051: remoteproc: qcom: pas: Add SM8350 PAS remoteprocs (2021-02-11 12:52:18 -0600) remoteproc updates for v5.12 This adds remoteproc support for the audio, compute, sensor and modem remoteprocs on the Qualcomm SM8350 platform, it adds Qualcomm WCN3660b support, Mediatek MT8192 SCP driver support for MPU and L1TCM memory, STM32 driver adopts dev_err_probe() and the Qualcomm Kconfig help texts are revamped. Arnaud Pouliquen (1): remoteproc: stm32: improve debug using dev_err_probe Arnd Bergmann (1): remoteproc: qcom: fix glink dependencies Daniele Alessandrelli (1): remoteproc: core: Fix rproc->firmware free in rproc_set_firmware() Paul Cercueil (1): remoteproc: ingenic: Add module parameter 'auto_boot' Shawn Guo (1): remoteproc: qcom: add more help text qcom options Stephan Gerhold (2): dt-bindings: remoteproc: qcom,wcnss: Add qcom,wcn3660b compatible remoteproc: qcom_wcnss: Add qcom,wcn3660b compatible Tzung-Bi Shih (5): remoteproc/mediatek: acknowledge watchdog IRQ after handled remoteproc/mediatek: use devm_platform_ioremap_resource_byname remoteproc/mediatek: enable MPU for all memory regions in MT8192 SCP dt-bindings: remoteproc: mediatek: add L1TCM memory region remoteproc/mediatek: support L1TCM Vinod Koul (2): dt-bindings: remoteproc: qcom: pas: Add SM8350 remoteprocs remoteproc: qcom: pas: Add SM8350 PAS remoteprocs Yang Li (1): remoteproc: qcom_wcnss: remove unneeded semicolon .../devicetree/bindings/remoteproc/mtk,scp.txt | 8 +-- .../devicetree/bindings/remoteproc/qcom,adsp.txt | 12 .../bindings/remoteproc/qcom,wcnss-pil.txt | 1 + drivers/remoteproc/Kconfig | 25 +-- drivers/remoteproc/ingenic_rproc.c | 7 ++ drivers/remoteproc/mtk_common.h| 7 ++ drivers/remoteproc/mtk_scp.c | 82 ++ drivers/remoteproc/qcom_q6v5_pas.c | 63 + drivers/remoteproc/qcom_wcnss.c| 2 +- drivers/remoteproc/qcom_wcnss_iris.c | 1 + drivers/remoteproc/remoteproc_core.c | 2 +- drivers/remoteproc/stm32_rproc.c | 23 +++--- 12 files changed, 198 insertions(+), 35 deletions(-)
[GIT PULL] hwspinlock updated for v5.12
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git tags/hwlock-v5.12 for you to fetch changes up to b9ddb2500e7e544410f38476ab928fc2fe01e381: hwspinlock: omap: Add support for K3 AM64x SoCs (2021-02-09 11:36:50 -0600) hwspinlock updated for v5.12 This adds support for the hardware spinlock in the TI K3 AM64x SoC. Suman Anna (2): dt-bindings: hwlock: Update OMAP HwSpinlock binding for AM64x SoCs hwspinlock: omap: Add support for K3 AM64x SoCs Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml | 1 + drivers/hwspinlock/omap_hwspinlock.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-)
Re: [PATCH] pinctrl: qcom: sc7280: Add GPIO wakeup interrupt map
On Thu 11 Feb 22:59 CST 2021, Rajendra Nayak wrote:
> From: Maulik Shah
>
> GPIOs that can be configured as wakeup sources, have their
> interrupt lines routed to PDC interrupt controller.
>
> Provide the interrupt map of the GPIO to its wakeup capable
> interrupt parent.
>
Acked-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Maulik Shah
> Signed-off-by: Rajendra Nayak
> ---
> drivers/pinctrl/qcom/pinctrl-sc7280.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-sc7280.c
> b/drivers/pinctrl/qcom/pinctrl-sc7280.c
> index 8daccd5..99c416e 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sc7280.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sc7280.c
> @@ -1449,6 +1449,28 @@ static const struct msm_pingroup sc7280_groups[] = {
> [182] = SDC_QDSD_PINGROUP(sdc2_data, 0x1b4000, 9, 0),
> };
>
> +static const struct msm_gpio_wakeirq_map sc7280_pdc_map[] = {
> + { 0, 134 }, { 3, 131 }, { 4, 121 }, { 7, 103 }, { 8, 155 },
> + { 11, 93 }, { 12, 78 }, { 15, 79 }, { 16, 80 }, { 18, 81 },
> + { 19, 107 }, { 20, 82 }, { 21, 83 }, { 23, 99 }, { 24, 86 },
> + { 25, 95 }, { 27, 158 }, { 28, 159 }, { 31, 90 }, { 32, 144 },
> + { 34, 77 }, { 35, 92 }, { 36, 157 }, { 39, 73 }, { 40, 97 },
> + { 41, 98 }, { 43, 85 }, { 44, 100 }, { 45, 101 }, { 47, 102 },
> + { 48, 74 }, { 51, 112 }, { 52, 156 }, { 54, 117 }, { 55, 84 },
> + { 56, 108 }, { 59, 110 }, { 60, 111 }, { 61, 123 }, { 63, 104 },
> + { 68, 127 }, { 72, 150 }, { 75, 133 }, { 77, 125 }, { 78, 105 },
> + { 79, 106 }, { 80, 118 }, { 81, 119 }, { 82, 162 }, { 83, 122 },
> + { 86, 75 }, { 88, 154 }, { 89, 124 }, { 90, 149 }, { 91, 76 },
> + { 93, 128 }, { 95, 160 }, { 101, 126 }, { 102, 96 }, { 103, 116 },
> + { 104, 114 }, { 112, 72 }, { 116, 135 }, { 117, 163 }, { 119, 137 },
> + { 121, 138 }, { 123, 139 }, { 125, 140 }, { 127, 141 }, { 128, 165 },
> + { 129, 143 }, { 130, 94 }, { 131, 145 }, { 133, 146 }, { 136, 147 },
> + { 140, 148 }, { 141, 115 }, { 142, 113 }, { 145, 130 }, { 148, 132 },
> + { 150, 87 }, { 151, 88 }, { 153, 89 }, { 155, 164 }, { 156, 129 },
> + { 157, 161 }, { 158, 120 }, { 161, 136 }, { 163, 142 }, { 172, 166 },
> + { 174, 167 },
> +};
> +
> static const struct msm_pinctrl_soc_data sc7280_pinctrl = {
> .pins = sc7280_pins,
> .npins = ARRAY_SIZE(sc7280_pins),
> @@ -1457,6 +1479,8 @@ static const struct msm_pinctrl_soc_data sc7280_pinctrl
> = {
> .groups = sc7280_groups,
> .ngroups = ARRAY_SIZE(sc7280_groups),
> .ngpios = 176,
> + .wakeirq_map = sc7280_pdc_map,
> + .nwakeirq_map = ARRAY_SIZE(sc7280_pdc_map),
> };
>
> static int sc7280_pinctrl_probe(struct platform_device *pdev)
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re: [PATCH v2 2/2] drm/msm/dp: add supported max link rate specified from dtsi
On Thu 18 Feb 14:55 CST 2021, Kuogee Hsieh wrote:
> Allow supported link rate to be limited to the value specified at
> dtsi. If it is not specified, then link rate is derived from dpcd
> directly. Below are examples,
> link-rate = <162000> for max link rate limited at 1.62G
> link-rate = <27> for max link rate limited at 2.7G
> link-rate = <54> for max link rate limited at 5.4G
> link-rate = <81> for max link rate limited at 8.1G
>
> Changes in V2:
> -- allow supported max link rate specified from dtsi
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 1 +
> drivers/gpu/drm/msm/dp/dp_panel.c | 7 ---
> drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
> drivers/gpu/drm/msm/dp/dp_parser.c | 13 +
> drivers/gpu/drm/msm/dp/dp_parser.h | 1 +
> 5 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 5a39da6..f633ba6 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -322,6 +322,7 @@ static int dp_display_process_hpd_high(struct
> dp_display_private *dp)
> struct edid *edid;
>
> dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
> + dp->panel->max_link_rate = dp->parser->max_link_rate;
>
> rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
> if (rc)
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
> b/drivers/gpu/drm/msm/dp/dp_panel.c
> index 9cc8166..be7f102 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -76,9 +76,10 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
> if (link_info->num_lanes > dp_panel->max_dp_lanes)
> link_info->num_lanes = dp_panel->max_dp_lanes;
>
> - /* Limit support upto HBR2 until HBR3 support is added */
> - if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
> - link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
> + /* Limit support of ink rate if specified */
> + if (dp_panel->max_link_rate &&
Make the parser always initialize max_link_rate to something reasonable
and just compare against that here.
> + (link_info->rate > dp_panel->max_link_rate))
No need for the (), nor for line breaking this.
> + link_info->rate = dp_panel->max_link_rate;
>
> DRM_DEBUG_DP("version: %d.%d\n", major, minor);
> DRM_DEBUG_DP("link_rate=%d\n", link_info->rate);
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
> b/drivers/gpu/drm/msm/dp/dp_panel.h
> index 9023e5b..1876f5e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.h
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.h
> @@ -51,6 +51,7 @@ struct dp_panel {
> u32 vic;
> u32 max_pclk_khz;
> u32 max_dp_lanes;
> + u32 max_link_rate;
>
> u32 max_bw_code;
> };
> diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
> b/drivers/gpu/drm/msm/dp/dp_parser.c
> index 0519dd3..d8b6898 100644
> --- a/drivers/gpu/drm/msm/dp/dp_parser.c
> +++ b/drivers/gpu/drm/msm/dp/dp_parser.c
> @@ -87,6 +87,8 @@ static int dp_parser_misc(struct dp_parser *parser)
> struct device_node *of_node = parser->pdev->dev.of_node;
> int len = 0;
> const char *data_lane_property = "data-lanes";
> + const char *link_rate_property = "link-rate";
There's no reason for stashing these in local variables.
> + u32 rate = 0;
>
> len = of_property_count_elems_of_size(of_node,
>data_lane_property, sizeof(u32));
> @@ -97,6 +99,17 @@ static int dp_parser_misc(struct dp_parser *parser)
> }
>
> parser->max_dp_lanes = len;
> +
> + len = of_property_count_elems_of_size(of_node,
> + link_rate_property, sizeof(u32));
I'm afraid I don't see the reason for this, simply rely on the return
value of of_property_read_u32(), i.e.
ret = of_property_read_u32(node, "link-rate", );
if (!ret)
parser->max_link_rate = rate;
Or if you want to give it some default value:
rate = 1234;
of_property_read_u32(node, "link-rate", );
Which either will overwrite the rate with the value of the property, or
leave it untouched.
Regards,
Bjorn
> +
> + if (len == 1) {
> + of_property_read_u32_index(of_node,
> + link_rate_property, 0, );
> +
> + parser->max_link_rate = rate;
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
> b/drivers/gpu/drm/msm/dp/dp_parser.h
> index 34b4962..7046fce 100644
> --- a/drivers/gpu/drm/msm/dp/dp_parser.h
> +++ b/drivers/gpu/drm/msm/dp/dp_parser.h
> @@ -116,6 +116,7 @@ struct dp_parser {
> struct dp_display_data disp_data;
> const struct dp_regulator_cfg *regulator_cfg;
> u32 max_dp_lanes;
> + u32 max_link_rate;
>
> int (*parse)(struct dp_parser *parser);
> };
> --
Re: [PATCH] dt-bindings: cpufreq: cpufreq-qcom-hw: Document SM8350 CPUfreq compatible
On Tue 16 Feb 05:12 CST 2021, Vinod Koul wrote: > Add the CPUfreq compatible for SM8350 SoC along with note for using the > specific compatible for SoCs > > Signed-off-by: Vinod Koul > --- > Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > index 9299028ee712..3eb3cee59d79 100644 > --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > @@ -8,7 +8,9 @@ Properties: > - compatible > Usage: required > Value type: > - Definition: must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss". > + Definition: must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss" > + along with SoC specific compatible: > + "qcom,sm8350-cpufreq-epss", "qcom,cpufreq-epss" Can you please extend this to add all the platforms that we currently support? PS. Didn't we have someone working on converting this to yaml? Regards, Bjorn > > - clocks > Usage: required > -- > 2.26.2 >
Re: [PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Fri 12 Feb 11:33 CST 2021, Serge Semin wrote: > On Wed, Feb 10, 2021 at 10:33:26PM +0300, Serge Semin wrote: > > On Wed, Feb 10, 2021 at 12:56:59PM -0600, Bjorn Andersson wrote: > > > On Wed 10 Feb 12:40 CST 2021, Serge Semin wrote: > > > > > > > On Wed, Feb 10, 2021 at 12:17:27PM -0600, Rob Herring wrote: > > > > > On Wed, Feb 10, 2021 at 11:29 AM Serge Semin > > > > > wrote: > > > > > > > > > > > > In accordance with the USB HCD/DRD schema all the USB controllers > > > > > > are > > > > > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > > > > > existing DT-nodes will be renamed in a subsequent patch let's first > > > > > > make > > > > > > sure the DWC3 Qualcomm driver supports them and second falls back > > > > > > to the > > > > > > deprecated naming so not to fail on the legacy DTS-files passed to > > > > > > the > > > > > > newer kernels. > > > > > > > > > > > > Signed-off-by: Serge Semin > > > > > > Reviewed-by: Bjorn Andersson > > > > > > --- > > > > > > drivers/usb/dwc3/dwc3-qcom.c | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c > > > > > > b/drivers/usb/dwc3/dwc3-qcom.c > > > > > > index c703d552bbcf..49ad8d507d37 100644 > > > > > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > > > > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > > > > > @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct > > > > > > platform_device *pdev) > > > > > > struct device *dev = >dev; > > > > > > int ret; > > > > > > > > > > > > - dwc3_np = of_get_child_by_name(np, "dwc3"); > > > > > > + dwc3_np = of_get_child_by_name(np, "usb") ?: > > > > > > + of_get_child_by_name(np, "dwc3"); > > > > > > > > > > > > > > Is there some reason using compatible instead wouldn't work here? > > > > > > > > I don't know for sure. The fix has been requested in the framework of > > > > this discussion: > > > > https://lore.kernel.org/linux-usb/20201020115959.2658-30-sergey.se...@baikalelectronics.ru/#t > > > > by the driver maintainer Bjorn. To get a firm answer it's better to > > > > have him asked. > > > > > > My feedback was simply that it has to catch both cases, I didn't > > > consider the fact that we have a compatible to match against. > > > > > > > As I see it having of_get_compatible_child() utilized > > > > here would also work. At least for the available in kernel dt-files. > > > > See the affected dts-es in: > > > > https://lore.kernel.org/linux-usb/20210210172850.20849-11-sergey.se...@baikalelectronics.ru/ > > > > > > > > A problem may happen if some older versions of DTS-es had another > > > > compatible string in the dwc3 sub-node... > > > > > > > > > > Afaict all Qualcomm dts files has "snps,dwc3", so you can match against > > > that instead. > > > > Ok then. I'll replace of_get_child_by_name() here with > > of_get_compatible_child() matching just against "snps,dwc3" in v7. Can you > > confirm that noone ever had a Qcom-based hardware described with dts having > > the "synopsys,dwc3" compatible used as the DWC USB3 sub-node here? That > > string has been marked as deprecated recently because the vendor-prefix > > was changed sometime ago, but the original driver still accept it. > > > > Alternatively to be on a safe side we could match against both > > compatibles here as Rob suggests. What do you think? > > Bjorn, any comment on the question above? So I could respin the series > with this patch updated. > > Also note, since the patch's gonna be changed I'll have to remove your > Reviewed-by tag unless u explicitly say I shouldn't. > Sounds good, I'd be happy to review the new patch. PS. As this only affect the Qualcomm part of the series I would suggest that you send these patches off separate and don't send all 10 patches together. Thanks, Bjorn
Re: [PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Wed 10 Feb 13:33 CST 2021, Serge Semin wrote: > On Wed, Feb 10, 2021 at 12:56:59PM -0600, Bjorn Andersson wrote: > > On Wed 10 Feb 12:40 CST 2021, Serge Semin wrote: > > > > > On Wed, Feb 10, 2021 at 12:17:27PM -0600, Rob Herring wrote: > > > > On Wed, Feb 10, 2021 at 11:29 AM Serge Semin > > > > wrote: > > > > > > > > > > In accordance with the USB HCD/DRD schema all the USB controllers are > > > > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > > > > existing DT-nodes will be renamed in a subsequent patch let's first > > > > > make > > > > > sure the DWC3 Qualcomm driver supports them and second falls back to > > > > > the > > > > > deprecated naming so not to fail on the legacy DTS-files passed to the > > > > > newer kernels. > > > > > > > > > > Signed-off-by: Serge Semin > > > > > Reviewed-by: Bjorn Andersson > > > > > --- > > > > > drivers/usb/dwc3/dwc3-qcom.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c > > > > > b/drivers/usb/dwc3/dwc3-qcom.c > > > > > index c703d552bbcf..49ad8d507d37 100644 > > > > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > > > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > > > > @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct > > > > > platform_device *pdev) > > > > > struct device *dev = >dev; > > > > > int ret; > > > > > > > > > > - dwc3_np = of_get_child_by_name(np, "dwc3"); > > > > > + dwc3_np = of_get_child_by_name(np, "usb") ?: > > > > > + of_get_child_by_name(np, "dwc3"); > > > > > > > > > > > Is there some reason using compatible instead wouldn't work here? > > > > > > I don't know for sure. The fix has been requested in the framework of > > > this discussion: > > > https://lore.kernel.org/linux-usb/20201020115959.2658-30-sergey.se...@baikalelectronics.ru/#t > > > by the driver maintainer Bjorn. To get a firm answer it's better to > > > have him asked. > > > > My feedback was simply that it has to catch both cases, I didn't > > consider the fact that we have a compatible to match against. > > > > > As I see it having of_get_compatible_child() utilized > > > here would also work. At least for the available in kernel dt-files. > > > See the affected dts-es in: > > > https://lore.kernel.org/linux-usb/20210210172850.20849-11-sergey.se...@baikalelectronics.ru/ > > > > > > A problem may happen if some older versions of DTS-es had another > > > compatible string in the dwc3 sub-node... > > > > > > > Afaict all Qualcomm dts files has "snps,dwc3", so you can match against > > that instead. > > Ok then. I'll replace of_get_child_by_name() here with > of_get_compatible_child() matching just against "snps,dwc3" in v7. Can you > confirm that noone ever had a Qcom-based hardware described with dts having > the "synopsys,dwc3" compatible used as the DWC USB3 sub-node here? That > string has been marked as deprecated recently because the vendor-prefix > was changed sometime ago, but the original driver still accept it. > I don't see any Qualcomm users of "synopsys,dwc3", past or present. > Alternatively to be on a safe side we could match against both > compatibles here as Rob suggests. What do you think? > Let's go with only "snps,dwc3". Regards, Bjorn
Re: [PATCH 1/2] dt-bindings: remoteproc: qcom: pas: Add SM8350 remoteprocs
On Wed 10 Feb 04:45 CST 2021, Vinod Koul wrote: > Add the SM8350 audio, compute, modem and sensor remoteprocs to the PAS > DT binding. > > Signed-off-by: Vinod Koul > --- > .../devicetree/bindings/remoteproc/qcom,adsp.txt | 12 > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > index 54737024da20..41eaa2466aab 100644 > --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > @@ -25,6 +25,10 @@ on the Qualcomm ADSP Hexagon core. > "qcom,sm8250-adsp-pas" > "qcom,sm8250-cdsp-pas" > "qcom,sm8250-slpi-pas" > + "qcom,sm8350-adsp-pas" > + "qcom,sm8350-cdsp-pas" > + "qcom,sm8350-slpi-pas" > + "qcom,sm8350-mpss-pas" > > - interrupts-extended: > Usage: required > @@ -51,10 +55,14 @@ on the Qualcomm ADSP Hexagon core. > qcom,sm8250-adsp-pas: > qcom,sm8250-cdsp-pas: > qcom,sm8250-slpi-pas: > + qcom,sm8350-adsp-pas: > + qcom,sm8350-cdsp-pas: > + qcom,sm8350-slpi-pas: > must be "wdog", "fatal", "ready", "handover", "stop-ack" > qcom,qcs404-wcss-pas: > qcom,sc7180-mpss-pas: > qcom,sm8150-mpss-pas: > + qcom,sm8350-mpss-pas: > must be "wdog", "fatal", "ready", "handover", "stop-ack", > "shutdown-ack" > > @@ -113,14 +121,18 @@ on the Qualcomm ADSP Hexagon core. > qcom,sdm845-cdsp-pas: > qcom,sm8150-adsp-pas: > qcom,sm8150-cdsp-pas: > + qcom,sm8250-cdsp-pas: This should be sm8350, I fixed this up and applied the patch. Thanks, Bjorn > qcom,sm8250-cdsp-pas: > must be "cx", "load_state" > qcom,sc7180-mpss-pas: > qcom,sm8150-mpss-pas: > + qcom,sm8350-mpss-pas: > must be "cx", "load_state", "mss" > qcom,sm8250-adsp-pas: > + qcom,sm8350-adsp-pas: > qcom,sm8150-slpi-pas: > qcom,sm8250-slpi-pas: > + qcom,sm8350-slpi-pas: > must be "lcx", "lmx", "load_state" > > - memory-region: > -- > 2.26.2 >
Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
On Wed 10 Feb 12:41 CST 2021, Jakub Kicinski wrote: > On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote: > > On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote: > > > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > > > > This may be a stupid suggestion, but would the integration look less a > > > > backdoor if it would have been named "mhi_wwan" and it exposed already > > > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > > > > QMI? > > > > > > What's DIAG? Who's going to remember that this is a backdoor driver > > > a year from now when Qualcomm sends a one liner patches which just > > > adds a single ID to open another channel? > > > > I really appreciate your feedback on this driver eventhough I'm not > > inclined with you calling this driver a "backdoor interface". But can > > you please propose a solution on how to make this driver a good one as > > per your thoughts? > > > > I really don't know what bothers you even if the userspace tools making > > use of these chardevs are available openly (you can do the audit and see > > if anything wrong we are doing). > > What bothers me is maintaining shim drivers which just shuttle opaque > messages between user space and firmware. One of which definitely is, > and the other may well be, proprietary. This is an open source project, > users are supposed to be able to meaningfully change the behavior of > the system. > You're absolutely right in that we in general don't like shim drivers and there are several examples of proper MHI drivers - for e.g. networking, WiFi Technically we could fork/reimplement https://github.com/freedesktop/libqmi, https://github.com/andersson/diag and https://github.com/andersson/qdl in the kernel as "proper drivers" - each one exposing their own userspace ABI. But to leave these in userspace and rely on something that looks exactly like USBDEVFS seems like a much better strategy. > What bothers me is that we have 3 WWAN vendors all doing their own > thing and no common Linux API for WWAN. It may have been fine 10 years > ago, but WWAN is increasingly complex and important. > We had a deep discussion and a few prototypes for a WWAN framework going around 1-1.5 years ago. Unfortunately, what did fit Intel's view of what a WWAN device is didn't fit at all with what's run and exposed by the "modem" DSP in a Qualcomm platform. After trying to find various contrived ways to model this we gave up. > > And exposing the raw access to the > > hardware is not a new thing in kernel. There are several existing > > subsystems/drivers does this as pointed out by Bjorn. Moreover we don't > > have in-kernel APIs for the functionalities exposed by this driver and > > creating one is not feasible as explained by many. > > > > So please let us know the path forward on this series. We are open to > > any suggestions but you haven't provided one till now. > > Well. You sure know how to aggravate people. I said clearly that you > can move forward on purpose build drivers (e.g. for WWAN). There is no > way forward on this common shim driver as far as I'm concerned. But what is a WWAN device? What features does it have? What kind of APIs does it expose? Note that in this sense "QMI" really is a "binary equivalent" of AT commands, the data flows over a DMA engine, which is not part of the "WWAN device" and other services, such as GPS, already has specific transports available upstream. Regards, Bjorn
Re: [PATCH v6 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Wed 10 Feb 12:40 CST 2021, Serge Semin wrote: > On Wed, Feb 10, 2021 at 12:17:27PM -0600, Rob Herring wrote: > > On Wed, Feb 10, 2021 at 11:29 AM Serge Semin > > wrote: > > > > > > In accordance with the USB HCD/DRD schema all the USB controllers are > > > supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the > > > existing DT-nodes will be renamed in a subsequent patch let's first make > > > sure the DWC3 Qualcomm driver supports them and second falls back to the > > > deprecated naming so not to fail on the legacy DTS-files passed to the > > > newer kernels. > > > > > > Signed-off-by: Serge Semin > > > Reviewed-by: Bjorn Andersson > > > --- > > > drivers/usb/dwc3/dwc3-qcom.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c > > > index c703d552bbcf..49ad8d507d37 100644 > > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > > @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct > > > platform_device *pdev) > > > struct device *dev = >dev; > > > int ret; > > > > > > - dwc3_np = of_get_child_by_name(np, "dwc3"); > > > + dwc3_np = of_get_child_by_name(np, "usb") ?: > > > + of_get_child_by_name(np, "dwc3"); > > > > > Is there some reason using compatible instead wouldn't work here? > > I don't know for sure. The fix has been requested in the framework of > this discussion: > https://lore.kernel.org/linux-usb/20201020115959.2658-30-sergey.se...@baikalelectronics.ru/#t > by the driver maintainer Bjorn. To get a firm answer it's better to > have him asked. My feedback was simply that it has to catch both cases, I didn't consider the fact that we have a compatible to match against. > As I see it having of_get_compatible_child() utilized > here would also work. At least for the available in kernel dt-files. > See the affected dts-es in: > https://lore.kernel.org/linux-usb/20210210172850.20849-11-sergey.se...@baikalelectronics.ru/ > > A problem may happen if some older versions of DTS-es had another > compatible string in the dwc3 sub-node... > Afaict all Qualcomm dts files has "snps,dwc3", so you can match against that instead. Regards, Bjorn
Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
On Tue 09 Feb 17:25 CST 2021, Doug Anderson wrote:
> Hi,
>
> On Tue, Feb 9, 2021 at 8:09 AM Bjorn Andersson
> wrote:
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > index 216a74f0057c..2f44785d1af0 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > @@ -153,36 +153,66 @@ panel_in_edp: endpoint {
> > * all modifications to the memory map (from sdm845.dtsi) in one place.
> > */
> >
> > -/*
> > - * Our mpss_region is 8MB bigger than the default one and that conflicts
> > - * with venus_mem and cdsp_mem.
> > - *
> > - * For venus_mem we'll delete and re-create at a different address.
> > - *
> > - * cdsp_mem isn't used on cheza right now so we won't bother re-creating
> > it; but
> > - * that also means we need to delete cdsp_pas.
> > - */
> > -/delete-node/ _mem;
> > -/delete-node/ _mem;
> > -/delete-node/ _pas;
>
> Note to self: on cheza we'll end up with "cdsp_pas" existing now, but
> that _should_ be OK since it's disabled
>
That was not intentional, but as you say it shouldn't make a difference.
>
> > @@ -1321,6 +1359,7 @@ config {
> > };
> >
> > {
> > + memory-region = <_mem>;
> > video-firmware {
> > iommus = <_smmu 0x10b2 0x0>;
> > };
>
> slight nit: I think it looks ugly not to have a blank line between the
> property and the sub-node. ;-)
>
I agree, will go over and adjust this in v2.
>
> > @@ -766,8 +697,6 @@ adsp_pas: remoteproc-adsp {
> > clocks = < RPMH_CXO_CLK>;
> > clock-names = "xo";
> >
> > - memory-region = <_mem>;
> > -
>
> Note to self: we're losing the above on cheza, but that _should_ be OK
> since the node is disabled anyway.
>
> Probably not critical at this point, but it makes me wonder whether we
> could remove adsp_mem on cheza...
>
I noticed this too, but figured that this is an actual change, so it
would be better to do in a separate commit - if that's desired.
> ---
>
> So I only looked at the cheza and sdm845 changes and they look fine to
> me and this seems like a good change overall. I'm assuming that folks
> who focus on the other boards will double-check your work there if
> they care or just trust that everything is great. ;-)
>
> OK, I lied. I took a quick glance. In "sdm845-db845c" you maybe miss
> adding the "memory-region" back to the WiFi? Have you tried running
> something like this before/after:
>
> for f in sdm845*.dtb; do dtc -I dtb -O dts --sort $f > $f.dts; done
>
I was not aware of the --sort, so I did this by chaining together some
more things in the shell to confirm that I didn't actually change any
reserved-memory regions...
> You've gotta ignore phandle ID differences but otherwise it'll point
> out things like this.
>
But as the phandles changed all over the place I looked only at the
reserved-memory, will fix up the db845c wifi node and double check the
rest of the nodes. Thanks for spotting this!
Regards,
Bjorn
Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support
On Mon 01 Feb 09:50 CST 2021, mda...@codeaurora.org wrote:
> On 2021-02-01 12:13, Vinod Koul wrote:
> > On 01-02-21, 11:52, mda...@codeaurora.org wrote:
> > > On 2021-02-01 11:35, Vinod Koul wrote:
> > > > On 27-01-21, 23:56, mda...@codeaurora.org wrote:
> >
> > > > > The actual LOCK/UNLOCK flag should be set on hardware command
> > > > > descriptor.
> > > > > so this flag setting should be done in DMA engine driver. The user
> > > > > of the
> > > > > DMA
> > > > > driver like (in case of IPQ5018) Crypto can use flag
> > > > > "DMA_PREP_LOCK" &
> > > > > "DMA_PREP_UNLOCK"
> > > > > while preparing CMD descriptor before submitting to the DMA
> > > > > engine. In DMA
> > > > > engine driver
> > > > > we are checking these flasgs on CMD descriptor and setting actual
> > > > > LOCK/UNLOCK flag on hardware
> > > > > descriptor.
> > > >
> > > >
> > > > I am not sure I comprehend this yet.. when is that we would need to do
> > > > this... is this for each txn submitted to dmaengine.. or something
> > > > else..
> > >
> > > Its not for each transaction submitted to dmaengine. We have to set
> > > this
> > > only
> > > once on CMD descriptor. So when A53 crypto driver need to change
> > > the crypto
> > > configuration
> > > then first it will lock the all other pipes using setting the LOCK
> > > flag bit
> > > on CMD
> > > descriptor and then it can start the transaction , on data
> > > descriptor this
> > > flag will
> > > not get set once all transaction will be completed the A53 crypto
> > > driver
> > > release the lock on
> > > all other pipes using UNLOCK flag on CMD descriptor. So LOCK/UNLOCK
> > > will be
> > > only once and not for
> > > the each transaction.
> >
> > Okay so why cant the bam driver check cmd descriptor and do lock/unlock
> > as below, why do we need users to do this.
> >
> > if (flags & DMA_PREP_CMD) {
> > do_lock_bam();
>
> User will not decide to do this LOCK/UNLOCK mechanism. It depends on
> use case. This LOCK/UNLOCK mechanism not required always. It needs
> only when hardware will be shared between different core with
> different driver.
So you have a single piece of crypto hardware and you're using the BAM's
LOCK/UNLOCK feature to implement a "mutex" on a particular BAM channel?
> The LOCK/UNLOCK flags provides SW to enter ordering between pipes
> execution.
> (Generally, the BAM pipes are total independent from each other and work in
> parallel manner).
> This LOCK/UNLOCK flags are part of actual pipe hardware descriptor.
>
> Pipe descriptor having the following flags:
> INT : Interrupt
> EOT: End of transfer
> EOB: End of block
> NWD: Notify when done
> CMD: Command
> LOCK: Lock
> UNLOCK: Unlock
> etc.
>
> Here the BAM driver is common driver for (QPIC, Crypto, QUP etc. in
> IPQ5018)
> So here only Crypto will be shared b/w multiple cores so For crypto request
> only the LOCK/UNLOCK
> mechanism required.
> For other request like for QPIC driver, QUPT driver etc. its not required.
> So Crypto driver has to raise the flag for
> LOCK/UNLOCK while preparing CMD descriptor. The actual locking will happen
> in BAM driver only using condition
> if (flags & DMA_PREP_CMD) {
> if (flags & DMA_PREP_LOCK)
> desc->flags |= cpu_to_le16(DESC_FLAG_LOCK);
> }
>
> So Crypto driver should set this flag DMA_PREP_LOCK while preparing CMD
> descriptor.
> So LOCK should be set on actual hardware pipe descriptor with descriptor
> type CMD.
>
It sounds fairly clear that the actual descriptor modification must
happen in the BAM driver, but the question in my mind is how this is
exposed to the DMAengine clients (e.g. crypto, QPIC etc).
What is the life span of the locked state? Do you always provide a
series of descriptors that starts with a LOCK and ends with an UNLOCK?
Or do you envision that the crypto driver provides a LOCK descriptor and
at some later point provides a UNLOCK descriptor?
Finally, this patch just adds the BAM part of things, where is the patch
that actually makes use of this feature?
Regards,
Bjorn
> >
> > The point here is that this seems to be internal to dma and should be
> > handled by dma driver.
> >
> This LOCK/UNLOK flags are part of actual hardware descriptor so this
> should be handled by BAM driver only.
> If we set condition like this
> if (flags & DMA_PREP_CMD) {
> do_lock_bam();
> Then LOCK/UNLOCK will be applied for all the CMD descriptor including
> (QPIC driver, QUP driver , Crypto driver etc.).
> So this is not our intension. So we need to set this LOCK/UNLOCK only for
> the drivers it needs. So Crypto driver needs
> locking mechanism so we will set LOCK/UNLOCK flag on Crypto driver request
> only for other driver request like QPIC driver,
> QUP driver will not set this.
>
> > Also if we do this, it needs to be done for specific platforms..
> >
>
>
>
>
>
>
>
> > Thanks
Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12
On Tue 09 Feb 08:27 CST 2021, Rob Herring wrote:
> On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni
> wrote:
> >
> > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > > wrote:
> > > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski
> > > > > wrote:
> > > > > > Let me steer the discussion to original topic - it's about old
> > > > > > kernel
> > > > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > > > affected.
> > > > > >
> > > > > > Flow looks like this:
> > > > > >
> > > > > > 0. You have existing bidings and drivers.
> > > > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > > > >accepted by maintainer.
> > > > > > 2. Patch above (bindings+drivers) goes during merge window to
> > > > > > v5.11-rc1.
> > > > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > > > >maintainer and it is sent as v5.12-rc1 material to SoC
> > > > > > maintainers.
> > > > > >
> > > > > > So again: old kernel, using old bindings, new DTB.
> > > > > >
> > > >
> > > > I don't think forward compatibility was ever considered. I've seen it
> > > > being mentioned a few times on #armlinux but honestly this simply can't
> > > > be achieved. This would mean being able to write complete DT bindings
> > > > for a particular SoC at day 0 which will realistically never happen. You
> > > > may noteven have a complete datasheet and even if you have a datasheet,
> > > > it may not be complete or it may be missing hw errata that are
> > > > discovered later on and need a new binding to handle.
> > >
> > > You do not have to write the correct DT for this, the only requirement
> > > is that any changes to a node are backward-compatible, which is
> > > typically the case if you add properties or compatible strings without
> > > removing the old one. A bugfix in this case is also backward-compatible.
> > >
> > > The part that can not happen instead is to write a DT that can expose
> > > features that any future kernel will use.
> > >
> >
> > But I think we are speaking about the other way around were you would be
> > e.g. removing properties or splitting a node is multiple different
> > nodes following a different understanding of the hardware.
> > And in this case, any rework of the bindings will be forbidden, like
> > 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
> > break older kernels trying to use the new dtb.
> > 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
> > an other case.
> > I'm not sure want to keep the older properties or the older compatible
> > string as a fallback for this use case.
> >
> > > > > However, once the firmware is updated, it may no longer be possible to
> > > > > go back to the old kernel in case the new one is busted.
> > > > >
> > > >
> > > > Any serious update strategy will update both the kernel and device tree
> > > > at the same time, exactly like you already have to update the initramfs
> > > > with the kernel as soon as it is including kernel modules.
> > > > I would expect any embedded platform to actually use a container format,
> > > > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > > > image and will allow to sign all parts.
> > >
> > > Embedded systems that do this have no requirement for backward
> > > or forward compatibility at all, the only requirement for these is
> > > bisectability
> > > of git commits.
> > >
> >
> > Yes and I can't see any drawbacks in this approach.
> >
> > > > > A similar problem can happen with the EBBR boot flow that relies on
> > > > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > > > actual boot loader. This is commonly supported across distros. While
> > > > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > > > that, this often fails in practice because u-boot needs to fill a
> > > > > board specific set of DT properties (bootargs, detected memory,
> > > > > mac address, ...). The usual way this gets handled is that u-boot
> > > > > loads
> > > > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > > > which picks only kernel+initrd from disk and boots this with the dtb.
> > > > >
> > > > > The result is similar to case with dtb built into the firmware: after
> > > > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > > > old kernels but they may not work as they did in the past. There are
> > > > > obviously ways to work around it, but it does lead to user
> > > > > frustration.
> > > > >
> > > >
> > > > Are there really any platforms with the dtb built into the firmware?
> > > > I feel like this is a mythical creature used to scare people into
> > > > keeping
> > > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > > with keeping DTB and kernel in sync?
[PATCH 2/2] arm64: dts: qcom: sdm850-yoga: Enable IPA
The ipa_fws.elf found in the Lenovo Yoga C630 isn't packed like the one
found in e.g. the MTP, so it doesn't fit in the "standard" ipa_fws
memory region. Further more, authentication of ipa_fws at the usual base
address is rejected by the Peripheral Authentication Service (in
TrustZone), so some shuffling and trial and error was used to come up
with acceptable regions.
With this in order, enable the IPA device.
Signed-off-by: Bjorn Andersson
---
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 26 +--
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index 9c2ab377faf1..4dd5820b3b31 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -74,28 +74,23 @@ rmtfs_mem: memory@88f0 {
qcom,vmid = <15>;
};
- ipa_fw_mem: memory@8c40 {
- reg = <0 0x8c40 0 0x1>;
+ wlan_msa_mem: memory@8c40 {
+ reg = <0 0x8c40 0 0x10>;
no-map;
};
- ipa_gsi_mem: memory@8c41 {
- reg = <0 0x8c41 0 0x5000>;
+ gpu_mem: memory@8c515000 {
+ reg = <0 0x8c515000 0 0x2000>;
no-map;
};
- gpu_mem: memory@8c415000 {
- reg = <0 0x8c415000 0 0x2000>;
+ ipa_fw_mem: memory@8c517000 {
+ reg = <0 0x8c517000 0 0x5a000>;
no-map;
};
- adsp_mem: memory@8c50 {
- reg = <0 0x8c50 0 0x1a0>;
- no-map;
- };
-
- wlan_msa_mem: memory@8df0 {
- reg = <0 0x8df0 0 0x10>;
+ adsp_mem: memory@8c60 {
+ reg = <0 0x8c60 0 0x1a0>;
no-map;
};
@@ -500,6 +495,11 @@ ecsh: hid@5c {
};
};
+ {
+ status = "okay";
+ memory-region = <_fw_mem>;
+};
+
{
status = "okay";
};
--
2.30.0
[PATCH 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
The reserved-memory regions used for carrying firmware to be run on the
various cores and co-processors in a Qualcomm platform differs in size,
placement and presence based on each device's feature set and security
configuration.
Rather than providing some basic set that works on the MTP and then
piecemeal patch this up on the various devices, push the configuration
of these regions out to the individual device dts files.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 89 +--
arch/arm64/boot/dts/qcom/sdm845-db845c.dts| 85 ++
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 87 ++
.../boot/dts/qcom/sdm845-oneplus-common.dtsi | 78 +++-
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 45 ++
arch/arm64/boot/dts/qcom/sdm845.dtsi | 83 -
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 86 ++
7 files changed, 428 insertions(+), 125 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 216a74f0057c..2f44785d1af0 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -153,36 +153,66 @@ panel_in_edp: endpoint {
* all modifications to the memory map (from sdm845.dtsi) in one place.
*/
-/*
- * Our mpss_region is 8MB bigger than the default one and that conflicts
- * with venus_mem and cdsp_mem.
- *
- * For venus_mem we'll delete and re-create at a different address.
- *
- * cdsp_mem isn't used on cheza right now so we won't bother re-creating it;
but
- * that also means we need to delete cdsp_pas.
- */
-/delete-node/ _mem;
-/delete-node/ _mem;
-/delete-node/ _pas;
-/delete-node/ _mem;
-
-/* Increase the size from 120 MB to 128 MB */
-_region {
- reg = <0 0x8e00 0 0x800>;
-};
-
-/* Increase the size from 2MB to 8MB */
-_mem {
- reg = <0 0x88f0 0 0x80>;
-};
-
/ {
reserved-memory {
+ tz_mem: memory@8620 {
+ reg = <0 0x8620 0 0x2d0>;
+ no-map;
+ };
+
+ rmtfs_mem: memory@88f0 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0 0x88f0 0 0x80>;
+ no-map;
+
+ qcom,client-id = <1>;
+ qcom,vmid = <15>;
+ };
+
+ ipa_fw_mem: memory@8c40 {
+ reg = <0 0x8c40 0 0x1>;
+ no-map;
+ };
+
+ ipa_gsi_mem: memory@8c41 {
+ reg = <0 0x8c41 0 0x5000>;
+ no-map;
+ };
+
+ adsp_mem: memory@8c50 {
+ reg = <0 0x8c50 0 0x1a0>;
+ no-map;
+ };
+
+ wlan_msa_mem: memory@8df0 {
+ reg = <0 0x8df0 0 0x10>;
+ no-map;
+ };
+
+ mpss_region: memory@8e00 {
+ reg = <0 0x8e00 0 0x800>;
+ no-map;
+ };
+
venus_mem: memory@9600 {
reg = <0 0x9600 0 0x50>;
no-map;
};
+
+ mba_region: memory@9650 {
+ reg = <0 0x9650 0 0x20>;
+ no-map;
+ };
+
+ slpi_mem: memory@9670 {
+ reg = <0 0x9670 0 0x140>;
+ no-map;
+ };
+
+ spss_mem: memory@97b0 {
+ reg = <0 0x97b0 0 0x10>;
+ no-map;
+ };
};
};
@@ -206,7 +236,6 @@ flash@0 {
};
};
-
_rsc {
pm8998-rpmh-regulators {
compatible = "qcom,pm8998-rpmh-regulators";
@@ -645,6 +674,14 @@ _smmu {
_pil {
iommus = <_smmu 0x781 0x0>,
<_smmu 0x724 0x3>;
+
+ mba {
+ memory-region = <_region>;
+ };
+
+ mpss {
+ memory-region = <_region>;
+ };
};
_pwrkey {
@@ -850,6 +887,7 @@ _2_qmpphy {
{
status = "okay";
+ memory-region = <_msa_mem>;
vdd-0.8-cx-mx-supply = <_pp800_l5a >;
vdd-1.8-xo-supply = <_l7a_wcn3990>;
@@ -1321,6 +1359,7 @@ config {
};
{
+ memory-region = <_mem>;
video-firmware {
iommus = <_smmu 0x10b2 0x0>;
};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index c4ac6f5dc008..0c175685c135 100644
--- a/
Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12
On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote: > Hi Arnd, > > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann wrote: > > That said, I'm still not happy about the patch we discussed in the > > other email thread[1] and I'd like to handle it a little more strictly in > > the future, but I agree this wasn't obvious and we have been rather > > inconsistent about it in the past, with some platform maintainers > > handling it way more strictly than others. > > > > I've added the devicetree maintainers and a few other platform > > maintainers to Cc here, maybe they can provide some further > > opinions on the topic so we can come to an approach that > > works for everyone. > > > > My summary of the thread in [1] is there was a driver bug that > > required a DT binding change. Krzysztof and the other involved > > parties made sure the driver handles it in a backward-compatible > > way (an old dtb file will still run into the bug but keep working > > with new kernels), but decided that they did not need to worry > > about the opposite case (running an old kernel with an updated > > dtb). I noticed the compatibility break and said that I would > > prefer this to be done in a way that is compatible both ways, > > or at the minimum be alerted about the binding break in the > > pull request, with an explanation about why this had to be done, > > even when we don't think anyone is going to be affected. > > > > What do others think about this? Should we generally assume > > that breaking old kernels with new dtbs is acceptable, or should > > we try to avoid it if possible, the same way we try to avoid > > breaking new kernels with old dtbs? Should this be a platform > > specific policy or should we try to handle all platforms the same > > way? > > For Renesas SoCs, we typically only consider compatibility of new > kernels with old DTBs, not the other way around. > However, most DTB updates are due to new hardware support, so using the > new DTB with an old kernel usually just means no newly documented > hardware, or new feature, is being used by the old kernel. > This is the case for the Qualcomm tree as well, it's expected that a new kernel should work with older DT. But, while we don't actively try to break it, there are plenty of examples where we don't/can't give the promise in the other direction. These examples ranges from advancements in power management (implementation and binding) to DT validation forcing deprecation and adoption of new bindings. Regards, Bjorn
Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
On Mon 08 Feb 11:21 CST 2021, Kalle Valo wrote:
> Amit Pundir writes:
>
> > Hi Kalle,
> >
> > On Mon, 7 Dec 2020 at 22:25, Kalle Valo wrote:
> >>
> >> This is firmware version specific, right? There's also enum
> >> ath10k_fw_features which is embedded within firmware-N.bin, we could add
> >> a new flag there. But that means that a correct firmware-N.bin is needed
> >> for each firmware version, not sure if that would work out. Just
> >> throwing out ideas here.
> >
> > Apologies for this late reply. I was out for a while.
>
> No worries.
>
> > If by that (the firmware version) you mean "QC_IMAGE_VERSION_STRING",
> > then that may be a bit tricky. Pocophone F1 use the same firmware
> > family version (WLAN.HL.2.0.XXX), used by Dragonboard 845c (which has
> > Wi-Fi working upstream).
>
> I'm meaning the ath10k firmware meta data we have in firmware-N.bin
> (N=2,3,4...) file. A quick summary:
>
> Every ath10k firmware release should have firmware-N.bin. The file is
> created with this tool:
>
> https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder
>
> firmware-N.bin contains various metadata, one of those being firmware
> feature flags:
>
> enum ath10k_fw_features {
> /* wmi_mgmt_rx_hdr contains extra RSSI information */
> ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX = 0,
>
> /* Firmware from 10X branch. Deprecated, don't use in new code. */
> ATH10K_FW_FEATURE_WMI_10X = 1,
>
> [...]
>
> So what you could is add a new flag enum ath10k_fw_features, create a
> new firmware-N.bin for your device and enable the flag on the firmware
> releases for your device only.
>
> I don't know if this is usable, but one solution which came to my mind.
It sounds quite reasonable to pass this using firmawre-N.bin instead of
DT, however that would imply that we need to find firmware-N.bin in the
device-specific directory, where we keep the wlanmdsp.mbn as well - and
not under /lib/firmware/ath10k
For other devices (e.g. ADSP, modem or wlanmdsp.mbn) we're putting these
in e.g. /lib/firmware/qcom/LENOVO/81JL/ and specifies the location using
a firmware-name property in DT.
Regards,
Bjorn
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 2/3] phy: qcom-qmp: Add UFS V5 registers found in SM8350
On Thu 04 Feb 10:58 CST 2021, Vinod Koul wrote: > Add the registers for UFS found in SM8350. The UFS phy used in SM8350 > seems to have same offsets as V5 phy, although Documentation for that is > lacking. > Reviewed-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Vinod Koul > --- > drivers/phy/qualcomm/phy-qcom-qmp.h | 47 + > 1 file changed, 47 insertions(+) > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h > b/drivers/phy/qualcomm/phy-qcom-qmp.h > index dff7be5a1cc1..71ce3aa174ae 100644 > --- a/drivers/phy/qualcomm/phy-qcom-qmp.h > +++ b/drivers/phy/qualcomm/phy-qcom-qmp.h > @@ -824,6 +824,32 @@ > #define QPHY_V4_PCS_PCIE_PRESET_P10_PRE 0xbc > #define QPHY_V4_PCS_PCIE_PRESET_P10_POST 0xe0 > > +/* Only for QMP V5 PHY - QSERDES COM registers */ > +#define QSERDES_V5_COM_PLL_IVCO 0x058 > +#define QSERDES_V5_COM_CP_CTRL_MODE0 0x074 > +#define QSERDES_V5_COM_CP_CTRL_MODE1 0x078 > +#define QSERDES_V5_COM_PLL_RCTRL_MODE0 0x07c > +#define QSERDES_V5_COM_PLL_RCTRL_MODE1 0x080 > +#define QSERDES_V5_COM_PLL_CCTRL_MODE0 0x084 > +#define QSERDES_V5_COM_PLL_CCTRL_MODE1 0x088 > +#define QSERDES_V5_COM_SYSCLK_EN_SEL 0x094 > +#define QSERDES_V5_COM_LOCK_CMP_EN 0x0a4 > +#define QSERDES_V5_COM_LOCK_CMP1_MODE0 0x0ac > +#define QSERDES_V5_COM_LOCK_CMP2_MODE0 0x0b0 > +#define QSERDES_V5_COM_LOCK_CMP1_MODE1 0x0b4 > +#define QSERDES_V5_COM_DEC_START_MODE0 0x0bc > +#define QSERDES_V5_COM_LOCK_CMP2_MODE1 0x0b8 > +#define QSERDES_V5_COM_DEC_START_MODE1 0x0c4 > +#define QSERDES_V5_COM_VCO_TUNE_MAP 0x10c > +#define QSERDES_V5_COM_VCO_TUNE_INITVAL2 0x124 > +#define QSERDES_V5_COM_HSCLK_SEL 0x158 > +#define QSERDES_V5_COM_HSCLK_HS_SWITCH_SEL 0x15c > +#define QSERDES_V5_COM_BIN_VCOCAL_CMP_CODE1_MODE00x1ac > +#define QSERDES_V5_COM_BIN_VCOCAL_CMP_CODE2_MODE00x1b0 > +#define QSERDES_V5_COM_BIN_VCOCAL_CMP_CODE1_MODE10x1b4 > +#define QSERDES_V5_COM_BIN_VCOCAL_HSCLK_SEL 0x1bc > +#define QSERDES_V5_COM_BIN_VCOCAL_CMP_CODE2_MODE10x1b8 > + > /* Only for QMP V5 PHY - TX registers */ > #define QSERDES_V5_TX_RES_CODE_LANE_TX 0x34 > #define QSERDES_V5_TX_RES_CODE_LANE_RX 0x38 > @@ -837,6 +863,10 @@ > #define QSERDES_V5_TX_RCV_DETECT_LVL_2 0xa4 > #define QSERDES_V5_TX_TRAN_DRVR_EMP_EN 0xc0 > #define QSERDES_V5_TX_PI_QEC_CTRL0xe4 > +#define QSERDES_V5_TX_PWM_GEAR_1_DIVIDER_BAND0_1 0x178 > +#define QSERDES_V5_TX_PWM_GEAR_2_DIVIDER_BAND0_1 0x17c > +#define QSERDES_V5_TX_PWM_GEAR_3_DIVIDER_BAND0_1 0x180 > +#define QSERDES_V5_TX_PWM_GEAR_4_DIVIDER_BAND0_1 0x184 > > /* Only for QMP V5 PHY - RX registers */ > #define QSERDES_V5_RX_UCDR_FO_GAIN 0x008 > @@ -893,6 +923,23 @@ > #define QSERDES_V5_RX_DCC_CTRL1 0x1a8 > #define QSERDES_V5_RX_VTH_CODE 0x1b0 > > +/* Only for QMP V5 PHY - UFS PCS registers */ > +#define QPHY_V5_PCS_UFS_TIMER_20US_CORECLK_STEPS_MSB 0x00c > +#define QPHY_V5_PCS_UFS_TIMER_20US_CORECLK_STEPS_LSB 0x010 > +#define QPHY_V5_PCS_UFS_PLL_CNTL 0x02c > +#define QPHY_V5_PCS_UFS_TX_LARGE_AMP_DRV_LVL 0x030 > +#define QPHY_V5_PCS_UFS_TX_SMALL_AMP_DRV_LVL 0x038 > +#define QPHY_V5_PCS_UFS_TX_HSGEAR_CAPABILITY 0x074 > +#define QPHY_V5_PCS_UFS_RX_HSGEAR_CAPABILITY 0x0b4 > +#define QPHY_V5_PCS_UFS_DEBUG_BUS_CLKSEL 0x124 > +#define QPHY_V5_PCS_UFS_RX_MIN_HIBERN8_TIME 0x150 > +#define QPHY_V5_PCS_UFS_RX_SIGDET_CTRL1 0x154 > +#define QPHY_V5_PCS_UFS_RX_SIGDET_CTRL2 0x158 > +#define QPHY_V5_PCS_UFS_TX_PWM_GEAR_BAND 0x160 > +#define QPHY_V5_PCS_UFS_TX_HS_GEAR_BAND 0x168 > +#define QPHY_V5_PCS_UFS_TX_MID_TERM_CTRL10x1d8 > +#define QPHY_V5_PCS_UFS_MULTI_LANE_CTRL1 0x1e0 > + > /* Only for QMP V5 PHY - USB3 have different offsets than V4 */ > #define QPHY_V5_PCS_USB3_POWER_STATE_CONFIG1 0x300 > #define QPHY_V5_PCS_USB3_AUTONOMOUS_MODE_STATUS 0x304 > -- > 2.26.2 >
Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
On Wed 03 Feb 12:40 CST 2021, Jakub Kicinski wrote: > On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote: > > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski wrote: > > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > > > The current patchset only supports QMI channel so I'd request you to > > > > review the chardev node created for it. The QMI chardev node created > > > > will be unique for the MHI bus and the number of nodes depends on the > > > > MHI controllers in the system (typically 1 but not limited). > > > > > > If you want to add a MHI QMI driver, please write a QMI-only driver. > > > This generic "userspace client interface" driver is a no go. Nobody will > > > have the time and attention to police what you throw in there later. > > > > Think it should be seen as filtered userspace access to MHI bus > > (filtered because not all channels are exposed), again it's not > > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial, > > etc...). It will not be specific to QMI, since we will also need it > > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all > > these protocols are usually handled by userspace tools and not linked > > to any internal Linux framework, so it would be better not having a > > dedicated chardev for each of them. > > The more people argue for this backdoor interface the more distrustful > of it we'll become. Keep going at your own peril. With things such as USBDEVFS, UIO, spi-dev and i2c-dev already exposing various forms of hardware directly to userspace in an identical fashion, can you please explain why you believe this would be inappropriate for MHI devices? Thanks, Bjorn
Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
On Wed 03 Feb 12:05 CST 2021, Jakub Kicinski wrote: > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > >> Jakub, Dave, Adding you both to get your reviews on this series. I've > > >> provided an explanation above and in the previous iteration [1]. > > > > > >Let's be clear what the review would be for. Yet another QMI chardev > > >or the "UCI" direct generic user space to firmware pipe? > > > > The current patchset only supports QMI channel so I'd request you to > > review the chardev node created for it. The QMI chardev node created > > will be unique for the MHI bus and the number of nodes depends on the > > MHI controllers in the system (typically 1 but not limited). > > If you want to add a MHI QMI driver, please write a QMI-only driver. But said QMI driver would be identical to what is proposed here, given that the libqmi [1] communicates in the raw messages of the given MHI channel. Should I then propose another copy of the same driver for transporting debug messages between [2] and the modem? And a third copy to support firmware flashing using [3]. [1] https://www.freedesktop.org/wiki/Software/libqmi/ [2] https://github.com/andersson/diag [3] https://github.com/andersson/qdl > This generic "userspace client interface" driver is a no go. Nobody will > have the time and attention to police what you throw in there later. PCI devices implementing this must have a MHI controller driver, which explicitly needs to specify which logical channels should be exposed to userspace using the UCI driver. So in contrast to things like USBFS or the tty layer - which is used to implement "network devices" today - there is a natural point of policing this. Regards, Bjorn
Re: [PATCH v3 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
On Sat 05 Dec 09:56 CST 2020, Serge Semin wrote:
> In accordance with the USB HCD/DRD schema all the USB controllers are
> supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
> existing DT-nodes will be renamed in a subsequent patch let's first make
> sure the DWC3 Qualcomm driver supports them and second falls back to the
> deprecated naming so not to fail on the legacy DTS-files passed to the
> newer kernels.
>
Felipe, will you merge this, so that I can merge the dts patch depending
on this into the Qualcomm DT tree?
Regards,
Bjorn
> Signed-off-by: Serge Semin
> Reviewed-by: Bjorn Andersson
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index c703d552bbcf..49ad8d507d37 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct
> platform_device *pdev)
> struct device *dev = >dev;
> int ret;
>
> - dwc3_np = of_get_child_by_name(np, "dwc3");
> + dwc3_np = of_get_child_by_name(np, "usb") ?:
> + of_get_child_by_name(np, "dwc3");
> if (!dwc3_np) {
> dev_err(dev, "failed to find dwc3 core child\n");
> return -ENODEV;
> --
> 2.29.2
>
Re: [PATCH v4 2/2] arm: dts: sc7180: Add support for gpu fuse
On Fri 08 Jan 12:15 CST 2021, Akhil P Oommen wrote:
Please align the $subject prefix with other changes in the same file.
I fixed it up while picking up the patch this time.
Regards,
Bjorn
> Add support for gpu fuse to help identify the supported opps.
>
> Signed-off-by: Akhil P Oommen
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 6678f1e..8cae3eb 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -675,6 +675,11 @@
> reg = <0x25b 0x1>;
> bits = <1 3>;
> };
> +
> + gpu_speed_bin: gpu_speed_bin@1d2 {
> + reg = <0x1d2 0x2>;
> + bits = <5 8>;
> + };
> };
>
> sdhc_1: sdhci@7c4000 {
> @@ -1907,52 +1912,69 @@
> operating-points-v2 = <_opp_table>;
> qcom,gmu = <>;
>
> + nvmem-cells = <_speed_bin>;
> + nvmem-cell-names = "speed_bin";
> +
> interconnects = <_noc MASTER_GFX3D 0 _virt
> SLAVE_EBI1 0>;
> interconnect-names = "gfx-mem";
>
> gpu_opp_table: opp-table {
> compatible = "operating-points-v2";
>
> + opp-82500 {
> + opp-hz = /bits/ 64 <82500>;
> + opp-level =
> ;
> + opp-peak-kBps = <8532000>;
> + opp-supported-hw = <0x04>;
> + };
> +
> opp-8 {
> opp-hz = /bits/ 64 <8>;
> opp-level =
> ;
> opp-peak-kBps = <8532000>;
> + opp-supported-hw = <0x07>;
> };
>
> opp-65000 {
> opp-hz = /bits/ 64 <65000>;
> opp-level =
> ;
> opp-peak-kBps = <7216000>;
> + opp-supported-hw = <0x07>;
> };
>
> opp-56500 {
> opp-hz = /bits/ 64 <56500>;
> opp-level = ;
> opp-peak-kBps = <5412000>;
> + opp-supported-hw = <0x07>;
> };
>
> opp-43000 {
> opp-hz = /bits/ 64 <43000>;
> opp-level =
> ;
> opp-peak-kBps = <5412000>;
> + opp-supported-hw = <0x07>;
> };
>
> opp-35500 {
> opp-hz = /bits/ 64 <35500>;
> opp-level = ;
> opp-peak-kBps = <3072000>;
> + opp-supported-hw = <0x07>;
> };
>
> opp-26700 {
> opp-hz = /bits/ 64 <26700>;
> opp-level =
> ;
> opp-peak-kBps = <3072000>;
> + opp-supported-hw = <0x07>;
> };
>
> opp-18000 {
> opp-hz = /bits/ 64 <18000>;
> opp-level =
> ;
> opp-peak-kBps = <1804000>;
> + opp-supported-hw = <0x07>;
> };
> };
> };
> --
> 2.7.4
>
Re: [PATCH v3 19/22] arm64: defconfig: Build Qcom CAMSS as module
On Wed 27 Jan 08:49 CST 2021, Robert Foss wrote:
> Build camera ISP driver as a module.
>
Isn't this enabled since b47c5fc15d88 ("arm64: defconfig: Enable
Qualcomm CAMCC, CAMSS and CCI drivers")?
Regards,
Bjorn
> Signed-off-by: Robert Foss
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 838301650a79..cb224d2af6a0 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -640,6 +640,7 @@ CONFIG_VIDEO_RENESAS_FDP1=m
> CONFIG_VIDEO_RENESAS_FCP=m
> CONFIG_VIDEO_RENESAS_VSP1=m
> CONFIG_SDR_PLATFORM_DRIVERS=y
> +CONFIG_VIDEO_QCOM_CAMSS=m
> CONFIG_VIDEO_RCAR_DRIF=m
> CONFIG_VIDEO_IMX219=m
> CONFIG_VIDEO_OV5645=m
> --
> 2.27.0
>
Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
On Tue 02 Feb 15:37 CST 2021, Rob Herring wrote: > On Tue, Feb 2, 2021 at 1:48 PM Bjorn Andersson > wrote: > > > > On Sat 30 Jan 10:14 CST 2021, Dmitry Baryshkov wrote: > > > > > On Sat, 30 Jan 2021 at 06:53, Bjorn Andersson > > > wrote: > > > > > > > > On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > > > > > > > > > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas > > > > > wrote: > > > > > > > > > > > > On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote: > > > > > > > On 28/01/2021 22:26, Rob Herring wrote: > > > > > > > > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Some Qualcomm platforms require to power up an external > > > > > > > > > device before > > > > > > > > > probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT > > > > > > > > > chip needs > > > > > > > > > to be powered up before PCIe0 bus is probed. Add a quirk to > > > > > > > > > the > > > > > > > > > respective PCIe root bridge to attach to the power domain if > > > > > > > > > one is > > > > > > > > > required, so that the QCA chip is started before scanning the > > > > > > > > > PCIe bus. > > > > > > > > > > > > > > > > This is solving a generic problem in a specific driver. It > > > > > > > > needs to be > > > > > > > > solved for any PCI host and any device. > > > > > > > > > > > > > > Ack. I see your point here. > > > > > > > > > > > > > > As this would require porting code from powerpc/spark of-pci code > > > > > > > and > > > > > > > changing pcie port driver to apply power supply before bus > > > > > > > probing happens, > > > > > > > I'd also ask for the comments from PCI maintainers. Will that > > > > > > > solution be > > > > > > > acceptable to you? > > > > > > > > > > > > I can't say without seeing the code. I don't know enough about this > > > > > > scenario to envision how it might look. > > > > > > > > > > > > I guess the QCA6390 is a PCIe device? Why does it need to be > > > > > > powered > > > > > > up before probing? Shouldn't we get a link-up interrupt when it is > > > > > > powered up so we could probe it then? > > > > > > > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > > > > > parts. It has internal power regulators which once enabled will > > > > > powerup the PCIe, serial and radio parts. There is no need to manage > > > > > regulators. Once enabled they will automatically handle device > > > > > suspend/resume, etc. > > > > > > > > > > > > > So what you're saying is that if either the PCI controller or bluetooth > > > > driver probes these regulators will be turned on, indefinitely? > > > > > > > > If so, why do we need a driver to turn them on, rather than just mark > > > > them as always-on? > > > > > > > > What's the timing requirement wrt regulators vs WL_EN/BT_EN? > > > > > > According to the documentation I have, they must be enabled right > > > after enabling powering the chip and they must stay enabled all the > > > time. > > > > > > > So presumably just marking these things always-on and flipping the GPIO > > statically won't be good enough due to the lack of control over the > > timing. > > > > This really do look like a simplified case of what we see with the > > PCIe attached modems, where similar requirements are provided, but also > > the ability to perform a device specific reset sequence in case the > > hardware has locked up. I'm slightly worried about the ability of > > extending your power-domain model to handle the restart operation > > though. > > I think this is an abuse of 'power-domains'. Just define the > regulators in both WiFi and BT nodes and have each driver enable them. > They're refcounted. If that's still not enough control over the power > sequencing, then create a 3rd entity to do it, but that doesn't need > to leak into DT. You already have all the information you need. > As Dmitry explained he still need to pull the two GPIOs high after enabling the regulators, but before scanning the PCI or serdev buses. I was thinking something along the lines you suggest, but I've not been able to come up with something that will guarantee the ordering of the events. Regards, Bjorn
Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
On Sat 30 Jan 10:14 CST 2021, Dmitry Baryshkov wrote: > On Sat, 30 Jan 2021 at 06:53, Bjorn Andersson > wrote: > > > > On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > > > > > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas wrote: > > > > > > > > On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote: > > > > > On 28/01/2021 22:26, Rob Herring wrote: > > > > > > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov > > > > > > wrote: > > > > > > > > > > > > > > Some Qualcomm platforms require to power up an external device > > > > > > > before > > > > > > > probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT > > > > > > > chip needs > > > > > > > to be powered up before PCIe0 bus is probed. Add a quirk to the > > > > > > > respective PCIe root bridge to attach to the power domain if one > > > > > > > is > > > > > > > required, so that the QCA chip is started before scanning the > > > > > > > PCIe bus. > > > > > > > > > > > > This is solving a generic problem in a specific driver. It needs to > > > > > > be > > > > > > solved for any PCI host and any device. > > > > > > > > > > Ack. I see your point here. > > > > > > > > > > As this would require porting code from powerpc/spark of-pci code and > > > > > changing pcie port driver to apply power supply before bus probing > > > > > happens, > > > > > I'd also ask for the comments from PCI maintainers. Will that > > > > > solution be > > > > > acceptable to you? > > > > > > > > I can't say without seeing the code. I don't know enough about this > > > > scenario to envision how it might look. > > > > > > > > I guess the QCA6390 is a PCIe device? Why does it need to be powered > > > > up before probing? Shouldn't we get a link-up interrupt when it is > > > > powered up so we could probe it then? > > > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > > > parts. It has internal power regulators which once enabled will > > > powerup the PCIe, serial and radio parts. There is no need to manage > > > regulators. Once enabled they will automatically handle device > > > suspend/resume, etc. > > > > > > > So what you're saying is that if either the PCI controller or bluetooth > > driver probes these regulators will be turned on, indefinitely? > > > > If so, why do we need a driver to turn them on, rather than just mark > > them as always-on? > > > > What's the timing requirement wrt regulators vs WL_EN/BT_EN? > > According to the documentation I have, they must be enabled right > after enabling powering the chip and they must stay enabled all the > time. > So presumably just marking these things always-on and flipping the GPIO statically won't be good enough due to the lack of control over the timing. This really do look like a simplified case of what we see with the PCIe attached modems, where similar requirements are provided, but also the ability to perform a device specific reset sequence in case the hardware has locked up. I'm slightly worried about the ability of extending your power-domain model to handle the restart operation though. Regards, Bjorn
Re: [PATCH v7 4/5] usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default
On Thu 28 Jan 22:46 CST 2021, Wesley Cheng wrote:
> In order to take advantage of the TX fifo resizing logic, manually add
> these properties to the DWC3 child node by default. This will allow
> the DWC3 gadget to resize the TX fifos for the IN endpoints, which
> help with performance.
>
> Signed-off-by: Wesley Cheng
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index d803ee9..4ea6be3 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -564,6 +564,7 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, int
> count)
>
> static const struct property_entry dwc3_qcom_acpi_properties[] = {
> PROPERTY_ENTRY_STRING("dr_mode", "host"),
> + PROPERTY_ENTRY_BOOL("tx-fifo-resize"),
I checked the ACPI tables for Lenovo Miix 630, Yoga C630 and Flex 5G and
neither one has this property specified. So while we could just add this
here, it would have to be done in collaboration with the people who
actually define these. And as said before, I believe we want this to
always be enabled.
> {}
> };
>
> @@ -634,6 +635,7 @@ static int dwc3_qcom_of_register_core(struct
> platform_device *pdev)
> struct dwc3_qcom*qcom = platform_get_drvdata(pdev);
> struct device_node *np = pdev->dev.of_node, *dwc3_np;
> struct device *dev = >dev;
> + struct property *prop;
> int ret;
>
> dwc3_np = of_get_child_by_name(np, "dwc3");
> @@ -642,6 +644,14 @@ static int dwc3_qcom_of_register_core(struct
> platform_device *pdev)
> return -ENODEV;
> }
>
> + prop = kzalloc(sizeof(*prop), GFP_KERNEL);
> + if (prop) {
> + prop->name = "tx-fifo-resize";
> + ret = of_add_property(dwc3_np, prop);
Can't we come up with a way where the platform driver enables this on
the core driver without modifying DT?
Regards,
Bjorn
> + if (ret < 0)
> + dev_info(dev, "unable to add tx-fifo-resize prop\n");
> + }
> +
> ret = of_platform_populate(np, NULL, NULL, dev);
> if (ret) {
> dev_err(dev, "failed to register dwc3 core - %d\n", ret);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH v2 2/5] arm64: qcom: dts: qrb5165-rb5: add qca6391 power device
On Thu 28 Jan 11:52 CST 2021, Dmitry Baryshkov wrote:
> Add qca6391 to device tree as a way to provide power domain to WiFi and
> BT parts of the chip.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 61
> 1 file changed, 61 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> index 8aebc3660b11..2b0c1cc9333b 100644
> --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> @@ -151,6 +151,23 @@ vreg_s4a_1p8: vreg-s4a-1p8 {
> regulator-max-microvolt = <180>;
> regulator-always-on;
> };
> +
> + qca6391: qca6391 {
> + compatible = "qcom,qca6390";
> + #power-domain-cells = <0>;
> +
> + vddaon-supply = <_s6a_0p95>;
> + vddpmu-supply = <_s2f_0p95>;
> + vddrfa1-supply = <_s2f_0p95>;
> + vddrfa2-supply = <_s8c_1p3>;
> + vddrfa3-supply = <_s5a_1p9>;
> + vddpcie1-supply = <_s8c_1p3>;
> + vddpcie2-supply = <_s5a_1p9>;
> + vddio-supply = <_s4a_1p8>;
> + pinctrl-names = "default", "active";
> + pinctrl-0 = <_default_state _default_state>;
> + pinctrl-1 = <_active_state _active_state>;
I dislike the use of pinctrl states for toggling the level of the gpio
and would prefer that you use the gpio binding and api for this instead.
> + };
> };
>
> {
> @@ -1013,6 +1030,28 @@ {
> "HST_WLAN_UART_TX",
> "HST_WLAN_UART_RX";
>
> + bt_default_state: bt-default-state {
Are you sure you need to drive the BT_EN pin in order to have WiFi
working? On QCA6174 I believe the "WL_EN" was actually RESET_N and BT_EN
was actually "blueooth enable" - so we wired that in the bluetooth node
instead.
> + bt-en {
> + pins = "gpio21";
> + function = "gpio";
> +
> + drive-strength = <16>;
> + output-low;
> + bias-pull-up;
> + };
> + };
> +
> + bt_active_state: bt-active-state {
> + bt-en {
> + pins = "gpio21";
> + function = "gpio";
> +
> + drive-strength = <16>;
> + output-high;
> + bias-pull-up;
> + };
> + };
> +
> lt9611_irq_pin: lt9611-irq {
> pins = "gpio63";
> function = "gpio";
> @@ -1119,6 +1158,28 @@ sdc2_card_det_n: sd-card-det-n {
> function = "gpio";
> bias-pull-up;
> };
> +
> + wlan_default_state: wlan-default-state {
JFYI. You don't need this "dummy" subnode, you can put the properties
directly in the state node.
Regards,
Bjorn
> + wlan-en {
> + pins = "gpio20";
> + function = "gpio";
> +
> + drive-strength = <16>;
> + output-low;
> + bias-pull-up;
> + };
> + };
> +
> + wlan_active_state: wlan-active-state {
> + wlan-en {
> + pins = "gpio20";
> + function = "gpio";
> +
> + drive-strength = <16>;
> + output-high;
> + bias-pull-up;
> + };
> + };
> };
>
> {
> --
> 2.29.2
>
Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas wrote: > > > > On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote: > > > On 28/01/2021 22:26, Rob Herring wrote: > > > > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov > > > > wrote: > > > > > > > > > > Some Qualcomm platforms require to power up an external device before > > > > > probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT chip > > > > > needs > > > > > to be powered up before PCIe0 bus is probed. Add a quirk to the > > > > > respective PCIe root bridge to attach to the power domain if one is > > > > > required, so that the QCA chip is started before scanning the PCIe > > > > > bus. > > > > > > > > This is solving a generic problem in a specific driver. It needs to be > > > > solved for any PCI host and any device. > > > > > > Ack. I see your point here. > > > > > > As this would require porting code from powerpc/spark of-pci code and > > > changing pcie port driver to apply power supply before bus probing > > > happens, > > > I'd also ask for the comments from PCI maintainers. Will that solution be > > > acceptable to you? > > > > I can't say without seeing the code. I don't know enough about this > > scenario to envision how it might look. > > > > I guess the QCA6390 is a PCIe device? Why does it need to be powered > > up before probing? Shouldn't we get a link-up interrupt when it is > > powered up so we could probe it then? > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > parts. It has internal power regulators which once enabled will > powerup the PCIe, serial and radio parts. There is no need to manage > regulators. Once enabled they will automatically handle device > suspend/resume, etc. > So what you're saying is that if either the PCI controller or bluetooth driver probes these regulators will be turned on, indefinitely? If so, why do we need a driver to turn them on, rather than just mark them as always-on? What's the timing requirement wrt regulators vs WL_EN/BT_EN? Regards, Bjorn A > I'm not sure about link-up interrupt. I've just lightly tested using > PCIe HP on this port, getting no interrupts from it. > If I manually rescan the bus after enabling the qca6390 device (e.g. > via sysfs), it gets enabled, but then I see PCIe link errors (most > probably because the PCIe link was not retrained after the device > comes up). > > > Nit: when changing any file, please take a look at the commit history > > and make yours match, e.g., > > > > pcie-qcom: provide a way to power up qca6390 chip on RB5 platform > > > > does not look like: > > Ack. > > > -- > With best wishes > Dmitry
Re: [PATCH v2 1/6] dt-bindings: arm: qcom: Document SM8350 SoC and boards
On Wed 27 Jan 06:30 CST 2021, Vinod Koul wrote: > Document the SM8350 SoC binding and also the boards using it. > > Acked-by: Rob Herring > Signed-off-by: Vinod Koul Reviewed-by: Bjorn Andersson > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml > b/Documentation/devicetree/bindings/arm/qcom.yaml > index c97d4a580f47..8fe7e473bfdf 100644 > --- a/Documentation/devicetree/bindings/arm/qcom.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > @@ -41,6 +41,7 @@ description: | > sdm660 > sdm845 > sm8250 > +sm8350 > >The 'board' element must be one of the following strings: > > @@ -178,6 +179,11 @@ properties: >- qcom,sm8250-mtp >- const: qcom,sm8250 > > + - items: > + - enum: > + - qcom,sm8350-mtp > + - const: qcom,sm8350 > + > additionalProperties: true > > ... > -- > 2.26.2 >
Re: [PATCH 3/3] arm64: dts: qcom: msm8916-longcheer-l8910: Add imu/magnetometer
On Sun 24 Jan 13:49 CST 2021, Jonathan Albrieux wrote:
> On Sun, Jan 24, 2021 at 04:51:31PM +0100, Stephan Gerhold wrote:
> > On Sun, Jan 24, 2021 at 04:07:19PM +0100, Konrad Dybcio wrote:
> > > > +_i2c3 {
> > > > + status = "okay";
> > > > +
> > > > + imu@68 {
> > > > + compatible = "bosch,bmi160";
> > > > + reg = <0x68>;
> > > > +
> > > > + vdd-supply = <_l17>;
> > > > + vddio-supply = <_l6>;
> > > > +
> > > > + mount-matrix = "0", "1", "0",
> > > > + "-1", "0", "0",
> > > > + "0", "0", "1";
> > > > + };
> > > > +
> > > > + magnetometer@d {
> > > > + compatible = "asahi-kasei,ak09911";
> > > > + reg = <0x0d>;
> > > > +
> > > > + vdd-supply = <_l17>;
> > > > + vid-supply = <_l6>;
> > > > +
> > > > + reset-gpios = < 111 GPIO_ACTIVE_LOW>;
> > > > +
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <_reset_default>;
> > > > + };
> > > > +};
> > >
> > > Please sort I2C devices by their address.
> > >
> >
> > +1 :)
> >
> Thank you Konrad, thank you Stephan, I'll fix the order!
>
> > >
> > > > };
> > > >
> > > > + mag_reset_default: mag-reset-default {
> > > > + pins = "gpio111";
> > > > + function = "gpio";
> > > > +
> > > > + drive-strength = <2>;
> > > > + bias-disable;
> > > > + };
> > > > +
> > >
> > > Please add this after gpio110 to keep it sorted gpio-number-wise.
> > >
> >
> > This is ordered alphabetically. I haven't seen gpio-number order
> > anywhere yet... :)
> >
> Let me know if this order has to be changed, meanwhile I'll prepare
> a v2 for the i2c device order and will prepare a v3 in case this
> order too has to be changed.
>
I'm happy with having these sorted alphabetically.
Regards,
Bjorn
[PATCH] opp: Allow dev_pm_opp_set_opp() to be called without opp
a6xx_gmu_stop() calls dev_pm_opp_set_opp() with NULL as opp in order to
drop its bandwidth request, which was valid with dev_pm_opp_set_bw().
But after the transition to dev_pm_opp_set_opp() this leads to a NULL
dereference before jumping into _set_opp(), which does disable the
vote as expected.
Fixes: a0d67b94e2ef ("opp: Implement dev_pm_opp_set_opp()")
Signed-off-by: Bjorn Andersson
---
drivers/opp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 583bb1274df9..3ff05f40e443 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1157,7 +1157,7 @@ int dev_pm_opp_set_opp(struct device *dev, struct
dev_pm_opp *opp)
return PTR_ERR(opp_table);
}
- ret = _set_opp(dev, opp_table, opp, opp->rate);
+ ret = _set_opp(dev, opp_table, opp, opp ? opp->rate : 0);
dev_pm_opp_put_opp_table(opp_table);
return ret;
--
2.29.2
Re: [PATCH v2] scsi: ufs: Give clk scaling min gear a value
On Wed 27 Jan 20:49 CST 2021, Can Guo wrote:
> The initialization of clk_scaling.min_gear was removed by mistake. This
> change adds it back, otherwise clock scaling down would fail.
>
Thanks for the patch Can, it solves the problem I'm seeing!
Reviewed-by: Bjorn Andersson
Tested-by: Bjorn Andersson
And perhaps a:
Reported-by: Bjorn Andersson
Regards,
Bjorn
> Fixes: 4543d9d78227 ("scsi: ufs: Refactor
> ufshcd_init/exit_clk_scaling/gating()")
>
> Signed-off-by: Can Guo
> ---
> drivers/scsi/ufs/ufshcd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 36bcbb3..8ef6796 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1602,6 +1602,9 @@ static void ufshcd_init_clk_scaling(struct ufs_hba *hba)
> if (!ufshcd_is_clkscaling_supported(hba))
> return;
>
> + if (!hba->clk_scaling.min_gear)
> + hba->clk_scaling.min_gear = UFS_HS_G1;
> +
> INIT_WORK(>clk_scaling.suspend_work,
> ufshcd_clk_scaling_suspend_work);
> INIT_WORK(>clk_scaling.resume_work,
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project.
>
Re: [PATCH] thermal: qcom: tsens-v0_1: Add support for MDM9607
On Wed 27 Jan 12:14 CST 2021, Konrad Dybcio wrote:
> MDM9607 TSENS IP is very similar to the one of MSM8916, with
> minor adjustments to various tuning values.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/thermal/qcom-tsens.yaml | 2 +
> drivers/thermal/qcom/tsens-v0_1.c | 100 +-
> drivers/thermal/qcom/tsens.c | 3 +
> drivers/thermal/qcom/tsens.h | 2 +-
> 4 files changed, 105 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> index 95462e071ab4..8ad9dc139c23 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> @@ -22,6 +22,7 @@ properties:
>- description: v0.1 of TSENS
> items:
>- enum:
> + - qcom,mdm9607-tsens
>- qcom,msm8916-tsens
>- qcom,msm8939-tsens
>- qcom,msm8974-tsens
> @@ -94,6 +95,7 @@ allOf:
> compatible:
>contains:
> enum:
> + - qcom,mdm9607-tsens
>- qcom,msm8916-tsens
>- qcom,msm8974-tsens
>- qcom,msm8976-tsens
> diff --git a/drivers/thermal/qcom/tsens-v0_1.c
> b/drivers/thermal/qcom/tsens-v0_1.c
> index 4ffa2e2c0145..8efe925b860f 100644
> --- a/drivers/thermal/qcom/tsens-v0_1.c
> +++ b/drivers/thermal/qcom/tsens-v0_1.c
> @@ -126,6 +126,39 @@
> #define CAL_SEL_SHIFT30
> #define CAL_SEL_SHIFT_2 28
>
> +/* eeprom layout data for mdm9607 */
> +#define MDM9607_BASE0_MASK 0x00ff
> +#define MDM9607_BASE1_MASK 0x000ff000
> +#define MDM9607_BASE0_SHIFT 0
> +#define MDM9607_BASE1_SHIFT 12
> +
> +#define MDM9607_S0_P1_MASK 0x3f00
> +#define MDM9607_S1_P1_MASK 0x03f0
> +#define MDM9607_S2_P1_MASK 0x003f
> +#define MDM9607_S3_P1_MASK 0x0003f000
> +#define MDM9607_S4_P1_MASK 0x003f
> +
> +#define MDM9607_S0_P2_MASK 0x000fc000
> +#define MDM9607_S1_P2_MASK 0xfc00
> +#define MDM9607_S2_P2_MASK 0x0fc0
> +#define MDM9607_S3_P2_MASK 0x00fc
> +#define MDM9607_S4_P2_MASK 0x0fc0
> +
> +#define MDM9607_S0_P1_SHIFT 8
> +#define MDM9607_S1_P1_SHIFT 20
> +#define MDM9607_S2_P1_SHIFT 0
> +#define MDM9607_S3_P1_SHIFT 12
> +#define MDM9607_S4_P1_SHIFT 0
> +
> +#define MDM9607_S0_P2_SHIFT 14
> +#define MDM9607_S1_P2_SHIFT 26
> +#define MDM9607_S2_P2_SHIFT 6
> +#define MDM9607_S3_P2_SHIFT 18
> +#define MDM9607_S4_P2_SHIFT 6
> +
> +#define MDM9607_CAL_SEL_MASK 0x0070
> +#define MDM9607_CAL_SEL_SHIFT20
> +
> #define S0_P1_SHIFT 8
> #define S1_P1_SHIFT 14
> #define S2_P1_SHIFT 20
> @@ -452,7 +485,57 @@ static int calibrate_8974(struct tsens_priv *priv)
> return 0;
> }
>
> -/* v0.1: 8916, 8939, 8974 */
> +static int calibrate_9607(struct tsens_priv *priv)
> +{
> + int base0 = 0, base1 = 0, i;
Afaict, there's no need to initialize base0 and base1, they are both
assigned to before used.
Also, they are temporary variables within each case (even with the
fallthrough), so you should only need a single "base".
> + u32 p1[5], p2[5];
> + int mode = 0;
> + u32 *qfprom_cdata, *qfprom_csel;
> +
> + qfprom_cdata = (u32 *)qfprom_read(priv->dev, "calib");
> + if (IS_ERR(qfprom_cdata))
> + return PTR_ERR(qfprom_cdata);
> +
> + mode = (qfprom_cdata[2] & MDM9607_CAL_SEL_MASK) >>
> MDM9607_CAL_SEL_SHIFT;
How about:
mode = field_get(MDM9607_CAL_SEL_MASK, qfprom_cdata[2]);
and same below.
(I see that this would break the style of the file, perhaps we can clean
that up?)
> + dev_dbg(priv->dev, "calibration mode is %d\n", mode);
> +
> + switch (mode) {
> + case TWO_PT_CALIB:
> + base1 = (qfprom_cdata[2] & MDM9607_BASE1_MASK) >>
> MDM9607_BASE1_SHIFT;
> + p2[0] = (qfprom_cdata[0] & MDM9607_S0_P2_MASK) >>
> MDM9607_S0_P2_SHIFT;
> + p2[1] = (qfprom_cdata[0] & MDM9607_S1_P2_MASK) >>
> MDM9607_S1_P2_SHIFT;
> + p2[2] = (qfprom_cdata[1] & MDM9607_S2_P2_MASK) >>
> MDM9607_S2_P2_SHIFT;
> + p2[3] = (qfprom_cdata[1] & MDM9607_S3_P2_MASK) >>
> MDM9607_S3_P2_SHIFT;
> + p2[4] = (qfprom_cdata[2] & MDM9607_S4_P2_MASK) >>
> MDM9607_S4_P2_SHIFT;
> + for (i = 0; i < priv->num_sensors; i++)
> + p2[i] = ((base1 + p2[i]) << 2);
> + fallthrough;
> + case ONE_PT_CALIB2:
> + base0 = (qfprom_cdata[0] & MDM9607_BASE0_MASK);
> + p1[0] = (qfprom_cdata[0] & MDM9607_S0_P1_MASK) >>
> MDM9607_S0_P1_SHIFT;
> + p1[1] = (qfprom_cdata[0] & MDM9607_S1_P1_MASK) >>
> MDM9607_S1_P1_SHIFT;
> + p1[2] = (qfprom_cdata[1] & MDM9607_S2_P1_MASK) >>
> MDM9607_S2_P1_SHIFT;
> + p1[3] = (qfprom_cdata[1] &
Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
On Wed 27 Jan 09:15 CST 2021, Greg KH wrote: > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > > Hi Greg, > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > > This patch series adds support for UCI driver. UCI driver enables > > > userspace > > > clients to communicate to external MHI devices like modem. UCI driver > > > probe > > > creates standard character device file nodes for userspace clients to > > > perform open, read, write, poll and release file operations. These file > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > to communicate with MHI device. > > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > > or AT commands to userspace which can be used to configure the modem using > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This > > > is > > > required as there are no kernel APIs to access modem control path for > > > device > > > configuration. Data path transporting the network payload (IP), however, > > > is > > > routed to the Linux network via the mhi-net driver. Currently driver > > > supports > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > > service using QMI channel. Please refer to > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional > > > information > > > on libqmi. > > > > > > Patch is tested using arm64 and x86 based platform. > > > > > > > This series looks good to me and I'd like to merge it into mhi-next. You > > shared your reviews on the previous revisions, so I'd like to get your > > opinion first. > > If you get the networking people to give you an ack on this, it's fine > with me. > Why? As concluded in previous iterations of this series this does not relate to networking. Regards, Bjorn
Re: [PATCH v2 4/4] ARM: dts: qcom: pm8941: Add nodes for QCOM SPMI Flash LEDs
On Tue 26 Jan 08:06 CST 2021, N?colas F. R. A. Prado wrote:
> Add the necessary devicetree nodes for the Qualcomm SPMI Flash LEDs
> present in PM8941.
>
> Signed-off-by: NÃcolas F. R. A. Prado
> ---
> Changes in v2:
> - Moved from hammerhead dts to pm8941 dtsi, as it was this way downstream
> - Now using values from leds-qcom-spmi-flash.h
>
> arch/arm/boot/dts/qcom-pm8941.dtsi | 38 ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi
> b/arch/arm/boot/dts/qcom-pm8941.dtsi
> index c1f2012d1c8b..89309d3c777c 100644
> --- a/arch/arm/boot/dts/qcom-pm8941.dtsi
> +++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
> @@ -2,6 +2,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> _bus {
>
> @@ -189,5 +191,41 @@ pm8941_5vs2: 5vs2 {
> regulator-initial-mode = <1>;
> };
> };
> +
> + qcom,spmi-flash@d300 {
Please avoid "qcom," in the node names.
> + status = "okay";
The "default" status is "okay", so no need to specify that if you're not
disabling it. That said, there are 8974 devices without flash LED...
> +
> + compatible = "qcom,spmi-flash";
> + reg = <0xd300 0x100>;
> + flash-boost-supply = <_5vs1>;
> + torch-boost-supply = <_5v>;
> + pm8941_flash0: led0 {
> + led-sources = <0>;
> + function = LED_FUNCTION_FLASH;
> + color = ;
> + led-max-microamp = <20>;
> + flash-max-microamp = <100>;
> + flash-max-timeout-us = <128>;
> + default-state = "off";
> + qcom,clamp-curr = <20>;
> + qcom,headroom =
> ;
> + qcom,startup-dly =
> ;
> + qcom,safety-timer;
...and I would expect that at least some of these properties should be
tweaked/tuned/reviewed for each device.
So it would probably be a good idea to make the spmi-flash status
"disabled" and move some of these properties to the product .dts.
Regards,
Bjorn
> + };
> +
> + pm8941_flash1: led1 {
> + led-sources = <1>;
> + function = LED_FUNCTION_FLASH;
> + color = ;
> + led-max-microamp = <20>;
> + flash-max-microamp = <100>;
> + flash-max-timeout-us = <128>;
> + default-state = "off";
> + qcom,clamp-curr = <20>;
> + qcom,headroom =
> ;
> + qcom,startup-dly =
> ;
> + qcom,safety-timer;
> + };
> + };
> };
> };
> --
> 2.30.0
>
>
Re: [PATCH v2 3/4] ARM: qcom_defconfig: Enable QCOM SPMI Flash LEDs
On Tue 26 Jan 08:06 CST 2021, N?colas F. R. A. Prado wrote: > Enable module for the Qualcomm SPMI Flash LEDs present on the PM8941 > PMIC. > > Signed-off-by: NÃcolas F. R. A. Prado > --- > Changes in v2: > - Enabled CONFIG_LEDS_CLASS_FLASH since the driver now depends on it. > > arch/arm/configs/qcom_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig > index f6e9675f639c..05cacc59087e 100644 > --- a/arch/arm/configs/qcom_defconfig > +++ b/arch/arm/configs/qcom_defconfig > @@ -202,6 +202,7 @@ CONFIG_MMC_SDHCI_PLTFM=y > CONFIG_MMC_SDHCI_MSM=y > CONFIG_NEW_LEDS=y > CONFIG_LEDS_CLASS=y > +CONFIG_LEDS_CLASS_FLASH=y This doesn't seem critical to boot the system, can we make it =m? Regards, Bjorn > CONFIG_LEDS_GPIO=y > CONFIG_LEDS_PM8058=y > CONFIG_LEDS_TRIGGERS=y > @@ -284,3 +285,4 @@ CONFIG_DYNAMIC_DEBUG=y > CONFIG_DEBUG_INFO=y > CONFIG_MAGIC_SYSRQ=y > # CONFIG_SCHED_DEBUG is not set > +CONFIG_LEDS_QCOM_SPMI_FLASH=m > -- > 2.30.0 > >
Re: [PATCH v2 1/4] dt-bindings: leds: Add binding for qcom-spmi-flash
On Tue 26 Jan 08:04 CST 2021, N?colas F. R. A. Prado wrote:
> Add devicetree binding for QCOM SPMI Flash LEDs, which are part of
> PM8941, and are used both as lantern and camera flash.
>
> Signed-off-by: NÃcolas F. R. A. Prado
> ---
> Changes in v2:
> - Add this commit
>
> .../bindings/leds/leds-qcom-spmi-flash.yaml | 94 +++
> .../dt-bindings/leds/leds-qcom-spmi-flash.h | 15 +++
> 2 files changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/leds/leds-qcom-spmi-flash.yaml
> create mode 100644 include/dt-bindings/leds/leds-qcom-spmi-flash.h
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-spmi-flash.yaml
> b/Documentation/devicetree/bindings/leds/leds-qcom-spmi-flash.yaml
> new file mode 100644
> index ..169716e14f67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-qcom-spmi-flash.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-qcom-spmi-flash.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SPMI Flash LEDs
> +
> +maintainers:
> + - NÃcolas F. R. A. Prado
> +
> +description: |
> + The Qualcomm SPMI Flash LEDs are part of Qualcomm PMICs and are used
> primarily
> + as a camera or video flash. They can also be used as a lantern when on
> torch
> + mode.
> + The PMIC is connected to Host processor via SPMI bus.
> +
> +properties:
> + compatible:
> +const: qcom,spmi-flash
> +
> + reg:
> +maxItems: 1
> +
> + flash-boost-supply:
> +description: SMBB regulator for LED flash mode
> +
> + torch-boost-supply:
> +description: SMBB regulator for LED torch mode
> +
> +patternProperties:
> + "^led[0-1]$":
> +type: object
> +$ref: common.yaml#
> +
> +properties:
> + qcom,clamp-curr:
> +description: current to clamp at, in uA
> +$ref: /schemas/types.yaml#definitions/uint32
> +
> + qcom,headroom:
> +description: |
> + headroom to use. Use one of QCOM_SPMI_FLASH_HEADROOM_* defined in
> + include/dt-bindings/leds/leds-qcom-spmi-flash.h
Please make the unit of this property millivolts, instead of describing
it indirectly using the defines in the header file.
> +$ref: /schemas/types.yaml#definitions/uint32
> +minimum: 0
> +maximum: 3
And you can then list out the valid values here.
> +
> + qcom,startup-dly:
> +description: |
> + delay before flashing. Use one of QCOM_SPMI_FLASH_STARTUP_DLY_*
> + defined in include/dt-bindings/leds/leds-qcom-spmi-flash.h
As above, please describe this in microseconds.
> +$ref: /schemas/types.yaml#definitions/uint32
> +minimum: 0
> +maximum: 3
> +
> + qcom,safety-timer:
> +description: include for safety timer use, otherwise watchdog timer
> will be used
> +type: boolean
> +
> +required:
> + - compatible
> + - reg
> + - flash-boost-supply
> + - torch-boost-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +qcom,leds@d300 {
Please no "qcom," in the node name.
Regards,
Bjorn
> +compatible = "qcom,spmi-flash";
> +reg = <0xd300 0x100>;
> +flash-boost-supply = <_5vs1>;
> +torch-boost-supply = <_5v>;
> +
> +led0 {
> +led-sources = <0>;
> +function = LED_FUNCTION_FLASH;
> +color = ;
> +led-max-microamp = <20>;
> +flash-max-microamp = <100>;
> +flash-max-timeout-us = <128>;
> +default-state = "off";
> +qcom,clamp-curr = <20>;
> +qcom,headroom = ;
> +qcom,startup-dly = ;
> +qcom,safety-timer;
> +};
> +};
> +...
> diff --git a/include/dt-bindings/leds/leds-qcom-spmi-flash.h
> b/include/dt-bindings/leds/leds-qcom-spmi-flash.h
> new file mode 100644
> index ..8bd54a8e831d
> --- /dev/null
> +++ b/include/dt-bindings/leds/leds-qcom-spmi-flash.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _DT_BINDINGS_LEDS_QCOM_SPMI_FLASH_H
> +#define _DT_BINDINGS_LEDS_QCOM_SPMI_FLASH_H
> +
> +#define QCOM_SPMI_FLASH_HEADROOM_250MV 0
> +#define QCOM_SPMI_FLASH_HEADROOM_300MV 1
> +#define QCOM_SPMI_FLASH_HEADROOM_400MV 2
> +#define QCOM_SPMI_FLASH_HEADROOM_500MV 3
> +
> +#define QCOM_SPMI_FLASH_STARTUP_DLY_10US 0
> +#define QCOM_SPMI_FLASH_STARTUP_DLY_32US 1
> +#define QCOM_SPMI_FLASH_STARTUP_DLY_64US 2
> +#define QCOM_SPMI_FLASH_STARTUP_DLY_128US3
> +
> +#endif
> --
> 2.30.0
>
>
Re: [PATCH] venus: core: Parse firmware-name DT property
On Tue 26 Jan 02:42 CST 2021, Stanimir Varbanov wrote:
> On production devices the firmware could be located on different
> places, this path could be provided by special firmware-name DT
> property.
>
> Here we check for existence of such DT property and if it exist
> take the firmware path from there. Otherwise, if the property
> is missing we fallback to the predefined path from driver resource
> structure.
>
Reviewed-by: Bjorn Andersson
But firmware-name is not mentioned in the dt binding.
Regards,
Bjorn
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/firmware.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/firmware.c
> b/drivers/media/platform/qcom/venus/firmware.c
> index d03e2dd5808c..56c8fb5a019b 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -187,6 +187,7 @@ int venus_boot(struct venus_core *core)
> {
> struct device *dev = core->dev;
> const struct venus_resources *res = core->res;
> + const char *fwpath = NULL;
> phys_addr_t mem_phys;
> size_t mem_size;
> int ret;
> @@ -195,7 +196,12 @@ int venus_boot(struct venus_core *core)
> (core->use_tz && !qcom_scm_is_available()))
> return -EPROBE_DEFER;
>
> - ret = venus_load_fw(core, core->res->fwname, _phys, _size);
> + ret = of_property_read_string_index(dev->of_node, "firmware-name", 0,
> + );
> + if (ret)
> + fwpath = core->res->fwname;
> +
> + ret = venus_load_fw(core, fwpath, _phys, _size);
> if (ret) {
> dev_err(dev, "fail to load video firmware\n");
> return -EINVAL;
> --
> 2.25.1
>
Re: [PATCH v2] dma: qcom: bam_dma: Manage clocks when controlled_remotely is set
On Tue 26 Jan 15:18 CST 2021, Thara Gopinath wrote:
> When bam dma is "controlled remotely", thus far clocks were not controlled
> from the Linux. In this scenario, Linux was disabling runtime pm in bam dma
> driver and not doing any clock management in suspend/resume hooks.
>
> With introduction of crypto engine bam dma, the clock is a rpmh resource
> that can be controlled from both Linux and TZ/remote side. Now bam dma
> clock is getting enabled during probe even though the bam dma can be
> "controlled remotely". But due to clocks not being handled properly,
> bam_suspend generates a unbalanced clk_unprepare warning during system
> suspend.
>
> To fix the above issue and to enable proper clock-management, this patch
> enables runtim-pm and handles bam dma clocks in suspend/resume hooks if
> the clock node is present irrespective of controlled_remotely property.
>
> Signed-off-by: Thara Gopinath
Reviewed-by: Bjorn Andersson
And from John on IRC:
Tested-by: John Stultz
Regards,
Bjorn
> ---
>
> v1->v2:
> - As per Shawn's suggestion, use devm_clk_get_optional to get the
> bam clock if the "controlled_remotely" property is set so that
> the clock code takes care of setting the bam clock to NULL if
> not specified by dt.
> - Remove the check for "controlled_remotely" property in
> bam_dma_resume now that clock enable / disable is based on
> whether bamclk is NULL or not.
> - Rebased to v5.11-rc5
>
> drivers/dma/qcom/bam_dma.c | 29 +++--
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 88579857ca1d..c8a77b428b52 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1270,13 +1270,13 @@ static int bam_dma_probe(struct platform_device *pdev)
> dev_err(bdev->dev, "num-ees unspecified in dt\n");
> }
>
> - bdev->bamclk = devm_clk_get(bdev->dev, "bam_clk");
> - if (IS_ERR(bdev->bamclk)) {
> - if (!bdev->controlled_remotely)
> - return PTR_ERR(bdev->bamclk);
> + if (bdev->controlled_remotely)
> + bdev->bamclk = devm_clk_get_optional(bdev->dev, "bam_clk");
> + else
> + bdev->bamclk = devm_clk_get(bdev->dev, "bam_clk");
>
> - bdev->bamclk = NULL;
> - }
> + if (IS_ERR(bdev->bamclk))
> + return PTR_ERR(bdev->bamclk);
>
> ret = clk_prepare_enable(bdev->bamclk);
> if (ret) {
> @@ -1350,7 +1350,7 @@ static int bam_dma_probe(struct platform_device *pdev)
> if (ret)
> goto err_unregister_dma;
>
> - if (bdev->controlled_remotely) {
> + if (!bdev->bamclk) {
> pm_runtime_disable(>dev);
> return 0;
> }
> @@ -1438,10 +1438,10 @@ static int __maybe_unused bam_dma_suspend(struct
> device *dev)
> {
> struct bam_device *bdev = dev_get_drvdata(dev);
>
> - if (!bdev->controlled_remotely)
> + if (bdev->bamclk) {
> pm_runtime_force_suspend(dev);
> -
> - clk_unprepare(bdev->bamclk);
> + clk_unprepare(bdev->bamclk);
> + }
>
> return 0;
> }
> @@ -1451,12 +1451,13 @@ static int __maybe_unused bam_dma_resume(struct
> device *dev)
> struct bam_device *bdev = dev_get_drvdata(dev);
> int ret;
>
> - ret = clk_prepare(bdev->bamclk);
> - if (ret)
> - return ret;
> + if (bdev->bamclk) {
> + ret = clk_prepare(bdev->bamclk);
> + if (ret)
> + return ret;
>
> - if (!bdev->controlled_remotely)
> pm_runtime_force_resume(dev);
> + }
>
> return 0;
> }
> --
> 2.25.1
>
Re: [PATCH v2 2/4] leds: Add driver for QCOM SPMI Flash LEDs
On Tue 26 Jan 08:05 CST 2021, N?colas F. R. A. Prado wrote: > Add driver for the Qualcomm SPMI Flash LEDs. These are controlled > through an SPMI bus and are part of the PM8941 PMIC. There are two LEDs > present in the chip, and can be used independently as camera flash or > together in torch mode to act as a lantern. > > Signed-off-by: NÃcolas F. R. A. Prado > --- > Changes in v2: > - Thanks to Jacek: > - Implemented flash LED class framework > - Thanks to Bjorn: > - Renamed driver to "qcom spmi flash" > - Refactored code > - Added missing copyright > > drivers/leds/Kconfig|8 + > drivers/leds/Makefile |1 + > drivers/leds/leds-qcom-spmi-flash.c | 1153 +++ > 3 files changed, 1162 insertions(+) > create mode 100644 drivers/leds/leds-qcom-spmi-flash.c > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > index 849d3c5f908e..ad1c7846f9b3 100644 > --- a/drivers/leds/Kconfig > +++ b/drivers/leds/Kconfig > @@ -928,6 +928,14 @@ config LEDS_ACER_A500 > This option enables support for the Power Button LED of > Acer Iconia Tab A500. > > +config LEDS_QCOM_SPMI_FLASH > + tristate "Support for QCOM SPMI Flash LEDs" > + depends on SPMI > + depends on LEDS_CLASS_FLASH depends on OF? > + help > + This driver supports the Flash/Torch LED present in Qualcomm's PM8941 > + PMIC. > + > comment "LED Triggers" > source "drivers/leds/trigger/Kconfig" > > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile > index 73e603e1727e..e86bcfba016b 100644 > --- a/drivers/leds/Makefile > +++ b/drivers/leds/Makefile > @@ -93,6 +93,7 @@ obj-$(CONFIG_LEDS_TURRIS_OMNIA) += > leds-turris-omnia.o > obj-$(CONFIG_LEDS_WM831X_STATUS) += leds-wm831x-status.o > obj-$(CONFIG_LEDS_WM8350)+= leds-wm8350.o > obj-$(CONFIG_LEDS_WRAP) += leds-wrap.o > +obj-$(CONFIG_LEDS_QCOM_SPMI_FLASH) += leds-qcom-spmi-flash.o > > # LED SPI Drivers > obj-$(CONFIG_LEDS_CR0014114) += leds-cr0014114.o > diff --git a/drivers/leds/leds-qcom-spmi-flash.c > b/drivers/leds/leds-qcom-spmi-flash.c > new file mode 100644 > index ..023fc107abce > --- /dev/null > +++ b/drivers/leds/leds-qcom-spmi-flash.c > @@ -0,0 +1,1153 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Qualcomm SPMI Flash Driver > + * > + * Copyright (c) 2020, NÃcolas F. R. A. Prado > + * > + * Based on QPNP LEDs driver from downstream MSM kernel sources. > + * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define FLASH_SAFETY_TIMER 0x40 > +#define FLASH_MAX_CURR 0x41 > +#define FLASH_LED_0_CURR 0x42 > +#define FLASH_LED_1_CURR 0x43 > +#define FLASH_CLAMP_CURR 0x44 > +#define FLASH_LED_TMR_CTRL 0x48 > +#define FLASH_HEADROOM 0x4A > +#define FLASH_STARTUP_DELAY 0x4B > +#define FLASH_MASK_ENABLE0x4C > +#define FLASH_VREG_OK_FORCE 0x4F > +#define FLASH_ENABLE_CONTROL 0x46 > +#define FLASH_LED_STROBE_CTRL0x47 > +#define FLASH_LED_UNLOCK_SECURE 0xD0 > +#define FLASH_LED_TORCH 0xE4 > +#define FLASH_FAULT_DETECT 0x51 > +#define FLASH_RAMP_RATE 0x54 > +#define FLASH_PERIPHERAL_SUBTYPE 0x05 > +#define FLASH_VPH_PWR_DROOP 0x5A > + > +#define FLASH_MAX_LEVEL 0x4F > +#define TORCH_MAX_LEVEL 0x0F > +#define FLASH_NO_MASK 0x00 > + > +#define FLASH_MASK_1 0x20 > +#define FLASH_MASK_REG_MASK 0xE0 > +#define FLASH_HEADROOM_MASK 0x03 > +#define FLASH_SAFETY_TIMER_MASK 0x7F > +#define FLASH_CURRENT_MASK 0xFF > +#define FLASH_MAX_CURRENT_MASK 0x7F > +#define FLASH_TMR_MASK 0x03 > +#define FLASH_TMR_WATCHDOG 0x03 > +#define FLASH_TMR_SAFETY 0x00 > +#define FLASH_FAULT_DETECT_MASK 0X80 > +#define FLASH_HW_VREG_OK 0x40 > +#define FLASH_VREG_MASK 0xC0 > +#define FLASH_STARTUP_DLY_MASK 0x02 > +#define FLASH_RAMP_RATE_MASK 0xBF > +#define FLASH_VPH_PWR_DROOP_MASK 0xF3 > + > +#define FLASH_ENABLE_ALL 0xE0 > +#define FLASH_ENABLE_MODULE 0x80 > +#define FLASH_ENABLE_MODULE_MASK 0x80 > +#define FLASH_DISABLE_ALL0x00 > +#define FLASH_ENABLE_MASK0xE0 > +#define FLASH_ENABLE_LED_0 0xC0 > +#define FLASH_ENABLE_LED_1 0xA0 > +#define FLASH_INIT_MASK 0xE0 > +#define FLASH_SELFCHECK_ENABLE 0x80 > +#define FLASH_SELFCHECK_DISABLE
Re: Preemptible idr_alloc() in QRTR code
On Tue 26 Jan 10:21 CST 2021, Mark Rutland wrote: > On Tue, Jan 26, 2021 at 02:58:33PM +, Matthew Wilcox wrote: > > On Tue, Jan 26, 2021 at 10:47:34AM +, Mark Rutland wrote: > > > Hi, > > > > > > When fuzzing arm64 with Syzkaller, I'm seeing some splats where > > > this_cpu_ptr() is used in the bowels of idr_alloc(), by way of > > > radix_tree_node_alloc(), in a preemptible context: > > > > I sent a patch to fix this last June. The maintainer seems to be > > under the impression that I care an awful lot more about their > > code than I do. > > > > https://lore.kernel.org/netdev/20200605120037.17427-1-wi...@infradead.org/ > > Ah; I hadn't spotted the (glaringly obvious) GFP_ATOMIC abuse, thanks > for the pointer, and sorry for the noise. > I'm afraid this isn't as obvious to me as it is to you. Are you saying that one must not use GFP_ATOMIC in non-atomic contexts? That said, glancing at the code I'm puzzled to why it would use GFP_ATOMIC. > It looks like Eric was after a fix that trivially backported to v4.7 > (and hence couldn't rely on xarray) but instead it just got left broken > for months. :/ > > Bjorn, is this something you care about? You seem to have the most > commits to the file, and otherwise the official maintainer is Dave > Miller per get_maintainer.pl. > I certainly care about qrtr working and remember glancing at Matthew's patch, but seems like I never found time to properly review it. > It is very tempting to make the config option depend on BROKEN... > I hear you and that would be bad, so I'll make sure to take a proper look at this and Matthew's patch. Thanks, Bjorn
Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
On Mon 25 Jan 22:32 CST 2021, Wesley Cheng wrote: > On 1/25/2021 5:55 PM, Bjorn Andersson wrote: > > On Mon 25 Jan 19:14 CST 2021, Wesley Cheng wrote: > > > >> > >> > >> On 1/22/2021 9:12 AM, Bjorn Andersson wrote: > >>> On Thu 21 Jan 22:01 CST 2021, Wesley Cheng wrote: > >>> > >> > >> Hi Bjorn, > >>> > >>> Under what circumstances should we specify this? And in particular are > >>> there scenarios (in the Qualcomm platforms) where this must not be set? > >>> The TXFIFO dynamic allocation is actually a feature within the DWC3 > >> controller, and isn't specifically for QCOM based platforms. It won't > >> do any harm functionally if this flag is not set, as this is meant for > >> enhancing performance/bandwidth. > >> > >>> In particular, the composition can be changed in runtime, so should we > >>> set this for all Qualcomm platforms? > >>> > >> Ideally yes, if we want to increase bandwith for situations where SS > >> endpoint bursting is set to a higher value. > >> > >>> And if that's the case, can we not just set it from the qcom driver? > >>> > >> Since this is a common DWC3 core feature, I think it would make more > >> sense to have it in DWC3 core instead of a vendor's DWC3 glue driver. > >> > > > > I don't have any objections to implementing it in the core driver, but > > my question is can we just skip the DT binding and just enable it from > > the vendor driver? > > > > Regards, > > Bjorn > > > > Hi Bjorn, > > I see. I think there are some designs which don't have a DWC3 glue > driver, so assuming there may be other platforms using this, there may > not always be a vendor driver to set this. > You mean that there are implementations of dwc3 without an associated glue driver that haven't yet realized that they need this feature? I would suggest then that we implement the core code necessary, we enable it from the Qualcomm glue layer and when someone realize that they need this without a glue driver it's going to be trivial to add the DT binding. The alternative is that we're lugging around a requirement to specify this property in all past, present and future Qualcomm dts files - and then we'll need to hard code it for ACPI anyways. Regards, Bjorn
Re: [PATCH 3/4] phy: qcom-qmp: Add UFS v4 registers found in SM8350
On Mon 25 Jan 04:09 CST 2021, Vinod Koul wrote: > Add the registers for few new registers found in SM8350. Also the UFS > phy used in SM8350 seems to have different offsets than V4 phy, although > it claims it is v4 phy, so add the new offsets with SM8350 tag instead > of V4 tag. > Reviewed-by: Bjorn Andersson > Signed-off-by: Vinod Koul > --- > drivers/phy/qualcomm/phy-qcom-qmp.h | 27 +++ > 1 file changed, 27 insertions(+) > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h > b/drivers/phy/qualcomm/phy-qcom-qmp.h > index dff7be5a1cc1..bba1d5e3eb73 100644 > --- a/drivers/phy/qualcomm/phy-qcom-qmp.h > +++ b/drivers/phy/qualcomm/phy-qcom-qmp.h > @@ -451,6 +451,7 @@ > #define QSERDES_V4_TX_RES_CODE_LANE_OFFSET_RX0x40 > #define QSERDES_V4_TX_LANE_MODE_10x84 > #define QSERDES_V4_TX_LANE_MODE_20x88 > +#define QSERDES_V4_TX_LANE_MODE_30x8C > #define QSERDES_V4_TX_RCV_DETECT_LVL_2 0x9c > #define QSERDES_V4_TX_PWM_GEAR_1_DIVIDER_BAND0_1 0xd8 > #define QSERDES_V4_TX_PWM_GEAR_2_DIVIDER_BAND0_1 0xdC > @@ -459,6 +460,13 @@ > #define QSERDES_V4_TX_TRAN_DRVR_EMP_EN 0xb8 > #define QSERDES_V4_TX_PI_QEC_CTRL0x104 > > +/* Only for SM8350 QMP V4 Phy TX offsets different from V4 */ > +#define QSERDES_SM8350_TX_PWM_GEAR_1_DIVIDER_BAND0_1 0x178 > +#define QSERDES_SM8350_TX_PWM_GEAR_2_DIVIDER_BAND0_1 0x17c > +#define QSERDES_SM8350_TX_PWM_GEAR_3_DIVIDER_BAND0_1 0x180 > +#define QSERDES_SM8350_TX_PWM_GEAR_4_DIVIDER_BAND0_1 0x184 > +#define QSERDES_SM8350_TX_TRAN_DRVR_EMP_EN 0xc0 > + > /* Only for QMP V4 PHY - RX registers */ > #define QSERDES_V4_RX_UCDR_FO_GAIN 0x008 > #define QSERDES_V4_RX_UCDR_SO_GAIN 0x014 > @@ -514,6 +522,24 @@ > #define QSERDES_V4_RX_DCC_CTRL1 0x1bc > #define QSERDES_V4_RX_VTH_CODE 0x1c4 > > +/* Only for SM8350 QMP V4 Phy RX offsets different from V4 */ > +#define QSERDES_SM8350_RX_RX_MODE_00_LOW 0x15c > +#define QSERDES_SM8350_RX_RX_MODE_00_HIGH0x160 > +#define QSERDES_SM8350_RX_RX_MODE_00_HIGH2 0x164 > +#define QSERDES_SM8350_RX_RX_MODE_00_HIGH3 0x168 > +#define QSERDES_SM8350_RX_RX_MODE_00_HIGH4 0x16c > +#define QSERDES_SM8350_RX_RX_MODE_01_LOW 0x170 > +#define QSERDES_SM8350_RX_RX_MODE_01_HIGH0x174 > +#define QSERDES_SM8350_RX_RX_MODE_01_HIGH2 0x178 > +#define QSERDES_SM8350_RX_RX_MODE_01_HIGH3 0x17c > +#define QSERDES_SM8350_RX_RX_MODE_01_HIGH4 0x180 > +#define QSERDES_SM8350_RX_RX_MODE_10_LOW 0x184 > +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH0x188 > +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH2 0x18c > +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH3 0x190 > +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH4 0x194 > +#define QSERDES_SM8350_RX_DCC_CTRL1 0x1a8 > + > /* Only for QMP V4 PHY - UFS PCS registers */ > #define QPHY_V4_PCS_UFS_PHY_START0x000 > #define QPHY_V4_PCS_UFS_POWER_DOWN_CONTROL 0x004 > @@ -529,6 +555,7 @@ > #define QPHY_V4_PCS_UFS_DEBUG_BUS_CLKSEL 0x124 > #define QPHY_V4_PCS_UFS_LINECFG_DISABLE 0x148 > #define QPHY_V4_PCS_UFS_RX_MIN_HIBERN8_TIME 0x150 > +#define QPHY_V4_PCS_UFS_RX_SIGDET_CTRL1 0x154 > #define QPHY_V4_PCS_UFS_RX_SIGDET_CTRL2 0x158 > #define QPHY_V4_PCS_UFS_TX_PWM_GEAR_BAND 0x160 > #define QPHY_V4_PCS_UFS_TX_HS_GEAR_BAND 0x168 > -- > 2.26.2 >
Re: [PATCH v2 6/9] clk: qcom: mmcc-msm8996: Migrate gfx3d clock to clk_rcg2_gfx3d
On Wed 13 Jan 12:38 CST 2021, AngeloGioacchino Del Regno wrote:
> In commit 734bdefdb043 ("clk: qcom: rcg2: Stop hardcoding gfx3d
> pingpong parent numbers") the gfx3d ping-pong ops (clk_gfx3d_ops)
I believe you're referring to patch 5 here, which when merged won't have
this hash. So you'd need to say "in the previous commit (...)" or
something like that.
Regards,
Bjorn
> were generalized in order to be able to reuse the same ops for
> more than just one clock for one SoC: follow the change here in
> the MSM8996 MMCC.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> drivers/clk/qcom/mmcc-msm8996.c | 29 ++---
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
> index 3b3aac07fb2d..24843e4f2599 100644
> --- a/drivers/clk/qcom/mmcc-msm8996.c
> +++ b/drivers/clk/qcom/mmcc-msm8996.c
> @@ -528,16 +528,23 @@ static struct clk_rcg2 maxi_clk_src = {
> },
> };
>
> -static struct clk_rcg2 gfx3d_clk_src = {
> - .cmd_rcgr = 0x4000,
> - .hid_width = 5,
> - .parent_map = mmss_xo_mmpll0_mmpll9_mmpll2_mmpll8_gpll0_map,
> - .clkr.hw.init = &(struct clk_init_data){
> - .name = "gfx3d_clk_src",
> - .parent_names = mmss_xo_mmpll0_mmpll9_mmpll2_mmpll8_gpll0,
> - .num_parents = 6,
> - .ops = _gfx3d_ops,
> - .flags = CLK_SET_RATE_PARENT,
> +static struct clk_rcg2_gfx3d gfx3d_clk_src = {
> + .rcg = {
> + .cmd_rcgr = 0x4000,
> + .hid_width = 5,
> + .parent_map = mmss_xo_mmpll0_mmpll9_mmpll2_mmpll8_gpll0_map,
> + .clkr.hw.init = &(struct clk_init_data){
> + .name = "gfx3d_clk_src",
> + .parent_names =
> mmss_xo_mmpll0_mmpll9_mmpll2_mmpll8_gpll0,
> + .num_parents = 6,
> + .ops = _gfx3d_ops,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> + },
> + .hws = (struct clk_hw*[]) {
> + ,
> + ,
> +
> },
> };
>
> @@ -3089,7 +3096,7 @@ static struct clk_regmap *mmcc_msm8996_clocks[] = {
> [AHB_CLK_SRC] = _clk_src.clkr,
> [AXI_CLK_SRC] = _clk_src.clkr,
> [MAXI_CLK_SRC] = _clk_src.clkr,
> - [GFX3D_CLK_SRC] = _clk_src.clkr,
> + [GFX3D_CLK_SRC] = _clk_src.rcg.clkr,
> [RBBMTIMER_CLK_SRC] = _clk_src.clkr,
> [ISENSE_CLK_SRC] = _clk_src.clkr,
> [RBCPR_CLK_SRC] = _clk_src.clkr,
> --
> 2.29.2
>
Re: [PATCH v4 4/5] dt-bindings: clock: Add SM8350 GCC clock bindings
On Tue 26 Jan 02:00 CST 2021, Vinod Koul wrote: > On 25-01-21, 11:25, Bjorn Andersson wrote: > > On Sun 17 Jan 22:43 CST 2021, Vinod Koul wrote: > > > > > Add device tree bindings for global clock controller on SM8350 SoCs. > > > > > > Reviewed-by: Rob Herring > > > Signed-off-by: Vinod Koul > > > --- > > > .../bindings/clock/qcom,gcc-sm8350.yaml | 96 +++ > > > include/dt-bindings/clock/qcom,gcc-sm8350.h | 261 ++ > > > 2 files changed, 357 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml > > > create mode 100644 include/dt-bindings/clock/qcom,gcc-sm8350.h > > > > > > diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml > > > b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml > > > new file mode 100644 > > > index ..78f35832aa41 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml > > > @@ -0,0 +1,96 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8350.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Qualcomm Global Clock & Reset Controller Binding for SM8350 > > > + > > > +maintainers: > > > + - Vinod Koul > > > + > > > +description: | > > > + Qualcomm global clock control module which supports the clocks, resets > > > and > > > + power domains on SM8350. > > > + > > > + See also: > > > + - dt-bindings/clock/qcom,gcc-sm8350.h > > > + > > > +properties: > > > + compatible: > > > +const: qcom,gcc-sm8350 > > > + > > > + clocks: > > > +items: > > > + - description: Board XO source > > > + - description: Sleep clock source > > > + - description: PLL test clock source (Optional clock) > > > + - description: PCIE 0 Pipe clock source (Optional clock) > > > + - description: PCIE 1 Pipe clock source (Optional clock) > > > + - description: UFS card Rx symbol 0 clock source (Optional clock) > > > + - description: UFS card Rx symbol 1 clock source (Optional clock) > > > + - description: UFS card Tx symbol 0 clock source (Optional clock) > > > + - description: UFS phy Rx symbol 0 clock source (Optional clock) > > > + - description: UFS phy Rx symbol 1 clock source (Optional clock) > > > + - description: UFS phy Tx symbol 0 clock source (Optional clock) > > > + - description: USB3 phy wrapper pipe clock source (Optional clock) > > > + - description: USB3 phy sec pipe clock source (Optional clock) > > > +minItems: 2 > > > +maxItems: 13 > > > + > > > + clock-names: > > > +items: > > > + - const: bi_tcxo > > > + - const: sleep_clk > > > + - const: core_bi_pll_test_se # Optional clock > > > + - const: pcie_0_pipe_clk # Optional clock > > > + - const: pcie_1_pipe_clk # Optional clock > > > + - const: ufs_card_rx_symbol_0_clk # Optional clock > > > + - const: ufs_card_rx_symbol_1_clk # Optional clock > > > + - const: ufs_card_tx_symbol_0_clk # Optional clock > > > + - const: ufs_phy_rx_symbol_0_clk # Optional clock > > > + - const: ufs_phy_rx_symbol_1_clk # Optional clock > > > + - const: ufs_phy_tx_symbol_0_clk # Optional clock > > > + - const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock > > > + - const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock > > > +minItems: 2 > > > +maxItems: 13 > > > + > > > + '#clock-cells': > > > +const: 1 > > > + > > > + '#reset-cells': > > > +const: 1 > > > + > > > + '#power-domain-cells': > > > +const: 1 > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > +required: > > > + - compatible > > > + - clocks > > > + - clock-names > > > + - reg > > > + - '#clock-cells' > > > + - '#reset-cells' > > > + - '#power-domain-cells' > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - | > > > +#include
Re: [PATCH] media: firmware: qcom_scm: Simplify the calculation of variables
On Tue 26 Jan 02:52 CST 2021, Jiapeng Zhong wrote:
> Fix the following coccicheck warnings:
>
> ./drivers/firmware/qcom_scm.c:324:20-22: WARNING !A || A && B is
> equivalent to !A || B.
>
Reviewed-by: Bjorn Andersson
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Zhong
> ---
> drivers/firmware/qcom_scm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 7be48c1..c530072 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -321,7 +321,7 @@ int qcom_scm_set_cold_boot_addr(void *entry, const
> cpumask_t *cpus)
> .owner = ARM_SMCCC_OWNER_SIP,
> };
>
> - if (!cpus || (cpus && cpumask_empty(cpus)))
> + if (!cpus || cpumask_empty(cpus))
> return -EINVAL;
>
> for_each_cpu(cpu, cpus) {
> --
> 1.8.3.1
>
Re: [PATCH 18/21] clk: qcom: clk-rpm: Remove a bunch of superfluous code
On Tue 26 Jan 06:45 CST 2021, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/clk/qcom/clk-rpm.c:453:29: warning: ‘clk_rpm_branch_ops’ defined but
> not used [-Wunused-const-variable=]
>
> Cc: Andy Gross
> Cc: Bjorn Andersson
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
Reviewed-by: Bjorn Andersson
> Signed-off-by: Lee Jones
> ---
> drivers/clk/qcom/clk-rpm.c | 63 --
> 1 file changed, 63 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-rpm.c b/drivers/clk/qcom/clk-rpm.c
> index f71d228fd6bd5..a18811c380187 100644
> --- a/drivers/clk/qcom/clk-rpm.c
> +++ b/drivers/clk/qcom/clk-rpm.c
> @@ -73,62 +73,6 @@
> },\
> }
>
> -#define DEFINE_CLK_RPM_PXO_BRANCH(_platform, _name, _active, r_id, r)
> \
> - static struct clk_rpm _platform##_##_active; \
> - static struct clk_rpm _platform##_##_name = { \
> - .rpm_clk_id = (r_id), \
> - .active_only = true, \
> - .peer = &_platform##_##_active, \
> - .rate = (r), \
> - .branch = true, \
> - .hw.init = &(struct clk_init_data){ \
> - .ops = _rpm_branch_ops, \
> - .name = #_name, \
> - .parent_names = (const char *[]){ "pxo_board" }, \
> - .num_parents = 1, \
> - },\
> - };\
> - static struct clk_rpm _platform##_##_active = { \
> - .rpm_clk_id = (r_id), \
> - .peer = &_platform##_##_name, \
> - .rate = (r), \
> - .branch = true, \
> - .hw.init = &(struct clk_init_data){ \
> - .ops = _rpm_branch_ops, \
> - .name = #_active, \
> - .parent_names = (const char *[]){ "pxo_board" }, \
> - .num_parents = 1, \
> - },\
> - }
> -
> -#define DEFINE_CLK_RPM_CXO_BRANCH(_platform, _name, _active, r_id, r)
> \
> - static struct clk_rpm _platform##_##_active; \
> - static struct clk_rpm _platform##_##_name = { \
> - .rpm_clk_id = (r_id), \
> - .peer = &_platform##_##_active, \
> - .rate = (r), \
> - .branch = true, \
> - .hw.init = &(struct clk_init_data){ \
> - .ops = _rpm_branch_ops, \
> - .name = #_name, \
> - .parent_names = (const char *[]){ "cxo_board" }, \
> - .num_parents = 1, \
> - },\
> - };\
> - static struct clk_rpm _platform##_##_active = { \
> - .rpm_clk_id = (r_id), \
> - .active_only = true, \
> - .peer = &_platform##_##_name, \
> - .rate = (r), \
> - .branch = true, \
> - .hw.init = &(struct clk_init_data){
Re: [PATCH 16/21] clk: qcom: mmcc-msm8974: Remove unused static const tables 'mmcc_xo_mmpll0_1_2_gpll0{map}'
On Tue 26 Jan 06:45 CST 2021, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/clk/qcom/mmcc-msm8974.c:85:27: warning: ‘mmcc_xo_mmpll0_1_2_gpll0’
> defined but not used [-Wunused-const-variable=]
> drivers/clk/qcom/mmcc-msm8974.c:77:32: warning:
> ‘mmcc_xo_mmpll0_1_2_gpll0_map’ defined but not used [-Wunused-const-variable=]
>
> Cc: Andy Gross
> Cc: Bjorn Andersson
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
Reviewed-by: Bjorn Andersson
> Signed-off-by: Lee Jones
> ---
> drivers/clk/qcom/mmcc-msm8974.c | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
> index 015426262d080..a1552b6771bc6 100644
> --- a/drivers/clk/qcom/mmcc-msm8974.c
> +++ b/drivers/clk/qcom/mmcc-msm8974.c
> @@ -74,22 +74,6 @@ static const char * const mmcc_xo_mmpll0_dsi_hdmi_gpll0[]
> = {
> "dsi1pll",
> };
>
> -static const struct parent_map mmcc_xo_mmpll0_1_2_gpll0_map[] = {
> - { P_XO, 0 },
> - { P_MMPLL0, 1 },
> - { P_MMPLL1, 2 },
> - { P_GPLL0, 5 },
> - { P_MMPLL2, 3 }
> -};
> -
> -static const char * const mmcc_xo_mmpll0_1_2_gpll0[] = {
> - "xo",
> - "mmpll0_vote",
> - "mmpll1_vote",
> - "mmss_gpll0_vote",
> - "mmpll2",
> -};
> -
> static const struct parent_map mmcc_xo_mmpll0_1_3_gpll0_map[] = {
> { P_XO, 0 },
> { P_MMPLL0, 1 },
> --
> 2.25.1
>
Re: [PATCH 13/21] clk: qcom: gcc-ipq4019: Remove unused variable 'ret'
On Tue 26 Jan 06:45 CST 2021, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/clk/qcom/gcc-ipq4019.c: In function ‘clk_cpu_div_set_rate’: > drivers/clk/qcom/gcc-ipq4019.c:1279:6: warning: variable ‘ret’ set but not > used [-Wunused-but-set-variable] > > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-arm-...@vger.kernel.org > Cc: linux-...@vger.kernel.org Reviewed-by: Bjorn Andersson > Signed-off-by: Lee Jones > --- > drivers/clk/qcom/gcc-ipq4019.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c > index ef5137fd50f3f..8abad4032de71 100644 > --- a/drivers/clk/qcom/gcc-ipq4019.c > +++ b/drivers/clk/qcom/gcc-ipq4019.c > @@ -1276,16 +1276,15 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, > unsigned long rate, > struct clk_fepll *pll = to_clk_fepll(hw); > const struct freq_tbl *f; > u32 mask; > - int ret; > > f = qcom_find_freq(pll->freq_tbl, rate); > if (!f) > return -EINVAL; > > mask = (BIT(pll->cdiv.width) - 1) << pll->cdiv.shift; > - ret = regmap_update_bits(pll->cdiv.clkr.regmap, > - pll->cdiv.reg, mask, > - f->pre_div << pll->cdiv.shift); > + regmap_update_bits(pll->cdiv.clkr.regmap, > +pll->cdiv.reg, mask, > +f->pre_div << pll->cdiv.shift); > /* >* There is no status bit which can be checked for successful CPU >* divider update operation so using delay for the same. > -- > 2.25.1 >
Re: [PATCH 04/21] clk: qcom: clk-regmap: Provide missing description for 'devm_clk_register_regmap()'s dev param
On Tue 26 Jan 06:45 CST 2021, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/clk/qcom/clk-regmap.c:97: warning: Function parameter or member > 'dev' not described in 'devm_clk_register_regmap' > > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-arm-...@vger.kernel.org > Cc: linux-...@vger.kernel.org Reviewed-by: Bjorn Andersson > Signed-off-by: Lee Jones > --- > drivers/clk/qcom/clk-regmap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/clk/qcom/clk-regmap.c b/drivers/clk/qcom/clk-regmap.c > index ce80db27ccf2a..92ac4e0d7dbe2 100644 > --- a/drivers/clk/qcom/clk-regmap.c > +++ b/drivers/clk/qcom/clk-regmap.c > @@ -87,6 +87,7 @@ EXPORT_SYMBOL_GPL(clk_disable_regmap); > /** > * devm_clk_register_regmap - register a clk_regmap clock > * > + * @dev: reference to the caller's device > * @rclk: clk to operate on > * > * Clocks that use regmap for their register I/O should register their > -- > 2.25.1 >
[PATCH v2 1/2] dt-bindings: clock: Add SC8180x GCC binding
Add devicetree binding for the global clock controller found in the
Qualcomm SC8180x platform.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- None
.../bindings/clock/qcom,gcc-sc8180x.yaml | 76 +
include/dt-bindings/clock/qcom,gcc-sc8180x.h | 309 ++
2 files changed, 385 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
create mode 100644 include/dt-bindings/clock/qcom,gcc-sc8180x.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
new file mode 100644
index ..f03ef96e57fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-sc8180x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller Binding for SC8180x
+
+maintainers:
+ - Bjorn Andersson
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on SC8180x.
+
+ See also:
+ - dt-bindings/clock/qcom,gcc-sc8180x.h
+
+properties:
+ compatible:
+const: qcom,gcc-sc8180x
+
+ clocks:
+items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep clock source
+
+ clock-names:
+items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+ - const: sleep_clk
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 1
+
+ '#power-domain-cells':
+const: 1
+
+ reg:
+maxItems: 1
+
+ protected-clocks:
+description:
+ Protected clock specifier list as per common clock binding.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+clock-controller@10 {
+ compatible = "qcom,gcc-sc8180x";
+ reg = <0x0010 0x1f>;
+ clocks = < RPMH_CXO_CLK>,
+ < RPMH_CXO_CLK_A>,
+ <_clk>;
+ clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+};
+...
diff --git a/include/dt-bindings/clock/qcom,gcc-sc8180x.h
b/include/dt-bindings/clock/qcom,gcc-sc8180x.h
new file mode 100644
index ..e893415ae13d
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gcc-sc8180x.h
@@ -0,0 +1,309 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2021, Linaro Ltd.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GCC_SC8180X_H
+#define _DT_BINDINGS_CLK_QCOM_GCC_SC8180X_H
+
+#define GCC_AGGRE_NOC_PCIE_TBU_CLK 0
+#define GCC_AGGRE_UFS_CARD_AXI_CLK 1
+#define GCC_AGGRE_UFS_CARD_AXI_HW_CTL_CLK 2
+#define GCC_AGGRE_UFS_PHY_AXI_CLK 3
+#define GCC_AGGRE_UFS_PHY_AXI_HW_CTL_CLK 4
+#define GCC_AGGRE_USB3_MP_AXI_CLK 5
+#define GCC_AGGRE_USB3_PRIM_AXI_CLK6
+#define GCC_AGGRE_USB3_SEC_AXI_CLK 7
+#define GCC_BOOT_ROM_AHB_CLK 8
+#define GCC_CAMERA_HF_AXI_CLK 9
+#define GCC_CAMERA_SF_AXI_CLK 10
+#define GCC_CFG_NOC_USB3_MP_AXI_CLK11
+#define GCC_CFG_NOC_USB3_PRIM_AXI_CLK 12
+#define GCC_CFG_NOC_USB3_SEC_AXI_CLK 13
+#define GCC_CPUSS_AHB_CLK 14
+#define GCC_CPUSS_AHB_CLK_SRC 15
+#define GCC_CPUSS_RBCPR_CLK16
+#define GCC_DDRSS_GPU_AXI_CLK 17
+#define GCC_DISP_HF_AXI_CLK18
+#define GCC_DISP_SF_AXI_CLK19
+#define GCC_EMAC_AXI_CLK 20
+#define GCC_EMAC_PTP_CLK 21
+#define GCC_EMAC_PTP_CLK_SRC 22
+#define GCC_EMAC_RGMII_CLK 23
+#define GCC_EMAC_RGMII_CLK_SRC 24
+#define GCC_EMAC_SLV_AHB_CLK 25
+#define GCC_GP1_CLK26
+#define GCC_GP1_CLK_SRC27
+#define GCC_GP2_CLK28
+#define GCC_GP2_CLK_SRC
[PATCH v2 2/2] clk: qcom: gcc: Add global clock controller driver for SC8180x
Add clocks, resets and some of the GDSC provided by the global clock
controller found in the Qualcomm SC8180x platform.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Fixes all gdsc addresses (missed to fold the fixup that subtracted gcc base
in v1)
drivers/clk/qcom/Kconfig |9 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/gcc-sc8180x.c | 4629
3 files changed, 4639 insertions(+)
create mode 100644 drivers/clk/qcom/gcc-sc8180x.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index d32bb12cd8d0..efd2e97f56ef 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -317,6 +317,15 @@ config SC_GCC_7180
Say Y if you want to use peripheral devices such as UART, SPI,
I2C, USB, UFS, SDCC, etc.
+config SC_GCC_8180X
+ tristate "SC8180X Global Clock Controller"
+ select QCOM_GDSC
+ depends on COMMON_CLK_QCOM
+ help
+ Support for the global clock controller on SC8180X devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ I2C, USB, UFS, SDCC, etc.
+
config SC_LPASS_CORECC_7180
tristate "SC7180 LPASS Core Clock Controller"
select SC_GCC_7180
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 9e5e0e3cb7b4..2ff4c4b462e2 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_QCS_TURING_404) += turingcc-qcs404.o
obj-$(CONFIG_SC_CAMCC_7180) += camcc-sc7180.o
obj-$(CONFIG_SC_DISPCC_7180) += dispcc-sc7180.o
obj-$(CONFIG_SC_GCC_7180) += gcc-sc7180.o
+obj-$(CONFIG_SC_GCC_8180X) += gcc-sc8180x.o
obj-$(CONFIG_SC_GPUCC_7180) += gpucc-sc7180.o
obj-$(CONFIG_SC_LPASS_CORECC_7180) += lpasscorecc-sc7180.o
obj-$(CONFIG_SC_MSS_7180) += mss-sc7180.o
diff --git a/drivers/clk/qcom/gcc-sc8180x.c b/drivers/clk/qcom/gcc-sc8180x.c
new file mode 100644
index ..d84ca5063b65
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sc8180x.c
@@ -0,0 +1,4629 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020-2021, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "gdsc.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+enum {
+ P_AUD_REF_CLK,
+ P_BI_TCXO,
+ P_GPLL0_OUT_EVEN,
+ P_GPLL0_OUT_MAIN,
+ P_GPLL1_OUT_MAIN,
+ P_GPLL2_OUT_MAIN,
+ P_GPLL4_OUT_MAIN,
+ P_GPLL5_OUT_MAIN,
+ P_GPLL7_OUT_MAIN,
+ P_GPLL9_OUT_MAIN,
+ P_SLEEP_CLK,
+};
+
+static struct pll_vco trion_vco[] = {
+ { 24960, 20, 0 },
+};
+
+static struct clk_alpha_pll gpll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_TRION],
+ .vco_table = trion_vco,
+ .num_vco = ARRAY_SIZE(trion_vco),
+ .clkr = {
+ .enable_reg = 0x52000,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll0",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fixed_trion_ops,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_trion_even[] = {
+ { 0x0, 1 },
+ { 0x1, 2 },
+ { 0x3, 4 },
+ { 0x7, 8 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv gpll0_out_even = {
+ .offset = 0x0,
+ .post_div_shift = 8,
+ .post_div_table = post_div_table_trion_even,
+ .num_post_div = ARRAY_SIZE(post_div_table_trion_even),
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_TRION],
+ .width = 4,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpll0_out_even",
+ .parent_hws = (const struct clk_hw *[]){ },
+ .num_parents = 1,
+ .ops = _alpha_pll_postdiv_trion_ops,
+ },
+};
+
+static struct clk_alpha_pll gpll1 = {
+ .offset = 0x1000,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_TRION],
+ .vco_table = trion_vco,
+ .num_vco = ARRAY_SIZE(trion_vco),
+ .clkr = {
+ .enable_reg = 0x52000,
+ .enable_mask = BIT(1),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll1",
+ .parent_data = &(const struct clk_parent_data){
+
[PATCH v2 3/3] pinctrl: qcom: Add sc8180x TLMM driver
Add pinctrl driver for the sc8180x TLMM block.
A noteworthy difference from previous TLMM blocks is that the registers
for GPIO 177 through 189 are for some reason offset from the typical
layout. Other than that the driver is same old...
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/qcom/Kconfig |9 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-sc8180x.c | 1624
3 files changed, 1634 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sc8180x.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index a003776506d0..4984fe9f700d 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -220,6 +220,15 @@ config PINCTRL_SC7280
Qualcomm Technologies Inc TLMM block found on the Qualcomm
Technologies Inc SC7280 platform.
+config PINCTRL_SC8180X
+ tristate "Qualcomm Technologies Inc SC8180x pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc TLMM block found on the Qualcomm
+ Technologies Inc SC8180x platform.
+
config PINCTRL_SDM660
tristate "Qualcomm Technologies Inc SDM660 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 91875a3f5ac4..468b840343fd 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-gpio.o
obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-mpp.o
obj-$(CONFIG_PINCTRL_SC7180) += pinctrl-sc7180.o
obj-$(CONFIG_PINCTRL_SC7280) += pinctrl-sc7280.o
+obj-$(CONFIG_PINCTRL_SC8180X) += pinctrl-sc8180x.o
obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o
obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
obj-$(CONFIG_PINCTRL_SDX55) += pinctrl-sdx55.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sc8180x.c
b/drivers/pinctrl/qcom/pinctrl-sc8180x.c
new file mode 100644
index ..b765bf667574
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sc8180x.c
@@ -0,0 +1,1624 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020-2021, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+static const char * const sc8180x_tiles[] = {
+ "south",
+ "east",
+ "west"
+};
+
+enum {
+ SOUTH,
+ EAST,
+ WEST
+};
+
+#define FUNCTION(fname)\
+ [msm_mux_##fname] = { \
+ .name = #fname, \
+ .groups = fname##_groups, \
+ .ngroups = ARRAY_SIZE(fname##_groups), \
+ }
+
+#define REG_SIZE 0x1000
+#define PINGROUP_OFFSET(id, _tile, offset, f1, f2, f3, f4, f5, f6, f7, f8, f9)
\
+ { \
+ .name = "gpio" #id, \
+ .pins = gpio##id##_pins,\
+ .npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins), \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9\
+ }, \
+ .nfuncs = 10, \
+ .ctl_reg = REG_SIZE * id + offset, \
+ .io_reg = REG_SIZE * id + 0x4 + offset, \
+ .intr_cfg_reg = REG_SIZE * id + 0x8 + offset, \
+ .intr_status_reg = REG_SIZE * id + 0xc + offset,\
+ .intr_target_reg = REG_SIZE * id + 0x8 + offset,\
+ .tile = _tile, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9,\
+ .in_bit = 0,\
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+
[PATCH v2 2/3] dt-bindings: pinctrl: qcom: Add sc8180x binding
Add binding for the TLMM block in the Qualcomm SC8180X platform.
Signed-off-by: Bjorn Andersson
---
.../pinctrl/qcom,sc8180x-pinctrl.yaml | 152 ++
1 file changed, 152 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml
diff --git
a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml
new file mode 100644
index ..a82dab898395
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sc8180x-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SC8180X TLMM block
+
+maintainers:
+ - Bjorn Andersson
+
+description: |
+ This binding describes the Top Level Mode Multiplexer block found in the
+ SC8180X platform.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+const: qcom,sc8180x-tlmm
+
+ reg:
+maxItems: 3
+
+ reg-names:
+items:
+ - const: "west"
+ - const: "east"
+ - const: "south"
+
+ interrupts: true
+ interrupt-controller: true
+ '#interrupt-cells': true
+ gpio-controller: true
+ gpio-reserved-ranges: true
+ '#gpio-cells': true
+ gpio-ranges: true
+ wakeup-parent: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+patternProperties:
+ '-state$':
+oneOf:
+ - $ref: "#/$defs/qcom-sc8180x-tlmm-state"
+ - patternProperties:
+ ".*":
+$ref: "#/$defs/qcom-sc8180x-tlmm-state"
+
+'$defs':
+ qcom-sc8180x-tlmm-state:
+type: object
+description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+$ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
+
+properties:
+ pins:
+description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+items:
+ oneOf:
+- pattern: "^gpio([0-9]|[1-9][0-9]|1[0-8][0-9])$"
+- enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+minItems: 1
+maxItems: 16
+
+ function:
+description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+enum: [ adsp_ext, agera_pll, aoss_cti, atest_char, atest_tsens,
+atest_tsens2, atest_usb0, atest_usb1, atest_usb2, atest_usb3,
+atest_usb4, audio_ref, btfm_slimbus, cam_mclk, cci_async,
+cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
+cci_timer4, cci_timer5, cci_timer6, cci_timer7, cci_timer8,
+cci_timer9, cri_trng, dbg_out, ddr_bist, ddr_pxi, debug_hot,
+dp_hot, edp_hot, edp_lcd, emac_phy, emac_pps, gcc_gp1, gcc_gp2,
+gcc_gp3, gcc_gp4, gcc_gp5, gpio, gps, grfc, hs1_mi2s, hs2_mi2s,
+hs3_mi2s, jitter_bist, lpass_slimbus, m_voc, mdp_vsync,
+mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mdp_vsync4,
+mdp_vsync5, mss_lte, nav_pps, pa_indicator, pci_e0, pci_e1,
+pci_e2, pci_e3, phase_flag, pll_bist, pll_bypassnl, pll_reset,
+pri_mi2s, pri_mi2s_ws, prng_rosc, qdss_cti, qdss_gpio, qlink,
+qspi0, qspi0_clk, qspi0_cs, qspi1, qspi1_clk, qspi1_cs,
+qua_mi2s, qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8,
+qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17,
+qup18, qup19, qup_l4, qup_l5, qup_l6, rgmii, sd_write, sdc4,
+sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, spkr_i2s, ter_mi2s, tgu,
+tsense_pwm1, tsense_pwm2, tsif1, tsif2, uim1, uim2, uim_batt,
+usb0_phy, usb1_phy, usb2phy_ac, vfr_1, vsense_trigger,
+wlan1_adc, wlan2_adc, wmss_reset ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-strength: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+required:
+ - pins
+ - function
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+pinctrl@310 {
+compatible = "qcom,sc8180x-tlmm";
+reg = <0x0310 0x30>,
+ <0x0350 0x70>,
+ <0x03d0 0x30>;
+reg-names = "west", "east", "south";
+interrupts = ;
+gpio-controller;
+#gpio-cells = <2>;
+interrupt-controller;
+
[PATCH v2 1/3] dt-bindings: pinctrl: qcom: Define common TLMM binding
Several properties are shared between all TLMM bindings. By providing a common binding to define these properties each platform's binding can be reduced to just listing which of these properties should be checked for - or further specified. Reviewed-by: Vinod Koul Signed-off-by: Bjorn Andersson --- Changes since v1: - Dropped "phandle", as Rob pushed this to the dt-schema instead - Expanded the "TLMM" abbreviation .../bindings/pinctrl/qcom,tlmm-common.yaml| 85 +++ 1 file changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml new file mode 100644 index ..3b37cf102d41 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,tlmm-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Top Level Mode Multiplexer (TLMM) definitions + +maintainers: + - Bjorn Andersson + +description: + This defines the common properties used to describe all Qualcomm Top Level + Mode Multiplexer bindings and pinconf/pinmux states for these. + +properties: + interrupts: +description: + Specifies the TLMM summary IRQ +maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': +description: + Specifies the PIN numbers and Flags, as defined in defined in + include/dt-bindings/interrupt-controller/irq.h +const: 2 + + gpio-controller: true + + '#gpio-cells': +description: + Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h +const: 2 + + gpio-ranges: +maxItems: 1 + + wakeup-parent: +description: + Specifying the interrupt-controller used to wake up the system when the + TLMM block has been powered down. +maxItems: 1 + + gpio-reserved-ranges: +description: + Pins can be reserved for trusted applications and thereby unaccessible + from the OS. This property can be used to mark the pins which resources + should not be accessed by the OS. Please see the ../gpio/gpio.txt for more + information. + +required: + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: true + +$defs: + qcom-tlmm-state: +allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + +properties: + drive-strength: +enum: [2, 4, 6, 8, 10, 12, 14, 16] +default: 2 +description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + bias-pull-up: true + bias-disable: true + input-enable: true + output-high: true + output-low: true + +additionalProperties: true +... -- 2.29.2
Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
On Mon 25 Jan 19:14 CST 2021, Wesley Cheng wrote: > > > On 1/22/2021 9:12 AM, Bjorn Andersson wrote: > > On Thu 21 Jan 22:01 CST 2021, Wesley Cheng wrote: > > > > Hi Bjorn, > > > > Under what circumstances should we specify this? And in particular are > > there scenarios (in the Qualcomm platforms) where this must not be set? > >The TXFIFO dynamic allocation is actually a feature within the DWC3 > controller, and isn't specifically for QCOM based platforms. It won't > do any harm functionally if this flag is not set, as this is meant for > enhancing performance/bandwidth. > > > In particular, the composition can be changed in runtime, so should we > > set this for all Qualcomm platforms? > > > Ideally yes, if we want to increase bandwith for situations where SS > endpoint bursting is set to a higher value. > > > And if that's the case, can we not just set it from the qcom driver? > > > Since this is a common DWC3 core feature, I think it would make more > sense to have it in DWC3 core instead of a vendor's DWC3 glue driver. > I don't have any objections to implementing it in the core driver, but my question is can we just skip the DT binding and just enable it from the vendor driver? Regards, Bjorn
Re: [PATCH 4/4] phy: qcom-qmp: Add support for SM8350 UFS phy
On Mon 25 Jan 04:09 CST 2021, Vinod Koul wrote:
> Add the tables for init sequences for UFS QMP phy found in SM8350 SoC.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Vinod Koul
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 127
> 1 file changed, 127 insertions(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index dbc12a19b702..4a9d1010910d 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1983,6 +1983,106 @@ static const struct qmp_phy_init_tbl
> sm8250_qmp_gen3x2_pcie_pcs_misc_tbl[] = {
> QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG4, 0x07),
> };
>
> +static const struct qmp_phy_init_tbl sm8350_ufsphy_serdes_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0xd9),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x11),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_HS_SWITCH_SEL, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x42),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_IVCO, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_INITVAL2, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL, 0x11),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x82),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE0, 0x14),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE0, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE0, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0xff),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x19),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xac),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x1e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE1, 0x98),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE1, 0x14),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE1, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE1, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE1, 0x65),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE1, 0x1e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1, 0xdd),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1, 0x23),
> +
> + /* Rate B */
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x06),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8350_ufsphy_tx_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_1_DIVIDER_BAND0_1, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_2_DIVIDER_BAND0_1, 0x03),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_3_DIVIDER_BAND0_1, 0x01),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_PWM_GEAR_4_DIVIDER_BAND0_1, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_1, 0xf5),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_3, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_TX, 0x09),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_RX, 0x09),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_TX_TRAN_DRVR_EMP_EN, 0x0c),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8350_ufsphy_rx_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_LVL, 0x24),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_CNTRL, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_BAND, 0x18),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_FO_GAIN, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x5a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0xf1),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_COUNT_LOW, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CTRL2, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FO_GAIN, 0x0e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_TERM_BW, 0x1b),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL1, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL2, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x17),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_MEASURE_TIME, 0x10),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_LOW, 0xc0),
> + QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_HIGH, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_RX_RX_MODE_00_LOW, 0x6d),
> + QMP_PHY_INIT_CFG(QSERDES_SM8350_RX_RX_
Re: [PATCH v3 2/6] drivers: crypto: qce: sha: Hold back a block of data to be transferred as part of final
On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:
> If the available data to transfer is exactly a multiple of block size, save
> the last block to be transferred in qce_ahash_final (with the last block
> bit set) if this is indeed the end of data stream. If not this saved block
> will be transferred as part of next update. If this block is not held back
> and if this is indeed the end of data stream, the digest obtained will be
> wrong since qce_ahash_final will see that rctx->buflen is 0 and return
> doing nothing which in turn means that a digest will not be copied to the
> destination result buffer. qce_ahash_final cannot be made to alter this
> behavior and allowed to proceed if rctx->buflen is 0 because the crypto
> engine BAM does not allow for zero length transfers.
>
Please drop "drivers: " from $subject.
Apart from that this looks good.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/sha.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
> index 08aed03e2b59..dd263c5e4dd8 100644
> --- a/drivers/crypto/qce/sha.c
> +++ b/drivers/crypto/qce/sha.c
> @@ -216,6 +216,25 @@ static int qce_ahash_update(struct ahash_request *req)
>
> /* calculate how many bytes will be hashed later */
> hash_later = total % blocksize;
> +
> + /*
> + * At this point, there is more than one block size of data. If
> + * the available data to transfer is exactly a multiple of block
> + * size, save the last block to be transferred in qce_ahash_final
> + * (with the last block bit set) if this is indeed the end of data
> + * stream. If not this saved block will be transferred as part of
> + * next update. If this block is not held back and if this is
> + * indeed the end of data stream, the digest obtained will be wrong
> + * since qce_ahash_final will see that rctx->buflen is 0 and return
> + * doing nothing which in turn means that a digest will not be
> + * copied to the destination result buffer. qce_ahash_final cannot
> + * be made to alter this behavior and allowed to proceed if
> + * rctx->buflen is 0 because the crypto engine BAM does not allow
> + * for zero length transfers.
> + */
> + if (!hash_later)
> + hash_later = blocksize;
> +
> if (hash_later) {
> unsigned int src_offset = req->nbytes - hash_later;
> scatterwalk_map_and_copy(rctx->buf, req->src, src_offset,
> --
> 2.25.1
>
Re: [PATCH 3/4] ARM: dts: qcom: msm8974-klte: add support for display
On Mon 25 Jan 09:47 CST 2021, Konrad Dybcio wrote: > > > I know how bad it is, so I understand your desire to not have to rebase > > that, but I will merge things as they become ready on the list. > > > > So please post your change (perhaps it's posted and I'm failing to find > > it in my inbox?) and I'd be happy to merge it so we get it cleaned up! > > > > Thanks, > > Bjorn > > > Here it is: [1] > > > Be aware that it truly is humongous and should be split (I couldn't > resist adding missing pins/dma while cleaning things up) and it.. was > not really intended to be sent as-is. It's also supposed to work on > the previous release of Linux, so some Samsung DTs in particular > changed since and will need some manual rebasing. But I'll happily > leave it as a reference if somebody has the time to pick it up. The > konrad/8974 branch in this repo contains more (beware, GPU ones are > untested!) 8974 fixes and I have some more on my drive that are.. not > really ready for their prime time just yet either.. > I like the end result, so please spend some time trying to get this upstream (which would save you from having to rebase that going forward :)) As you say I don't think it's appropriate to post or merge it as is, but you should be able to send patches related to the 7 steps described in the commit message - and don't be afraid of splitting it in more than those patches. And we don't need to merge them all at once either... Regards, Bjorn
Re: [PATCH 1/2] media: venus: core: Add sdm660 DT compatible and resource struct
On Mon 25 Jan 08:51 CST 2021, AngeloGioacchino Del Regno wrote: > Il 25/01/21 11:40, Hans Verkuil ha scritto: > > On 18/01/2021 18:45, AngeloGioacchino Del Regno wrote: > > > Il 18/01/21 18:21, Stanimir Varbanov ha scritto: > > > > > diff --git a/drivers/media/platform/qcom/venus/core.c > > > > > b/drivers/media/platform/qcom/venus/core.c [..] > > > > > + .fwname = "qcom/venus-4.4/venus.mdt", [..] > > This patch can't be merged unless there is a corresponding firmware > > available > > in linux-firmware. Is the current 4.2 firmware in linux-firmware signed by > > Qualcomm? Can they provided 4.4 firmware as well? > > > > If there is such issue, then maybe we should do "something" about it: I > would then propose to remove all references to fwname and just get this > done in DT, where every qcom board already specifies its own path for > its own firmware. > We have the same problem with production devices on e.g. SDM845, where the firmware referenced by fw_name and present in linux-firmware won't work on any real devices. As such, providing means for specifying the firmware name in DT would be a very reasonable thing, and in line with how we handle this in other subsystems (using the firmware-name property, containing the full relative path). Regards, Bjorn
Re: [PATCH 3/4] ARM: dts: qcom: msm8974-klte: add support for display
On Sun 24 Jan 11:33 CST 2021, Konrad Dybcio wrote: > > > All msm8974 dts(i) files use this style. Deviating from it for this doesn't > > make sense. And yes msm8974 should probably be converted to the newer label > > style (as was done with msm8916 a while ago). > > I have a >3k lines commit fixing that. Adding more code that strays > from the new style doesn't really help. > I know how bad it is, so I understand your desire to not have to rebase that, but I will merge things as they become ready on the list. So please post your change (perhaps it's posted and I'm failing to find it in my inbox?) and I'd be happy to merge it so we get it cleaned up! Thanks, Bjorn
Re: [Linux-stm32] [PATCH] rpmsg: char: return an error if device already open
On Fri 15 Jan 03:13 CST 2021, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
>
> On 1/14/21 8:05 PM, Mathieu Poirier wrote:
> > On Wed, Jan 06, 2021 at 02:37:14PM +0100, Arnaud Pouliquen wrote:
> >> The rpmsg_create_ept function is invoked when the device is opened.
> >> As only one endpoint must be created per device. It is not
> >> possible to open the same device twice.
> >> The fix consists in returning -EBUSY when device is already
> >> opened.
> >>
> >> Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface")
> >> Signed-off-by: Arnaud Pouliquen
> >> ---
> >> drivers/rpmsg/rpmsg_char.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> >> index 4bbbacdbf3bb..360a1ab0a9c4 100644
> >> --- a/drivers/rpmsg/rpmsg_char.c
> >> +++ b/drivers/rpmsg/rpmsg_char.c
> >> @@ -127,6 +127,9 @@ static int rpmsg_eptdev_open(struct inode *inode,
> >> struct file *filp)
> >>struct rpmsg_device *rpdev = eptdev->rpdev;
> >>struct device *dev = >dev;
> >>
> >> + if (eptdev->ept)
> >> + return -EBUSY;
> >> +
> >
> > I rarely had to work so hard to review a 2 line patch...
>
> That means that my commit description was not enough explicit...
>
> >
> > As far as I can tell the actual code is doing the right thing. If user
> > space is
> > trying to open the same eptdev more than once function rpmsg_create_ept()
> > should
> > complain and the operation denied, wich is what the current code is doing.
> >
> > There is currently two customers for this API - SMD and GLINK. The SMD
> > code is
> > quite clear that if the channel is already open, the operation will be
> > denied [1]. The GLINK code isn't as clear but the fact that it returns
> > NULL on
> > error conditions [2] is a good indication that things are working the same
> > way.
> >
> > What kind of use case are you looking to address? Is there any way you can
> > use
> > rpdev->ops->create_ept() as it is currently done?
>
> This patch was part of the IOCTL rpmsg series. I sent it separately at Bjorn's
> request [1].
>
I apparently didn't spend as much effort as Mathieu thinking about the
details. I do believe that he's right, at least both GLINK and SMD
_should_ return -EBUSY if we try to open an already open channel -
either because the kernel has bound a driver to the channel or because
rpmsg_char already has it opened.
> I detect the issue using the RPMSG_ADDR_ANY for the source address when tested
> it with the rpmsf_virtio bus. In this case at each sys open of the device, a
> new
> endpoint is created because a new source address is allocated.
>
In SMD and GLINK channels are identified solely by their name and hence
it's not possible to have duplicates. As this isn't the case for virtio
I didn't have any objections to it and that's why I asked you to resend
it separately.
But in line with GLINK/SMD, what would the expected behavior be if I
with the virtio backend open a rpmsg_char which is already bound to a
kernel driver?
Do you think we should get another "channel" or do you think the virtio
driver should detect this and return -EBUSY? (I.e. render this patch
unnecessary)
Regards,
Bjorn
> [1]https://patchwork.kernel.org/project/linux-remoteproc/patch/20201222105726.16906-11-arnaud.pouliq...@foss.st.com/
>
> Thanks,
> Arnaud
>
> >
> > Thanks,
> > Mathieu
> >
> > [1].
> > https://elixir.bootlin.com/linux/v5.11-rc3/source/drivers/rpmsg/qcom_smd.c#L920
> > [2].
> > https://elixir.bootlin.com/linux/v5.11-rc3/source/drivers/rpmsg/qcom_glink_native.c#L1149
> >
> >>get_device(dev);
> >>
> >>ept = rpmsg_create_ept(rpdev, rpmsg_ept_cb, eptdev, eptdev->chinfo);
> >> --
> >> 2.17.1
> >>
> > ___
> > Linux-stm32 mailing list
> > linux-st...@st-md-mailman.stormreply.com
> > https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
> >
Re: [PATCH] [net-next] ipa: add remoteproc dependency
On Mon 25 Jan 05:35 CST 2021, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Compile-testing without CONFIG_REMOTEPROC results in a build failure:
>
> >>> referenced by ipa_main.c
> >>> net/ipa/ipa_main.o:(ipa_probe) in archive drivers/built-in.a
> ld.lld: error: undefined symbol: rproc_put
> >>> referenced by ipa_main.c
> >>> net/ipa/ipa_main.o:(ipa_probe) in archive drivers/built-in.a
> >>> referenced by ipa_main.c
> >>> net/ipa/ipa_main.o:(ipa_remove) in archive
> >>> drivers/built-in.a
>
> Add a new dependency to avoid this.
>
Afaict this should be addressed by:
86fdf1fc60e9 ("net: ipa: remove a remoteproc dependency")
which is present in linux-next.
Regards,
Bjorn
> Fixes: 38a4066f593c ("net: ipa: support COMPILE_TEST")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/net/ipa/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ipa/Kconfig b/drivers/net/ipa/Kconfig
> index b68f1289b89e..aa1c0ae3cf01 100644
> --- a/drivers/net/ipa/Kconfig
> +++ b/drivers/net/ipa/Kconfig
> @@ -3,6 +3,7 @@ config QCOM_IPA
> depends on 64BIT && NET && QCOM_SMEM
> depends on ARCH_QCOM || COMPILE_TEST
> depends on QCOM_RPROC_COMMON || (QCOM_RPROC_COMMON=n && COMPILE_TEST)
> + depends on REMOTEPROC
> select QCOM_MDT_LOADER if ARCH_QCOM
> select QCOM_QMI_HELPERS
> help
> --
> 2.29.2
>
Re: [PATCH v4 5/5] clk: qcom: gcc: Add clock driver for SM8350
On Sun 17 Jan 22:43 CST 2021, Vinod Koul wrote:
> From: Vivek Aknurwar
>
> This adds Global Clock controller (GCC) driver for SM8350 SoC
>
> Signed-off-by: Vivek Aknurwar
> Signed-off-by: Jeevan Shriram
> [vkoul: rebase and tidy up for upstream]
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/clk/qcom/Kconfig |8 +
> drivers/clk/qcom/Makefile |1 +
> drivers/clk/qcom/gcc-sm8350.c | 3790 +
> 3 files changed, 3799 insertions(+)
> create mode 100644 drivers/clk/qcom/gcc-sm8350.c
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index d32bb12cd8d0..54b217956469 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -454,6 +454,14 @@ config SM_GCC_8250
> Say Y if you want to use peripheral devices such as UART,
> SPI, I2C, USB, SD/UFS, PCIe etc.
>
> +config SM_GCC_8350
> + tristate "SM8350 Global Clock Controller"
> + select QCOM_GDSC
> + help
> + Support for the global clock controller on SM8350 devices.
> + Say Y if you want to use peripheral devices such as UART,
> + SPI, I2C, USB, SD/UFS, PCIe etc.
> +
> config SM_GPUCC_8150
> tristate "SM8150 Graphics Clock Controller"
> select SM_GCC_8150
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 9e5e0e3cb7b4..a89c7016 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_SDX_GCC_55) += gcc-sdx55.o
> obj-$(CONFIG_SM_DISPCC_8250) += dispcc-sm8250.o
> obj-$(CONFIG_SM_GCC_8150) += gcc-sm8150.o
> obj-$(CONFIG_SM_GCC_8250) += gcc-sm8250.o
> +obj-$(CONFIG_SM_GCC_8350) += gcc-sm8350.o
> obj-$(CONFIG_SM_GPUCC_8150) += gpucc-sm8150.o
> obj-$(CONFIG_SM_GPUCC_8250) += gpucc-sm8250.o
> obj-$(CONFIG_SM_VIDEOCC_8150) += videocc-sm8150.o
> diff --git a/drivers/clk/qcom/gcc-sm8350.c b/drivers/clk/qcom/gcc-sm8350.c
> new file mode 100644
> index ..a16c08651206
> --- /dev/null
> +++ b/drivers/clk/qcom/gcc-sm8350.c
> @@ -0,0 +1,3790 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2020-2021, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "clk-alpha-pll.h"
> +#include "clk-branch.h"
> +#include "clk-rcg.h"
> +#include "clk-regmap.h"
> +#include "clk-regmap-divider.h"
> +#include "clk-regmap-mux.h"
> +#include "reset.h"
> +
> +enum {
> + P_BI_TCXO,
> + P_CORE_BI_PLL_TEST_SE,
> + P_GCC_GPLL0_OUT_EVEN,
> + P_GCC_GPLL0_OUT_MAIN,
> + P_GCC_GPLL4_OUT_MAIN,
> + P_GCC_GPLL9_OUT_MAIN,
> + P_PCIE_0_PIPE_CLK,
> + P_PCIE_1_PIPE_CLK,
> + P_SLEEP_CLK,
> + P_UFS_CARD_RX_SYMBOL_0_CLK,
> + P_UFS_CARD_RX_SYMBOL_1_CLK,
> + P_UFS_CARD_TX_SYMBOL_0_CLK,
> + P_UFS_PHY_RX_SYMBOL_0_CLK,
> + P_UFS_PHY_RX_SYMBOL_1_CLK,
> + P_UFS_PHY_TX_SYMBOL_0_CLK,
> + P_USB3_PHY_WRAPPER_GCC_USB30_PIPE_CLK,
> + P_USB3_UNI_PHY_SEC_GCC_USB30_PIPE_CLK,
> +};
> +
> +static struct clk_alpha_pll gcc_gpll0 = {
> + .offset = 0x0,
> + .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
> + .clkr = {
> + .enable_reg = 0x52018,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data){
> + .name = "gcc_gpll0",
> + .parent_data = &(const struct clk_parent_data){
> + .fw_name = "bi_tcxo",
> + },
> + .num_parents = 1,
> + .ops = _alpha_pll_fixed_lucid_5lpe_ops,
> + },
> + },
> +};
> +
> +static const struct clk_div_table post_div_table_gcc_gpll0_out_even[] = {
> + { 0x1, 2 },
> + { }
> +};
> +
> +static struct clk_alpha_pll_postdiv gcc_gpll0_out_even = {
> + .offset = 0x0,
> + .post_div_shift = 8,
> + .post_div_table = post_div_table_gcc_gpll0_out_even,
> + .num_post_div = ARRAY_SIZE(post_div_table_gcc_gpll0_out_even),
> + .width = 4,
> + .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
> + .clkr.hw.init = &(struct clk_init_data){
> + .name = "gcc_gpll0_out_even",
> + .parent_data = &(const struct clk_parent_data){
> + .hw = _gpll0.clkr.hw,
> + },
> + .num_parents = 1,
> +
Re: [PATCH v4 1/5] clk: qcom: clk-alpha-pll: replace regval with val
On Sun 17 Jan 22:43 CST 2021, Vinod Koul wrote:
> Driver uses regval variable for holding register values, replace with a
> shorter one val
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Suggested-by: Stephen Boyd
> Signed-off-by: Vinod Koul
> ---
> drivers/clk/qcom/clk-alpha-pll.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> b/drivers/clk/qcom/clk-alpha-pll.c
> index 21c357c26ec4..f7721088494c 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -777,15 +777,15 @@ static long alpha_pll_huayra_round_rate(struct clk_hw
> *hw, unsigned long rate,
> static int trion_pll_is_enabled(struct clk_alpha_pll *pll,
> struct regmap *regmap)
> {
> - u32 mode_regval, opmode_regval;
> + u32 mode_val, opmode_val;
> int ret;
>
> - ret = regmap_read(regmap, PLL_MODE(pll), _regval);
> - ret |= regmap_read(regmap, PLL_OPMODE(pll), _regval);
> + ret = regmap_read(regmap, PLL_MODE(pll), _val);
> + ret |= regmap_read(regmap, PLL_OPMODE(pll), _val);
> if (ret)
> return 0;
>
> - return ((opmode_regval & PLL_RUN) && (mode_regval & PLL_OUTCTRL));
> + return ((opmode_val & PLL_RUN) && (mode_val & PLL_OUTCTRL));
> }
>
> static int clk_trion_pll_is_enabled(struct clk_hw *hw)
> @@ -1445,12 +1445,12 @@ EXPORT_SYMBOL_GPL(clk_trion_pll_configure);
> static int __alpha_pll_trion_prepare(struct clk_hw *hw, u32 pcal_done)
> {
> struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> - u32 regval;
> + u32 val;
> int ret;
>
> /* Return early if calibration is not needed. */
> - regmap_read(pll->clkr.regmap, PLL_STATUS(pll), );
> - if (regval & pcal_done)
> + regmap_read(pll->clkr.regmap, PLL_STATUS(pll), );
> + if (val & pcal_done)
> return 0;
>
> /* On/off to calibrate */
> @@ -1476,7 +1476,7 @@ static int alpha_pll_trion_set_rate(struct clk_hw *hw,
> unsigned long rate,
> {
> struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> unsigned long rrate;
> - u32 regval, l, alpha_width = pll_alpha_width(pll);
> + u32 val, l, alpha_width = pll_alpha_width(pll);
> u64 a;
> int ret;
>
> @@ -1497,8 +1497,8 @@ static int alpha_pll_trion_set_rate(struct clk_hw *hw,
> unsigned long rate,
>
> /* Wait for 2 reference cycles before checking the ACK bit. */
> udelay(1);
> - regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
> - if (!(regval & ALPHA_PLL_ACK_LATCH)) {
> + regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
> + if (!(val & ALPHA_PLL_ACK_LATCH)) {
> pr_err("Lucid PLL latch failed. Output may be unstable!\n");
> return -EINVAL;
> }
> --
> 2.26.2
>
Re: [PATCH v4 4/5] dt-bindings: clock: Add SM8350 GCC clock bindings
E_CLK 1 > +#define PCIE_1_PIPE_CLK 2 > +#define UFS_CARD_RX_SYMBOL_0_CLK 3 > +#define UFS_CARD_RX_SYMBOL_1_CLK 4 > +#define UFS_CARD_TX_SYMBOL_0_CLK 5 > +#define UFS_PHY_RX_SYMBOL_0_CLK 6 > +#define UFS_PHY_RX_SYMBOL_1_CLK 7 > +#define UFS_PHY_TX_SYMBOL_0_CLK 8 > +#define USB3_PHY_WRAPPER_GCC_USB30_PIPE_CLK 9 > +#define USB3_UNI_PHY_SEC_GCC_USB30_PIPE_CLK 10 > + > +/* GCC clocks */ > +#define GCC_AGGRE_NOC_PCIE_0_AXI_CLK 11 > +#define GCC_AGGRE_NOC_PCIE_1_AXI_CLK 12 > +#define GCC_AGGRE_NOC_PCIE_TBU_CLK 13 > +#define GCC_AGGRE_UFS_CARD_AXI_CLK 14 > +#define GCC_AGGRE_UFS_CARD_AXI_HW_CTL_CLK15 > +#define GCC_AGGRE_UFS_PHY_AXI_CLK16 > +#define GCC_AGGRE_UFS_PHY_AXI_HW_CTL_CLK 17 > +#define GCC_AGGRE_USB3_PRIM_AXI_CLK 18 > +#define GCC_AGGRE_USB3_SEC_AXI_CLK 19 > +#define GCC_BOOT_ROM_AHB_CLK 20 > +#define GCC_CAMERA_AHB_CLK 21 You removed these from the driver, so no need to expose them in the dt-binding either. Apart from that Reviewed-by: Bjorn Andersson Regards, Bjorn > +#define GCC_CAMERA_HF_AXI_CLK22 > +#define GCC_CAMERA_SF_AXI_CLK23 > +#define GCC_CAMERA_XO_CLK24 > +#define GCC_CFG_NOC_USB3_PRIM_AXI_CLK25 > +#define GCC_CFG_NOC_USB3_SEC_AXI_CLK 26 > +#define GCC_DDRSS_GPU_AXI_CLK27 > +#define GCC_DDRSS_PCIE_SF_TBU_CLK28 > +#define GCC_DISP_AHB_CLK 29 > +#define GCC_DISP_HF_AXI_CLK 30 > +#define GCC_DISP_SF_AXI_CLK 31 > +#define GCC_DISP_XO_CLK 32 > +#define GCC_GP1_CLK 33 > +#define GCC_GP1_CLK_SRC 34 > +#define GCC_GP2_CLK 35 > +#define GCC_GP2_CLK_SRC 36 > +#define GCC_GP3_CLK 37 > +#define GCC_GP3_CLK_SRC 38 > +#define GCC_GPLL039 > +#define GCC_GPLL0_OUT_EVEN 40 > +#define GCC_GPLL441 > +#define GCC_GPLL942 > +#define GCC_GPU_CFG_AHB_CLK 43 > +#define GCC_GPU_GPLL0_CLK_SRC44 > +#define GCC_GPU_GPLL0_DIV_CLK_SRC45 > +#define GCC_GPU_IREF_EN 46 > +#define GCC_GPU_MEMNOC_GFX_CLK 47 > +#define GCC_GPU_SNOC_DVM_GFX_CLK 48 > +#define GCC_PCIE0_PHY_RCHNG_CLK 49 > +#define GCC_PCIE1_PHY_RCHNG_CLK 50 > +#define GCC_PCIE_0_AUX_CLK 51 > +#define GCC_PCIE_0_AUX_CLK_SRC 52 > +#define GCC_PCIE_0_CFG_AHB_CLK 53 > +#define GCC_PCIE_0_CLKREF_EN 54 > +#define GCC_PCIE_0_MSTR_AXI_CLK 55 > +#define GCC_PCIE_0_PHY_RCHNG_CLK_SRC 56 > +#define GCC_PCIE_0_PIPE_CLK 57 > +#define GCC_PCIE_0_PIPE_CLK_SRC 58 > +#define GCC_PCIE_0_SLV_AXI_CLK 59 > +#define GCC_PCIE_0_SLV_Q2A_AXI_CLK 60 > +#define GCC_PCIE_1_AUX_CLK 61 > +#define GCC_PCIE_1_AUX_CLK_SRC 62 > +#define GCC_PCIE_1_CFG_AHB_CLK 63 > +#define GCC_PCIE_1_CLKREF_EN 64 > +#define GCC_PCIE_1_MSTR_AXI_CLK 65 > +#define GCC_PCIE_1_PHY_RCHNG_CLK_SRC 66 > +#define GCC_PCIE_1_PIP
Re: [PATCH v4 3/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
On Sun 17 Jan 22:43 CST 2021, Vinod Koul wrote:
> From: Vivek Aknurwar
>
> Lucid 5LPE is a slightly different Lucid PLL with different offsets and
> porgramming sequence so add support for these
>
> Signed-off-by: Vivek Aknurwar
> Signed-off-by: Jeevan Shriram
> [vkoul: rebase and tidy up for upstream]
> Signed-off-by: Vinod Koul
> ---
> drivers/clk/qcom/clk-alpha-pll.c | 173 +++
> drivers/clk/qcom/clk-alpha-pll.h | 4 +
> 2 files changed, 177 insertions(+)
>
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> b/drivers/clk/qcom/clk-alpha-pll.c
> index a30ea7b09224..f9c48da21bd1 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -156,6 +156,12 @@ EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
> /* LUCID PLL specific settings and offsets */
> #define LUCID_PCAL_DONE BIT(27)
>
> +/* LUCID 5LPE PLL specific settings and offsets */
> +#define LUCID_5LPE_PCAL_DONE BIT(11)
> +#define LUCID_5LPE_ALPHA_PLL_ACK_LATCH BIT(13)
> +#define LUCID_5LPE_PLL_LATCH_INPUT BIT(14)
> +#define LUCID_5LPE_ENABLE_VOTE_RUN BIT(21)
> +
> #define pll_alpha_width(p) \
> ((PLL_ALPHA_VAL_U(p) - PLL_ALPHA_VAL(p) == 4) ? \
>ALPHA_REG_BITWIDTH : ALPHA_REG_16BIT_WIDTH)
> @@ -1604,3 +1610,170 @@ const struct clk_ops clk_alpha_pll_agera_ops = {
> .set_rate = clk_alpha_pll_agera_set_rate,
> };
> EXPORT_SYMBOL_GPL(clk_alpha_pll_agera_ops);
> +
> +static int alpha_pll_lucid_5lpe_enable(struct clk_hw *hw)
> +{
> + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
> + if (ret)
> + return ret;
> +
> + /* If in FSM mode, just vote for it */
> + if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
> + ret = clk_enable_regmap(hw);
> + if (ret)
> + return ret;
> + return wait_for_pll_enable_lock(pll);
> + }
> +
> + /* Check if PLL is already enabled, return if enabled */
> + ret = trion_pll_is_enabled(pll, pll->clkr.regmap);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_RESET_N,
> PLL_RESET_N);
> + if (ret)
> + return ret;
> +
> + regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_RUN);
> +
> + ret = wait_for_pll_enable_lock(pll);
> + if (ret)
> + return ret;
> +
> + /* Enable the PLL outputs */
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
> PLL_OUT_MASK, PLL_OUT_MASK);
> + if (ret)
> + return ret;
> +
> + /* Enable the global PLL outputs */
> + return regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL,
> PLL_OUTCTRL);
> +}
> +
> +static void alpha_pll_lucid_5lpe_disable(struct clk_hw *hw)
> +{
> + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
> + if (ret)
> + return;
> +
> + /* If in FSM mode, just unvote it */
> + if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
> + clk_disable_regmap(hw);
> + return;
> + }
> +
> + /* Disable the global PLL output */
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL,
> 0);
> + if (ret)
> + return;
> +
> + /* Disable the PLL outputs */
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
> PLL_OUT_MASK, 0);
> + if (ret)
> + return;
> +
> + /* Place the PLL mode in STANDBY */
> + regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_STANDBY);
> +}
> +
> +/*
> + * The Lucid 5LPE PLL requires a power-on self-calibration which happens
> + * when the PLL comes out of reset. Calibrate in case it is not completed.
> + */
> +static int alpha_pll_lucid_5lpe_prepare(struct clk_hw *hw)
> +{
> + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> + struct clk_hw *p;
> + u32 val;
> + int ret;
> +
> + /* Return early if calibration is not needed. */
> + regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
I doubt this will ever fail, but static analysis tools would complain
about val possibly being uninitialized after this.
And the return value is checked in the other functions.
Regards,
Bjorn
> + if (val & LUCID_5LPE_PCAL_DONE)
> + return 0;
> +
> + p = clk_hw_get_parent(hw);
> + if (!p)
> + return -EINVAL;
> +
> + ret = alpha_pll_lucid_5lpe_enable(hw);
> + if (ret)
> + return ret;
> +
> + alpha_pll_lucid_5lpe_disable(hw);
> +
> + return 0;
> +}
> +
> +static int alpha_pll_lucid_5lpe_set_rate(struct clk_hw *hw, unsigned long
> rate,
> + unsigned long prate)
> +{
> + return
Re: [PATCH v4 2/5] clk: qcom: clk-alpha-pll: modularize alpha_pll_trion_set_rate()
On Sun 17 Jan 22:43 CST 2021, Vinod Koul wrote:
> Trion 5LPE set rate uses code similar to alpha_pll_trion_set_rate() but
> with different registers. Modularize these by moving out latch and latch
> ack bits so that we can reuse the function.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Suggested-by: AngeloGioacchino Del Regno
>
> Signed-off-by: Vinod Koul
> ---
> drivers/clk/qcom/clk-alpha-pll.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> b/drivers/clk/qcom/clk-alpha-pll.c
> index f7721088494c..a30ea7b09224 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -1471,8 +1471,8 @@ static int alpha_pll_lucid_prepare(struct clk_hw *hw)
> return __alpha_pll_trion_prepare(hw, LUCID_PCAL_DONE);
> }
>
> -static int alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long prate)
> +static int __alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long prate, u32 latch_bit, u32
> latch_ack)
> {
> struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> unsigned long rrate;
> @@ -1490,22 +1490,20 @@ static int alpha_pll_trion_set_rate(struct clk_hw
> *hw, unsigned long rate,
> regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a);
>
> /* Latch the PLL input */
> - ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> - PLL_UPDATE, PLL_UPDATE);
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), latch_bit,
> latch_bit);
> if (ret)
> return ret;
>
> /* Wait for 2 reference cycles before checking the ACK bit. */
> udelay(1);
> regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
> - if (!(val & ALPHA_PLL_ACK_LATCH)) {
> + if (!(val & latch_ack)) {
> pr_err("Lucid PLL latch failed. Output may be unstable!\n");
> return -EINVAL;
> }
>
> /* Return the latch input to 0 */
> - ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> - PLL_UPDATE, 0);
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), latch_bit, 0);
> if (ret)
> return ret;
>
> @@ -1520,6 +1518,12 @@ static int alpha_pll_trion_set_rate(struct clk_hw *hw,
> unsigned long rate,
> return 0;
> }
>
> +static int alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long prate)
> +{
> + return __alpha_pll_trion_set_rate(hw, rate, prate, PLL_UPDATE,
> ALPHA_PLL_ACK_LATCH);
> +}
> +
> const struct clk_ops clk_alpha_pll_trion_ops = {
> .prepare = alpha_pll_trion_prepare,
> .enable = clk_trion_pll_enable,
> --
> 2.26.2
>
Re: [PATCH 2/4] dt-bindings: phy: qcom,qmp: Add SM8350 UFS PHY bindings
On Mon 25 Jan 04:09 CST 2021, Vinod Koul wrote: > Add the compatible strings for the UFS PHY found on SM8350 SoC. > Reviewed-by: Bjorn Andersson > Signed-off-by: Vinod Koul > --- > Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml > b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml > index 62c4f2ba5b9f..bf804c12fa5f 100644 > --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml > @@ -38,6 +38,7 @@ properties: >- qcom,sm8250-qmp-modem-pcie-phy >- qcom,sm8250-qmp-usb3-phy >- qcom,sm8250-qmp-usb3-uni-phy > + - qcom,sm8350-qmp-ufs-phy >- qcom,sm8350-qmp-usb3-phy >- qcom,sm8350-qmp-usb3-uni-phy >- qcom,sdx55-qmp-usb3-uni-phy > -- > 2.26.2 >
Re: [PATCH 1/4] scsi: dt-bindings: ufs: Add sm8250, sm8350 compatible strings
On Mon 25 Jan 04:09 CST 2021, Vinod Koul wrote: > Document "qcom,sm8250-ufshc" and "qcom,sm8350-ufshc" compatible string. > Use of "qcom,sm8250-ufshc" is already present upstream, so add misiing > documentation. "qcom,sm8350-ufshc" is for UFS HC found in SM8350 SoC. > This can/should be picked up independently of the other patches, so would have been better sent solo. Reviewed-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Vinod Koul > --- > Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt > b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt > index 415ccdd7442d..d8fd4df81743 100644 > --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt > +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt > @@ -14,6 +14,8 @@ Required properties: > "qcom,msm8998-ufshc", "qcom,ufshc", "jedec,ufs-2.0" > "qcom,sdm845-ufshc", "qcom,ufshc", "jedec,ufs-2.0" > "qcom,sm8150-ufshc", "qcom,ufshc", "jedec,ufs-2.0" > + "qcom,sm8250-ufshc", "qcom,ufshc", "jedec,ufs-2.0" > + "qcom,sm8350-ufshc", "qcom,ufshc", "jedec,ufs-2.0" > - interrupts: > - reg : > > -- > 2.26.2 >
Re: [PATCH v2 4/4] arm: dts: add 8devices Habanero DVK
On Mon 25 Jan 04:59 CST 2021, Robert Marko wrote: > On Fri, Jan 22, 2021 at 7:56 PM Bjorn Andersson > wrote: > > > On Fri 02 Oct 12:41 CDT 2020, Robert Marko wrote: > > > > > On Wed, Sep 9, 2020 at 9:56 PM Robert Marko > > wrote: > > > > > > > > 8devices Habanero DVK is a dual-band SoM development kit based on > > Qualcomm > > > > IPQ4019 + QCA8075 platform. > > > > > > > > Specs are: > > > > CPU: QCA IPQ4019 > > > > RAM: DDR3L 512MB > > > > Storage: 32MB SPI-NOR and optional Parallel SLC NAND(Some boards ship > > with it and some without) > > > > WLAN1: 2.4 GHz built into IPQ4019 (802.11n) 2x2 > > > > WLAN2: 5 GHz built into IPO4019 (802.11ac Wawe-2) 2x2 > > > > Ethernet: 5x Gbit LAN (QCA 8075) > > > > USB: 1x USB 2.0 and 1x USB 3.0 (Both built into IPQ4019) > > > > MicroSD slot (Uses SD controller built into IPQ4019) > > > > SDIO3.0/EMMC slot (Uses the same SD controller) > > > > Mini PCI-E Gen 2.0 slot (Built into IPQ4019) > > > > 5x LEDs (4 GPIO controllable) > > > > 2x Pushbutton (1 is connected to GPIO, other to SoC reset) > > > > LCD ZIF socket (Uses the LCD controller built into IPQ4019 which has > > no driver support) > > > > 1x UART 115200 rate on J18 > > > > > > > > 2x breakout development headers > > > > 12V DC Jack for power > > > > DIP switch for bootstrap configuration > > > > > > > > Signed-off-by: Robert Marko > > > > Cc: Luka Perkov > > > > --- > > > > Changes since v1: > > > > * Drop include that does not exist > > > > > > > > arch/arm/boot/dts/Makefile| 1 + > > > > .../boot/dts/qcom-ipq4019-habanero-dvk.dts| 304 ++ > > > > 2 files changed, 305 insertions(+) > > > > create mode 100644 arch/arm/boot/dts/qcom-ipq4019-habanero-dvk.dts > > > > > > > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > > > > index 246d82fc5fcd..004262e0d699 100644 > > > > --- a/arch/arm/boot/dts/Makefile > > > > +++ b/arch/arm/boot/dts/Makefile > > > > @@ -898,6 +898,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \ > > > > qcom-ipq4019-ap.dk04.1-c3.dtb \ > > > > qcom-ipq4019-ap.dk07.1-c1.dtb \ > > > > qcom-ipq4019-ap.dk07.1-c2.dtb \ > > > > + qcom-ipq4019-habanero-dvk.dtb \ > > > > qcom-ipq8064-ap148.dtb \ > > > > qcom-ipq8064-rb3011.dtb \ > > > > qcom-msm8660-surf.dtb \ > > > > diff --git a/arch/arm/boot/dts/qcom-ipq4019-habanero-dvk.dts > > b/arch/arm/boot/dts/qcom-ipq4019-habanero-dvk.dts [..] > > > > > > Hi, > > > Is there an issue with the patch preventing the review? > > > > > > > Found this in my inbox and I don't know why I never replied to you, > > perhaps because kernel test robot says it doesn't build... > > > > I tried to apply it now but there's no "vqmmc" so it doesn't build :/ > > > > > > If you're still interested in this I'd be happy to merge it if you can > > fix up the vqmmc - and if respinning it I would appreciate if you could > > sort the nodes alphabetically. > > > > Regards, > > Bjorn > > > > Hi, > This patch series depends on: > https://patchwork.kernel.org/patch/11765789/ > https://patchwork.kernel.org/patch/11760437/ > > USB nodes appear to finally be picked for the Qcom tree while the VQMMC LDO > is still pending. > > I am still interested in this and was planning to send the updated versions > anyway soon. > I Will respin these and reorder the nodes. > I've pushed out the vqmmc patch now as well. Looking forward to the respin of this patch. Thank you, Bjorn
Re: [PATCH] arm: dts: IPQ4019: add SDHCI VQMMC LDO node
On Mon 07 Sep 05:19 CDT 2020, Robert Marko wrote:
> Since we now have driver for the SDHCI VQMMC LDO needed
> for I/0 voltage levels lets introduce the necessary node for it.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> ---
> arch/arm/boot/dts/qcom-ipq4019.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
> b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> index 6741a1972e55..7774dbd3cec7 100644
> --- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
> +++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> @@ -211,6 +211,16 @@ tlmm: pinctrl@100 {
> interrupts = ;
> };
>
> + vqmmc: regulator@1948000 {
> + compatible = "qcom,vqmmc-ipq4019-regulator";
> + reg = <0x01948000 0x4>;
The actual hardware block where this register is found is the "TCSR"
which is 0x01947000 of size 0x21000 - making this the register at offset
0x11000.
Perhaps it would have been better represented as a simple-mfd with this
regulator as a child node thereof.
That said, this has been sitting long enough, so I'll merge it as is and
we can rework it once we need more pieces of tcsr.
Thanks,
Bjorn
> + regulator-name = "vqmmc";
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <300>;
> + regulator-always-on;
> + status = "disabled";
> + };
> +
> sdhci: sdhci@7824900 {
> compatible = "qcom,sdhci-msm-v4";
> reg = <0x7824900 0x11c>, <0x7824000 0x800>;
> --
> 2.26.2
>
Re: [PATCH v3 6/6] drivers: crypto: qce: Remove totallen and offset in qce_start
On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:
> totallen is used to get the size of the data to be transformed.
> This is also available via nbytes or cryptlen in the qce_sha_reqctx
> and qce_cipher_ctx. Similarly offset convey nothing for the supported
> encryption and authentication transformations and is always 0.
> Remove these two redundant parameters in qce_start.
>
Please drop "drivers: " from $subject.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/common.c | 17 +++--
> drivers/crypto/qce/common.h | 3 +--
> drivers/crypto/qce/sha.c | 2 +-
> drivers/crypto/qce/skcipher.c | 2 +-
> 4 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> index f7bc701a4aa2..dceb9579d87a 100644
> --- a/drivers/crypto/qce/common.c
> +++ b/drivers/crypto/qce/common.c
> @@ -140,8 +140,7 @@ static u32 qce_auth_cfg(unsigned long flags, u32 key_size)
> return cfg;
> }
>
> -static int qce_setup_regs_ahash(struct crypto_async_request *async_req,
> - u32 totallen, u32 offset)
> +static int qce_setup_regs_ahash(struct crypto_async_request *async_req)
> {
> struct ahash_request *req = ahash_request_cast(async_req);
> struct crypto_ahash *ahash = __crypto_ahash_cast(async_req->tfm);
> @@ -306,8 +305,7 @@ static void qce_xtskey(struct qce_device *qce, const u8
> *enckey,
> qce_write(qce, REG_ENCR_XTS_DU_SIZE, cryptlen);
> }
>
> -static int qce_setup_regs_skcipher(struct crypto_async_request *async_req,
> - u32 totallen, u32 offset)
> +static int qce_setup_regs_skcipher(struct crypto_async_request *async_req)
> {
> struct skcipher_request *req = skcipher_request_cast(async_req);
> struct qce_cipher_reqctx *rctx = skcipher_request_ctx(req);
> @@ -367,7 +365,7 @@ static int qce_setup_regs_skcipher(struct
> crypto_async_request *async_req,
>
> qce_write(qce, REG_ENCR_SEG_CFG, encr_cfg);
> qce_write(qce, REG_ENCR_SEG_SIZE, rctx->cryptlen);
> - qce_write(qce, REG_ENCR_SEG_START, offset & 0x);
> + qce_write(qce, REG_ENCR_SEG_START, 0);
>
> if (IS_CTR(flags)) {
> qce_write(qce, REG_CNTR_MASK, ~0);
> @@ -376,7 +374,7 @@ static int qce_setup_regs_skcipher(struct
> crypto_async_request *async_req,
> qce_write(qce, REG_CNTR_MASK2, ~0);
> }
>
> - qce_write(qce, REG_SEG_SIZE, totallen);
> + qce_write(qce, REG_SEG_SIZE, rctx->cryptlen);
>
> /* get little endianness */
> config = qce_config_reg(qce, 1);
> @@ -388,17 +386,16 @@ static int qce_setup_regs_skcipher(struct
> crypto_async_request *async_req,
> }
> #endif
>
> -int qce_start(struct crypto_async_request *async_req, u32 type, u32 totallen,
> - u32 offset)
> +int qce_start(struct crypto_async_request *async_req, u32 type)
> {
> switch (type) {
> #ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> case CRYPTO_ALG_TYPE_SKCIPHER:
> - return qce_setup_regs_skcipher(async_req, totallen, offset);
> + return qce_setup_regs_skcipher(async_req);
> #endif
> #ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> case CRYPTO_ALG_TYPE_AHASH:
> - return qce_setup_regs_ahash(async_req, totallen, offset);
> + return qce_setup_regs_ahash(async_req);
> #endif
> default:
> return -EINVAL;
> diff --git a/drivers/crypto/qce/common.h b/drivers/crypto/qce/common.h
> index 85ba16418a04..3bc244bcca2d 100644
> --- a/drivers/crypto/qce/common.h
> +++ b/drivers/crypto/qce/common.h
> @@ -94,7 +94,6 @@ struct qce_alg_template {
> void qce_cpu_to_be32p_array(__be32 *dst, const u8 *src, unsigned int len);
> int qce_check_status(struct qce_device *qce, u32 *status);
> void qce_get_version(struct qce_device *qce, u32 *major, u32 *minor, u32
> *step);
> -int qce_start(struct crypto_async_request *async_req, u32 type, u32 totallen,
> - u32 offset);
> +int qce_start(struct crypto_async_request *async_req, u32 type);
>
> #endif /* _COMMON_H_ */
> diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
> index dd263c5e4dd8..a079e92b4e75 100644
> --- a/drivers/crypto/qce/sha.c
> +++ b/drivers/crypto/qce/sha.c
> @@ -113,7 +113,7 @@ static int qce_ahash_async_req_handle(struct
> crypto_async_request *async_req)
>
> qce_dma_issue_pending(>dma);
>
> - ret = qce_start(async_req, tmpl->crypto_alg_type, 0, 0);
> + ret = qce_start(async_req, tmpl->crypto_alg_type);
> if (ret)
>
Re: [PATCH v3 4/6] drivers: crypto: qce: common: Set data unit size to message length for AES XTS transformation
On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:
> Set the register REG_ENCR_XTS_DU_SIZE to cryptlen for AES XTS
> transformation. Anything else causes the engine to return back
> wrong results.
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/common.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> index a73db2a5637f..f7bc701a4aa2 100644
> --- a/drivers/crypto/qce/common.c
> +++ b/drivers/crypto/qce/common.c
> @@ -295,15 +295,15 @@ static void qce_xtskey(struct qce_device *qce, const u8
> *enckey,
> {
> u32 xtskey[QCE_MAX_CIPHER_KEY_SIZE / sizeof(u32)] = {0};
> unsigned int xtsklen = enckeylen / (2 * sizeof(u32));
> - unsigned int xtsdusize;
>
> qce_cpu_to_be32p_array((__be32 *)xtskey, enckey + enckeylen / 2,
> enckeylen / 2);
> qce_write_array(qce, REG_ENCR_XTS_KEY0, xtskey, xtsklen);
>
> - /* xts du size 512B */
> - xtsdusize = min_t(u32, QCE_SECTOR_SIZE, cryptlen);
I wonder if this is a hardware limitation that has gone away in the
newer chips. I am however not able to find anything about it, so I'm in
favor of merging this patch and if anyone actually uses the driver on
the older hardware we'd have to go back and quirk it somehow.
Acked-by: Bjorn Andersson
Regards,
Bjorn
> - qce_write(qce, REG_ENCR_XTS_DU_SIZE, xtsdusize);
> + /* Set data unit size to cryptlen. Anything else causes
> + * crypto engine to return back incorrect results.
> + */
> + qce_write(qce, REG_ENCR_XTS_DU_SIZE, cryptlen);
> }
>
> static int qce_setup_regs_skcipher(struct crypto_async_request *async_req,
> --
> 2.25.1
>
Re: [PATCH v3 5/6] drivers: crypto: qce: Remover src_tbl from qce_cipher_reqctx
On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:
> src_table is unused and hence remove it from struct qce_cipher_reqctx
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/cipher.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/crypto/qce/cipher.h b/drivers/crypto/qce/cipher.h
> index cffa9fc628ff..850f257d00f3 100644
> --- a/drivers/crypto/qce/cipher.h
> +++ b/drivers/crypto/qce/cipher.h
> @@ -40,7 +40,6 @@ struct qce_cipher_reqctx {
> struct scatterlist result_sg;
> struct sg_table dst_tbl;
> struct scatterlist *dst_sg;
> - struct sg_table src_tbl;
Please also remove the associated kerneldoc entry.
Regards,
Bjorn
> struct scatterlist *src_sg;
> unsigned int cryptlen;
> struct skcipher_request fallback_req; // keep at the end
> --
> 2.25.1
>
Re: [PATCH v3 3/6] drivers: crypto: qce: skcipher: Fix regressions found during fuzz testing
On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:
> This patch contains the following fixes for the supported encryption
> algorithms in the Qualcomm crypto engine(CE)
> 1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
> does not support this and the operation causes the engine to hang.
> 2. Return unsupported if any three keys are same for DES3 algorithms
> since CE does not support this and the operation causes the engine to
> hang.
> 3. Return unsupported for 0 length plain texts since crypto engine BAM
> dma does not support 0 length data.
> 4. ECB messages do not have an IV and hence set the ivsize to 0.
> 5. Ensure that the data passed for ECB/CBC encryption/decryption is
> blocksize aligned. Otherwise the CE hangs on the operation.
> 6. Allow messages of length less that 512 bytes for all other encryption
> algorithms other than AES XTS. The recommendation is only for AES XTS
> to have data size greater than 512 bytes.
>
This seems like 6 trivial changes, that if send individually will be
easy to reason about and if there's ever any regressions it will be easy
to bisect.
So please split this patch.
Regards,
Bjorn
> Signed-off-by: Thara Gopinath
> ---
>
> v2->v3:
> - Made the comparison between keys to check if any two keys are
> same for triple des algorithms constant-time as per
> Nym Seddon's suggestion.
>
> drivers/crypto/qce/skcipher.c | 68 ++-
> 1 file changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c
> index a2d3da0ad95f..d78b932441ab 100644
> --- a/drivers/crypto/qce/skcipher.c
> +++ b/drivers/crypto/qce/skcipher.c
> @@ -167,16 +167,32 @@ static int qce_skcipher_setkey(struct crypto_skcipher
> *ablk, const u8 *key,
> struct crypto_tfm *tfm = crypto_skcipher_tfm(ablk);
> struct qce_cipher_ctx *ctx = crypto_tfm_ctx(tfm);
> unsigned long flags = to_cipher_tmpl(ablk)->alg_flags;
> + unsigned int __keylen;
> int ret;
>
> if (!key || !keylen)
> return -EINVAL;
>
> - switch (IS_XTS(flags) ? keylen >> 1 : keylen) {
> + /*
> + * AES XTS key1 = key2 not supported by crypto engine.
> + * Revisit to request a fallback cipher in this case.
> + */
> + if (IS_XTS(flags)) {
> + __keylen = keylen >> 1;
> + if (!memcmp(key, key + __keylen, __keylen))
> + return -EINVAL;
> + } else {
> + __keylen = keylen;
> + }
> + switch (__keylen) {
> case AES_KEYSIZE_128:
> case AES_KEYSIZE_256:
> memcpy(ctx->enc_key, key, keylen);
> break;
> + case AES_KEYSIZE_192:
> + break;
> + default:
> + return -EINVAL;
> }
>
> ret = crypto_skcipher_setkey(ctx->fallback, key, keylen);
> @@ -204,12 +220,27 @@ static int qce_des3_setkey(struct crypto_skcipher
> *ablk, const u8 *key,
> unsigned int keylen)
> {
> struct qce_cipher_ctx *ctx = crypto_skcipher_ctx(ablk);
> + u32 _key[6];
> int err;
>
> err = verify_skcipher_des3_key(ablk, key);
> if (err)
> return err;
>
> + /*
> + * The crypto engine does not support any two keys
> + * being the same for triple des algorithms. The
> + * verify_skcipher_des3_key does not check for all the
> + * below conditions. Return -ENOKEY in case any two keys
> + * are the same. Revisit to see if a fallback cipher
> + * is needed to handle this condition.
> + */
> + memcpy(_key, key, DES3_EDE_KEY_SIZE);
> + if (!((_key[0] ^ _key[2]) | (_key[1] ^ _key[3])) |
> + !((_key[2] ^ _key[4]) | (_key[3] ^ _key[5])) |
> + !((_key[0] ^ _key[4]) | (_key[1] ^ _key[5])))
> + return -ENOKEY;
> +
> ctx->enc_keylen = keylen;
> memcpy(ctx->enc_key, key, keylen);
> return 0;
> @@ -221,6 +252,7 @@ static int qce_skcipher_crypt(struct skcipher_request
> *req, int encrypt)
> struct qce_cipher_ctx *ctx = crypto_skcipher_ctx(tfm);
> struct qce_cipher_reqctx *rctx = skcipher_request_ctx(req);
> struct qce_alg_template *tmpl = to_cipher_tmpl(tfm);
> + unsigned int blocksize = crypto_skcipher_blocksize(tfm);
> int keylen;
> int ret;
>
> @@ -228,14 +260,34 @@ static int qce_skcipher_crypt(struct skcipher_request
> *req, int encrypt)
> rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
> keylen = IS_XTS(rctx->flags) ? ctx->enc_keylen >> 1 : ctx->enc_keylen;
>
> - /* qce is hanging when AES-XTS request len > QCE_SECTOR_SIZE and
> - * is not a multiple of it; pass such requests to the fallback
> + /* CE does not handle 0 length messages */
> + if (!req->cryptlen)
> + return -EINVAL;
> +
> + /*
> + * ECB and CBC algorithms require message lengths to be
> + * multiples of block size.
> + *
Re: [PATCH v3 1/6] drivers: crypto: qce: sha: Restore/save ahash state with custom struct in export/import
On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:
Please drop "drivers: " from $subject.
> Export and import interfaces save and restore partial transformation
> states. The partial states were being stored and restored in struct
> sha1_state for sha1/hmac(sha1) transformations and sha256_state for
> sha256/hmac(sha256) transformations.This led to a bunch of corner cases
> where improper state was being stored and restored. A few of the corner
> cases that turned up during testing are:
>
> - wrong byte_count restored if export/import is called twice without h/w
> transaction in between
> - wrong buflen restored back if the pending buffer
> length is exactly the block size.
> - wrong state restored if buffer length is 0.
>
> To fix these issues, save and restore the partial transformation state
> using the newly introduced qce_sha_saved_state struct. This ensures that
> all the pieces required to properly restart the transformation is captured
> and restored back
>
> Signed-off-by: Thara Gopinath
> ---
>
> v1->v2:
> - Introduced custom struct qce_sha_saved_state to store and
> restore partial sha transformation. v1 was re-using
> qce_sha_reqctx to save and restore partial states and this
> could lead to potential memcpy issues around pointer copying.
>
> drivers/crypto/qce/sha.c | 122 +++
> 1 file changed, 34 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
> index 61c418c12345..08aed03e2b59 100644
> --- a/drivers/crypto/qce/sha.c
> +++ b/drivers/crypto/qce/sha.c
> @@ -12,9 +12,15 @@
> #include "core.h"
> #include "sha.h"
>
> -/* crypto hw padding constant for first operation */
> -#define SHA_PADDING 64
> -#define SHA_PADDING_MASK (SHA_PADDING - 1)
> +struct qce_sha_saved_state {
> + u8 pending_buf[QCE_SHA_MAX_BLOCKSIZE];
> + u8 partial_digest[QCE_SHA_MAX_DIGESTSIZE];
> + __be32 byte_count[2];
> + unsigned int pending_buflen;
> + unsigned int flags;
> + u64 count;
> + bool first_blk;
> +};
>
> static LIST_HEAD(ahash_algs);
>
> @@ -139,97 +145,37 @@ static int qce_ahash_init(struct ahash_request *req)
>
> static int qce_ahash_export(struct ahash_request *req, void *out)
> {
> - struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
> struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> - unsigned long flags = rctx->flags;
> - unsigned int digestsize = crypto_ahash_digestsize(ahash);
> - unsigned int blocksize =
> - crypto_tfm_alg_blocksize(crypto_ahash_tfm(ahash));
> -
> - if (IS_SHA1(flags) || IS_SHA1_HMAC(flags)) {
> - struct sha1_state *out_state = out;
> -
> - out_state->count = rctx->count;
> - qce_cpu_to_be32p_array((__be32 *)out_state->state,
> -rctx->digest, digestsize);
> - memcpy(out_state->buffer, rctx->buf, blocksize);
> - } else if (IS_SHA256(flags) || IS_SHA256_HMAC(flags)) {
> - struct sha256_state *out_state = out;
> -
> - out_state->count = rctx->count;
> - qce_cpu_to_be32p_array((__be32 *)out_state->state,
> -rctx->digest, digestsize);
> - memcpy(out_state->buf, rctx->buf, blocksize);
> - } else {
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> -static int qce_import_common(struct ahash_request *req, u64 in_count,
> - const u32 *state, const u8 *buffer, bool hmac)
> -{
> - struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
> - struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> - unsigned int digestsize = crypto_ahash_digestsize(ahash);
> - unsigned int blocksize;
> - u64 count = in_count;
> -
> - blocksize = crypto_tfm_alg_blocksize(crypto_ahash_tfm(ahash));
> - rctx->count = in_count;
> - memcpy(rctx->buf, buffer, blocksize);
> -
> - if (in_count <= blocksize) {
> - rctx->first_blk = 1;
> - } else {
> - rctx->first_blk = 0;
> - /*
> - * For HMAC, there is a hardware padding done when first block
> - * is set. Therefore the byte_count must be incremened by 64
> - * after the first block operation.
> - */
> - if (hmac)
> - count += SHA_PADDING;
> - }
> + struct qce_sha_saved_state *export_state = out;
>
> - rctx->byte_count[0] = (__force __be32)(count & ~SHA_PADDING_MASK);
> - rctx->byte_count[1] = (__force __be32)(count >> 32);
> - qce_cpu_to_be32p_array((__be32 *)rctx->digest, (const u8 *)state,
> -digestsize);
> - rctx->buflen = (unsigned int)(in_count & (blocksize - 1));
> + memcpy(export_state->pending_buf, rctx->buf, rctx->buflen);
> + memcpy(export_state->partial_digest, rctx->digest,
> +
Re: [PATCH] bus: qcom: Put child node before return
On Fri 22 Jan 16:47 CST 2021, Linus Walleij wrote:
> On Thu, Jan 21, 2021 at 12:49 PM Pan Bian wrote:
>
> > Put child node before return to fix potential reference count leak.
> > Generally, the reference count of child is incremented and decremented
> > automatically in the macro for_each_available_child_of_node() and should
> > be decremented manually if the loop is broken in loop body.
> >
> > Fixes: 335a12754808 ("bus: qcom: add EBI2 driver")
> > Signed-off-by: Pan Bian
>
> Reviewed-by: Linus Walleij
>
> Please submit this patch for inclusion through the ARM SoC tree.
>
Any objections to me picking it in the Qualcomm tree? Or that's what you
indirectly meant?
Regards,
Bjorn
Re: [PATCH] ARM: dts: qcom: add prng definition to ipq806x
On Sun 29 Nov 12:50 CST 2020, Jonathan McDowell wrote:
> Gentle poke; did this just get missed or is there some reason not to
> apply it?
>
There's no reason why this wasn't applied. I've picked it up now.
Thank you,
Bjorn
> On Sun, Jul 05, 2020 at 03:25:44PM +0100, Jonathan McDowell wrote:
> > Add missing prng definition for ipq806x SoC
> >
> > Signed-off-by: Jonathan McDowell
> > ---
> > arch/arm/boot/dts/qcom-ipq8064.dtsi | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
> > b/arch/arm/boot/dts/qcom-ipq8064.dtsi
> > index b912da9a3ff3..22e0669b9133 100644
> > --- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
> > +++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
> > @@ -386,6 +386,13 @@ gsbi7_serial: serial@1664 {
> > };
> > };
> >
> > + rng@1a50 {
> > + compatible = "qcom,prng";
> > + reg = <0x1a50 0x200>;
> > + clocks = < PRNG_CLK>;
> > + clock-names = "core";
> > + };
> > +
> > sata_phy: sata-phy@1b40 {
> > compatible = "qcom,ipq806x-sata-phy";
> > reg = <0x1b40 0x200>;
> > --
> > 2.27.0
> >
>
> J.
>
> --
> Revd Jonathan McDowell, ULC | Hail Eris. All hail Discordia. Fnord?
Re: [PATCH v2 4/4] arm: dts: add 8devices Habanero DVK
On Fri 02 Oct 12:41 CDT 2020, Robert Marko wrote:
> On Wed, Sep 9, 2020 at 9:56 PM Robert Marko wrote:
> >
> > 8devices Habanero DVK is a dual-band SoM development kit based on Qualcomm
> > IPQ4019 + QCA8075 platform.
> >
> > Specs are:
> > CPU: QCA IPQ4019
> > RAM: DDR3L 512MB
> > Storage: 32MB SPI-NOR and optional Parallel SLC NAND(Some boards ship with
> > it and some without)
> > WLAN1: 2.4 GHz built into IPQ4019 (802.11n) 2x2
> > WLAN2: 5 GHz built into IPO4019 (802.11ac Wawe-2) 2x2
> > Ethernet: 5x Gbit LAN (QCA 8075)
> > USB: 1x USB 2.0 and 1x USB 3.0 (Both built into IPQ4019)
> > MicroSD slot (Uses SD controller built into IPQ4019)
> > SDIO3.0/EMMC slot (Uses the same SD controller)
> > Mini PCI-E Gen 2.0 slot (Built into IPQ4019)
> > 5x LEDs (4 GPIO controllable)
> > 2x Pushbutton (1 is connected to GPIO, other to SoC reset)
> > LCD ZIF socket (Uses the LCD controller built into IPQ4019 which has no
> > driver support)
> > 1x UART 115200 rate on J18
> >
> > 2x breakout development headers
> > 12V DC Jack for power
> > DIP switch for bootstrap configuration
> >
> > Signed-off-by: Robert Marko
> > Cc: Luka Perkov
> > ---
> > Changes since v1:
> > * Drop include that does not exist
> >
> > arch/arm/boot/dts/Makefile| 1 +
> > .../boot/dts/qcom-ipq4019-habanero-dvk.dts| 304 ++
> > 2 files changed, 305 insertions(+)
> > create mode 100644 arch/arm/boot/dts/qcom-ipq4019-habanero-dvk.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 246d82fc5fcd..004262e0d699 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -898,6 +898,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
> > qcom-ipq4019-ap.dk04.1-c3.dtb \
> > qcom-ipq4019-ap.dk07.1-c1.dtb \
> > qcom-ipq4019-ap.dk07.1-c2.dtb \
> > + qcom-ipq4019-habanero-dvk.dtb \
> > qcom-ipq8064-ap148.dtb \
> > qcom-ipq8064-rb3011.dtb \
> > qcom-msm8660-surf.dtb \
> > diff --git a/arch/arm/boot/dts/qcom-ipq4019-habanero-dvk.dts
> > b/arch/arm/boot/dts/qcom-ipq4019-habanero-dvk.dts
> > new file mode 100644
> > index ..fe054adda0a7
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/qcom-ipq4019-habanero-dvk.dts
> > @@ -0,0 +1,304 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +/* Copyright (c) 2019, Robert Marko */
> > +
> > +#include "qcom-ipq4019.dtsi"
> > +#include
> > +#include
> > +
> > +/ {
> > + model = "8devices Habanero DVK";
> > + compatible = "8dev,habanero-dvk";
> > +
> > + keys {
> > + compatible = "gpio-keys";
> > +
> > + reset {
> > + label = "reset";
> > + gpios = < 8 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + };
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + led_status: status {
> > + label = "habanero-dvk:green:status";
> > + gpios = < 37 GPIO_ACTIVE_HIGH>;
> > + panic-indicator;
> > + };
> > +
> > + led_upgrade: upgrade {
> > + label = "habanero-dvk:green:upgrade";
> > + gpios = < 40 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> > + wlan2g {
> > + label = "habanero-dvk:green:wlan2g";
> > + gpios = < 46 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "phy0tpt";
> > + };
> > +
> > + wlan5g {
> > + label = "habanero-dvk:green:wlan5g";
> > + gpios = < 48 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "phy1tpt";
> > + };
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +
> > + pinctrl-0 = <_pins>;
> > + pinctrl-names = "default";
> > + cd-gpios = < 22 GPIO_ACTIVE_LOW>;
> > + vqmmc-supply = <>;
> > +};
> > +
> > +_bam {
> > + status = "okay";
> > +};
> > +
> > + {
> > + mdio_pins: mdio_pinmux {
> > + mux_1 {
> > + pins = "gpio6";
> > + function = "mdio";
> > + bias-pull-up;
> > + };
> > +
> > + mux_2 {
> > + pins = "gpio7";
> > + function = "mdc";
> > + bias-pull-up;
> > + };
> > + };
> > +
> > + serial_pins: serial_pinmux {
> > + mux {
> > + pins = "gpio16", "gpio17";
> > + function = "blsp_uart0";
> > + bias-disable;
> > + };
> > + };
> > +
> > + spi_0_pins: spi_0_pinmux {
> > + pinmux {
> > + function =
Re: [PATCH 1/4] ARM: dts: qcom: msm8974: add gpu support
On Wed 30 Dec 09:51 CST 2020, Iskren Chernev wrote:
> From: Brian Masney
>
> Add support for the a3xx GPU
>
> Signed-off-by: Brian Masney
As discussed on IRC I'm waiting for a respin of this with your S-o-b
added after Brian's.
Thanks,
Bjorn
> ---
> arch/arm/boot/dts/qcom-msm8974.dtsi | 45 +
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 51f5f904f9eb9..c399446d8154e 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -1399,6 +1399,51 @@ cnoc: interconnect@fc48 {
>< RPM_SMD_CNOC_A_CLK>;
> };
>
> + gpu_opp_table: opp_table {
> + status = "disabled";
> +
> + compatible = "operating-points-v2";
> +
> + opp-8 {
> + opp-hz = /bits/ 64 <8>;
> + };
> +
> + opp-5 {
> + opp-hz = /bits/ 64 <5>;
> + };
> +
> + opp-27500 {
> + opp-hz = /bits/ 64 <27500>;
> + };
> + };
> +
> + gpu: adreno@fdb0 {
> + status = "disabled";
> +
> + compatible = "qcom,adreno-330.2",
> + "qcom,adreno";
> + reg = <0xfdb0 0x1>;
> + reg-names = "kgsl_3d0_reg_memory";
> + interrupts = ;
> + interrupt-names = "kgsl_3d0_irq";
> + clock-names = "core",
> + "iface",
> + "mem_iface";
> + clocks = < OXILI_GFX3D_CLK>,
> + < OXILICX_AHB_CLK>,
> + < OXILICX_AXI_CLK>;
> + sram = <_sram>;
> + power-domains = < OXILICX_GDSC>;
> + operating-points-v2 = <_opp_table>;
> +
> + interconnects = < MNOC_MAS_GRAPHICS_3D
> BIMC_SLV_EBI_CH0>,
> + < OCMEM_VNOC_MAS_GFX3D
> OCMEM_SLV_OCMEM>;
> + interconnect-names = "gfx-mem",
> + "ocmem";
> +
> + // iommus = <_iommu 0>;
> + };
> +
> mdss: mdss@fd90 {
> status = "disabled";
>
>
> base-commit: d7a03a44a5e93f39ece70ec75d25c6088caa0fdb
> prerequisite-patch-id: aba6f684932cab35d98457c21e4ff7a5ac75c753
> prerequisite-patch-id: 4884d57df1bd197896b69e115d9002d6c26ae2e2
> prerequisite-patch-id: 4f1aba3c3675236b18578eedbe71b0cdca01ed77
> prerequisite-patch-id: cbfe6ccfebb142370baff15bbdf3cf2f34ee77df
> --
> 2.29.2
>
Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
On Thu 21 Jan 22:01 CST 2021, Wesley Cheng wrote:
> Some devices have USB compositions which may require multiple endpoints
> that support EP bursting. HW defined TX FIFO sizes may not always be
> sufficient for these compositions. By utilizing flexible TX FIFO
> allocation, this allows for endpoints to request the required FIFO depth to
> achieve higher bandwidth. With some higher bMaxBurst configurations, using
> a larger TX FIFO size results in better TX throughput.
>
> By introducing the check_config() callback, the resizing logic can fetch
> the maximum number of endpoints used in the USB composition (can contain
> multiple configurations), which helps ensure that the resizing logic can
> fulfill the configuration(s), or return an error to the gadget layer
> otherwise during bind time.
>
> Signed-off-by: Wesley Cheng
> ---
> drivers/usb/dwc3/core.c | 2 +
> drivers/usb/dwc3/core.h | 8 ++
> drivers/usb/dwc3/ep0.c| 2 +
> drivers/usb/dwc3/gadget.c | 194
> ++
> 4 files changed, 206 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 6969196..e7fa6af 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1284,6 +1284,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> _thr_num_pkt_prd);
> device_property_read_u8(dev, "snps,tx-max-burst-prd",
> _max_burst_prd);
> + dwc->needs_fifo_resize = device_property_read_bool(dev,
> +"tx-fifo-resize");
Under what circumstances should we specify this? And in particular are
there scenarios (in the Qualcomm platforms) where this must not be set?
In particular, the composition can be changed in runtime, so should we
set this for all Qualcomm platforms?
And if that's the case, can we not just set it from the qcom driver?
Regards,
Bjorn
>
> dwc->disable_scramble_quirk = device_property_read_bool(dev,
> "snps,disable_scramble_quirk");
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index eec1cf4..983b2fd4 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -1223,6 +1223,7 @@ struct dwc3 {
> unsignedis_utmi_l1_suspend:1;
> unsignedis_fpga:1;
> unsignedpending_events:1;
> + unsignedneeds_fifo_resize:1;
> unsignedpullups_connected:1;
> unsignedsetup_packet_pending:1;
> unsignedthree_stage_setup:1;
> @@ -1257,6 +1258,10 @@ struct dwc3 {
> unsigneddis_split_quirk:1;
>
> u16 imod_interval;
> +
> + int max_cfg_eps;
> + int last_fifo_depth;
> + int num_ep_resized;
> };
>
> #define INCRX_BURST_MODE 0
> @@ -1471,6 +1476,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep,
> unsigned int cmd,
> struct dwc3_gadget_ep_cmd_params *params);
> int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned int cmd,
> u32 param);
> +void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc);
> #else
> static inline int dwc3_gadget_init(struct dwc3 *dwc)
> { return 0; }
> @@ -1490,6 +1496,8 @@ static inline int dwc3_send_gadget_ep_cmd(struct
> dwc3_ep *dep, unsigned int cmd,
> static inline int dwc3_send_gadget_generic_command(struct dwc3 *dwc,
> int cmd, u32 param)
> { return 0; }
> +static inline void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
> +{ }
> #endif
>
> #if IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 8b668ef..4f216bd 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -616,6 +616,8 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
> usb_ctrlrequest *ctrl)
> return -EINVAL;
>
> case USB_STATE_ADDRESS:
> + dwc3_gadget_clear_tx_fifos(dwc);
> +
> ret = dwc3_ep0_delegate_req(dwc, ctrl);
> /* if the cfg matches and the cfg is non zero */
> if (cfg && (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 86f257f..26f9d64 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -615,6 +615,161 @@ static int dwc3_gadget_set_ep_config(struct dwc3_ep
> *dep, unsigned int action)
> static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force,
> bool interrupt);
>
> +static int dwc3_gadget_calc_tx_fifo_size(struct dwc3 *dwc, int mult)
> +{
> + int max_packet = 1024;
> + int fifo_size;
> + int mdwidth;
> +
> + mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
> + /* MDWIDTH is represented in bits, we need it in bytes */
> +
Re: [PATCH v5 2/2] pinctrl: qcom: Add SM8350 pinctrl driver
On Thu 21 Jan 11:17 CST 2021, Vinod Koul wrote: > This adds pincontrol driver for tlmm block found in SM8350 SoC > > This patch is based on initial code downstream by Raghavendra. > > Signed-off-by: Raghavendra Rao Ananta With Raghavendra's s-o-b here he should be From:, but based on the changes you've done I don't think he has certified the origin of this patch anymore. So the line crediting his work above and your alone S-o-b seems more reasonable. For the content of the patch: Reviewed-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Jeevan Shriram > Signed-off-by: Vinod Koul
Re: [PATCH v5 1/2] dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings
On Thu 21 Jan 11:17 CST 2021, Vinod Koul wrote: > Add device tree binding Documentation details for Qualcomm SM8350 > pinctrl driver. > Reviewed-by: Bjorn Andersson Although that's dependent on the acceptance of the common binding in a state similar its current one. Regards, Bjorn > Signed-off-by: Vinod Koul > --- > .../bindings/pinctrl/qcom,sm8350-pinctrl.yaml | 146 ++ > 1 file changed, 146 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml > > diff --git > a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml > b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml > new file mode 100644 > index ..706bc79db60b > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml > @@ -0,0 +1,146 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-pinctrl.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Technologies, Inc. SM8350 TLMM block > + > +maintainers: > + - Vinod Koul > + > +description: | > + This binding describes the Top Level Mode Multiplexer (TLMM) block found > + in the SM8350 platform. > + > +allOf: > + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# > + > +properties: > + compatible: > +const: qcom,sm8350-tlmm > + > + reg: > +maxItems: 1 > + > + interrupts: true > + interrupt-controller: true > + '#interrupt-cells': true > + gpio-controller: true > + gpio-reserved-ranges: true > + '#gpio-cells': true > + gpio-ranges: true > + wakeup-parent: true > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > + > +patternProperties: > + '-state$': > +oneOf: > + - $ref: "#/$defs/qcom-sm8350-tlmm-state" > + - patternProperties: > + ".*": > +$ref: "#/$defs/qcom-sm8350-tlmm-state" > + > +'$defs': > + qcom-sm8350-tlmm-state: > +type: object > +description: > + Pinctrl node's client devices use subnodes for desired pin > configuration. > + Client device subnodes use below standard properties. > +$ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" > + > +properties: > + pins: > +description: > + List of gpio pins affected by the properties specified in this > + subnode. > +items: > + oneOf: > +- pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-3])$" > +- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, > sdc2_data ] > +minItems: 1 > +maxItems: 36 > + > + function: > +description: > + Specify the alternative function to be configured for the specified > + pins. > + > +enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async, > +cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, > cri_trng, > +cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, > +ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, > gcc_gp3, > +gpio, ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync, > mdp_vsync0, > +mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1, > +mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck, > +mi2s1_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, > +mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12, > +mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6, > +mss_grfc7, mss_grfc8, mss_grfc9, nav_gpio, pa_indicator, > +pcie0_clkreqn, pcie1_clkreqn, phase_flag, pll_bist, pll_clk, > +pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable, > +qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request, > +qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss, > qspi0, > +qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10, > +qup11, qup12, qup13, qup14, qup15, qup16, qup17, qup18, > qup19, > +qup2, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, > qup_l5, > +qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk, > +sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, > +tgu_ch3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data, > +uim0_present, uim0_reset, uim1_clk, uim1_data, uim1_prese
Re: [PATCH 1/3] dt-bindings: pinctrl: qcom: Define common TLMM binding
On Thu 21 Jan 07:20 CST 2021, Linus Walleij wrote: > On Wed, Jan 20, 2021 at 11:21 PM Bjorn Andersson > wrote: > > > Several properties are shared between all TLMM bindings. By providing a > > common binding to define these properties each platform's binding can be > > reduced to just listing which of these properties should be checked for > > - or further specified. > > > > Signed-off-by: Bjorn Andersson > > Overall it looks good, just cutting some slack for reviewers (especially > DT people) before applying. > > > +description: > > + This defines the common properties used to describe all Qualcomm TLMM > > + bindings and pinconf/pinmux states for these. > > I vaguely recall asking you in the past what the acronym TLMM actually > means. This would be a good place to expand the acronym so people > know what these four letters actually represent. > As Vinod said, it's used in a few places and I agree that we should spell it out here. In particular I had to include "phandle" in the list of valid properties for for the dtbs_check to pass when there are references to state nodes, so I would like to hear from Rob about that. Will respin this after getting his input - hopefully with his Ack ;) > (There, I finally gave you an official reason to go and poke Qualcomm > hardware engineers about this. ;) > :) Regards, Bjorn
Re: [PATCH] pinctrl: qcom: spmi-gpio: Assign boolean values to a bool variable
On Wed 20 Jan 01:29 CST 2021, Jiapeng Zhong wrote: > Fix the following coccicheck warnings: > > ./drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c:340:3-15: WARNING: > Assignment of 0/1 to bool variable. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Zhong Reviewed-by: Bjorn Andersson Although we're mixing bool/int on line 417 and 637 as well, with: val |= pin->disable; and pin->disable = val & BIT(0); respectively. The latter could be dealt with using !!(val & BIT(0)); I guess the appropriate for for the prior is: if (pin->disable) val |= BIT(0); If you would like to update your patch with these as well I'd be happy to review this. Thanks, Bjorn > --- > drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c > b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c > index b5949f7..eb0b60c 100644 > --- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c > +++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c > @@ -331,13 +331,13 @@ static int pm8xxx_pin_config_set(struct pinctrl_dev > *pctldev, > case PIN_CONFIG_BIAS_DISABLE: > pin->bias = PM8XXX_GPIO_BIAS_NP; > banks |= BIT(2); > - pin->disable = 0; > + pin->disable = false; > banks |= BIT(3); > break; > case PIN_CONFIG_BIAS_PULL_DOWN: > pin->bias = PM8XXX_GPIO_BIAS_PD; > banks |= BIT(2); > - pin->disable = 0; > + pin->disable = false; > banks |= BIT(3); > break; > case PM8XXX_QCOM_PULL_UP_STRENGTH: > @@ -350,11 +350,11 @@ static int pm8xxx_pin_config_set(struct pinctrl_dev > *pctldev, > case PIN_CONFIG_BIAS_PULL_UP: > pin->bias = pin->pull_up_strength; > banks |= BIT(2); > - pin->disable = 0; > + pin->disable = false; > banks |= BIT(3); > break; > case PIN_CONFIG_BIAS_HIGH_IMPEDANCE: > - pin->disable = 1; > + pin->disable = true; > banks |= BIT(3); > break; > case PIN_CONFIG_INPUT_ENABLE: > -- > 1.8.3.1 >
Re: [PATCH 2/2] clk: qcom: gcc: Add global clock controller driver for SC8180x
On Wed 20 Jan 16:35 CST 2021, Bjorn Andersson wrote:
> diff --git a/drivers/clk/qcom/gcc-sc8180x.c b/drivers/clk/qcom/gcc-sc8180x.c
[..]
> +static struct gdsc emac_gdsc = {
> + .gdscr = 0x106004,
Seems like I missed squashing the fixup where I subtract the gcc base
address after migrating these from the downstream dts.
As written the platform doesn't boot.
Please let me know if there's any other feedback before I respin v2.
Regards,
Bjorn
> + .pd = {
> + .name = "emac_gdsc",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .flags = POLL_CFG_GDSCR,
> +};
[PATCH 2/2] iommu/arm-smmu-qcom: Add Qualcomm SC8180X impl
The primary SMMU found in Qualcomm SC8180X platform needs to use the
Qualcomm implementation, so add a specific compatible for this.
Signed-off-by: Bjorn Andersson
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index bcda17012aee..82c7edc6e025 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -166,6 +166,7 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,sc7180-mdss" },
{ .compatible = "qcom,sc7180-mss-pil" },
+ { .compatible = "qcom,sc8180x-mdss" },
{ .compatible = "qcom,sdm845-mdss" },
{ .compatible = "qcom,sdm845-mss-pil" },
{ }
@@ -327,6 +328,7 @@ static struct arm_smmu_device *qcom_smmu_create(struct
arm_smmu_device *smmu,
static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
{ .compatible = "qcom,msm8998-smmu-v2" },
{ .compatible = "qcom,sc7180-smmu-500" },
+ { .compatible = "qcom,sc8180x-smmu-500" },
{ .compatible = "qcom,sdm630-smmu-v2" },
{ .compatible = "qcom,sdm845-smmu-500" },
{ .compatible = "qcom,sm8150-smmu-500" },
--
2.29.2
[PATCH 1/2] dt-bindings: arm-smmu-qcom: Add Qualcomm SC8180X compatible
Add compatible for the ARM SMMU found in the Qualcomm SC8180x platform. Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 3b63f2ae24db..c50198e17d52 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -34,6 +34,7 @@ properties: items: - enum: - qcom,sc7180-smmu-500 + - qcom,sc8180x-smmu-500 - qcom,sdm845-smmu-500 - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 -- 2.29.2
