* [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Markus Mayer @ 2017-05-03 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90f011d6-9241-e860-7a0e-2fb52c2337ce@gmail.com>
Hi Rob,
On 27 April 2017 at 15:00, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 04/27/2017 02:57 PM, Rob Herring wrote:
>>>>> +Optional properties:
>>>>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>>
>> Don't use cell-index. It's not a valid property for FDT (only real
>> OpenFirmware).
>
> My bad, I was advising Markus to use this property since it was largely
> used throughout Documentation/devicetree/bindings/. What would be a more
> appropriate way to have the same information? Aliases?
Hopefully this will be the last time we need to pester you about this.
What should we be using instead of cell-index to identify multiple
instances of a device?
To give you an idea of what the code looks like right now:
ret = of_property_read_u32(dev->of_node, "cell-index", &index);
if (ret)
index = 0;
[...]
dev_set_name(dpfe_dev, "dpfe%u", index);
ret = device_register(dpfe_dev);
Enumerating the devices like this is what we are after.
Thanks,
-Markus
^ permalink raw reply
* [PATCH v8 2/7] doc: Add documentation for Coresight CPU debug
From: Mathieu Poirier @ 2017-05-03 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493719717-27698-3-git-send-email-leo.yan@linaro.org>
On Tue, May 02, 2017 at 06:08:32PM +0800, Leo Yan wrote:
> Update kernel-parameters.txt to add new parameter:
> coresight_cpu_debug.enable is a knob to enable debugging at boot time.
>
> Add detailed documentation, which contains the implementation, Mike
> Leach excellent summary for "clock and power domain". At the end some
> examples on how to enable the debugging functionality are provided.
>
> Suggested-by: Mike Leach <mike.leach@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 7 +
> Documentation/trace/coresight-cpu-debug.txt | 174 ++++++++++++++++++++++++
Please add coresight-cpu-debug.txt to the list of maintained files in
MAINTAINERS. Moreover I'm pretty sure John will want you to split this patch in
two, i.e one patch for kernel-parameters.txt and another for
coresight-cpu-debug.txt
> 2 files changed, 181 insertions(+)
> create mode 100644 Documentation/trace/coresight-cpu-debug.txt
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index facc20a..cf90146 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -650,6 +650,13 @@
> /proc/<pid>/coredump_filter.
> See also Documentation/filesystems/proc.txt.
>
> + coresight_cpu_debug.enable
> + [ARM,ARM64]
> + Format: <bool>
> + Enable/disable the CPU sampling based debugging.
> + 0: default value, disable debugging
> + 1: enable debugging at boot time
> +
> cpuidle.off=1 [CPU_IDLE]
> disable the cpuidle sub-system
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.txt
> new file mode 100644
> index 0000000..0426d50
> --- /dev/null
> +++ b/Documentation/trace/coresight-cpu-debug.txt
> @@ -0,0 +1,174 @@
> + Coresight CPU Debug Module
> + ==========================
> +
> + Author: Leo Yan <leo.yan@linaro.org>
> + Date: April 5th, 2017
> +
> +Introduction
> +------------
> +
> +Coresight CPU debug module is defined in ARMv8-a architecture reference manual
> +(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
> +debug module and it is mainly used for two modes: self-hosted debug and
> +external debug. Usually the external debug mode is well known as the external
> +debugger connects with SoC from JTAG port; on the other hand the program can
> +explore debugging method which rely on self-hosted debug mode, this document
> +is to focus on this part.
> +
> +The debug module provides sample-based profiling extension, which can be used
> +to sample CPU program counter, secure state and exception level, etc; usually
> +every CPU has one dedicated debug module to be connected. Based on self-hosted
> +debug mechanism, Linux kernel can access these related registers from mmio
> +region when the kernel panic happens. The callback notifier for kernel panic
> +will dump related registers for every CPU; finally this is good for assistant
> +analysis for panic.
> +
> +
> +Implementation
> +--------------
> +
> +- During driver registration, use EDDEVID and EDDEVID1 two device ID
> + registers to decide if sample-based profiling is implemented or not. On some
> + platforms this hardware feature is fully or partialy implemented; and if
> + this feature is not supported then registration will fail.
> +
> +- When write this doc, the debug driver mainly relies on three sampling
> + registers. The kernel panic callback notifier gathers info from EDPCSR
> + EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has
> + information for secure state, exception level, bit width, etc; EDCIDSR is
> + context ID value which contains the sampled value of CONTEXTIDR_EL1.
> +
> +- The driver supports CPU running mode with either AArch64 or AArch32. The
> + registers naming convention is a bit different between them, AArch64 uses
> + 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
> + 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
> + use AArch64 naming convention.
> +
> +- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
> + register bits definition. So the driver consolidates two difference:
> +
> + If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented;
> + but ARMv7-a defines "PCSR samples are offset by a value that depends on the
> + instruction set state". For ARMv7-a, the driver checks furthermore if CPU
> + runs with ARM or thumb instruction set and calibrate PCSR value, the
> + detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
> + C11.11.34 "DBGPCSR, Program Counter Sampling Register".
> +
> + If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
> + no offset applied and do not sample the instruction set state in AArch32
> + state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
> + in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
> + state EDPCSR is sampled and no offset are applied.
> +
> +
> +Clock and power domain
> +----------------------
> +
> +Before accessing debug registers, we should ensure the clock and power domain
> +have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
> +Debug registers', the debug registers are spread into two domains: the debug
> +domain and the CPU domain.
> +
> + +---------------+
> + | |
> + | |
> + +----------+--+ |
> + dbg_clk -->| |**| |<-- cpu_clk
> + | Debug |**| CPU |
> + dbg_pd -->| |**| |<-- cpu_pd
> + +----------+--+ |
> + | |
> + | |
> + +---------------+
> +
> +For debug domain, the user uses DT binding "clocks" and "power-domains" to
> +specify the corresponding clock source and power supply for the debug logic.
> +The driver calls the pm_runtime_{put|get} operations as needed to handle the
> +debug power domain.
> +
> +For CPU domain, the different SoC designs have different power management
> +schemes and finally this heavily impacts external debug module. So we can
> +divide into below cases:
> +
> +- On systems with a sane power controller which can behave correctly with
> + respect to CPU power domain, the CPU power domain can be controlled by
> + register EDPRCR in driver. The driver firstly writes bit EDPRCR.COREPURQ
> + to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation
> + of CPU power down. As result, this can ensure the CPU power domain is
> + powered on properly during the period when access debug related registers;
> +
> +- Some designs will power down an entire cluster if all CPUs on the cluster
> + are powered down - including the parts of the debug registers that should
> + remain powered in the debug power domain. The bits in EDPRCR are not
> + respected in these cases, so these designs do not support debug over
> + power down in the way that the CoreSight / Debug designers anticipated.
> + This means that even checking EDPRSR has the potential to cause a bus hang
> + if the target register is unpowered.
> +
> + In this case, accessing to the debug registers while they are not powered
> + is a recipe for disaster; so we need preventing CPU low power states at boot
> + time or when user enable module at the run time. Please see chapter
> + "How to use the module" for detailed usage info for this.
> +
> +
> +Device Tree Bindings
> +--------------------
> +
> +See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details.
> +
> +
> +How to use the module
> +---------------------
> +
> +If you want to enable debugging functionality at boot time, you can add
> +"coresight_cpu_debug.enable=1" to the kernel command line parameter.
> +
> +The driver also can work as module, so can enable the debugging when insmod
> +module:
> +# insmod coresight_cpu_debug.ko debug=1
> +
> +When boot time or insmod module you have not enabled the debugging, the driver
> +uses the debugfs file system to provide a knob to dynamically enable or disable
> +debugging:
> +
> +To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
> +# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +
> +To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
> +# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
> +
> +As explained in chapter "Clock and power domain", if you are working on one
> +platform which has idle states to power off debug logic and the power
> +controller cannot work well for the request from EDPRCR, then you should
> +firstly constraint CPU idle states before enable CPU debugging feature; so can
> +ensure the accessing to debug logic.
> +
> +If you want to limit idle states at boot time, you can use "nohlt" or
> +"cpuidle.off=1" in the kernel command line.
> +
> +At the runtime you can disable idle states with below methods:
> +
> +Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
> +states (if latency = 0uS then disable all idle states):
> +# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> +
> +Disable specific CPU's specific idle state:
> +# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> +
> +
> +Output format
> +-------------
> +
> +Here is an example of the debugging output format:
> +
> +ARM external debug module:
> +CPU[0]:
> + EDPRSR: 0000000b (Power:On DLK:Unlock)
> + EDPCSR: [<ffff00000808eb54>] handle_IPI+0xe4/0x150
> + EDCIDSR: 00000000
> + EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> +CPU[1]:
> + EDPRSR: 0000000b (Power:On DLK:Unlock)
> + EDPCSR: [<ffff0000087a64c0>] debug_notifier_call+0x108/0x288
> + EDCIDSR: 00000000
> + EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> --
> 2.7.4
>
^ permalink raw reply
* linux-next: build warning after merge of the drm tree
From: Stephen Rothwell @ 2017-05-03 22:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Sorry that I did not notice this at the time ... This is now in Linus'
tree.
After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP
arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI
arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI
arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI
Introduced by commit
8820b68bd378 ("drm/rockchip: Refactor the component match logic.")
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] Documentation: earlycon: fix Marvell Armada 3700 UART name
From: Andre Przywara @ 2017-05-03 23:49 UTC (permalink / raw)
To: linux-arm-kernel
The Marvell Armada 3700 UART uses "ar3700_uart" for its earlycon name.
Adjust documentation to match the code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index facc20a..7ee86c2 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -973,7 +973,7 @@
A valid base address must be provided, and the serial
port must already be setup and configured.
- armada3700_uart,<addr>
+ ar3700_uart,<addr>
Start an early, polled-mode console on the
Armada 3700 serial port at the specified
address. The serial port must already be setup
--
2.8.2
^ permalink raw reply related
* linux-next: build failure after merge of the drm-misc tree
From: Stephen Rothwell @ 2017-05-03 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421121014.3ee14a83@canb.auug.org.au>
Hi all,
On Fri, 21 Apr 2017 12:10:14 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in initializer
> .kmap_atomic = tee_shm_op_kmap_atomic,
> ^
> drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .kmap_atomic = tee_shm_op_kmap_atomic,
> ^
> drivers/tee/tee_shm.c:87:17: note: (near initialization for 'tee_shm_dma_buf_ops.begin_cpu_access')
> drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in initializer
> .kmap = tee_shm_op_kmap,
> ^
> drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .kmap = tee_shm_op_kmap,
> ^
> drivers/tee/tee_shm.c:88:10: note: (near initialization for 'tee_shm_dma_buf_ops.end_cpu_access')
>
> Caused by commit
>
> f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro")
>
> interacting with commit
>
> 967c9cca2cc5 ("tee: generic TEE subsystem")
>
> from the arm-soc tree.
>
> I applied the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 21 Apr 2017 12:06:32 +1000
> Subject: [PATCH] tee: merge fix for dma-ops field name changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/tee/tee_shm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 0be1e3e93bee..4e14c9c9cb1c 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
> .map_dma_buf = tee_shm_op_map_dma_buf,
> .unmap_dma_buf = tee_shm_op_unmap_dma_buf,
> .release = tee_shm_op_release,
> - .kmap_atomic = tee_shm_op_kmap_atomic,
> - .kmap = tee_shm_op_kmap,
> + .map_atomic = tee_shm_op_kmap_atomic,
> + .map = tee_shm_op_kmap,
> .mmap = tee_shm_op_mmap,
> };
>
> --
> 2.11.0
This fixup is now needed when merging the arm-soc tree with Linus' tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] pinctrl: use non-devm kmalloc versions for free functions
From: Andre Przywara @ 2017-05-03 23:57 UTC (permalink / raw)
To: linux-arm-kernel
When a pinctrl driver gets interrupted during its probe process
(returning -EPROBE_DEFER), the devres system cleans up all allocated
resources. During this process it calls pinmux_generic_free_functions()
and pinctrl_generic_free_groups(), which in turn use managed kmalloc
calls for temporarily allocating some memory. Now those calls seem to
get added to the devres list, but are apparently not covered by the
cleanup process, because this is actually just running and iterating the
existing list. This leads to those mallocs being left with the device,
which the devres manager complains about when the driver eventually gets
probed again:
[ 0.825239] ------------[ cut here ]------------
[ 0.825256] WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349 driver_probe_device+0x2ac/0x2e8
[ 0.825258] Modules linked in:
[ 0.825262]
[ 0.825270] CPU: 1 PID: 89 Comm: kworker/1:1 Not tainted 4.11.0 #307
[ 0.825272] Hardware name: Pine64+ (DT)
[ 0.825283] Workqueue: events deferred_probe_work_func
[ 0.825288] task: ffff80007c19c100 task.stack: ffff80007c16c000
[ 0.825292] PC is at driver_probe_device+0x2ac/0x2e8
[ 0.825296] LR is at driver_probe_device+0x108/0x2e8
[ 0.825300] pc : [<ffff000008559234>] lr : [<ffff000008559090>] pstate: 20000045
....
This warning is triggered because the devres list is not empty. In this
case the allocations were using 0 bytes, so no real leaks, but still this
ugly warning.
Looking more closely at these *cleanup* functions, devm_kzalloc() is actually
not needed, because the memory is just allocated temporarily and can be
freed just before returning from this function.
So fix this issue by using the bog standard kcalloc() call instead of
devm_kzalloc() and kfree()ing the memory at the end.
This fixes above warnings on boot, which can be observed on *some* builds
for the Pine64, where the pinctrl driver gets loaded early, but it missing
resources, so gets deferred and is loaded again (successfully) later.
kernelci caught this as well [1].
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[1] https://storage.kernelci.org/net-next/master/v4.11-rc8-2122-gc08bac03d289/arm64/defconfig/lab-baylibre-seattle/boot-sun50i-a64-pine64-plus.html
---
Hi,
not sure this is the right fix, I am open to suggestions.
Cheers,
Andre.
drivers/pinctrl/core.c | 5 +++--
drivers/pinctrl/pinmux.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 32822b0d..5198415 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -690,8 +690,8 @@ static void pinctrl_generic_free_groups(struct pinctrl_dev *pctldev)
void **slot;
int i = 0;
- indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
- pctldev->num_groups, GFP_KERNEL);
+ indices = kcalloc(pctldev->num_groups, sizeof(*indices),
+ GFP_KERNEL);
if (!indices)
return;
@@ -704,6 +704,7 @@ static void pinctrl_generic_free_groups(struct pinctrl_dev *pctldev)
radix_tree_delete(&pctldev->pin_group_tree, indices[i]);
devm_kfree(pctldev->dev, group);
}
+ kfree(indices);
pctldev->num_groups = 0;
}
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 29ad315..6a70339 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -836,8 +836,8 @@ void pinmux_generic_free_functions(struct pinctrl_dev *pctldev)
void **slot;
int i = 0;
- indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
- pctldev->num_functions, GFP_KERNEL);
+ indices = kcalloc(pctldev->num_functions, sizeof(*indices),
+ GFP_KERNEL);
if (!indices)
return;
@@ -850,6 +850,7 @@ void pinmux_generic_free_functions(struct pinctrl_dev *pctldev)
radix_tree_delete(&pctldev->pin_function_tree, indices[i]);
devm_kfree(pctldev->dev, function);
}
+ kfree(indices);
pctldev->num_functions = 0;
}
--
2.8.2
^ permalink raw reply related
* [PATCH] ARM: Fix __show_regs output timestamps
From: Joe Perches @ 2017-05-04 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503213034.GF22219@n2100.armlinux.org.uk>
On Wed, 2017-05-03 at 22:30 +0100, Russell King - ARM Linux wrote:
> On Wed, May 03, 2017 at 12:44:11PM -0700, Joe Perches wrote:
> > On Wed, 2017-05-03 at 20:23 +0100, Russell King - ARM Linux wrote:
> > > On Wed, Apr 26, 2017 at 10:39:49AM -0700, Joe Perches wrote:
> > > > Multiple line formats are not preferred as the second and
> > > > subsequent lines may not have timestamps.
> > > >
> > > > Lacking timestamps makes reading the output a bit difficult.
> > > > This also makes arm/arm64 output more similar.
> > > >
> > > > Previous:
> > > >
> > > > [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> > > > sp : ecdd7e20 ip : 00000000 fp : ffffffff
> > > >
> > > > New:
> > > >
> > > > [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> > > > [ 1514.105316] sp : ecdd7e20 ip : 00000000 fp : ffffffff
> > > >
> > > > Signed-off-by: Joe Perches <joe@perches.com>
> > >
> > > Hi Joe,
> > >
> > > Could you put this in my patch system please, I'm unlikely to remember to
> > > apply it otherwise if not already there (massive email backlog.)
> > >
> > > Thanks.
> >
> > Your patch system bounced my perfectly formatted patch
> > because your system wants totally unnecessary additional
> > information specific to your workflow.
> >
> > No thanks, I don't need the additional work just to
> > please your system and neither should anyone else.
>
> Don't expect me to remember to apply your patch then. I've got days of
> catch up, and I'm just not going to remember. Sorry.
<shrug>
If your systems require special handling on the
part of patch submitters, you should document it
in the kernel tree.
Better, someone else should find the time to apply
properly formatted patches.
^ permalink raw reply
* [PATCH v2] coresight: use const for device_node structures
From: Leo Yan @ 2017-05-04 0:36 UTC (permalink / raw)
To: linux-arm-kernel
Almost low level functions from open firmware have used const to
qualify device_node structures, so add const for device_node
parameters in of_coresight related functions.
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/of_coresight.c | 7 ++++---
include/linux/coresight.h | 7 ++++---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index 629e031..b101590 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -52,7 +52,7 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
endpoint, of_dev_node_match);
}
-static void of_coresight_get_ports(struct device_node *node,
+static void of_coresight_get_ports(const struct device_node *node,
int *nr_inport, int *nr_outport)
{
struct device_node *ep = NULL;
@@ -101,8 +101,9 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
}
-struct coresight_platform_data *of_get_coresight_platform_data(
- struct device *dev, struct device_node *node)
+struct coresight_platform_data *
+of_get_coresight_platform_data(struct device *dev,
+ const struct device_node *node)
{
int i = 0, ret = 0, cpu;
struct coresight_platform_data *pdata;
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 2a5982c..b198168 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,11 +263,12 @@ static inline int coresight_timeout(void __iomem *addr, u32 offset,
#endif
#ifdef CONFIG_OF
-extern struct coresight_platform_data *of_get_coresight_platform_data(
- struct device *dev, struct device_node *node);
+extern struct coresight_platform_data *
+of_get_coresight_platform_data(struct device *dev,
+ const struct device_node *node);
#else
static inline struct coresight_platform_data *of_get_coresight_platform_data(
- struct device *dev, struct device_node *node) { return NULL; }
+ struct device *dev, const struct device_node *node) { return NULL; }
#endif
#ifdef CONFIG_PID_NS
--
2.7.4
^ permalink raw reply related
* [PATCH] coresight: use const for device_node structures
From: Leo Yan @ 2017-05-04 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503202136.GA7860@linaro.org>
On Wed, May 03, 2017 at 02:21:36PM -0600, Mathieu Poirier wrote:
> Hi Leo,
>
> On Tue, May 02, 2017 at 04:15:03PM +0800, Leo Yan wrote:
> > Almost low level functions from open firmware have used const to
> > qualify device_node structures, so add const for device_node
> > parameters in of_coresight related functions.
> >
> > Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> > drivers/hwtracing/coresight/of_coresight.c | 4 ++--
> > include/linux/coresight.h | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> > index 629e031..859ad49 100644
> > --- a/drivers/hwtracing/coresight/of_coresight.c
> > +++ b/drivers/hwtracing/coresight/of_coresight.c
> > @@ -52,7 +52,7 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
> > endpoint, of_dev_node_match);
> > }
> >
> > -static void of_coresight_get_ports(struct device_node *node,
> > +static void of_coresight_get_ports(const struct device_node *node,
> > int *nr_inport, int *nr_outport)
> > {
> > struct device_node *ep = NULL;
> > @@ -102,7 +102,7 @@ static int of_coresight_alloc_memory(struct device *dev,
> > }
> >
> > struct coresight_platform_data *of_get_coresight_platform_data(
> > - struct device *dev, struct device_node *node)
> > + struct device *dev, const struct device_node *node)
>
> The original code didn't do things right. I suggest:
>
> struct coresight_platform_data *
> of_get_coresight_platform_data(struct device *dev,
> const struct device_node *node)
>
>
> > {
> > int i = 0, ret = 0, cpu;
> > struct coresight_platform_data *pdata;
> > diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> > index 2a5982c..769f2c8 100644
> > --- a/include/linux/coresight.h
> > +++ b/include/linux/coresight.h
> > @@ -264,10 +264,10 @@ static inline int coresight_timeout(void __iomem *addr, u32 offset,
> >
> > #ifdef CONFIG_OF
> > extern struct coresight_platform_data *of_get_coresight_platform_data(
> > - struct device *dev, struct device_node *node);
> > + struct device *dev, const struct device_node *node);
>
> Same as above.
>
> Please send me another revision and I'll pick this up for the next cycle.
Sure, have sent out.
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH][v2] arm64: dts: ls2081ardb: Add DTS support for NXP LS2081ARDB
From: Shawn Guo @ 2017-05-04 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493367930-10612-1-git-send-email-priyanka.jain@nxp.com>
On Fri, Apr 28, 2017 at 01:55:30PM +0530, Priyanka Jain wrote:
> This patch add support for NXP LS2081ARDB board which has
> LS2081A SoC.
>
> LS2081A SoC is 40-pin derivative of LS2088A SoC
> So, from functional perspective both are same.
> Hence,ls2088a SoC dtsi files are included from ls2081ARDB dts
>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
The following recipients couldn't be delivered. Please drop them in the
next posting.
scott.wood at nxp.com
stuart.yoder at nxp.com
Shawn
^ permalink raw reply
* linux-next: build warning after merge of the drm tree
From: Stephen Rothwell @ 2017-05-04 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <tencent_62AF37B85899E2EA593CCE3B@qq.com>
Hi Jeffy,
On Thu, 4 May 2017 09:18:12 +0800 "Jeffy" <jeffy.chen@rock-chips.com> wrote:
>
> it should be fixed by "Arnd Bergmann"<arnd@arndb.de>(thanks a lot by the way) in:
>
> 4a85aae multi_v7_defconfig: make Rockchip DRM drivers built-in
Thanks for the heads up, I will await the arm-soc merges.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes
From: Chen-Yu Tsai @ 2017-05-04 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503203402.5mwhx5wjniav24nd@lukather>
Hi,
On Thu, May 4, 2017 at 4:34 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Wed, May 03, 2017 at 11:16:53AM +0800, Chen-Yu Tsai wrote:
>> The MMC clocks on newer SoCs, such as the A83T and H3, support the
>> "new timing mode". Under this mode, the output of the clock is divided
>> by 2, and the clock delays no longer apply.
>>
>> Due to how the clock tree is modeled and setup, we need to model
>> this function in two places, the master mmc clock and the two
>> child phase clocks. In the mmc clock, we can easily model the
>> mode bit as an extra variable post-divider. In the phase clocks,
>> we check the bit and return -ENOTSUPP if the bit is set, signaling
>> that the phase clocks are not to be used.
>>
>> This patch introduces a class of phase clocks that checks the
>> timing mode bit.
>
> We've been over this quite some times already...
>
> How do you retrieve the mode used in the clock so that you can also
> switch the MMC driver in the new mode?
This part is covered. As mentioned above, the phase clks will return
-ENOTSUPP if the mmc clk is set in the new timing mode. The MMC driver
would try getting the current phase, check if it fails, and if it does,
realizes the clk is in new timing mode, and will switch the mmc controller
to it as well. I think this semantic fits the hardware well enough,
though it might be confusing without the accompanying comments.
See this commit for an example on how it should work.
https://github.com/wens/linux/commit/41e386f1f945a0a135a20a00601b977a001353da
> And do you prevent that from happening on the DT we already have that
> use the old clock drivers that do not support this new timing at all?
I admit this is not taken care of in this patch. Mostly because there
is no existing DT for the A83T to cater to. For the H3 and other SoCs
that do, we need some way of asking the CCU to switch the mode.
IIRC the output and sample clocks do not support a phase delay of 0.
So what if we design the semantic for this class of clocks as, if
phase == 0, switch to new timing mode, otherwise use old timing mode?
That would allow us to support this without adding extra functions,
and kind of matches what the hardware does. If you're using the new
timing mode, the delays in the mmc clk are bypassed.
Regards
ChenYu
^ permalink raw reply
* [PATCH v2 2/20] clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate
From: Chen-Yu Tsai @ 2017-05-04 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83d508e254c6656aee02bbe5c410922ea66cf3d7.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The clocks might need to modify their parent clocks. In order to make that
> possible, give them access to the parent clock being evaluated, and to a
> pointer to the parent rate so that they can modify it if needed.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 3/20] clk: sunxi-ng: div: Switch to divider_round_rate
From: Chen-Yu Tsai @ 2017-05-04 3:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ea7c8c0ac01fe06f7ded94e03532a1838f2bf8f.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> divider_round_rate already evaluates changing the parent rate if
^^^ Might want to update this, as you are now using the new function
you added in patch 1.
> CLK_SET_RATE_PARENT is set. Now that we can do that on muxes too, let's
> just use it.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 4/20] clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT
From: Chen-Yu Tsai @ 2017-05-04 3:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27fcae13e64ef86d32001478f1923e9a02deb7b8.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The current code only rely on the parent to change its rate in the case
> where CLK_SET_RATE_PARENT is set.
>
> However, some clock rates might be obtained only through a modification of
> the parent and the clock divider. Just rely on the round rate of the clocks
> to give us the best computation that might be achieved for a given rate.
>
> round_rate functions now need to honor CLK_SET_RATE_PARENT, but either the
> functions already do that if they modify the parent, or don't modify the
> praents at all.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 5/20] clk: sunxi-ng: mux: split out the pre-divider computation code
From: Chen-Yu Tsai @ 2017-05-04 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fcda95612e72a1a5bb6010993181e638a41511e9.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The pre-divider retrieval code was merged into the function to apply the
> current pre-divider onto the parent clock rate so that we can use that
> adjusted value to do our factors computation.
>
> However, since we'll need to do the reverse operation, we need to split out
> that code into a function that will be shared.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Seems this would conflict with my "clk: sunxi-ng: Support multiple variable
pre-dividers" patch though. We'll see how this works out.
^ permalink raw reply
* [PATCH v2 6/20] clk: sunxi-ng: mux: Change pre-divider application function prototype
From: Chen-Yu Tsai @ 2017-05-04 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b7fab9142ae318f9188b93dfba0b6bd2b530a514.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The current function name is a bit confusing, and doesn't really allow to
> create an explicit function to reverse the operation.
>
> We also for now change the parent rate through a pointer, while we don't
> return anything.
>
> In order to be less confusing, and easier to use for downstream users,
> change the function name to something hopefully clearer, and return the
> adjusted rate instead of changing the pointer.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 7/20] clk: sunxi-ng: mux: Re-adjust parent rate
From: Chen-Yu Tsai @ 2017-05-04 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d8fc6d976c64be906fa86ead20aa10bb490386b.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Currently, the parent rate given back to the clock framework in our
> request is the original parent rate we calculated before trying to round
> the rate of our clock.
>
> This works fine unless our clock also changes its parent rate, in which
> case we will simply ignore that change and still use the previous parent
> rate.
>
> Create a new function to re-adjust the parent rate to take the pre-dividers
> into account, and give that back to the clock framework.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/clk/sunxi-ng/ccu_mux.c | 33 ++++++++++++++++++++++++++++-----
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
> index c33210972581..1ce62cc23f8a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mux.c
> +++ b/drivers/clk/sunxi-ng/ccu_mux.c
> @@ -64,6 +64,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
> return parent_rate / ccu_mux_get_prediv(common, cm, parent_index);
> }
>
> +unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
> + struct ccu_mux_internal *cm,
> + int parent_index,
> + unsigned long parent_rate)
> +{
> + return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
> +}
> +
> int ccu_mux_helper_determine_rate(struct ccu_common *common,
> struct ccu_mux_internal *cm,
> struct clk_rate_request *req,
> @@ -89,22 +97,37 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
> best_rate = round(cm, best_parent, &adj_parent_rate,
> req->rate, data);
>
> + /*
> + * parent_rate might have been modified by our clock.
> + * Re-apply the pre-divider if there's one, and give
Might want to reword the comments to match the new name.
> + * the actual frequency the parent needs to run at.
> + */
> + best_parent_rate = ccu_mux_helper_unapply_prediv(common, cm, -1,
> + adj_parent_rate);
> +
> goto out;
> }
>
> for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
> - unsigned long tmp_rate, parent_rate, adj_parent_rate;
> + unsigned long tmp_rate, parent_rate;
> struct clk_hw *parent;
>
> parent = clk_hw_get_parent_by_index(hw, i);
> if (!parent)
> continue;
>
> - parent_rate = clk_hw_get_rate(parent);
> - adj_parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> - parent_rate);
> + parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> + clk_hw_get_rate(parent));
> +
> + tmp_rate = round(cm, parent, &parent_rate, req->rate, data);
>
> - tmp_rate = round(cm, parent, &adj_parent_rate, req->rate, data);
> + /*
> + * parent_rate might have been modified by our clock.
> + * Re-apply the pre-divider if there's one, and give
Same here. Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + * the actual frequency the parent needs to run at.
> + */
> + parent_rate = ccu_mux_helper_unapply_prediv(common, cm, i,
> + parent_rate);
> if (tmp_rate == req->rate) {
> best_parent = parent;
> best_parent_rate = parent_rate;
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH v2 8/20] clk: sunxi-ng: sun5i: Export video PLLs
From: Chen-Yu Tsai @ 2017-05-04 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1fc17b7a14830306a83747b5086c0fd5d6dff290.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The video PLLs are used directly by the HDMI controller. Export them so
> that we can use them in our DT node.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 10/20] drm/sun4i: tcon: Move the muxing out of the mode set function
From: Chen-Yu Tsai @ 2017-05-04 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ea29ffd2bc3c76203168d0fd1e969b045424b24c.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The muxing can actually happen on both channels on some SoCs, so it makes
> more sense to just move it out of the sun4i_tcon1_mode_set function and
> create a separate function that needs to be called by the encoders.
>
> Let's do that and convert the existing drivers.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 1 +
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++++++++++++++++------
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
> drivers/gpu/drm/sun4i/sun4i_tv.c | 1 +
> 4 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index 67f0b91a99de..3003d290c635 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -175,6 +175,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder *encoder,
> struct sun4i_tcon *tcon = rgb->tcon;
>
> sun4i_tcon0_mode_set(tcon, mode);
> + sun4i_tcon_set_mux(tcon, 0, encoder);
>
> clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 66a5bb9b85e9..0204d9fadb66 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -108,6 +108,22 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool enable)
> }
> EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> + struct drm_encoder *encoder)
The channel doesn't really matter. What is needed is which TCON and encoder
are supposed to be muxed together. This is going to be per SoC type anyway.
I have something in the works, though it's not finished yet.
I think this works for now.
Acked-by: Chen-Yu Tsai <wens@csie.org>
> +{
> + if (!tcon->quirks->has_unknown_mux)
> + return;
> +
> + if (channel != 1)
> + return;
> +
> + /*
> + * FIXME: Undocumented bits
> + */
> + regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
> +}
> +EXPORT_SYMBOL(sun4i_tcon_set_mux);
> +
> static int sun4i_tcon_get_clk_delay(struct drm_display_mode *mode,
> int channel)
> {
> @@ -266,12 +282,6 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> SUN4I_TCON_GCTL_IOMAP_MASK,
> SUN4I_TCON_GCTL_IOMAP_TCON1);
> -
> - /*
> - * FIXME: Undocumented bits
> - */
> - if (tcon->quirks->has_unknown_mux)
> - regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
> }
> EXPORT_SYMBOL(sun4i_tcon1_mode_set);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index f636343a935d..0350936b413c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -190,6 +190,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool enable);
> /* Mode Related Controls */
> void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
> bool enable);
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> + struct drm_encoder *encoder);
> void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> struct drm_display_mode *mode);
> void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 49c49431a053..03c494b8159c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -393,6 +393,7 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
> const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
>
> sun4i_tcon1_mode_set(tcon, mode);
> + sun4i_tcon_set_mux(tcon, 1, encoder);
>
> /* Enable and map the DAC to the output */
> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH v2 11/20] drm/sun4i: tcon: Switch mux on only for composite
From: Chen-Yu Tsai @ 2017-05-04 3:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f97dbff6f99c108b5f4b7f144d02dde8c253ab6.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Even though that mux is undocumented, it seems like it needs to be set to 1
> when using composite, and 0 when using HDMI.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 13/20] drm/sun4i: tcon: Change vertical total size computation inconsistency
From: Chen-Yu Tsai @ 2017-05-04 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <745b9fc450798635d50f449473e9263ab3ace48e.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Both TCON channels need to have the resolution doubled, since the size the
> hardware is going to use is whatever we put in the register divided by two.
>
> However, we handle it differently for the two channels: in the channel 0,
> our register access macro does the multiplication of the value passed as
> paremeter, while in the channel 1, the macro doesn't do this, and we need
> to do it before calling it.
>
> Make this consistent by aligning the channel 0 with the channel 1
> behaviour.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 14/20] drm/sun4i: tcon: multiply the vtotal when not in interlace
From: Chen-Yu Tsai @ 2017-05-04 4:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <59bdbadc4d3adc6d75c2cef38df0af332bd313db.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> It appears that the total vertical resolution needs to be doubled when
> we're not in interlaced. Make sure that is the case.
I think the total vertical resolution needs to be doubled in all cases.
It just happens that you should've been using mode->crtc_vtotal, which
is halved when the mode is interlaced. Instead you used mode->vtotal,
which is double the actual scan resolution in interlaced mode.
ChenYu
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 0f91ec8a4b26..efa079c1a3f5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -272,9 +272,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> /* Set vertical display timings */
> bp = mode->crtc_vtotal - mode->crtc_vsync_start;
> DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> - mode->vtotal, bp);
> + mode->crtc_vtotal, bp);
> regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
> - SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
> + SUN4I_TCON1_BASIC4_V_TOTAL(mode->crtc_vtotal * 2) |
> SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
>
> /* Set Hsync and Vsync length */
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH v2 15/20] drm/sun4i: Ignore the generic connectors for components
From: Chen-Yu Tsai @ 2017-05-04 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88de0f79b508e51b5fbf38fac058921a3c748807.1493812478.git-series.maxime.ripard@free-electrons.com>
On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The generic connectors such as hdmi-connector doesn't have any driver in,
> so if they are added to the component list, we will be waiting forever for
> a non-existing driver to probe.
>
> Add a list of the connectors we want to ignore when building our component
> list.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 8ddd72cd5873..8c9d2e36be55 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -164,6 +164,11 @@ static const struct component_master_ops sun4i_drv_master_ops = {
> .unbind = sun4i_drv_unbind,
> };
>
> +static bool sun4i_drv_node_is_connector(struct device_node *node)
> +{
> + return of_device_is_compatible(node, "hdmi-connector");
> +}
> +
> static bool sun4i_drv_node_is_frontend(struct device_node *node)
> {
> return of_device_is_compatible(node, "allwinner,sun5i-a13-display-frontend") ||
> @@ -204,7 +209,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> !of_device_is_available(node))
> return 0;
>
> - if (!sun4i_drv_node_is_frontend(node)) {
> + if (!sun4i_drv_node_is_connector(node) &&
I think it's better to just bail out (return 0) if the current node
is a connector. The connector is the end of the pipeline anyway.
Nothing after it should be considered for the component graph.
The way you currently have it, traversal will continue beyond
the connector node.
ChenYu
> + !sun4i_drv_node_is_frontend(node)) {
> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %s\n",
> of_node_full_name(node));
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.
From: Karim Eshapa @ 2017-05-04 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493508775.25397.26.camel@buserror.net>
Avoid stuck and hacking jiffies for a long time and using msleep()
for certatin numeber of cylces without the factor of safety
but using the the long delay considering the factor of safety
with the while loop such that after msleep for a short period
of time we check the msg if it's OK, breaking the big loop delay.
Signed-off-by: Karim Eshapa <karim.eshapa@gmail.com>
---
drivers/soc/fsl/qbman/qman.c | 47 ++++++++++++++++++++++----------------------
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 6f509f6..4f99298 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1067,32 +1067,33 @@ static irqreturn_t portal_isr(int irq, void *ptr)
static int drain_mr_fqrni(struct qm_portal *p)
{
const union qm_mr_entry *msg;
+ unsigned long stop;
+ unsigned int timeout = jiffies_to_msecs(1000);
loop:
msg = qm_mr_current(p);
- if (!msg) {
- /*
- * if MR was full and h/w had other FQRNI entries to produce, we
- * need to allow it time to produce those entries once the
- * existing entries are consumed. A worst-case situation
- * (fully-loaded system) means h/w sequencers may have to do 3-4
- * other things before servicing the portal's MR pump, each of
- * which (if slow) may take ~50 qman cycles (which is ~200
- * processor cycles). So rounding up and then multiplying this
- * worst-case estimate by a factor of 10, just to be
- * ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
- * one entry at a time, so h/w has an opportunity to produce new
- * entries well before the ring has been fully consumed, so
- * we're being *really* paranoid here.
- */
- u64 now, then = jiffies;
-
- do {
- now = jiffies;
- } while ((then + 10000) > now);
+ stop = jiffies + 10000;
+ /*
+ * if MR was full and h/w had other FQRNI entries to produce, we
+ * need to allow it time to produce those entries once the
+ * existing entries are consumed. A worst-case situation
+ * (fully-loaded system) means h/w sequencers may have to do 3-4
+ * other things before servicing the portal's MR pump, each of
+ * which (if slow) may take ~50 qman cycles (which is ~200
+ * processor cycles). So rounding up and then multiplying this
+ * worst-case estimate by a factor of 10, just to be
+ * ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
+ * one entry at a time, so h/w has an opportunity to produce new
+ * entries well before the ring has been fully consumed, so
+ * we're being *really* paranoid here.
+ */
+ do {
+ if (msg)
+ break;
+ msleep(timeout);
msg = qm_mr_current(p);
- if (!msg)
- return 0;
- }
+ } while (time_before(jiffies, stop));
+ if (!msg)
+ return 0;
if ((msg->verb & QM_MR_VERB_TYPE_MASK) != QM_MR_VERB_FQRNI) {
/* We aren't draining anything but FQRNIs */
pr_err("Found verb 0x%x in MR\n", msg->verb);
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox