* [PATCH 1/1] ARM: imx5: Add clocks configuration
From: Fabien Lahoudere @ 2016-09-19 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918002451.GE15478@tiger>
Hi,
On 18/09/16 02:24, Shawn Guo wrote:
> On Sun, Sep 18, 2016 at 08:21:59AM +0800, Shawn Guo wrote:
>> On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
>>>> ???????, 15 ???????? 2016, 13:13 +03:00 ?? Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>:
>>>>
>>>> From: Kalle Kankare < kalle.kankare@vincit.fi >
>>>>
>>>> Add clocks configuration for CSI, FIRI and IEEE1588.
>>>>
>>>> Signed-off-by: Fabien Lahoudere < fabien.lahoudere@collabora.co.uk >
>>>> ---
>>>> drivers/clk/imx/clk-imx51-imx53.c | 20 ++++++++++++++++++++
>>>> include/dt-bindings/clock/imx5-clock.h | 15 ++++++++++++++-
>>>> 2 files changed, 34 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/imx/clk-imx51-imx53.c b/drivers/clk/imx/clk-imx51-imx53.c
>>>> index 29d4c44..1e3c9ea 100644
>>>> --- a/drivers/clk/imx/clk-imx51-imx53.c
>>>> +++ b/drivers/clk/imx/clk-imx51-imx53.c
>>>> @@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", "ssi1_root_gate", };
>>>> static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", "ssi2_root_gate", };
>>>> static const char *step_sels[] = { "lp_apm", };
>>>> static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
>>>> +static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* usbphy2_clk */, "dummy" /* fec_phy_clk */ };
>>>>
>>>> static struct clk *clk[IMX5_CLK_END];
>>>> static struct clk_onecell_data clk_data;
>>>> @@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node *np)
>>> ...
>>>
>>> 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
>>> I would ask to change the subject to i.MX53 if it possible.
>>
>> Yes. Actually, since clock driver is not moved to drivers/clk, we
>
> s/not/now
>
>> shouldn't prefix it with "ARM: " any longer.
Ok is "clk: imx53: Add clocks configuration" ok?
>
> Shawn
>
Thanks
Fabien
^ permalink raw reply
* [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller
From: Mirza Krak @ 2016-09-19 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3a2371b-5d98-db2d-b7e4-be6d08cb7271@nvidia.com>
2016-09-06 12:32 GMT+02:00 Jon Hunter <jonathanh@nvidia.com>:
>
> On 31/08/16 12:22, Mirza Krak wrote:
>> 2016-08-30 19:06 GMT+02:00 Rob Herring <robh@kernel.org>:
>
> ...
>
>>>> nvidia,snor-cs = <4>;
>>>
>>> NAK, no custom CS properties.
>
> Ok, so ...
>
>> gmi at 70090000 {
>> compatible = "nvidia,tegra20-gmi";
>> reg = <0x70009000 0x1000>;
>> #address-cells = <2>;
>> #size-cells = <1>;
>> clocks = <&tegra_car TEGRA20_CLK_NOR>;
>> clock-names = "gmi";
>> resets = <&tegra_car 42>;
>> reset-names = "gmi";
>> ranges = <4 0 0xd0000000 0xfffffff>;
>>
>> status = "okay";
>>
>> bus at 4,0 {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges = <0 4 0 0x40000>;
>>
>> nvidia,snor-mux-mode;
>> nvidia,snor-adv-inv;
>>
>> can at 0 {
>> reg = <0 0x100>;
>> ...
>> };
>>
>> can at 40000 {
>> reg = <0x40000 0x100>;
>> ...
>> };
>> };
>> };
>>
>> Have I understood you correct?
>>
>> Also wanted to verify the example case where you only have on device
>> connected to one CS#, from what I see in other implementations it
>> seems OK to put the CS# in the reg property in that case. Is this
>> correct?
>>
>> Example with one SJA1000 CAN controller connected to the GMI bus
>> on CS4:
>>
>> gmi at 70090000 {
>> compatible = "nvidia,tegra20-gmi";
>> reg = <0x70009000 0x1000>;
>> #address-cells = <2>;
>> #size-cells = <1>;
>> clocks = <&tegra_car TEGRA20_CLK_NOR>;
>> clock-names = "gmi";
>> resets = <&tegra_car 42>;
>> reset-names = "gmi";
>> ranges = <4 0 0xd0000000 0xfffffff>;
>>
>> status = "okay";
>>
>> can at 4,0 {
>> reg = <4 0 0x100>;
>> nvidia,snor-mux-mode;
>> nvidia,snor-adv-inv;
>> ...
>> };
>> };
>>
>> Jon, to be able to handle both cases in the driver we would first
>> attempt to decode the CS# from the ranges property, and fallback to
>> reg property if no ranges are defined. Does that sound reasonable?
>
> Given the above examples that may be supported, is there a
> better/simpler way to extract the CS# than what Mirza is proposing? For
> example, from the node-name unit-address?
>
Hi.
I have been on vacation and now I am back and wanted to finalize these
patch series.
So pinging this thread to see I we can agree on a solution.
Rob any comments to my proposal and Jon`s comment?
Best Regards
Mirza Krak
^ permalink raw reply
* [PATCH 07/19] ahci: st: Remove STiH416 dt example
From: Patrice Chotard @ 2016-09-19 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916155449.GB26371@htj.duckdns.org>
On 09/16/2016 05:54 PM, Tejun Heo wrote:
> On Wed, Sep 14, 2016 at 02:27:45PM +0100, Peter Griffin wrote:
>> This platform is being removed from the kernel so remove
>> the dt example.
>>
>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>> Cc: <tj@kernel.org>
>> Cc: <robh+dt@kernel.org>
>> Cc: <linux-ide@vger.kernel.org>
>
> This is gonna go through dt tree, right? If it should go through
> libata, please let me know.
Hi Tejun
I will take care of this patch and include it in the next STi DT pull request.
Thanks
>
> Thanks.
>
^ permalink raw reply
* [PATCH v14 0/4] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2016-09-19 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473039885-24009-1-git-send-email-hs.liao@mediatek.com>
On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.8-rc1.
>
> Changes since v13:
> - move to mailbox folder
> - simplify cmdq_thread_is_in_wfe
>
> Best regards,
> HS Liao
>
> HS Liao (4):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> CMDQ: Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> CMDQ: save more energy in idle
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 +
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq.c | 965 +++++++++++++++++++++
> include/linux/mailbox/mtk-cmdq.h | 180 ++++
> 6 files changed, 1210 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq.c
> create mode 100644 include/linux/mailbox/mtk-cmdq.h
>
Hi Jassi,
Sorry to disturb you.
Do you have any further comment on CMDQ v14?
Thanks.
HS
^ permalink raw reply
* [PATCH v4] mtd: nand: automate NAND timings selection
From: Sascha Hauer @ 2016-09-19 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916141918.0353f65f@bbrezillon>
On Fri, Sep 16, 2016 at 02:19:18PM +0200, Boris Brezillon wrote:
> On Thu, 15 Sep 2016 10:32:44 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > This series aims at automating the NAND timings selection which is
> > currently supposed to be done in each NAND controller driver, thus
> > simplifying drivers implementation.
> >
> > As suggested by Boris this version of the series introduces a nand_reset()
> > function which replaces the several open coded NAND_CMD_RESET commands
> > in the code. This makes sure we can apply the timing each time after
> > after reset.
> >
> > Also I have brought back the conversion patch for teh sunxi driver whic
> > was part of Boris initial posting. It's untested due to the lack of hardware,
> > so please test before applying.
>
> Applied after fixing a few coding style issues (to make checkpatch
> happy), and exporting the onfi_init_data_interface() function (not sure
> it's the best solution, but at least, it's consistent with the other
> functions defined in nand_timings.c).
Thanks Boris.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 2/2] media: mtk-mdp: fix build error
From: Minghsiu Tsai @ 2016-09-19 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474266883-51155-1-git-send-email-minghsiu.tsai@mediatek.com>
This patch fix build error without CONFIG_PM_RUNTIME
and CONFIG_PM_SLEEP
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index b0c421e..f4424064 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -233,7 +233,7 @@ static int mtk_mdp_remove(struct platform_device *pdev)
return 0;
}
-#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_PM_SLEEP)
+#ifdef CONFIG_PM
static int mtk_mdp_pm_suspend(struct device *dev)
{
struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
@@ -251,7 +251,7 @@ static int mtk_mdp_pm_resume(struct device *dev)
return 0;
}
-#endif /* CONFIG_PM_RUNTIME || CONFIG_PM_SLEEP */
+#endif /* CONFIG_PM */
#ifdef CONFIG_PM_SLEEP
static int mtk_mdp_suspend(struct device *dev)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] media: mtk-mdp: fix build warning in arch x86
From: Minghsiu Tsai @ 2016-09-19 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474266883-51155-1-git-send-email-minghsiu.tsai@mediatek.com>
This patch fix build warning in arch x86
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1 +
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 10 ++++++----
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index a90972e..9a747e7 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -17,6 +17,7 @@
#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/pm_runtime.h>
+#include <linux/slab.h>
#include <linux/workqueue.h>
#include <media/v4l2-event.h>
#include <media/v4l2-ioctl.h>
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
index fb07bf3..39188e5 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
@@ -25,7 +25,8 @@ static inline struct mtk_mdp_ctx *vpu_to_ctx(struct mtk_mdp_vpu *vpu)
static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg)
{
- struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
+ struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)
+ (unsigned long)msg->ap_inst;
/* mapping VPU address to kernel virtual address */
vpu->vsi = (struct mdp_process_vsi *)
@@ -37,7 +38,8 @@ static void mtk_mdp_vpu_ipi_handler(void *data, unsigned int len, void *priv)
{
unsigned int msg_id = *(unsigned int *)data;
struct mdp_ipi_comm_ack *msg = (struct mdp_ipi_comm_ack *)data;
- struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
+ struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)
+ (unsigned long)msg->ap_inst;
struct mtk_mdp_ctx *ctx;
vpu->failure = msg->status;
@@ -108,7 +110,7 @@ static int mtk_mdp_vpu_send_ap_ipi(struct mtk_mdp_vpu *vpu, uint32_t msg_id)
msg.msg_id = msg_id;
msg.ipi_id = IPI_MDP;
msg.vpu_inst_addr = vpu->inst_addr;
- msg.ap_inst = (uint64_t)vpu;
+ msg.ap_inst = (unsigned long)vpu;
err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
if (!err && vpu->failure)
err = -EINVAL;
@@ -126,7 +128,7 @@ int mtk_mdp_vpu_init(struct mtk_mdp_vpu *vpu)
msg.msg_id = AP_MDP_INIT;
msg.ipi_id = IPI_MDP;
- msg.ap_inst = (uint64_t)vpu;
+ msg.ap_inst = (unsigned long)vpu;
err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
if (!err && vpu->failure)
err = -EINVAL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] Fix build warning and error in Mediatek MDP driver
From: Minghsiu Tsai @ 2016-09-19 6:34 UTC (permalink / raw)
To: linux-arm-kernel
- Fix build warning in arch x86
- Fix build warning in kzalloc() and kfree() in arch x86
- Fix build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
v4l2-compliance test output:
v4l2-compliance SHA : abc1453dfe89f244dccd3460d8e1a2e3091cbadb
Driver Info:
Driver name : mtk-mdp
Card type : soc:mdp
Bus info : platform:mt8173
Driver version: 4.8.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Compliance test for device /dev/image-proc0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
Test input 0:
Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
Minghsiu Tsai (2):
media: mtk-mdp: fix build warning in arch x86
media: mtk-mdp: fix build error
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 4 ++--
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1 +
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 10 ++++++----
3 files changed, 9 insertions(+), 6 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH V5] perf tools: adding support for address filters
From: Adrian Hunter @ 2016-09-19 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917223311.19dac50f03da4f40fd5cc844@kernel.org>
On 17/09/16 16:33, Masami Hiramatsu wrote:
> On Fri, 16 Sep 2016 09:32:43 -0600
> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>
>> On 13 September 2016 at 17:25, Masami Hiramatsu <mhiramat@kernel.org> wrote:
>>> On Tue, 13 Sep 2016 08:18:10 -0600
>>> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>>>
>>>> On 13 September 2016 at 04:01, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>>> On 12/09/16 20:53, Mathieu Poirier wrote:
>>>>>> This patch makes it possible to use the current filter
>>>>>> framework with address filters. That way address filters for
>>>>>> HW tracers such as CoreSight and IntelPT can be communicated
>>>>>> to the kernel drivers.
>>>>>>
>>>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>
>>>>>> ---
>>>>>> Changes for V5:
>>>>>> - Modified perf_evsel__append_filter() to take a string format
>>>>>> rather than an operation.
>>>>>
>>>>> Hope I'm not being a pain, but aren't there other places calling
>>>>> perf_evsel__append_filter() that need to be changed. Might make
>>>>> sense as a separate patch.
>>>>
>>>> No no, you're right - I completely overlooked that.
>>>>
>>>> But shouldn't it be in the same patch? That way a git bisect would
>>>> stay consistent...
>>>
>>> You're right. Caller and callee should be changed in atomic.
>>>
>>> BTW, could you add document updates how the perf command line
>>> will be changed, and also show the result in the patch description?
>>
>> This patch does not change anything on the perf command line. It
>> simply allows current options to succeed (as they should) rather than
>> fail.
>
> Yes, and it will make perf acceptable to pass --filter to CoreSight or
> Intel PT events, or am I misunderstand?
> If it is correct, could you give us an example how to pass it, since
> tools/perf/Documentation/perf-record.txt says it is only for tracepoints?
I am adding support for symbols in the address filter. I will send the
patches soon, but the documentation will be:
--filter=<filter>::
Event filter. This option should follow a event selector (-e) which
selects either tracepoint event(s) or a hardware trace PMU
(e.g. Intel PT or CoreSight).
- tracepoint filters
In the case of tracepoints, multiple '--filter' options are combined
using '&&'.
- address filters
A hardware trace PMU advertises its ability to accept a number of
address filters by specifying a non-zero value in
/sys/bus/event_source/devices/<pmu>/nr_addr_filters.
Address filters have the format:
filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
Where:
- 'filter': defines a region that will be traced.
- 'start': defines an address at which tracing will begin.
- 'stop': defines an address at which tracing will stop.
- 'tracestop': defines a region in which tracing will stop.
<file name> is the name of the object file, <start> is the offset to the
code to trace in that file, and <size> is the size of the region to
trace. 'start' and 'stop' filters need not specify a <size>.
If no object file is specified then the kernel is assumed, in which case
the start address must be a current kernel memory address.
<start> can also be specified by providing the name of a symbol. If the
symbol name is not unique, it can be disambiguated by inserting #n where
'n' selects the n'th symbol in address order. Alternately #0, #g or #G
select only a global symbol. <size> can also be specified by providing
the name of a symbol, in which case the size is calculated to the end
of that symbol. For 'filter' and 'tracestop' filters, if <size> is
omitted and <start> is a symbol, then the size is calculated to the end
of that symbol.
If <size> is omitted and <start> is '*', then the start and size will
be calculated from the first and last symbols, i.e. to trace the whole
file.
If symbol names (or "*") are provided, they must be surrounded by white
space.
The filter passed to the kernel is not necessarily the same as entered.
To see the filter that is passed, use the -v option.
The kernel may not be able to configure a trace region if it is not
within a single mapping. MMAP events (or /proc/<pid>/maps) can be
examined to determine if that is a possibility.
Multiple filters can be separated with space or comma.
^ permalink raw reply
* [PATCH 0/2] ARM: imx31/of: clk: init clock controller with CLK_OF_DECLARE
From: Uwe Kleine-König @ 2016-09-19 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474252939-12579-1-git-send-email-vz@mleia.com>
Hello,
On Mon, Sep 19, 2016 at 05:42:17AM +0300, Vladimir Zapolskiy wrote:
> The change is based on v4.8.0-rc1 and plus it depends on this fixup:
>
> ARM: dts: imx31: fix clock control module interrupts description
>
> The change is tested on qemu kzm target and mx31lite board, while both
> targets don't have DTS in upstream, I had to write simple DTS files for
> them, because the proposed change is for i.MX31 targets with OF support.
>
> The second change in the series compilation time dependent on the first
> one, while the first change apparently should break runtime execution
> of i.MX31 boards with OF support, if both changes are applied everything
> should be fine, regression testing on the same legacy targets does not
that means this should be done in a single patch.
> show any problems. Moreover i.MX31/OF/clock initialization seems to be
> broken currently, if the change is not applied I can not get a working
> clock source during early boot stage, jiffies are not incremented, but
> because I didn't check the problem thoroughly (can it be caused by
> missing CLK_OF_DECLARE? Or caused by something fixed by the change
> http://www.spinics.net/lists/linux-clk/msg12235.html ?) and because
> the change was tested against code which is not found in upstream,
> I won't call this change as a fix, however its application is apparently
> wanted to get better OF support for i.MX31 targets.
Very appreciated!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v6 0/6] Add MT8173 MDP Driver
From: Minghsiu Tsai @ 2016-09-19 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <703024ec-f6d4-60e8-ed09-6a2e935857d7@xs4all.nl>
On Wed, 2016-09-14 at 14:43 +0200, Hans Verkuil wrote:
> Hi Minghsiu,
>
> v6 looks good, but I get these warnings when compiling it for i686:
>
> linux-git-i686: WARNINGS
>
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_handle_init_ack':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:28:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_ipi_handler':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:40:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_send_ap_ipi':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:111:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_init':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:129:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
>
> This is not blocking, but if you can post a follow-up patch for this, then that
> would be helpful.
>
Hi Hans,
I have duplicated this warning message in arch x86.
I also got the report from kbuild robot. There are build errors in
mtk_mdp_pm_suspend().
Besides, in arch x86, I also have build warning messages in kzalloc()
and kfree() used in mtk_mdp_m2m.c. It can be fixed by including
linux/slab.h
I will upload the patches today.
Thanks
Ming Hsiu
> Regards,
>
> Hans
>
>
> On 09/08/2016 03:09 PM, Minghsiu Tsai wrote:
> > Changes in v6:
> > - s_selection() can't set the _DEFAULT and _BOUNDS targets
> > - Add Maintainers entry
> >
> > Changes in v5:
> > - Add ack in the comment of dts patch
> > - Fix s/g_selection()
> > - Separate format V4L2_PIX_FMT_MT21C into new patch
> >
> > Changes in v4:
> > - Add "depends on HAS_DMA" in Kconfig.
> > - Fix s/g_selection()
> > - Replace struct v4l2_crop with u32 and struct v4l2_rect
> > - Remove VB2_USERPTR
> > - Move mutex lock after ctx allocation in mtk_mdp_m2m_open()
> > - Add new format V4L2_PIX_FMT_YVU420 to support software on Android platform.
> > - Only width/height of image in format V4L2_PIX_FMT_MT21 is aligned to 16/16,
> > other ones are aligned to 2/2 by default
> >
> > Changes in v3:
> > - Modify device ndoe as structured one.
> > - Fix conflict in dts on Linux 4.8-rc1
> >
> > Changes in v2:
> > - Add section to describe blocks function in dts-bindings
> > - Remove the assignment of device_caps in querycap()
> > - Remove format's name assignment
> > - Copy colorspace-related parameters from OUTPUT to CAPTURE
> > - Use m2m helper functions
> > - Fix DMA allocation failure
> > - Initialize lazily vpu instance in streamon()
> >
> > ==============
> > Introduction
> > ==============
> >
> > The purpose of this series is to add the driver for Media Data Path HW embedded in the Mediatek's MT8173 SoC.
> > MDP is used for scaling and color space conversion.
> >
> > It could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or V4L2_PIX_FMT_YUV420M.
> >
> > NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M
> >
> > This patch series rely on MTK VPU driver in patch series "Add MT8173 Video Encoder Driver and VPU Driver"[1] and "Add MT8173 Video Decoder Driver"[2].
> > MDP driver rely on VPU driver to load, communicate with VPU.
> >
> > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both have been merged in v4.6-rc1.
> >
> > [1]https://patchwork.kernel.org/patch/9002171/
> > [2]https://patchwork.kernel.org/patch/9141245/
> >
> > ==================
> > Device interface
> > ==================
> >
> > In principle the driver bases on v4l2 memory-to-memory framework:
> > it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers) and CAPTURE (for destination buffers).
> > OUTPUT and CAPTURE buffer could be MMAP or DMABUF memory type.
> >
> > v4l2-compliance test output:
> > v4l2-compliance SHA : abc1453dfe89f244dccd3460d8e1a2e3091cbadb
> >
> > Driver Info:
> > Driver name : mtk-mdp
> > Card type : soc:mdp
> > Bus info : platform:mt8173
> > Driver version: 4.8.0
> > Capabilities : 0x84204000
> > Video Memory-to-Memory Multiplanar
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04204000
> > Video Memory-to-Memory Multiplanar
> > Streaming
> > Extended Pix Format
> >
> > Compliance test for device /dev/image-proc0 (not using libv4l2):
> >
> > Required ioctls:
> > test VIDIOC_QUERYCAP: OK
> >
> > Allow for multiple opens:
> > test second video open: OK
> > test VIDIOC_QUERYCAP: OK
> > test VIDIOC_G/S_PRIORITY: OK
> > test for unlimited opens: OK
> >
> > Debug ioctls:
> > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> > test VIDIOC_LOG_STATUS: OK (Not Supported)
> >
> > Input ioctls:
> > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> > test VIDIOC_ENUMAUDIO: OK (Not Supported)
> > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 0 Audio Inputs: 0 Tuners: 0
> >
> > Output ioctls:
> > test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> > Outputs: 0 Audio Outputs: 0 Modulators: 0
> >
> > Input/Output configuration ioctls:
> > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> > test VIDIOC_G/S_EDID: OK (Not Supported)
> >
> > Control ioctls:
> > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> > test VIDIOC_QUERYCTRL: OK
> > test VIDIOC_G/S_CTRL: OK
> > test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > Standard Controls: 5 Private Controls: 0
> >
> > Format ioctls:
> > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> > test VIDIOC_G/S_PARM: OK (Not Supported)
> > test VIDIOC_G_FBUF: OK (Not Supported)
> > test VIDIOC_G_FMT: OK
> > test VIDIOC_TRY_FMT: OK
> > test VIDIOC_S_FMT: OK
> > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> > test Cropping: OK
> > test Composing: OK
> > test Scaling: OK
> >
> > Codec ioctls:
> > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> > test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >
> > Buffer ioctls:
> > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> > test VIDIOC_EXPBUF: OK
> >
> > Test input 0:
> >
> >
> > Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
> >
> > Minghsiu Tsai (6):
> > VPU: mediatek: Add mdp support
> > dt-bindings: Add a binding for Mediatek MDP
> > media: Add Mediatek MDP Driver
> > arm64: dts: mediatek: Add MDP for MT8173
> > media: mtk-mdp: support pixelformat V4L2_PIX_FMT_MT21C
> > media: mtk-mdp: add Maintainers entry for Mediatek MDP driver
> >
> > .../devicetree/bindings/media/mediatek-mdp.txt | 109 ++
> > MAINTAINERS | 9 +
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 84 ++
> > drivers/media/platform/Kconfig | 17 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/mtk-mdp/Makefile | 9 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 159 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 72 ++
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 294 +++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 260 ++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h | 126 ++
> > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1278 ++++++++++++++++++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h | 22 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_regs.c | 156 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_regs.h | 31 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 145 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h | 41 +
> > drivers/media/platform/mtk-vpu/mtk_vpu.h | 5 +
> > 18 files changed, 2819 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > create mode 100644 drivers/media/platform/mtk-mdp/Makefile
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h
> >
^ permalink raw reply
* [PATCH] clk: imx31: fix potential stack corruption on clock initialization
From: Uwe Kleine-König @ 2016-09-19 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474249708-11088-1-git-send-email-vz@mleia.com>
On Mon, Sep 19, 2016 at 04:48:28AM +0300, Vladimir Zapolskiy wrote:
> Function mx31_clocks_init() is called during clock intialization on
> legacy boards with reference clock frequency passed as its input
> argument, this can be verified by examination of the function
> declaration found in arch/arm/mach-imx/common.h and actual function
> users which include that header file.
I don't think this can corrupt the stack. The caller puts a value in r0
that is unused by mx31_clocks_init. And given that all callers pass
26000000 there should happen nothing bad apart from a compiler warning.
So: the change is fine, IMHO the commit log shouldn't mention stack
corruption.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2263d508999ada9476268138b2922702eb50131f.1474260360.git.maitysanchayan@gmail.com>
Use enable-gpios property of PWM backlight driver for backlight
control.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Fix commit message
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 8c67dd8..9100bde 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -49,7 +49,10 @@
backlight: backlight {
compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_bl_on>;
pwms = <&pwm4 0 5000000>;
+ enable-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
@@ -614,6 +617,12 @@
>;
};
+ pinctrl_gpio_bl_on: gpioblon {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
+ >;
+ };
+
pinctrl_gpio_keys: gpio1io04grp {
fsl,pins = <
/* Power button */
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: imx6q-apalis-ixora: Remove use of pwm-leds
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2263d508999ada9476268138b2922702eb50131f.1474260360.git.maitysanchayan@gmail.com>
Remove use of pwm-leds and use the standard /sys/class/pwm
interface from PWM subsystem.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index 82b81e0..383192c 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -146,28 +146,6 @@
gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
};
};
-
- pwmleds {
- compatible = "pwm-leds";
-
- ledpwm1 {
- label = "PWM1";
- pwms = <&pwm1 0 50000>;
- max-brightness = <255>;
- };
-
- ledpwm2 {
- label = "PWM2";
- pwms = <&pwm2 0 50000>;
- max-brightness = <255>;
- };
-
- ledpwm3 {
- label = "PWM3";
- pwms = <&pwm3 0 50000>;
- max-brightness = <255>;
- };
- };
};
&backlight {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
Remove the use of DDC I2C bus bitbang to support reading of EDID
and rely on support from internal HDMI I2C master controller instead.
As a result remove the device tree property ddc-i2c-bus.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Change the ranking in i2c aliases
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++---------
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 25 +++++++++----------------
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index 207b85b..82b81e0 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -55,10 +55,9 @@
"fsl,imx6q";
aliases {
- i2c0 = &i2cddc;
- i2c1 = &i2c1;
- i2c2 = &i2c2;
- i2c3 = &i2c3;
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ i2c2 = &i2c3;
};
aliases {
@@ -186,11 +185,6 @@
};
&hdmi {
- ddc-i2c-bus = <&i2cddc>;
- status = "okay";
-};
-
-&i2cddc {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 99e323b..8c67dd8 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -53,18 +53,6 @@
status = "disabled";
};
- /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
- i2cddc: i2c at 0 {
- compatible = "i2c-gpio";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c_ddc>;
- gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
- &gpio2 30 GPIO_ACTIVE_HIGH /* scl */
- >;
- i2c-gpio,delay-us = <2>; /* ~100 kHz */
- status = "disabled";
- };
-
reg_1p8v: regulator-1p8v {
compatible = "regulator-fixed";
regulator-name = "1P8V";
@@ -209,6 +197,12 @@
};
};
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi_ddc>;
+ status = "disabled";
+};
+
/*
* GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
* board)
@@ -633,11 +627,10 @@
>;
};
- pinctrl_i2c_ddc: gpioi2cddcgrp {
+ pinctrl_hdmi_ddc: hdmiddcgrp {
fsl,pins = <
- /* DDC bitbang */
- MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
- MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kishon Vijay Abraham I @ 2016-09-19 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCC5fhbtkNdc6MJs7veD+xVGC6Qb-jgX_pwvraP1x2JrhQ@mail.gmail.com>
Hi,
On Monday 19 September 2016 01:26 AM, Martin Blumenstingl wrote:
> Hi Kishon,
>
> On Fri, Sep 16, 2016 at 10:19 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi,
>>
>> On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
>>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>>> However, the problem with all of the solutions proposed (runtime PM ones
>>>> included) is that we're forcing a board-specific design issue (2 devices
>>>> sharing a reset line) into a driver that should not have any
>>>> board-specific assumptions in it.
>>>>
>>>> For example, if this driver is used on another platform where different
>>>> PHYs have different reset lines, then one of them (the unlucky one who
>>>> is not probed first) will never get reset. So any form of per-device
>>>> ref-counting is not a portable solution.
>>> maybe we should also consider Ben's solution: he played with the USB
>>> PHY on his Meson8b board. His approach was to have only one USB PHY
>>> driver instance which exposes two PHYs.
>>> The downside of this: the driver would have to know the offset of the
>>> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
>>> the reset using runtime PM without any hacks.
>>
>> I think the offset information can come from the devicetree too. The phy can be
>> modeled something like below.
>>
>> usb-phys at c0000000 {
>> compatible = "amlogic,meson-gxbb-usb2-phy";
>> reg = <0x0 0xc0000000 0x0 0x40>;
>> #address-cells = <2>;
>> #size-cells = <2>;
>> ranges = <0x0 0x0 0x0 0xc0000000 0x0 0x40>;
>> resets = <&reset 34>;
>>
>> usb0_phy: usb_phy at 0 {
>> #phy-cells = <0>;
>> reg = <0x0 0x0 0x0 0x20>;
>> clocks = <&clkc CLKID_USB &clkc CLKID_USB0>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>>
>> usb1_phy: usb_phy at 20 {
>> #phy-cells = <0>;
>> reg = <0x0 0x20 0x0 0x20>;
>> clocks = <&clkc CLKID_USB &clkc CLKID_USB1>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>> };
>>
>> This way the driver will be probed only once (the reset can be done during
>> probe). The phy driver should scan the dt node and for every sub-node it
>> invokes phy_create?
> I'll recap what we have discussed so far (so you don't have to re-read
> the whole thread):
> The reference driver treats both USB PHYs as separate devices (the
> datasheet has no information about the PHYs though). The only
> "special" thing is the shared reset line -> together with Philipp
> Zabel (the reset framework maintainer) we decided to make
> reset_control_reset work for shared reset lines.
>
> That means we can keep the two PHYs as separate devices inside the
> .dts, while keeping everything else separate (just like the reference
> driver)
> Is this fine for you and Arnd?
yeah.. I'm fine with that.
Thanks
Kishon
>
>
> Regards,
> Martin
>
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912113615.GA20804@leverpostej>
On Mon, 2016-09-12 at 12:36 +0100, Mark Rutland wrote:
> On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote:
> > +static __always_inline void arch_timer_cval_write_cp15(int access, u64
> > val)
> > +{
> > + if (access == ARCH_TIMER_PHYS_ACCESS)
> > + asm volatile("msr cntp_cval_el0, %0" : : "r" (val));
> > + else if (access == ARCH_TIMER_VIRT_ACCESS)
> > + asm volatile("msr cntv_cval_el0, %0" : : "r" (val));
> > +
> > + isb();
> > +}
> Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these
> accesses into arch_timer_reg_write_cp15().
Adding ARCH_TIMER_REG_CVAL to the enum means we get warnings from bunch of
switch statements that don't actually need a CVAL implementation -- or else we
have to add untested CVAL accessors for arm32 and mmio. ?The arm32 part would
add another dependency on getting an ack from RMK, that can't be postponed as
easily as the archdata/vdso patch.
Since this is specific to an erratum rather than general cval support, I can
move the accesses into fsl_a008585_set_next_event (and convert to
write_sysreg).
> >
> > +
> > + do {
> > + isb();
> What's the ISB for?
>
> The core should order accesses to the same counter, and any ISB required
> for ordering against other counters should already be present. So I
> don't follow what this is trying to achieve.
>
> If this is necessary, please add a comment explaining what it is
> intended to ensure.
I think it may have been a leftover from early patch versions when this
function was entirely replacing arch_counter_get_cntvct(). ?I'm not sure why I
put it in the loop, though.
> > @@ -271,6 +346,19 @@ static int
> > arch_timer_set_next_event_phys_mem(unsigned long evt,
> > ? return 0;
> > ?}
> > ?
> > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > +{
> > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > + return;
> > +
> > + if (arch_timer_uses_ppi == VIRT_PPI)
> > + clk->set_next_event = fsl_a008585_set_next_event_virt;
> > + else
> > + clk->set_next_event = fsl_a008585_set_next_event_phys;
> > +#endif
> > +}
> > +
> I'm not keen on the magic hook to reset the function pointers, and the
> additional phys/virt stubs seem pointless. Instead, can we fold this
> into the existing set_next_event? e.g. have that do:
>
> if (needs_fsl_a008585_workaround() {
> fsl_a008585_set_next_event(access, evt, clk);
> return;
> }
OK. ?I had been trying to avoid messing with the standard set_next_event, but
it doesn't matter as much now that static branches are being used. ?In that
case we can avoid duplicating the ctrl code, and only replace the tval write.
-Scott
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6A88D.7000002@arm.com>
On Mon, 2016-09-12 at 14:07 +0100, Marc Zyngier wrote:
> On 12/09/16 13:59, Mark Rutland wrote:
> >
> > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
> > >
> > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > > >
> > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > > >
> > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > > some cleanup [1,2] that just landed in the arm64 for-next/core
> > > > > branch.
> > > > >
> > > > > Could you please rebase atop of that?
> > > > Well, we should figure out what tree this is going through first.
> > > > There
> > > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > > of it is carrying the appropriate acks for me to queue it.
> > > Given that mix, I had assumed that this would all go through the arm64
> > > tree -- I see that Rob has already acked the binding, and I'm happy to
> > > give my ack for the driver once that's in shape.
> > Now I see that I'd missed the arch/arm changes in patch 4, which lack a
> > relevant ack.
> >
> > Given that, I don't know what to suggest.
> I wouldn't mind delaying patch 4 until it gets acked by RMK, as it
> doesn't impact the functionality.
Mark asked me to move that patch before the workaround patch, to avoid ever
having to add more code that messes with the name. ?Should I keep the order as
is then?
-Scott
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 4:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912123027.GA13741@leverpostej>
On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> >
> > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > >
> > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > >
> > > Could you please rebase atop of that?
> > Well, we should figure out what tree this is going through first. There
> > are a mixture of arm, arm64, driver and dts changes here and not all
> > of it is carrying the appropriate acks for me to queue it.
> Given that mix, I had assumed that this would all go through the arm64
> tree -- I see that Rob has already acked the binding, and I'm happy to
> give my ack for the driver once that's in shape.
>
> The dts change could go through arm-soc in parallel, I guess. It doesn't
> look like arm-soc have been Cc'd for that, though.
The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
did. ?There doesn't appear to be a separate arm-soc mailing list, nor is there
a request to CC Olof/Arnd. ?I did CC Shawn Guo who has been handling the
device tree patches for these chips.
-Scott
^ permalink raw reply
* We could not deliver your parcel, #000246043
From: FedEx Standard Overnight @ 2016-09-19 3:58 UTC (permalink / raw)
To: linux-arm-kernel
Dear Customer,
Courier was unable to deliver the parcel to you.
Please, download Delivery Label attached to this email.
Thanks and best regards,
Tony Goodman,
Support Manager.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delivery_Notification_000246043.zip
Type: application/zip
Size: 6671 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/c6f03669/attachment-0001.zip>
^ permalink raw reply
* [PATCH V2 1/7] dt-bindings: Update QorIQ TMU thermal bindings
From: Zhang Rui @ 2016-09-19 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADRPPNQ+hikr1qNK1wPbLnhudUrU1bN_2iuYyRQnqCN4Zwh83Q@mail.gmail.com>
On ?, 2016-09-14 at 11:40 -0500, Leo Li wrote:
> On Wed, Jun 8, 2016 at 2:52 PM, Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Jun 07, 2016 at 11:27:34AM +0800, Jia Hongtao wrote:
> > >
> > > For different types of SoC the sensor id and endianness may vary.
> > > "#thermal-sensor-cells" is used to provide sensor id information.
> > > "little-endian" property is to tell the endianness of TMU.
> > >
> > > Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
> > > ---
> > > Changes for V2:
> > > * Remove formatting chnages.
> > >
> > > ?Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 7
> > > +++++++
> > > ?1 file changed, 7 insertions(+)
> > Acked-by: Rob Herring <robh@kernel.org>
> Hi Zhang Rui,
>
> Since you have applied the driver patch, can you also apply the
> binding patch???The binding is supposed to go with the driver.
>
Do you mean I should take both patch 1/7 and 7/7? I can not see the
other patches in this patch set.
thanks,
rui
^ permalink raw reply
* [PATCH 2/2] clk: imx31: properly init clocks for machines with DT
From: Vladimir Zapolskiy @ 2016-09-19 2:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474252939-12579-1-git-send-email-vz@mleia.com>
The change converts exported mx31_clocks_init_dt() into a static
initialization function registered by CLK_OF_DECLARE().
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/clk/imx/clk-imx31.c | 50 +++++++++++++++++++++++----------------------
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 6a49ba2..cbce308 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -21,6 +21,7 @@
#include <linux/io.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <soc/imx/revision.h>
#include <soc/imx/timer.h>
#include <asm/irq.h>
@@ -72,14 +73,8 @@ static struct clk ** const uart_clks[] __initconst = {
NULL
};
-static void __init _mx31_clocks_init(unsigned long fref)
+static void __init _mx31_clocks_init(void __iomem *base, unsigned long fref)
{
- void __iomem *base;
- struct device_node *np;
-
- base = ioremap(MX31_CCM_BASE_ADDR, SZ_4K);
- BUG_ON(!base);
-
clk[dummy] = imx_clk_fixed("dummy", 0);
clk[ckih] = imx_clk_fixed("ckih", fref);
clk[ckil] = imx_clk_fixed("ckil", 32768);
@@ -147,19 +142,17 @@ static void __init _mx31_clocks_init(unsigned long fref)
clk_prepare_enable(clk[iim_gate]);
mx31_revision();
clk_disable_unprepare(clk[iim_gate]);
-
- np = of_find_compatible_node(NULL, NULL, "fsl,imx31-ccm");
-
- if (np) {
- clk_data.clks = clk;
- clk_data.clk_num = ARRAY_SIZE(clk);
- of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
- }
}
int __init mx31_clocks_init(unsigned long fref)
{
- _mx31_clocks_init(fref);
+ void __iomem *base;
+
+ base = ioremap(MX31_CCM_BASE_ADDR, SZ_4K);
+ if (!base)
+ panic("%s: failed to map registers\n", __func__);
+
+ _mx31_clocks_init(base, fref);
clk_register_clkdev(clk[gpt_gate], "per", "imx-gpt.0");
clk_register_clkdev(clk[ipg], "ipg", "imx-gpt.0");
@@ -222,22 +215,31 @@ int __init mx31_clocks_init(unsigned long fref)
return 0;
}
-int __init mx31_clocks_init_dt(void)
+static void __init mx31_clocks_init_dt(struct device_node *np)
{
- struct device_node *np;
+ struct device_node *osc_np;
u32 fref = 26000000; /* default */
+ void __iomem *ccm;
- for_each_compatible_node(np, NULL, "fixed-clock") {
- if (!of_device_is_compatible(np, "fsl,imx-osc26m"))
+ for_each_compatible_node(osc_np, NULL, "fixed-clock") {
+ if (!of_device_is_compatible(osc_np, "fsl,imx-osc26m"))
continue;
- if (!of_property_read_u32(np, "clock-frequency", &fref)) {
- of_node_put(np);
+ if (!of_property_read_u32(osc_np, "clock-frequency", &fref)) {
+ of_node_put(osc_np);
break;
}
}
- _mx31_clocks_init(fref);
+ ccm = of_iomap(np, 0);
+ if (!ccm)
+ panic("%s: failed to map registers\n", __func__);
- return 0;
+ _mx31_clocks_init(ccm, fref);
+
+ clk_data.clks = clk;
+ clk_data.clk_num = ARRAY_SIZE(clk);
+ of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
}
+
+CLK_OF_DECLARE(imx31_ccm, "fsl,imx31-ccm", mx31_clocks_init_dt);
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] ARM: imx31: remove mx31_clocks_init_dt() function calls
From: Vladimir Zapolskiy @ 2016-09-19 2:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474252939-12579-1-git-send-email-vz@mleia.com>
Clock initialization for i.MX31 powered machines with DT support
should be done by a call of an init function registered with
CLK_OF_DECLARE() in common clock framework.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/imx31-dt.c | 6 ------
2 files changed, 7 deletions(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index a8f4693..e97d8cb 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -48,7 +48,6 @@ int mx21_clocks_init(unsigned long lref, unsigned long fref);
int mx27_clocks_init(unsigned long fref);
int mx31_clocks_init(unsigned long fref);
int mx35_clocks_init(void);
-int mx31_clocks_init_dt(void);
struct platform_device *mxc_register_gpio(char *name, int id,
resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
void mxc_set_cpu_type(unsigned int type);
diff --git a/arch/arm/mach-imx/imx31-dt.c b/arch/arm/mach-imx/imx31-dt.c
index 62e6b4f..668d74b 100644
--- a/arch/arm/mach-imx/imx31-dt.c
+++ b/arch/arm/mach-imx/imx31-dt.c
@@ -23,11 +23,6 @@ static const char * const imx31_dt_board_compat[] __initconst = {
NULL
};
-static void __init imx31_dt_timer_init(void)
-{
- mx31_clocks_init_dt();
-}
-
/* FIXME: replace with DT binding */
static const struct resource imx31_rnga_res[] __initconst = {
DEFINE_RES_MEM(MX31_RNGA_BASE_ADDR, SZ_16K),
@@ -43,7 +38,6 @@ DT_MACHINE_START(IMX31_DT, "Freescale i.MX31 (Device Tree Support)")
.map_io = mx31_map_io,
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
- .init_time = imx31_dt_timer_init,
.init_machine = imx31_dt_mach_init,
.dt_compat = imx31_dt_board_compat,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 0/2] ARM: imx31/of: clk: init clock controller with CLK_OF_DECLARE
From: Vladimir Zapolskiy @ 2016-09-19 2:42 UTC (permalink / raw)
To: linux-arm-kernel
The change is based on v4.8.0-rc1 and plus it depends on this fixup:
ARM: dts: imx31: fix clock control module interrupts description
The change is tested on qemu kzm target and mx31lite board, while both
targets don't have DTS in upstream, I had to write simple DTS files for
them, because the proposed change is for i.MX31 targets with OF support.
The second change in the series compilation time dependent on the first
one, while the first change apparently should break runtime execution
of i.MX31 boards with OF support, if both changes are applied everything
should be fine, regression testing on the same legacy targets does not
show any problems. Moreover i.MX31/OF/clock initialization seems to be
broken currently, if the change is not applied I can not get a working
clock source during early boot stage, jiffies are not incremented, but
because I didn't check the problem thoroughly (can it be caused by
missing CLK_OF_DECLARE? Or caused by something fixed by the change
http://www.spinics.net/lists/linux-clk/msg12235.html ?) and because
the change was tested against code which is not found in upstream,
I won't call this change as a fix, however its application is apparently
wanted to get better OF support for i.MX31 targets.
Vladimir Zapolskiy (2):
ARM: imx31: remove mx31_clocks_init_dt() function calls
clk: imx31: properly init clocks for machines with DT
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/imx31-dt.c | 6 ------
drivers/clk/imx/clk-imx31.c | 49 ++++++++++++++++++++++----------------------
3 files changed, 25 insertions(+), 31 deletions(-)
--
2.8.1
^ permalink raw reply
* [PATCH] ARM: dts: imx31: fix clock control module interrupts description
From: Vladimir Zapolskiy @ 2016-09-19 1:54 UTC (permalink / raw)
To: linux-arm-kernel
The type of AVIC interrupt controller found on i.MX31 is one-cell,
namely 31 for CCM DVFS and 53 for CCM, however for clock control
module its interrupts are specified as 3-cells, fix it.
Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
Documentation/devicetree/bindings/clock/imx31-clock.txt | 2 +-
arch/arm/boot/dts/imx31.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842..8163d56 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -77,7 +77,7 @@ Examples:
clks: ccm at 53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
- interrupts = <0 31 0x04 0 53 0x04>;
+ interrupts = <31>, <53>;
#clock-cells = <1>;
};
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 1ce7ae9..3e0893e 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -122,7 +122,7 @@
clks: ccm at 53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
- interrupts = <0 31 0x04 0 53 0x04>;
+ interrupts = <31>, <53>;
#clock-cells = <1>;
};
};
--
2.8.1
^ 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