* [PATCH] pwm: core: Use pwm->args.polarity to setup PWM_POLARITY_INVERSED
From: Lukasz Majewski @ 2016-10-06 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-3-bhuvanchandra.dv@toradex.com>
The pwm_set_polarity() function finally calls pwm_apply_state(), which
in turn requires state->duty_cycle and state->period properly set.
In the moment when polarity is set, the PWM is disabled and not configured.
For that reason both above variables are set to 0 and the polarity is not
set.
To be sure that polarity is setup, one needs to set pwm->args.polarity, which
controls MX3_PWMCR_POUTC bit setting at imx_pwm_config_v2().
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
---
This patch should be applied on top of:
"[v2,2/6] pwm: core: make the PWM_POLARITY flag in DTB optional"
http://patchwork.ozlabs.org/patch/677330/
---
drivers/pwm/core.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1f62668..6cd6004 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -153,13 +153,11 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
return pwm;
pwm->args.period = args->args[1];
+ pwm->args.polarity = PWM_POLARITY_NORMAL;
- if (args->args_count > 2) {
+ if (args->args_count > 2)
if (args->args[2] & PWM_POLARITY_INVERTED)
- pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
- else
- pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
- }
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
return pwm;
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: imx7-colibri: Use pwm polarity control
From: Lukasz Majewski @ 2016-10-06 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-6-bhuvanchandra.dv@toradex.com>
On Sat, 1 Oct 2016 15:42:34 +0530
Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> wrote:
> Configure PWM polarity control.
>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> ---
> arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
> b/arch/arm/boot/dts/imx7-colibri.dtsi index a9cc657..2af5e3e 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -43,7 +43,7 @@
> / {
> bl: backlight {
> compatible = "pwm-backlight";
> - pwms = <&pwm1 0 5000000>;
> + pwms = <&pwm1 0 5000000 0>;
My recommendation would be to add:
#include <dt-bindings/pwm/pwm.h>
and then define pwms as:
pwms = <&pwm1 0 5000000 PWM_POLARITY_NORMAL>;
It would be more readable
Best regards,
?ukasz Majewski
> };
>
> reg_module_3v3: regulator-module-3v3 {
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/124c447f/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/6] pwm: core: make the PWM_POLARITY flag in DTB optional
From: Lukasz Majewski @ 2016-10-06 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-3-bhuvanchandra.dv@toradex.com>
Hi Bhuvanchandra,
> From: Lothar Wassmann <LW@KARO-electronics.de>
>
> Change the pwm chip driver registration, so that a chip driver that
> supports polarity inversion can still be used with DTBs that don't
> provide the 'PWM_POLARITY' flag.
>
> This is done to provide polarity inversion support for the pwm-imx
> driver without having to modify all existing DTS files.
>
> Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> Suggested-by: Thierry Reding <thierry.reding@gmail.com>
> ---
> drivers/pwm/core.c | 27 ++++++++++++++++-----------
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 195373e..aae8db3 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -137,9 +137,14 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
> const struct of_phandle_args *args) {
> struct pwm_device *pwm;
>
> + /* check, whether the driver supports a third cell for flags
> */ if (pc->of_pwm_n_cells < 3)
> return ERR_PTR(-EINVAL);
>
> + /* flags in the third cell are optional */
> + if (args->args_count < 2)
> + return ERR_PTR(-EINVAL);
> +
> if (args->args[0] >= pc->npwm)
> return ERR_PTR(-EINVAL);
>
> @@ -149,10 +154,12 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
> const struct of_phandle_args *args)
> pwm->args.period = args->args[1];
>
> - if (args->args[2] & PWM_POLARITY_INVERTED)
> - pwm->args.polarity = PWM_POLARITY_INVERSED;
> - else
> - pwm->args.polarity = PWM_POLARITY_NORMAL;
> + if (args->args_count > 2) {
> + if (args->args[2] & PWM_POLARITY_INVERTED)
> + pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
^^^^^^^^^^^^^^^^
here we should set pwm->args.polarity, since
the pwm_set_polarity() calls pwm_apply_state()
which requires duty_cycle and period to be set.
In this particular moment it is not yet set and
polarity is not properly configured.
Patch fixing this will be sent as a reply to this e-mail. Please just
squash it and test on your platform.
Best regards,
?ukasz Majewski
> + else
> + pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
> + }
>
> return pwm;
> }
> @@ -163,9 +170,14 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const
> struct of_phandle_args *args) {
> struct pwm_device *pwm;
>
> + /* sanity check driver support */
> if (pc->of_pwm_n_cells < 2)
> return ERR_PTR(-EINVAL);
>
> + /* all cells are required */
> + if (args->args_count != pc->of_pwm_n_cells)
> + return ERR_PTR(-EINVAL);
> +
> if (args->args[0] >= pc->npwm)
> return ERR_PTR(-EINVAL);
>
> @@ -672,13 +684,6 @@ struct pwm_device *of_pwm_get(struct device_node
> *np, const char *con_id) goto put;
> }
>
> - if (args.args_count != pc->of_pwm_n_cells) {
> - pr_debug("%s: wrong #pwm-cells for %s\n",
> np->full_name,
> - args.np->full_name);
> - pwm = ERR_PTR(-EINVAL);
> - goto put;
> - }
> -
> pwm = pc->of_xlate(pc, &args);
> if (IS_ERR(pwm))
> goto put;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/743020b3/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/6] Support PWM polarity control
From: Lukasz Majewski @ 2016-10-06 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be9c9f6b22788ca4d9c9243a46932945@agner.ch>
Hi Stefan,
> Hi Lukasz,
>
> On 2016-10-04 00:48, Lukasz Majewski wrote:
> > Dear Bhuvanchandra,
> >
> > Thank you for your effort to send those patches to ML.
> >
> >> Changes since v2:
> >>
> >> - Picked the stalled patchset[1] from Lothar Wassmann which adds
> >> the basic support for polarity control on imx-pwm driver and adds
> >> backward compatibility support for devices which does not have
> >> polarity control feature.
> >>
> >> Changes since Lothars v6:
> >>
> >> - Squash Lukasz patch[2].
> >>
> >> [1] http://thread.gmane.org/gmane.linux.pwm/1621
> >> [2] https://www.spinics.net/lists/arm-kernel/msg530818.html
> >>
> >> Bhuvanchandra DV (3):
> >> arm: dts: imx7: Update #pwm-cells for PWM polarity control
> >> arm: dts: imx7-colibri: Use pwm polarity control
> >> arm: dts: imx7-colibri: Use enable-gpios for BL_ON
> >>
> >> Lothar Wassmann (3):
> >> pwm: print error messages with pr_err() instead of pr_debug()
> >> pwm: core: make the PWM_POLARITY flag in DTB optional
> >> pwm: imx: support output polarity inversion
> >
> > For some reason this patchset works differently than the one
> > developed by Lothar.
> >
> > The difference is with the brightness level control.
> >
> > My brightness definition in DTS:
> >
> > pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
> >
> > brightness-levels = < 0 1 2 3 4 5 6
> > 7 8 9
> >
> > .. ............
> > 250 251 252 253 254 255>;
> > default-brightness-level = <50>;
> > enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
> >
>
> If you are using something else than i.MX 7 you also want to update
> the SoC level device tree, specifically change the pwm-cells property:
> #pwm-cells = <3>;
Good point. However, it is declared elsewhere (with pwm2 node)
&pwm2 {
#pwm-cells = <3>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm2>;
status = "okay";
};
>
>
> > When I go to the backlight sysfs entry:
> >
> > cd /sys/devices/soc0/backlight/backlight/backlight
> >
> > It seems like the brightness level control is inverted - i.e.
> > 'echo 20 > brightness" makes picture on the screen very bright, and
> > 'echo 200 > brightness' makes the picture diminish.
> >
> > With my "internal" patches the situation is opposite (and I've
> > checked it with my HW connections).
>
> Just to check whether the driver actually applies the polarity you can
> add a #define DEBUG at the top of the driver (drivers/pwm/pwm-imx.c)
> and pass ignore_loglevel as kernel command line. This should give you
> "PWM supports output inversion" at startup and a "... polarity set
> to .." message whenever the polarity is set.
The problem is with the Bhuvanchandra original patch.
I will point it out when replying to original patch.
Thanks for support,
?ukasz Majewski
>
> --
> Stefan
>
> >
> > Could you check on your setup if similar situation takes place? I
> > mean if the brightness control works as expected?
> >
> > Thanks in advance,
> > ?ukasz Majewski
> >
> >>
> >> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +--
> >> arch/arm/boot/dts/imx7-colibri.dtsi | 12 +++++-
> >> arch/arm/boot/dts/imx7s.dtsi | 8 ++--
> >> drivers/pwm/core.c | 31
> >> ++++++++------ drivers/pwm/pwm-imx.c |
> >> 51 +++++++++++++++++++++-- 5 files changed, 83 insertions(+), 25
> >> deletions(-)
> >>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/67f38538/attachment-0001.sig>
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Venkatesh Vivekanandan @ 2016-10-06 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81bf19a4-5716-1a68-77c2-a0a98f19ecc0@arm.com>
On Wed, Oct 5, 2016 at 10:47 PM, Suzuki K Poulose
<Suzuki.Poulose@arm.com> wrote:
> On 05/10/16 06:27, Venkatesh Vivekanandan wrote:
>>
>> On Tue, Oct 4, 2016 at 7:59 PM, Suzuki K Poulose <Suzuki.Poulose@arm.com>
>> wrote:
>>>
>>> On 04/10/16 06:37, Venkatesh Vivekanandan wrote:
>>>>
>>>>
>>>> On Mon, Oct 3, 2016 at 6:44 PM, Sudeep Holla <sudeep.holla@arm.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Venkatesh,
>>>>>
>>>>> On 03/10/16 12:36, Venkatesh Vivekanandan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I am trying to collect ETF trace from Juno R1 and could see "cpu
>>>>>> stall" while dumping the trace. Attached is the log of sequence
>>>>>> followed. Was trying to collect the trace data from hardware and see
>>>>>> if it is any valid data. Am I missing anything here?.
>>>>>>
>>>>>
>>>>> There are few fixes from me and Suzuki queued for v4.9.
>>>>> Can you check if this issue persists even on linux-next ?
>>>>
>>>>
>>>>
>>>> Issue is the same in linux-next as well. Please find the attached log.
>>>>
>>>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>>>> [ 120.009698] INFO: rcu_preempt detected stalls on CPUs/tasks:
>>>> [ 120.015307] 2-...: (1 GPs behind) idle=f11/140000000000000/0
>>>> softirq=224/224 fqs=1903
>>>> [ 120.023226] (detected by 1, t=5255 jiffies, g=-1, c=-2, q=19)
>>>> [ 120.029001] Task dump for CPU 2:
>>>> [ 120.032190] dd R running task 0 1270 1267
>>>> 0x00000002
>>>> [ 120.039172] Call trace:
>>>> [ 120.041594] [<ffff000008085534>] __switch_to+0xc8/0xd4
>>>> [ 120.046675] [<0000000000020000>] 0x20000
>>>>
>>>> Steps followed,
>>>> # git clone
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>>>> linux-next
>>>> # cd linux-next
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig <---
>>>> enable coresight
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 Image
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs
>>>> # arch/arm64/boot/Image <--- copied this kernel
>>>> # arch/arm64/boot/dts/arm/juno-r1.dtb <--- copied this dtb
>>>>
>>>> Top commit in linux-next is,
>>>>
>>>> commit c7d3b912180a9bb0733e5cfab84e5a7493dd3599
>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>> Date: Tue Oct 4 14:52:03 2016 +1100
>>>>
>>>> Add linux-next specific files for 20161004
>>>
>>>
>>>
>>> Can't reproduce it here either.
>>>
>>> root at localhost:/sys/bus/coresight/devices# echo 1 >
>>> 20010000.etf/enable_sink
>>> root at localhost:/sys/bus/coresight/devices# echo 1 >
>>> 22140000.etm/enable_source
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.227546 s, 288 kB/s
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.233527 s, 281 kB/s
>>> root at localhost:/sys/bus/coresight/devices# echo 0 >
>>> 20010000.etf/enable_sink
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.474943 s, 138 kB/s
>>>
>>> FWIW, here is my firmware version :
>>>
>>> NOTICE: Booting Trusted Firmware
>>> NOTICE: BL1: v1.1(release):e04723e21362
>>> NOTICE: BL1: Built : 15:39:56, Sep 1 2015
>>> NOTICE: BL1: Booting BL2
>>> NOTICE: BL2: v1.1(release):e04723e21362
>>> NOTICE: BL2: Built : 15:42:30, Sep 1 2015
>>> NOTICE: BL1: Booting BL3-1
>>> NOTICE: BL3-1: v1.1(release):604d5da6f2aa
>>> NOTICE: BL3-1: Built : 14:50:36, Sep 10 2015
>>> UEFI firmware (version ea31f8e built at 16:35:17 on Aug 5 2015)
>>>
>>
>> Hang is seen while trying to dump trace _after_ disabling the ETM
>> source. Is it not supposed to work?.
>> It works fine, when dumped before disabling ETM source. Please find
>> the log below.
>>
>> linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
>> [ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
>> [ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> enabled
>> [ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 enabled
>> [ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 108.105492] coresight-tmc 20010000.etf: TMC read start
>> [ 108.404335] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 125.069740] coresight-tmc 20010000.etf: TMC read start
>> [ 125.184370] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
>> [ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
>> [ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 disabled
>> [ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> disabled
>> [ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> <---- It hangs here...
>
>
> The point is once you disable the source, which eventually disables
> all the components upto the sink, the data in the ETF is already captured
> into a buffer, so there is no coresight hardware access involved.
>
> Also, looks like the open(/dev/20010000.etf,..) from the dd didn't
> complete,
> as we don't see a "TMC read start" line.
>
> Could you please :
>
> a) Try the patch [0] and see if it helps ?
> b) If a doesn't help, after disabling the source, run any other command
> instead of the trace collection. e.g,
>
> dd if=/dev/zero of=/dev/null
>
> and see if it hangs the system in a similar way ?
Applied the patch(fixed unused variable warning) and tested. System
hangs the same way as before
with one extra print. dd to /dev/null works fine. Please find the log below.
linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 60.519034] coresight-tmc 20010000.etf: TMC read start
[ 60.635825] coresight-tmc 20010000.etf: TMC read end
65536+0 records in
65536+0 records out
linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
[ 78.394169] coresight-etm4x 22140000.etm: ETM tracing disabled
[ 78.399977] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
inport 1 disabled
[ 78.407225] coresight-funnel 20040000.main-funnel: FUNNEL inport 0 disabled
[ 78.414140] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
linaro-test [rc=0]# dd if=/dev/zero of=/dev/null bs=1 count=100
100+0 records in
100+0 records out
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 104.673413] coresight-tmc 20010000.etf: TMC read start
==== it just hangs here====
>
>
> Thanks
> Suzuki
>
> [0] test patch
>
> ----8>----
>
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index 1ffdab8..ef72ed8 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -511,13 +511,6 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> goto out;
> }
> - /* There is no point in reading a TMC in HW FIFO mode */
> - mode = readl_relaxed(drvdata->base + TMC_MODE);
> - if (mode != TMC_MODE_CIRCULAR_BUFFER) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> /* Don't interfere if operated from Perf */
> if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
>
>
>
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Venkatesh Vivekanandan @ 2016-10-06 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e1e514b-fc3b-ca96-4631-88d537019e08@arm.com>
On Wed, Oct 5, 2016 at 4:12 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On 05/10/16 06:27, Venkatesh Vivekanandan wrote:
>
> [...]
>
>
>>
>> Hang is seen while trying to dump trace _after_ disabling the ETM
>> source. Is it not supposed to work?.
>> It works fine, when dumped before disabling ETM source. Please find
>> the log below.
>>
>> linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
>> [ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
>> [ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> enabled
>> [ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 enabled
>> [ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 108.105492] coresight-tmc 20010000.etf: TMC read start
>> [ 108.404335] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 125.069740] coresight-tmc 20010000.etf: TMC read start
>> [ 125.184370] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
>> [ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
>> [ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 disabled
>> [ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> disabled
>> [ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> <---- It hangs here...
>>
>
> I get dd: failed to open '/dev/20010000.etf': Invalid argument
> once all the data is read.
>
It hangs in my board.
>> My firmware version,
>>
>> NOTICE: Booting Trusted Firmware
>> NOTICE: BL1: v1.1(debug):4a1dcde
>> NOTICE: BL1: Built : 17:54:40, Nov 24 2015
>> NOTICE: BL1: Booting BL2
>> NOTICE: BL2: v1.1(debug):4a1dcde
>> NOTICE: BL2: Built : 17:54:40, Nov 24 2015
>> NOTICE: BL1: Booting BL3-1
>> NOTICE: BL3-1: v1.1(debug):4a1dcde
>> NOTICE: BL3-1: Built : 17:54:40, Nov 24 2015
>> UEFI firmware (version 9ed6f7e built at 17:54:28 on Nov 24 2015)
>>
>
> OK, this looks as good as what Suzuki has, so should be fine.
> But it doesn't list SCP version, can you see that from the Linux boot
> logs ?(something like below)
>
> "scpi_protocol scpi: SCP Protocol 1.2 Firmware 1.17.0 version"
[ 2.537096] scpi_protocol scpi: SCP Protocol 1.0 Firmware 1.11.0 version
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index aafb594..01e1f39 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy at 2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..aafb594 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from v2:
* Fixed a typo in dts and driver.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23283056/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v3
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: add phy impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.0.372.g6fe1b14
^ permalink raw reply
* [PATCH] ARM: fix delays
From: Nicolas Pitre @ 2016-10-06 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1brv6h-0003j7-7J@rmk-PC.armlinux.org.uk>
On Wed, 5 Oct 2016, Russell King wrote:
> Commit 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value
> limitation") tried to increase the bogomips limitation, but in doing
> so messed up udelay such that it always gives about a 5% error in the
> delay, even if we use a timer.
>
> The calculation is:
>
> loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT
>
> Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT
> 30. Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000
> (eg, 166MHz timer, 1ms delay) this would calculate:
>
> ((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30
> => 165999
>
> With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get:
>
> (2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
> => 158269
>
> which is incorrect. This is due to a typo - correcting it gives:
>
> (2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
> => 165999
>
> i.o.w, the original value.
WTF!
I don't know what kind of drugs I was on to make such a typo. It's not
like if the 0 and 1 keys were close together.
For those who might wonder where the UDELAY_MULT magic value comes from:
loops = loops_per_jiffy * jiffies_per_sec * us_delay / us_per_sec
where:
jiffies_per_sec = HZ
us_per_sec = 1000000
therefore the constant part is HZ / 1000000 which is a small fractional
number. To make this usable with integer math, we scale up this
constant by 2^31, do the actual multiplication, and scale the result
back down by 2^31 with a simple shift. That means:
UDELAY_MULT = 2^31 * HZ / 1000000
= (2^31 / 1000000) * HZ
= 2147.483648 * HZ
= 2147 * HZ + 483648 * HZ / 1000000
Maybe I should make a patch documenting this directly in the code.
While at it, why 2^31? Because we assume HZ <= 1000 and us_delay <=
2000. The result of UDELAY_MULT * us_delay must not overflow 32 bits as
we let loops_per_jiffy span the whole 32 bits range and the final
product must fit in 64 bits. Therefore:
2000 * (2^31 * 1000 / 1000000) = 4294966000
This could be optimized even further by assuming that lpj will never
reach 32 bits of magnitude, limiting it to 31 bits. In this case the
scale factor could be 2^32, making a down shift by 32 bits even faster
than a shift by 31 bits.
> Fixes: 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value limitation")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/delay.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/delay.h b/arch/arm/include/asm/delay.h
> index b7a428154355..b1ce037e4380 100644
> --- a/arch/arm/include/asm/delay.h
> +++ b/arch/arm/include/asm/delay.h
> @@ -10,7 +10,7 @@
> #include <asm/param.h> /* HZ */
>
> #define MAX_UDELAY_MS 2
> -#define UDELAY_MULT UL(2047 * HZ + 483648 * HZ / 1000000)
> +#define UDELAY_MULT UL(2147 * HZ + 483648 * HZ / 1000000)
> #define UDELAY_SHIFT 31
>
> #ifndef __ASSEMBLY__
> --
> 2.1.0
>
>
^ permalink raw reply
* [GIT PULL] Mailbox changes for v4.9
From: Jassi Brar @ 2016-10-06 3:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit d060e0f603a4156087813d221d818bb39ec91429:
Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
(2016-09-06 12:33:12 -0700)
are available in the git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-next
for you to fetch changes up to a649244de727b87d38fe46d86ef98c8d1fc49551:
dt-bindings: mailbox: Add Amlogic Meson MHU Bindings (2016-09-07
13:07:18 +0530)
----------------------------------------------------------------
- New driver and DT bindings for MHU controller integrated
on Amlogic Meson platform.
----------------------------------------------------------------
Neil Armstrong (2):
mailbox: Add Platform Message-Handling-Unit variant driver
dt-bindings: mailbox: Add Amlogic Meson MHU Bindings
.../devicetree/bindings/mailbox/meson-mhu.txt | 34 ++++
drivers/mailbox/Kconfig | 10 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/platform_mhu.c | 205 +++++++++++++++++++++
4 files changed, 251 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
create mode 100644 drivers/mailbox/platform_mhu.c
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Benjamin Herrenschmidt @ 2016-10-06 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6bbfeb57-7a55-6a3e-60b2-3f44525e5882@huawei.com>
On Tue, 2016-10-04 at 13:02 +0100, John Garry wrote:
> Right, so I think Zhichang can make the necessary generic changes to?
> 8250 OF driver to support IO port as well as MMIO-based.
>
> However an LPC-based earlycon driver is still required.
>
> A note on hip07-based D05 (for those unaware): this does not use?
> LPC-based uart. It uses PL011. The hardware guys have managed some?
> trickery where they loopback the serial line around the BMC/CPLD. But we?
> still need it for hip06 D03 and any other boards which want to use LPC?
> bus for uart.
>
> A question on SBSA: does it propose how to provide serial via BMC for SOL?
Probably another reason to keep 8250 as a legal option ... The (very
popular) Aspeed BMCs tend to do this via a 8250-looking virtual UART on
LPC.
Cheers,
Ben,
^ permalink raw reply
* [PATCH 3/3] mtd: s3c2410: parse the device configuration from OF node
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-1-git-send-email-sergio.prado@e-labworks.com>
Allows configuring Samsung's s3c2410 memory controller using a
devicetree.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
drivers/mtd/nand/s3c2410.c | 171 ++++++++++++++++++++++---
include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
2 files changed, 156 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index 174ac9dc4265..352cf2656bc8 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -39,6 +39,8 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/cpufreq.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
@@ -185,6 +187,26 @@ struct s3c2410_nand_info {
#endif
};
+struct s3c24XX_nand_devtype_data {
+ enum s3c_cpu_type type;
+};
+
+struct s3c24XX_nand_devtype_data s3c2410_nand_devtype_data = {
+ .type = TYPE_S3C2410,
+};
+
+struct s3c24XX_nand_devtype_data s3c2412_nand_devtype_data = {
+ .type = TYPE_S3C2412,
+};
+
+struct s3c24XX_nand_devtype_data s3c2440_nand_devtype_data = {
+ .type = TYPE_S3C2440,
+};
+
+struct s3c24XX_nand_devtype_data s3c6400_nand_devtype_data = {
+ .type = TYPE_S3C2412,
+};
+
/* conversion functions */
static struct s3c2410_nand_mtd *s3c2410_nand_mtd_toours(struct mtd_info *mtd)
@@ -811,6 +833,8 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
struct nand_chip *chip = &nmtd->chip;
void __iomem *regs = info->regs;
+ nand_set_flash_node(chip, set->of_node);
+
chip->write_buf = s3c2410_nand_write_buf;
chip->read_buf = s3c2410_nand_read_buf;
chip->select_chip = s3c2410_nand_select_chip;
@@ -859,12 +883,35 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
chip->ecc.mode = info->platform->ecc_mode;
/* If you use u-boot BBT creation code, specifying this flag will
- * let the kernel fish out the BBT from the NAND, and also skip the
- * full NAND scan that can take 1/2s or so. Little things... */
- if (set->flash_bbt) {
+ * let the kernel fish out the BBT from the NAND */
+ if (set->flash_bbt)
chip->bbt_options |= NAND_BBT_USE_FLASH;
- chip->options |= NAND_SKIP_BBTSCAN;
- }
+}
+
+static int s3c2410_nand_init_timings(struct s3c2410_nand_info *info,
+ struct nand_chip *chip)
+{
+ struct s3c2410_platform_nand *pdata = info->platform;
+ const struct nand_sdr_timings *t;
+ int tacls, mode;
+
+ mode = onfi_get_async_timing_mode(chip);
+ if (mode == ONFI_TIMING_MODE_UNKNOWN)
+ mode = chip->onfi_timing_mode_default;
+
+ t = onfi_async_timing_mode_to_sdr_timings(mode);
+ if (IS_ERR(t))
+ return PTR_ERR(t);
+
+ tacls = t->tCLS_min - t->tWP_min;
+ if (tacls < 0)
+ tacls = 0;
+
+ pdata->tacls = DIV_ROUND_UP(tacls, 1000);
+ pdata->twrph0 = DIV_ROUND_UP(t->tWP_min, 1000);
+ pdata->twrph1 = DIV_ROUND_UP(t->tCLH_min, 1000);
+
+ return 0;
}
/**
@@ -881,7 +928,9 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
struct s3c2410_nand_mtd *nmtd)
{
+ struct device_node *np = info->device->of_node;
struct nand_chip *chip = &nmtd->chip;
+ int ret;
switch (chip->ecc.mode) {
@@ -943,6 +992,90 @@ static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
return -EINVAL;
}
+ if (chip->bbt_options & NAND_BBT_USE_FLASH)
+ chip->options |= NAND_SKIP_BBTSCAN;
+
+ /* read timings from nand_sdr_timings when booting with a device tree */
+ if (np) {
+ ret = s3c2410_nand_init_timings(info, chip);
+ if (ret) {
+ dev_err(info->device,
+ "could not configure chip timings: %d\n", ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static const struct of_device_id s3c24xx_nand_dt_ids[] = {
+ {
+ .compatible = "samsung,s3c2410-nand",
+ .data = &s3c2410_nand_devtype_data,
+ }, {
+ .compatible = "samsung,s3c2412-nand",
+ .data = &s3c2412_nand_devtype_data,
+ }, {
+ .compatible = "samsung,s3c2440-nand",
+ .data = &s3c2440_nand_devtype_data,
+ }, {
+ .compatible = "samsung,s3c6400-nand",
+ .data = &s3c6400_nand_devtype_data,
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, s3c24xx_nand_dt_ids);
+
+static int s3c24xx_nand_probe_dt(struct platform_device *pdev)
+{
+ const struct s3c24XX_nand_devtype_data *devtype_data;
+ struct s3c2410_platform_nand *pdata;
+ struct s3c2410_nand_info *info = platform_get_drvdata(pdev);
+ struct device_node *np = pdev->dev.of_node, *child;
+ struct s3c2410_nand_set *sets;
+
+ devtype_data = of_device_get_match_data(&pdev->dev);
+ if (!devtype_data)
+ return -ENODEV;
+
+ info->cpu_type = devtype_data->type;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdev->dev.platform_data = pdata;
+
+ pdata->nr_sets = of_get_child_count(np);
+ if (!pdata->nr_sets)
+ return 0;
+
+ sets = devm_kzalloc(&pdev->dev, sizeof(*sets) * pdata->nr_sets, GFP_KERNEL);
+ if (!sets)
+ return -ENOMEM;
+
+ pdata->sets = sets;
+
+ for_each_available_child_of_node(np, child) {
+
+ sets->name = (char *)child->name;
+ sets->of_node = child;
+ sets->nr_chips = 1;
+
+ of_node_get(child);
+
+ sets++;
+ }
+
+ return 0;
+}
+
+static int s3c24xx_nand_probe_pdata(struct platform_device *pdev)
+{
+ struct s3c2410_nand_info *info = platform_get_drvdata(pdev);
+
+ info->cpu_type = platform_get_device_id(pdev)->driver_data;
+
return 0;
}
@@ -955,8 +1088,7 @@ static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
*/
static int s3c24xx_nand_probe(struct platform_device *pdev)
{
- struct s3c2410_platform_nand *plat = to_nand_plat(pdev);
- enum s3c_cpu_type cpu_type;
+ struct s3c2410_platform_nand *plat;
struct s3c2410_nand_info *info;
struct s3c2410_nand_mtd *nmtd;
struct s3c2410_nand_set *sets;
@@ -966,8 +1098,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
int nr_sets;
int setno;
- cpu_type = platform_get_device_id(pdev)->driver_data;
-
info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
if (info == NULL) {
err = -ENOMEM;
@@ -990,6 +1120,16 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
s3c2410_nand_clk_set_state(info, CLOCK_ENABLE);
+ if (pdev->dev.of_node)
+ err = s3c24xx_nand_probe_dt(pdev);
+ else
+ err = s3c24xx_nand_probe_pdata(pdev);
+
+ if (err)
+ goto exit_error;
+
+ plat = to_nand_plat(pdev);
+
/* allocate and map the resource */
/* currently we assume we have the one resource */
@@ -998,7 +1138,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
info->device = &pdev->dev;
info->platform = plat;
- info->cpu_type = cpu_type;
info->regs = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(info->regs)) {
@@ -1008,12 +1147,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "mapped registers at %p\n", info->regs);
- /* initialise the hardware */
-
- err = s3c2410_nand_inithw(info);
- if (err != 0)
- goto exit_error;
-
sets = (plat != NULL) ? plat->sets : NULL;
nr_sets = (plat != NULL) ? plat->nr_sets : 1;
@@ -1057,6 +1190,11 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
sets++;
}
+ /* initialise the hardware */
+ err = s3c2410_nand_inithw(info);
+ if (err != 0)
+ goto exit_error;
+
err = s3c2410_nand_cpufreq_register(info);
if (err < 0) {
dev_err(&pdev->dev, "failed to init cpufreq support\n");
@@ -1157,6 +1295,7 @@ static struct platform_driver s3c24xx_nand_driver = {
.id_table = s3c24xx_driver_ids,
.driver = {
.name = "s3c24xx-nand",
+ .of_match_table = s3c24xx_nand_dt_ids,
},
};
diff --git a/include/linux/platform_data/mtd-nand-s3c2410.h b/include/linux/platform_data/mtd-nand-s3c2410.h
index 729af13d1773..f01659026b26 100644
--- a/include/linux/platform_data/mtd-nand-s3c2410.h
+++ b/include/linux/platform_data/mtd-nand-s3c2410.h
@@ -40,6 +40,7 @@ struct s3c2410_nand_set {
char *name;
int *nr_map;
struct mtd_partition *partitions;
+ struct device_node *of_node;
};
struct s3c2410_platform_nand {
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: mtd: add DT binding for s3c2410 flash controller
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-1-git-send-email-sergio.prado@e-labworks.com>
Adds the device tree bindings description for Samsung S3C2410 and
compatible NAND flash controller.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
.../devicetree/bindings/mtd/samsung-s3c2410.txt | 57 ++++++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
new file mode 100644
index 000000000000..1cc8e84479ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
@@ -0,0 +1,57 @@
+* Samsung S3C2410 and compatible NAND flash controller
+
+Required properties:
+- compatible : The possible values are:
+ "samsung,s3c2410-nand"
+ "samsung,s3c2412-nand"
+ "samsung,s3c2440-nand"
+ "samsung,s3c6400-nand"
+- reg : register's location and length.
+- #address-cells, #size-cells : see nand.txt
+- clocks : phandle to the nand controller clock
+- clock-names : must contain "nand"
+
+Optional child nodes:
+Child nodes representing the available nand chips.
+
+Optional child properties:
+- nand-ecc-mode : see nand.txt
+- nand-on-flash-bbt : see nand.txt
+
+Each child device node may optionally contain a 'partitions' sub-node,
+which further contains sub-nodes describing the flash partition mapping.
+See partition.txt for more detail.
+
+Example:
+
+nand-controller at 4e000000 {
+ compatible = "samsung,s3c2440-nand";
+ reg = <0x4e000000 0x40>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clocks = <&clocks HCLK_NAND>;
+ clock-names = "nand";
+
+ nand {
+ nand-ecc-mode = "soft";
+ nand-on-flash-bbt;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0 0x040000>;
+ };
+
+ partition at 40000 {
+ label = "kernel";
+ reg = <0x040000 0x500000>;
+ };
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-1-git-send-email-sergio.prado@e-labworks.com>
Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
field in the drivers's platform data structure so it can be selectable
via platform data.
Also setting this field to NAND_ECC_SOFT in all boards using this
driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
arch/arm/mach-s3c24xx/common-smdk.c | 1 +
arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
arch/arm/mach-s3c24xx/mach-bast.c | 1 +
arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
arch/arm/mach-s3c24xx/mach-jive.c | 1 +
arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
drivers/mtd/nand/Kconfig | 9 --
drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
18 files changed, 79 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/common-smdk.c b/arch/arm/mach-s3c24xx/common-smdk.c
index e9fbcc91c5c0..9e0bc46e90ec 100644
--- a/arch/arm/mach-s3c24xx/common-smdk.c
+++ b/arch/arm/mach-s3c24xx/common-smdk.c
@@ -171,6 +171,7 @@ static struct s3c2410_platform_nand smdk_nand_info = {
.twrph1 = 20,
.nr_sets = ARRAY_SIZE(smdk_nand_sets),
.sets = smdk_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* devices we initialise */
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c b/arch/arm/mach-s3c24xx/mach-anubis.c
index d03df0df01fa..029ef1b58925 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -223,6 +223,7 @@ static struct s3c2410_platform_nand __initdata anubis_nand_info = {
.nr_sets = ARRAY_SIZE(anubis_nand_sets),
.sets = anubis_nand_sets,
.select_chip = anubis_nand_select,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* IDE channels */
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index 9ae170fef2a7..7b28eb623fc1 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -114,6 +114,7 @@ static struct s3c2410_platform_nand __initdata at2440evb_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(at2440evb_nand_sets),
.sets = at2440evb_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* DM9000AEP 10/100 ethernet controller */
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c b/arch/arm/mach-s3c24xx/mach-bast.c
index ed07cf392d4b..5185036765db 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -299,6 +299,7 @@ static struct s3c2410_platform_nand __initdata bast_nand_info = {
.nr_sets = ARRAY_SIZE(bast_nand_sets),
.sets = bast_nand_sets,
.select_chip = bast_nand_select,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* DM9000 */
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 27ae6877550f..b0ed401da3a3 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -443,6 +443,7 @@ static struct s3c2410_platform_nand __initdata gta02_nand_info = {
.twrph1 = 15,
.nr_sets = ARRAY_SIZE(gta02_nand_sets),
.sets = gta02_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 7d99fe8f6157..895aca225952 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -232,6 +232,7 @@ static struct s3c2410_platform_nand __initdata jive_nand_info = {
.twrph1 = 40,
.sets = jive_nand_sets,
.nr_sets = ARRAY_SIZE(jive_nand_sets),
+ .ecc_mode = NAND_ECC_SOFT,
};
static int __init jive_mtdset(char *options)
diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c b/arch/arm/mach-s3c24xx/mach-mini2440.c
index bbf41322d726..97edcc12a9e6 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -287,6 +287,7 @@ static struct s3c2410_platform_nand mini2440_nand_info __initdata = {
.nr_sets = ARRAY_SIZE(mini2440_nand_sets),
.sets = mini2440_nand_sets,
.ignore_unset_ecc = 1,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* DM9000AEP 10/100 ethernet controller */
diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c b/arch/arm/mach-s3c24xx/mach-osiris.c
index 2f6fdc326835..70b0eb7d3134 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris.c
@@ -238,6 +238,7 @@ static struct s3c2410_platform_nand __initdata osiris_nand_info = {
.nr_sets = ARRAY_SIZE(osiris_nand_sets),
.sets = osiris_nand_sets,
.select_chip = osiris_nand_select,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* PCMCIA control and configuration */
diff --git a/arch/arm/mach-s3c24xx/mach-qt2410.c b/arch/arm/mach-s3c24xx/mach-qt2410.c
index 984516e8307a..868c82087403 100644
--- a/arch/arm/mach-s3c24xx/mach-qt2410.c
+++ b/arch/arm/mach-s3c24xx/mach-qt2410.c
@@ -284,6 +284,7 @@ static struct s3c2410_platform_nand __initdata qt2410_nand_info = {
.twrph1 = 20,
.nr_sets = ARRAY_SIZE(qt2410_nand_sets),
.sets = qt2410_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* UDC */
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 25a139bb9826..e86ad6a68a0b 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -611,6 +611,7 @@ static struct s3c2410_platform_nand rx1950_nand_info = {
.twrph1 = 15,
.nr_sets = ARRAY_SIZE(rx1950_nand_sets),
.sets = rx1950_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct s3c2410_udc_mach_info rx1950_udc_cfg __initdata = {
diff --git a/arch/arm/mach-s3c24xx/mach-rx3715.c b/arch/arm/mach-s3c24xx/mach-rx3715.c
index cf55196f89ca..a39fb9780dd3 100644
--- a/arch/arm/mach-s3c24xx/mach-rx3715.c
+++ b/arch/arm/mach-s3c24xx/mach-rx3715.c
@@ -164,6 +164,7 @@ static struct s3c2410_platform_nand __initdata rx3715_nand_info = {
.twrph1 = 15,
.nr_sets = ARRAY_SIZE(rx3715_nand_sets),
.sets = rx3715_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct platform_device *rx3715_devices[] __initdata = {
diff --git a/arch/arm/mach-s3c24xx/mach-vstms.c b/arch/arm/mach-s3c24xx/mach-vstms.c
index b4460d5f7011..f5e6322145fa 100644
--- a/arch/arm/mach-s3c24xx/mach-vstms.c
+++ b/arch/arm/mach-s3c24xx/mach-vstms.c
@@ -117,6 +117,7 @@ static struct s3c2410_platform_nand __initdata vstms_nand_info = {
.twrph1 = 20,
.nr_sets = ARRAY_SIZE(vstms_nand_sets),
.sets = vstms_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct platform_device *vstms_devices[] __initdata = {
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index bc7dc1fcbf7d..59b5531f1987 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -204,6 +204,7 @@ static struct s3c2410_platform_nand hmt_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(hmt_nand_sets),
.sets = hmt_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct gpio_led hmt_leds[] = {
diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
index ae999fb3fe6d..a3e3e25728b4 100644
--- a/arch/arm/mach-s3c64xx/mach-mini6410.c
+++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
@@ -142,6 +142,7 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(mini6410_nand_sets),
.sets = mini6410_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct s3c_fb_pd_win mini6410_lcd_type0_fb_win = {
diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
index 4e240ffa7ac7..d6b3ffd7704b 100644
--- a/arch/arm/mach-s3c64xx/mach-real6410.c
+++ b/arch/arm/mach-s3c64xx/mach-real6410.c
@@ -194,6 +194,7 @@ static struct s3c2410_platform_nand real6410_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(real6410_nand_sets),
.sets = real6410_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct platform_device *real6410_devices[] __initdata = {
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 21ff58099f3b..f2737229f506 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -179,15 +179,6 @@ config MTD_NAND_S3C2410_DEBUG
help
Enable debugging of the S3C NAND driver
-config MTD_NAND_S3C2410_HWECC
- bool "Samsung S3C NAND Hardware ECC"
- depends on MTD_NAND_S3C2410
- help
- Enable the use of the controller's internal ECC generator when
- using NAND. Early versions of the chips have had problems with
- incorrect ECC generation, and if using these, the default of
- software ECC is preferable.
-
config MTD_NAND_NDFC
tristate "NDFC NanD Flash Controller"
depends on 4xx
diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index d9309cf0ce2e..174ac9dc4265 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -497,7 +497,6 @@ static int s3c2412_nand_devready(struct mtd_info *mtd)
/* ECC handling functions */
-#ifdef CONFIG_MTD_NAND_S3C2410_HWECC
static int s3c2410_nand_correct_data(struct mtd_info *mtd, u_char *dat,
u_char *read_ecc, u_char *calc_ecc)
{
@@ -649,7 +648,6 @@ static int s3c2440_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
return 0;
}
-#endif
/* over-ride the standard functions for a little more speed. We can
* use read/write block to move the data buffers to/from the controller
@@ -858,50 +856,7 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
nmtd->info = info;
nmtd->set = set;
-#ifdef CONFIG_MTD_NAND_S3C2410_HWECC
- chip->ecc.calculate = s3c2410_nand_calculate_ecc;
- chip->ecc.correct = s3c2410_nand_correct_data;
- chip->ecc.mode = NAND_ECC_HW;
- chip->ecc.strength = 1;
-
- switch (info->cpu_type) {
- case TYPE_S3C2410:
- chip->ecc.hwctl = s3c2410_nand_enable_hwecc;
- chip->ecc.calculate = s3c2410_nand_calculate_ecc;
- break;
-
- case TYPE_S3C2412:
- chip->ecc.hwctl = s3c2412_nand_enable_hwecc;
- chip->ecc.calculate = s3c2412_nand_calculate_ecc;
- break;
-
- case TYPE_S3C2440:
- chip->ecc.hwctl = s3c2440_nand_enable_hwecc;
- chip->ecc.calculate = s3c2440_nand_calculate_ecc;
- break;
- }
-#else
- chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
-#endif
-
- if (set->disable_ecc)
- chip->ecc.mode = NAND_ECC_NONE;
-
- switch (chip->ecc.mode) {
- case NAND_ECC_NONE:
- dev_info(info->device, "NAND ECC disabled\n");
- break;
- case NAND_ECC_SOFT:
- dev_info(info->device, "NAND soft ECC\n");
- break;
- case NAND_ECC_HW:
- dev_info(info->device, "NAND hardware ECC\n");
- break;
- default:
- dev_info(info->device, "NAND ECC UNKNOWN\n");
- break;
- }
+ chip->ecc.mode = info->platform->ecc_mode;
/* If you use u-boot BBT creation code, specifying this flag will
* let the kernel fish out the BBT from the NAND, and also skip the
@@ -923,28 +878,72 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
*
* The internal state is currently limited to the ECC state information.
*/
-static void s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
+static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
struct s3c2410_nand_mtd *nmtd)
{
struct nand_chip *chip = &nmtd->chip;
- dev_dbg(info->device, "chip %p => page shift %d\n",
- chip, chip->page_shift);
+ switch (chip->ecc.mode) {
- if (chip->ecc.mode != NAND_ECC_HW)
- return;
+ case NAND_ECC_NONE:
+ dev_info(info->device, "ECC disabled\n");
+ break;
+
+ case NAND_ECC_SOFT:
+ /*
+ * This driver expects Hamming based ECC when ecc_mode is set
+ * to NAND_ECC_SOFT. Force ecc.algo to NAND_ECC_HAMMING to
+ * avoid adding an extra ecc_algo field to s3c2410_platform_nand.
+ */
+ chip->ecc.algo = NAND_ECC_HAMMING;
+ dev_info(info->device, "soft ECC\n");
+ break;
+
+ case NAND_ECC_HW:
+ chip->ecc.calculate = s3c2410_nand_calculate_ecc;
+ chip->ecc.correct = s3c2410_nand_correct_data;
+ chip->ecc.strength = 1;
+
+ switch (info->cpu_type) {
+ case TYPE_S3C2410:
+ chip->ecc.hwctl = s3c2410_nand_enable_hwecc;
+ chip->ecc.calculate = s3c2410_nand_calculate_ecc;
+ break;
+
+ case TYPE_S3C2412:
+ chip->ecc.hwctl = s3c2412_nand_enable_hwecc;
+ chip->ecc.calculate = s3c2412_nand_calculate_ecc;
+ break;
+
+ case TYPE_S3C2440:
+ chip->ecc.hwctl = s3c2440_nand_enable_hwecc;
+ chip->ecc.calculate = s3c2440_nand_calculate_ecc;
+ break;
+ }
+
+ dev_dbg(info->device, "chip %p => page shift %d\n",
+ chip, chip->page_shift);
/* change the behaviour depending on whether we are using
* the large or small page nand device */
+ if (chip->page_shift > 10) {
+ chip->ecc.size = 256;
+ chip->ecc.bytes = 3;
+ } else {
+ chip->ecc.size = 512;
+ chip->ecc.bytes = 3;
+ mtd_set_ooblayout(nand_to_mtd(chip), &s3c2410_ooblayout_ops);
+ }
- if (chip->page_shift > 10) {
- chip->ecc.size = 256;
- chip->ecc.bytes = 3;
- } else {
- chip->ecc.size = 512;
- chip->ecc.bytes = 3;
- mtd_set_ooblayout(nand_to_mtd(chip), &s3c2410_ooblayout_ops);
+ dev_info(info->device, "hardware ECC\n");
+ break;
+
+ default:
+ dev_err(info->device, "invalid ECC mode!\n");
+ return -EINVAL;
}
+
+ return 0;
}
/* s3c24xx_nand_probe
@@ -1047,7 +1046,9 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
NULL);
if (nmtd->scan_res == 0) {
- s3c2410_nand_update_chip(info, nmtd);
+ err = s3c2410_nand_update_chip(info, nmtd);
+ if (err < 0)
+ goto exit_error;
nand_scan_tail(mtd);
s3c2410_nand_add_partition(info, nmtd, sets);
}
diff --git a/include/linux/platform_data/mtd-nand-s3c2410.h b/include/linux/platform_data/mtd-nand-s3c2410.h
index c55e42ee57fa..729af13d1773 100644
--- a/include/linux/platform_data/mtd-nand-s3c2410.h
+++ b/include/linux/platform_data/mtd-nand-s3c2410.h
@@ -12,9 +12,10 @@
#ifndef __MTD_NAND_S3C2410_H
#define __MTD_NAND_S3C2410_H
+#include <linux/mtd/nand.h>
+
/**
* struct s3c2410_nand_set - define a set of one or more nand chips
- * @disable_ecc: Entirely disable ECC - Dangerous
* @flash_bbt: Openmoko u-boot can create a Bad Block Table
* Setting this flag will allow the kernel to
* look for it at boot time and also skip the NAND
@@ -31,7 +32,6 @@
* a warning at boot time.
*/
struct s3c2410_nand_set {
- unsigned int disable_ecc:1;
unsigned int flash_bbt:1;
unsigned int options;
@@ -51,6 +51,8 @@ struct s3c2410_platform_nand {
unsigned int ignore_unset_ecc:1;
+ nand_ecc_modes_t ecc_mode;
+
int nr_sets;
struct s3c2410_nand_set *sets;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] mtd: s3c2410: add device tree support
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for configuring Samsung's s3c2410 and
compatible flash memory controller via devicetree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Patch 3 depends on patch 1.
Changes since v1:
- read timings from nand_sdr_timings when booting with a device tree
- naming improvements in the device tree binding
(s/nand/nand-controller/, s/_/-, s/children/child)
- dropped property samsung,ignore_unset_ecc
- remove @0 from nand device node
- checking pdev->dev.of_node instead of using ifdef CONFIG_OF_MTD
- preventing from parsing device tree properties twice
- increment the nand controller child node refcount, since we
maintain a reference to it and its name field
- using of_device_get_match_data() instead of of_match_device()
to make the code simpler
- remove CONFIG_MTD_NAND_S3C2410_HWECC compile option so we can
select ECC mode using nand-ecc-mode property in the device tree
Sergio Prado (3):
mtd: s3c2410: make ecc mode configurable via platform data
dt-bindings: mtd: add DT binding for s3c2410 flash controller
mtd: s3c2410: parse the device configuration from OF node
.../devicetree/bindings/mtd/samsung-s3c2410.txt | 57 +++++
arch/arm/mach-s3c24xx/common-smdk.c | 1 +
arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
arch/arm/mach-s3c24xx/mach-bast.c | 1 +
arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
arch/arm/mach-s3c24xx/mach-jive.c | 1 +
arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
drivers/mtd/nand/Kconfig | 9 -
drivers/mtd/nand/s3c2410.c | 284 +++++++++++++++------
include/linux/platform_data/mtd-nand-s3c2410.h | 7 +-
19 files changed, 289 insertions(+), 83 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
--
1.9.1
^ permalink raw reply
* [PATCH] ARM: fix delays
From: Russell King @ 2016-10-05 22:56 UTC (permalink / raw)
To: linux-arm-kernel
Commit 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value
limitation") tried to increase the bogomips limitation, but in doing
so messed up udelay such that it always gives about a 5% error in the
delay, even if we use a timer.
The calculation is:
loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT
Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT
30. Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000
(eg, 166MHz timer, 1ms delay) this would calculate:
((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30
=> 165999
With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get:
(2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
=> 158269
which is incorrect. This is due to a typo - correcting it gives:
(2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
=> 165999
i.o.w, the original value.
Fixes: 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value limitation")
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/delay.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/delay.h b/arch/arm/include/asm/delay.h
index b7a428154355..b1ce037e4380 100644
--- a/arch/arm/include/asm/delay.h
+++ b/arch/arm/include/asm/delay.h
@@ -10,7 +10,7 @@
#include <asm/param.h> /* HZ */
#define MAX_UDELAY_MS 2
-#define UDELAY_MULT UL(2047 * HZ + 483648 * HZ / 1000000)
+#define UDELAY_MULT UL(2147 * HZ + 483648 * HZ / 1000000)
#define UDELAY_SHIFT 31
#ifndef __ASSEMBLY__
--
2.1.0
^ permalink raw reply related
* linux-next: manual merge of the gpio tree with the arm-soc tree
From: Stephen Rothwell @ 2016-10-05 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160927150542.7e81e7ee@canb.auug.org.au>
Hi all,
On Tue, 27 Sep 2016 15:05:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the gpio tree got a conflict in:
>
> arch/arm/mach-omap2/board-rx51-peripherals.c
>
> between commit:
>
> 9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900")
>
> from the arm-soc tree and commit:
>
> 9132ce450bd1 ("ARM: omap2: fix missing include")
>
> from the gpio tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Since Linus (Torvalds) has merged the gpio tree, this conflict (and
file removal) now affects the merge of the arm-soc tree).
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH v3 11/11] ARM: dts: sk-rzg1m: add Ether support
From: Sergei Shtylyov @ 2016-10-05 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2056698.ncAHq8vRQ3@wasted.cogentembedded.com>
Define the SK-RZG1M board dependent part of the Ether device node.
Enable DHCP and NFS root for the kernel booting.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- new patch.
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -20,7 +20,7 @@
};
chosen {
- bootargs = "ignore_loglevel";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial0:115200n8";
};
@@ -42,3 +42,16 @@
&scif0 {
status = "okay";
};
+
+ðer {
+ phy-handle = <&phy1>;
+ renesas,ether-link-active-low;
+ status = "okay";
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ interrupt-parent = <&irqc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ };
+};
^ permalink raw reply
* [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW
From: Mark Rutland @ 2016-10-05 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005210137.GS1041@n2100.armlinux.org.uk>
On Wed, Oct 05, 2016 at 10:01:38PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 05, 2016 at 09:44:53PM +0100, Mark Rutland wrote:
> > The zeroing case is similar to the restartable sequences design. So that's
> > probably worth looking into.
>
> You're sending mixed messages: in your previous message, you said:
>
> Arguably, someone could have (ab)used TPIDRURW between commits 6a1c531
> and a4780ad to detect context switches, but in practice they don't
> appear to have, and we know of an established user relying on the
> current behaviour.
>
> For better or worse, the current behaviour is ABI.
>
> Now you're suggesting that we could go back to the case where the
> register is zeroed.
Sorry; clumsy wording on my behalf.
I meant that functionality-wise, restartable sequences had similar behaviour to
the zeroing case (without touching TPIDRURW at all) and were probably worth
looking at. I did not intend to suggest that we should go pack to case where
TPIDRURW was zeroed.
> Well, the fact is that we _can_ change the TPIDRURW behaviour - we just
> need to be careful about how we change it. Eg, we _could_ introduce a
> per-process flag which indicates that we want some other behaviour from
> TPIDRURW such as zeroing it on context switches. The default would be
> to preserve the existing behaviour as doing anything else breaks
> existing programs. The problem there is finding an acceptable way to
> control such a flag from userspace (eg, prctl, syscall, etc).
Sure. Something like that could work.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 10/11] ARM: dts: sk-rzg1m: initial device tree
From: Sergei Shtylyov @ 2016-10-05 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2056698.ncAHq8vRQ3@wasted.cogentembedded.com>
Add the initial device tree for the R8A7743 SoC based SK-RZG1M board.
The board has one debug serial port (SCIF0); include support for it, so
that the serial console can work.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 3:
- added Geert's tag.
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 44 +++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -654,6 +654,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r7s72100-rskrza1.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
+ r8a7743-sk-rzg1m.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the SK-RZG1M board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7743.dtsi"
+
+/ {
+ model = "SK-RZG1M";
+ compatible = "renesas,sk-rzg1m", "renesas,r8a7743";
+
+ aliases {
+ serial0 = &scif0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+
+ memory at 200000000 {
+ device_type = "memory";
+ reg = <2 0x00000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif0 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH v3 08/11] ARM: dts: r8a7743: add IRQC support
From: Sergei Shtylyov @ 2016-10-05 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2056698.ncAHq8vRQ3@wasted.cogentembedded.com>
Describe the IRQC interrupt controller in the R8A7743 device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- updated the "clocks" property for the CPG/MSSR driver.
Changes in version 2:
- new patch.
arch/arm/boot/dts/r8a7743.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -72,6 +72,25 @@
IRQ_TYPE_LEVEL_HIGH)>;
};
+ irqc: interrupt-controller at e61c0000 {
+ compatible = "renesas,irqc-r8a7743", "renesas,irqc";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <0 0xe61c0000 0 0x200>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 407>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
^ permalink raw reply
* [PATCH v3 07/11] ARM: dts: r8a7743: add Ether support
From: Sergei Shtylyov @ 2016-10-05 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2056698.ncAHq8vRQ3@wasted.cogentembedded.com>
Define the generic R8A7743 part of the Ether device node.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- resoled a reject;
- updated the "clocks" property for the CPG/MSSR driver.
Changes in version 2:
- new patch.
arch/arm/boot/dts/r8a7743.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -423,6 +423,18 @@
power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
status = "disabled";
};
+
+ ether: ethernet at ee700000 {
+ compatible = "renesas,ether-r8a7743";
+ reg = <0 0xee700000 0 0x400>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ phy-mode = "rmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
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