Re: [PATCH] ARM: dts: nuvoton: Fix flash layout
Hi Anton, At runtime do you get into the code inside npcmx50_sdhci.c, but it doesn't work well or not access at all? Can you check those registers (BootBlock should set them for you): sd1irv1 at address 0xf0800054 value = 0xf5c80f80 sd1irv2 at address 0xf0800058 value = 0x52001132 sd2irv1 at address 0xf08000b4 value = 0xfdc80f80 sd2irv2 at address 0xf08000b8 value = 0x52003132 Also try to use attached file. Thanks, Avi On Mon, Feb 22, 2021 at 4:25 PM Anton Kachalov wrote: > > Ofer, > > The oldest version from igps doesn't work as well as the latest > version from u-boot github. > > The only version that works for me is in software deliverables: > > https://github.com/Nuvoton-Israel/nuvoton-info/tree/master/npcm7xx-poleg/evaluation-board/sw_deliverables/npcm7xx_v2.3 > > On Mon, 22 Feb 2021 at 15:10, IS20 Ofer Eilon wrote: > > > > Hi Avi, > > > > It seems an old version of uboot u-boot_2019.01.7.5.bin from igps below: > > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNuvoton-Israel%2Figps%2Ftree%2Fmaster%2FImageGeneration%2Fversions&data=04%7C01%7Cofer.eilon%40nuvoton.com%7Ce56881b8491d42e5ee4c08d8d71bacd4%7Ca3f24931d4034b4a94f17d83ac638e07%7C0%7C0%7C637495861162860437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0%2BNzEv%2FSX9QTg0XumchRrU61uGbZ3CZXrtspXu2560I%3D&reserved=0 > > > > Please use latest from uboot.bin github. > > > > Regards, > > Ofer > > > > > > -Original Message- > > From: Avi Fishman > > Sent: Monday, February 22, 2021 12:21 PM > > To: Anton Kachalov > > Cc: Tomer Maimon ; Benjamin Fair > > ; Tali Perry ; Patrick > > Venture ; Nancy Yuen ; Rob Herring > > ; OpenBMC Maillist ; > > devicetree ; Linux Kernel Mailing List > > ; IS20 Ofer Eilon > > Subject: Re: [PATCH] ARM: dts: nuvoton: Fix flash layout > > > > Ofer, > > > > Can you check why u-boot doesn't work with SD cards? > > > > On Mon, Feb 22, 2021 at 11:27 AM Anton Kachalov wrote: > > > > > > Hi, Tom. > > > > > > Yes, I'm using it for testing on real hardware. > > > > > > BTW. Recent u-boot doesn't work with SD cards. The card doesn't > > > detect. The last working version was this one: > > > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2FNuvoton-Israel%2Fnuvoton-info%2Ftree%2Fmaster%2Fnpcm7xx-poleg > > > %2Fevaluation-board%2Fsw_deliverables%2Fnpcm7xx_v2.3&data=04%7C01% > > > 7Cofer.eilon%40nuvoton.com%7Ce56881b8491d42e5ee4c08d8d71bacd4%7Ca3f249 > > > 31d4034b4a94f17d83ac638e07%7C0%7C0%7C637495861162860437%7CUnknown%7CTW > > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > > > Mn0%3D%7C1000&sdata=f4t41g3CQaFTQNfwwNVBrIwQScndIGcfRTms0yrTn5o%3D > > > &reserved=0 > > > > > > However, u-boot from igps repo: > > > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2FNuvoton-Israel%2Figps%2Ftree%2Fmaster%2FImageGeneration%2Fver > > > sions&data=04%7C01%7Cofer.eilon%40nuvoton.com%7Ce56881b8491d42e5ee > > > 4c08d8d71bacd4%7Ca3f24931d4034b4a94f17d83ac638e07%7C0%7C0%7C6374958611 > > > 62860437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0%2BNzEv%2FSX9QTg0Xumch > > > RrU61uGbZ3CZXrtspXu2560I%3D&reserved=0 > > > > > > Has issues too. It doesn't allow me to read more than 4k bytes once at > > > a time. Thus, to flash the stuff I have manually read chunks from the > > > SD-card: fat load doesn't work at all and I write that data in raw > > > partition. > > > > > > On Sun, 21 Feb 2021 at 17:40, Tomer Maimon wrote: > > > > > > > > Hi Benjamin and Anton, > > > > > > > > Sorry for the late reply, > > > > > > > > The EVB FIU0-CS0 partitioning is used for testing the EVB and this is > > > > why it is different than the OpenBMC flash layout. > > > > > > > > > > > > > > > > Are you using the NPCM7XX EVB for OpenBMC? if yes we can consider to > > > > modify the flash partition to OpenBMC use. > > > > > > > > > > > > On Thu, 18 Feb 2021 at 19:11, Benjamin Fair > > > > wrote: > > > >> > > > >> On Thu, 18 Feb 2021 at 04:42, wrote: > > > &
Re: [PATCH] ARM: dts: nuvoton: Fix flash layout
Ofer,
Can you check why u-boot doesn't work with SD cards?
On Mon, Feb 22, 2021 at 11:27 AM Anton Kachalov wrote:
>
> Hi, Tom.
>
> Yes, I'm using it for testing on real hardware.
>
> BTW. Recent u-boot doesn't work with SD cards. The card doesn't
> detect. The last working version was this one:
>
> https://github.com/Nuvoton-Israel/nuvoton-info/tree/master/npcm7xx-poleg/evaluation-board/sw_deliverables/npcm7xx_v2.3
>
> However, u-boot from igps repo:
>
> https://github.com/Nuvoton-Israel/igps/tree/master/ImageGeneration/versions
>
> Has issues too. It doesn't allow me to read more than 4k bytes once at
> a time. Thus, to flash the stuff I have manually read chunks from the
> SD-card: fat load doesn't work at all and I write that data in raw
> partition.
>
> On Sun, 21 Feb 2021 at 17:40, Tomer Maimon wrote:
> >
> > Hi Benjamin and Anton,
> >
> > Sorry for the late reply,
> >
> > The EVB FIU0-CS0 partitioning is used for testing the EVB and this is why
> > it is different than the OpenBMC flash layout.
> >
> >
> >
> > Are you using the NPCM7XX EVB for OpenBMC? if yes we can consider to modify
> > the flash partition to OpenBMC use.
> >
> >
> > On Thu, 18 Feb 2021 at 19:11, Benjamin Fair wrote:
> >>
> >> On Thu, 18 Feb 2021 at 04:42, wrote:
> >> >
> >> > From: "Anton D. Kachalov"
> >> >
> >> > This change satisfy OpenBMC requirements for flash layout.
> >> >
> >> > Signed-off-by: Anton D. Kachalov
> >> > ---
> >> > arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 28 +++
> >> > 1 file changed, 8 insertions(+), 20 deletions(-)
> >> >
> >> > diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
> >> > b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
> >> > index bd1eb6ee380f..741c1fee8552 100644
> >> > --- a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
> >> > +++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
> >> > @@ -182,8 +182,8 @@ bbuboot2@8 {
> >> > reg = <0x008 0x8>;
> >> > read-only;
> >> > };
> >> > - envparam@10 {
> >> > - label = "env-param";
> >> > + ubootenv@10 {
> >> > + label = "u-boot-env";
> >> > reg = <0x010 0x4>;
> >> > read-only;
> >> > };
> >> > @@ -195,25 +195,13 @@ kernel@20 {
> >> > label = "kernel";
> >> > reg = <0x020 0x40>;
> >> > };
> >> > - rootfs@60 {
> >> > - label = "rootfs";
> >> > - reg = <0x060 0x70>;
> >> > + rofs@78 {
> >> > + label = "rofs";
> >> > + reg = <0x078 0x168>;
> >> > };
> >> > - spare1@D0 {
> >> > - label = "spare1";
> >> > - reg = <0x0D0 0x20>;
> >> > - };
> >> > - spare2@0F0 {
> >> > - label = "spare2";
> >> > - reg = <0x0F0 0x20>;
> >> > - };
> >> > - spare3@110 {
> >> > - label = "spare3";
> >> > - reg = <0x110 0x20>;
> >> > - };
> >> > - spare4@130 {
> >> > - label = "spare4";
> >> > - reg = <0x130 0x0>;
> >> > + rwfs@1e0 {
> >> > + label = "rwfs";
> >> > + reg = <0x1e0 0x20>;
> >> > };
> >>
> >> I recommend just including the openbmc-flash-layout.dtsi file here
> >> instead since that contains the common flash layout for most OpenBMC
> >> systems.
> >>
> > Good solution,
> > Do you mean nuvoton-openbmc-flash-layout?
> >>
> >> > };
> >> > };
> >> > --
> >> > 2.30.0.478.g8a0d178c01-goog
> >> >
> >
> >
> > Thanks,
> >
> > Tomer
--
Regards,
Avi
Re: [PATCH v2] dt-bindings: timer: nuvoton: Clarify that interrupt of timer 0 should be specified
On Fri, Jan 8, 2021 at 6:30 PM Jonathan Neuschäfer wrote: > > The NPCM750 Timer/Watchdog Controller has multiple interrupt lines, > connected to multiple timers. The driver uses timer 0 for timer > interrupts, so the interrupt line corresponding to timer 0 should be > specified in DT. > > I removed the mention of "flags for falling edge", because the timer > controller uses high-level interrupts rather than falling-edge > interrupts, and whether flags should be specified is up the interrupt > controller's DT binding. > > Signed-off-by: Jonathan Neuschäfer Reviewed-by Avi Fishman > --- > > v2: > - Fix a typo in the word "watchdog" > --- > .../devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt| 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > index ea22dfe485bee..97258f1a1505b 100644 > --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > @@ -6,8 +6,7 @@ timer counters. > Required properties: > - compatible : "nuvoton,npcm750-timer" for Poleg NPCM750. > - reg : Offset and length of the register set for the device. > -- interrupts : Contain the timer interrupt with flags for > -falling edge. > +- interrupts : Contain the timer interrupt of timer 0. > - clocks : phandle of timer reference clock (usually a 25 MHz > clock). > > Example: > -- > 2.29.2 > -- Regards, Avi
Re: [PATCH v1] i2c: npcm7xx: Support changing bus speed using debugfs.
Tali indeed pointed our major customers (Alex represent one of them :) that this feature must be handled carefully since it may break the communication and they are aware of that. Nevertheless they still want this feature, they already reviewed this and accepted it (in internal mails) So we will appreciate if this will be accepted. On Thu, Oct 1, 2020 at 9:27 PM Alex Qiu wrote: > > On Thu, Oct 1, 2020 at 10:41 AM Andy Shevchenko > wrote: > > > > On Thu, Oct 01, 2020 at 08:13:49PM +0300, Avi Fishman wrote: > > > Hi Andy, > > > > > > Customers using BMC with complex i2c topology asked us to support > > > changing bus frequency at run time, for example same device will > > > communicate with one slave at 100Kbp/s and another with 400kbp/s and > > > maybe also with smae device at different speed (for example an i2c > > > mux). > > > This is not only for debug. > > > > The above design is fragile to start with. If you have connected peripheral > > devices with different speed limitations and you try to access faster one > > the > > slower ones may block and break the bus which will need recovery. > > > > Hi Andy, > > To clarify, we are using a single read-only image to support multiple > configurations, so the supported bus rate of the devices are not known > at compile time, but at runtime. We start with 100 kHz, and go 400 kHz > if applicable. FYI, we are using 5.1 kernel, however I don't know much > about DT overlay. > > Thx. > > -Alex Qiu -- Regards, Avi
Re: [PATCH v1] i2c: npcm7xx: Support changing bus speed using debugfs.
Hi Andy, Customers using BMC with complex i2c topology asked us to support changing bus frequency at run time, for example same device will communicate with one slave at 100Kbp/s and another with 400kbp/s and maybe also with smae device at different speed (for example an i2c mux). This is not only for debug. Can DT overlay support that? On Thu, Oct 1, 2020 at 6:40 PM Andy Shevchenko wrote: > > On Thu, Oct 1, 2020 at 8:34 AM Tali Perry wrote: > > On Wed, Sep 30, 2020 at 12:31 PM Andy Shevchenko > > wrote: > > > > > > On Wed, Sep 30, 2020 at 10:13:42AM +0300, Tali Perry wrote: > > > > Systems that can dinamically add and remove slave devices > > > > > > dynamically > > > > > > > often need to change the bus speed in runtime. > > > > > > > This patch exposes the bus frequency to the user. > > > > > > Expose the bus frequency to the user. > > > > > > > This feature can also be used for test automation. > > > > > > In general I think that DT overlays or so should be user rather than this. > > > If we allow to change bus speed settings for debugging purposes it might > > > make > > > sense to do this on framework level for all drivers which support that > > > (via > > > additional callback or so). > > > > Do you mean adding something like this: > > Nope. I meant to use DT description for that. I²C core should cope > with DT already. > I do not understand why you need special nodes for that rather than DT > overlay which will change the speed for you. > > -- > With Best Regards, > Andy Shevchenko -- Regards, Avi
Re: [PATCH v2] i2c: npcm7xx: bug fix timeout (usec instead of msec)
Please ignore my last mail, Tali already sent v3.
On Mon, Aug 31, 2020 at 10:57 AM Avi Fishman wrote:
>
> On Sun, Aug 30, 2020 at 9:01 PM Andy Shevchenko
> wrote:
> >
> > On Sun, Aug 30, 2020 at 3:23 PM Tali Perry wrote:
> >
> > >
> > > i2c: npcm7xx: bug fix timeout (usec instead of msec)
> >
> > This commit message is awful. Please read [1] as a tutorial how to
> > write a commit messages.
> >
>
> Would this be better:
> i2c: npcm7xx: Fix microsecond timeout calculation
>
> Inside npcm_i2c_master_xfer() we calculate a timeout for the entire
> transaction in microseconds, the calculation was wrong so big i2c
> massages would timeout before they ended.
> This commit fix that.
>
> > [1]: https://chris.beams.io/posts/git-commit/
> >
> > ...
> >
> > > - /* Adaptive TimeOut: astimated time in usec + 100% margin */
> > > - timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
> > > + /*
> > > +* Adaptive TimeOut: estimated time in usec + 100% margin:
> > > +* 2: double the timeout for clock stretching case
> > > +* 9: bits per transaction (including the ack/nack)
> >
> > > +* 100: micro second in a second
> >
> > No need. See below.
> >
> > > +*/
> >
> > > + timeout_usec = (2 * 9 * 100 / bus->bus_freq) * (2 + nread +
> > > nwrite);
> >
> > USEC_PER_SEC
>
> OK
>
> >
> > > timeout = max(msecs_to_jiffies(35),
> > > usecs_to_jiffies(timeout_usec));
> > > if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
> > > dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
>
>
> --
> Regards,
> Avi
--
Regards,
Avi
Re: [PATCH v2] i2c: npcm7xx: bug fix timeout (usec instead of msec)
On Sun, Aug 30, 2020 at 9:01 PM Andy Shevchenko
wrote:
>
> On Sun, Aug 30, 2020 at 3:23 PM Tali Perry wrote:
>
> >
> > i2c: npcm7xx: bug fix timeout (usec instead of msec)
>
> This commit message is awful. Please read [1] as a tutorial how to
> write a commit messages.
>
Would this be better:
i2c: npcm7xx: Fix microsecond timeout calculation
Inside npcm_i2c_master_xfer() we calculate a timeout for the entire
transaction in microseconds, the calculation was wrong so big i2c
massages would timeout before they ended.
This commit fix that.
> [1]: https://chris.beams.io/posts/git-commit/
>
> ...
>
> > - /* Adaptive TimeOut: astimated time in usec + 100% margin */
> > - timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
> > + /*
> > +* Adaptive TimeOut: estimated time in usec + 100% margin:
> > +* 2: double the timeout for clock stretching case
> > +* 9: bits per transaction (including the ack/nack)
>
> > +* 100: micro second in a second
>
> No need. See below.
>
> > +*/
>
> > + timeout_usec = (2 * 9 * 100 / bus->bus_freq) * (2 + nread +
> > nwrite);
>
> USEC_PER_SEC
OK
>
> > timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
> > if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
> > dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
>
> --
> With Best Regards,
> Andy Shevchenko
--
Regards,
Avi
Re: [PATCH v2] i2c: npcm7xx: bug fix timeout (usec instead of msec)
On Sun, Aug 30, 2020 at 3:21 PM Tali Perry wrote:
>
> i2c: npcm7xx: bug fix timeout (usec instead of msec)
>
> Signed-off-by: Tali Perry
Reviewed-by: Avi Fishman
> ---
> drivers/i2c/busses/i2c-npcm7xx.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-npcm7xx.c
> b/drivers/i2c/busses/i2c-npcm7xx.c
> index 75f07138a6fa..abb334492a3d 100644
> --- a/drivers/i2c/busses/i2c-npcm7xx.c
> +++ b/drivers/i2c/busses/i2c-npcm7xx.c
> @@ -2093,8 +2093,13 @@ static int npcm_i2c_master_xfer(struct i2c_adapter
> *adap, struct i2c_msg *msgs,
> }
> }
>
> - /* Adaptive TimeOut: astimated time in usec + 100% margin */
> - timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
> + /*
> +* Adaptive TimeOut: estimated time in usec + 100% margin:
> +* 2: double the timeout for clock stretching case
> +* 9: bits per transaction (including the ack/nack)
> +* 100: micro second in a second
> +*/
> + timeout_usec = (2 * 9 * 100 / bus->bus_freq) * (2 + nread +
> nwrite);
> timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
> if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
> dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
>
> base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
> --
> 2.22.0
>
--
Regards,
Avi
Re: [PATCH v1] i2c: npcm7xx: bug fix timeout (usec instead of msec)
Hi Tali,
On Sun, Aug 30, 2020 at 11:09 AM Tali Perry wrote:
>
> i2c: npcm7xx: bug fix timeout (usec instead of msec)
>
> Signed-off-by: Tali Perry
> ---
> drivers/i2c/busses/i2c-npcm7xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-npcm7xx.c
> b/drivers/i2c/busses/i2c-npcm7xx.c
> index 75f07138a6fa..c118f93a2610 100644
> --- a/drivers/i2c/busses/i2c-npcm7xx.c
> +++ b/drivers/i2c/busses/i2c-npcm7xx.c
> @@ -2094,7 +2094,7 @@ static int npcm_i2c_master_xfer(struct i2c_adapter
> *adap, struct i2c_msg *msgs,
> }
>
> /* Adaptive TimeOut: astimated time in usec + 100% margin */
> - timeout_usec = (2 * 1 / bus->bus_freq) * (2 + nread + nwrite);
I suggest to add a short description like:
2: double the timeout for clock stretching case
9: bits per transaction (including the avk/nack)
100: micro second in a second
timeout_usec = (2 * 9 * 100 / bus->bus_freq) * (2 + nread + nwrite);
> + timeout_usec = (2 * 1000 / bus->bus_freq) * (2 + nread + nwrite);
> timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
> if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
> dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
>
> base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
> --
> 2.22.0
>
--
Regards,
Avi
Re: [PATCH v11 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
Thanks Andy, Question below: On Wed, May 20, 2020 at 1:24 PM Andy Shevchenko wrote: > > On Wed, May 20, 2020 at 12:51:12PM +0300, Tali Perry wrote: > > Add Nuvoton NPCM BMC I2C controller driver. > > ... > > > +#ifdef CONFIG_DEBUG_FS > > Why?! It is made to save code size if CONFIG_DEBUG_FS is not defined? We see a lot of kernel code that is doing it. So could you elaborate what is the problem? > > > +#include > > +#endif >
[tip: timers/core] clocksource/drivers/npcm: Fix GENMASK and timer operation
The following commit has been merged into the timers/core branch of tip:
Commit-ID: a2b58537b4a1cc08fd254fb8d1c24191ce286ae1
Gitweb:
https://git.kernel.org/tip/a2b58537b4a1cc08fd254fb8d1c24191ce286ae1
Author:Avi Fishman
AuthorDate:Mon, 29 Jul 2019 20:03:54 +03:00
Committer: Daniel Lezcano
CommitterDate: Tue, 27 Aug 2019 00:31:39 +02:00
clocksource/drivers/npcm: Fix GENMASK and timer operation
NPCM7XX_Tx_OPER GENMASK bits are wrong, fix them.
Hopefully the NPCM7XX_REG_TICR0 register reset value of those bits was 0,
so it did not cause an issue.
The function npcm7xx_timer_oneshot() reads the register
NPCM7XX_REG_TCSR0, modifies it and then reads it again overwriting the
previous changes. Remove the extra read which is pointless.
The function npcm7xx_timer_periodic() is correct but the code writes
to the NPCM7XX_REG_TICR0 register while it is dealing with the
NPCM7XX_REG_TCSR0 register, that is confusing. Separate the write to
the registers in the code for the sake of clarity.
Fixes: 1c00289ecd12 ("clocksource/drivers/npcm: Add NPCM7xx timer driver")
Signed-off-by: Avi Fishman
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/timer-npcm7xx.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/timer-npcm7xx.c
b/drivers/clocksource/timer-npcm7xx.c
index 8a30da7..9780ffd 100644
--- a/drivers/clocksource/timer-npcm7xx.c
+++ b/drivers/clocksource/timer-npcm7xx.c
@@ -32,7 +32,7 @@
#define NPCM7XX_Tx_INTEN BIT(29)
#define NPCM7XX_Tx_COUNTEN BIT(30)
#define NPCM7XX_Tx_ONESHOT 0x0
-#define NPCM7XX_Tx_OPERGENMASK(27, 3)
+#define NPCM7XX_Tx_OPERGENMASK(28, 27)
#define NPCM7XX_Tx_MIN_PRESCALE0x1
#define NPCM7XX_Tx_TDR_MASK_BITS 24
#define NPCM7XX_Tx_MAX_CNT 0xFF
@@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct clock_event_device
*evt)
val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0);
val &= ~NPCM7XX_Tx_OPER;
-
- val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0);
val |= NPCM7XX_START_ONESHOT_Tx;
writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0);
@@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct clock_event_device
*evt)
struct timer_of *to = to_timer_of(evt);
u32 val;
+ writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0);
+
val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0);
val &= ~NPCM7XX_Tx_OPER;
-
- writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0);
val |= NPCM7XX_START_PERIODIC_Tx;
-
writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0);
return 0;
Re: [PATCH] [v5] clocksource/drivers/npcm: fix GENMASK and timer operation
Thanks Daniel, It seems more clear now :) Good to know about the need for Fixes tag. On Wed, Aug 21, 2019 at 1:11 PM Daniel Lezcano wrote: > > On 29/07/2019 19:03, Avi Fishman wrote: > > NPCM7XX_Tx_OPER GENMASK bits where wrong, > > Since NPCM7XX_REG_TICR0 register reset value of those bits was 0, > > it did not cause an issue. > > in npcm7xx_timer_oneshot() the original NPCM7XX_REG_TCSR0 register was > > read again after masking it with ~NPCM7XX_Tx_OPER so the masking didn't > > take effect. > > > > npcm7xx_timer_periodic() was not wrong but it wrote to NPCM7XX_REG_TICR0 > > in a middle of read modify write to NPCM7XX_REG_TCSR0 which is > > confusing. > > npcm7xx_timer_oneshot() did wrong calculation > > > > Signed-off-by: Avi Fishman > > I've applied the patch and massaged the changelog [1]. > > Let me know if you disagree with it. > > Please, in the future take care of adding the Fixes tag. > > Thanks > > -- Daniel > > [1] > https://git.linaro.org/people/daniel.lezcano/linux.git/commit/?h=clockevents/next&id=a5f6679fc81e42fcbef0184770d8a3b04c0f153e > > > --- > > drivers/clocksource/timer-npcm7xx.c | 9 +++-- > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/clocksource/timer-npcm7xx.c > > b/drivers/clocksource/timer-npcm7xx.c > > index 8a30da7f083b..9780ffd8010e 100644 > > --- a/drivers/clocksource/timer-npcm7xx.c > > +++ b/drivers/clocksource/timer-npcm7xx.c > > @@ -32,7 +32,7 @@ > > #define NPCM7XX_Tx_INTEN BIT(29) > > #define NPCM7XX_Tx_COUNTEN BIT(30) > > #define NPCM7XX_Tx_ONESHOT 0x0 > > -#define NPCM7XX_Tx_OPER GENMASK(27, 3) > > +#define NPCM7XX_Tx_OPER GENMASK(28, 27) > > #define NPCM7XX_Tx_MIN_PRESCALE 0x1 > > #define NPCM7XX_Tx_TDR_MASK_BITS 24 > > #define NPCM7XX_Tx_MAX_CNT 0xFF > > @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct > > clock_event_device *evt) > > > > val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > > val &= ~NPCM7XX_Tx_OPER; > > - > > - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > > val |= NPCM7XX_START_ONESHOT_Tx; > > writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); > > > > @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct > > clock_event_device *evt) > > struct timer_of *to = to_timer_of(evt); > > u32 val; > > > > + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); > > + > > val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > > val &= ~NPCM7XX_Tx_OPER; > > - > > - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); > > val |= NPCM7XX_START_PERIODIC_Tx; > > - > > writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); > > > > return 0; > > > > > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | > <http://www.linaro.org/linaro-blog/> Blog > -- Regards, Avi
Re: [PATCH v1 2/2] net: npcm: add NPCM7xx EMC 10/100 Ethernet driver
Thanks for the input Willem,
Before I will submit a new version please help me with some questions:
On Thu, Aug 1, 2019 at 8:26 PM Willem de Bruijn
wrote:
>
> On Thu, Aug 1, 2019 at 3:28 AM Avi Fishman wrote:
> >
> > EMC Ethernet Media Access Controller supports 10/100 Mbps and
> > RMII.
> > This driver has been working on Nuvoton BMC NPCM7xx.
> >
> > Signed-off-by: Avi Fishman
>
>
>
> > +/* global setting for driver */
> > +#define RX_QUEUE_LEN 128
> > +#define TX_QUEUE_LEN 64
> > +#define MAX_RBUFF_SZ 0x600
> > +#define MAX_TBUFF_SZ 0x600
> > +#define TX_TIMEOUT 50
> > +#define DELAY 1000
> > +#define CAM0 0x0
> > +#define RX_POLL_SIZE16
> > +
> > +#ifdef CONFIG_VLAN_8021Q
> > +#define IS_VLAN 1
> > +#else
> > +#define IS_VLAN 0
> > +#endif
> > +
> > +#define MAX_PACKET_SIZE (1514 + (IS_VLAN * 4))
>
> 1514 -> ETH_FRAME_LEN
>
> 4 -> VLAN_HLEN
OK
>
> Does this device support stacked VLAN?
I am not familiar with stacked VLAN.
Our HW for sure there is no support. can the SW stack handle it for me?
Does it mean that the packets can be larger?
>
> Is this really the device maximum?
The device can support upto 64KB, but of course I will not allocate
for each RX data such a big buffer.
Can I know what is the maximum value the network stack may request? I
saw many driver allocating 1536 for each packet.
>
> > +#define MAX_PACKET_SIZE_W_CRC (MAX_PACKET_SIZE + 4) /* 1518 */
>
> 4 -> ETH_FCS_LEN
OK
>
> > +#if defined CONFIG_NPCM7XX_EMC_ETH_DEBUG || defined CONFIG_DEBUG_FS
> > +#define REG_PRINT(reg_name) {t = scnprintf(next, size, "%-10s = %08X\n", \
> > + #reg_name, readl(ether->reg + (reg_name))); size -= t; next += t; }
> > +#define DUMP_PRINT(f, x...) {t = scnprintf(next, size, f, ## x); size -=
> > t; \
> > + next += t; }
> > +
> > +static int npcm7xx_info_dump(char *buf, int count, struct net_device
> > *netdev)
> > +{
> > + struct npcm7xx_ether *ether = netdev_priv(netdev);
> > + struct npcm7xx_txbd *txbd;
> > + struct npcm7xx_rxbd *rxbd;
> > + unsigned long flags;
> > + unsigned int i, cur, txd_offset, rxd_offset;
> > + char *next = buf;
> > + unsigned int size = count;
> > + int t;
> > + int is_locked = spin_is_locked(ðer->lock);
> > +
> > + if (!is_locked)
> > + spin_lock_irqsave(ðer->lock, flags);
> > +
> > + /* --basic driver information */
> > + DUMP_PRINT("NPCM7XX EMC %s driver version: %s\n", netdev->name,
> > + DRV_MODULE_VERSION);
> > +
> > + REG_PRINT(REG_CAMCMR);
> > + REG_PRINT(REG_CAMEN);
> > + REG_PRINT(REG_CAMM_BASE);
> > + REG_PRINT(REG_CAML_BASE);
> > + REG_PRINT(REG_TXDLSA);
> > + REG_PRINT(REG_RXDLSA);
> > + REG_PRINT(REG_MCMDR);
> > + REG_PRINT(REG_MIID);
> > + REG_PRINT(REG_MIIDA);
> > + REG_PRINT(REG_FFTCR);
> > + REG_PRINT(REG_TSDR);
> > + REG_PRINT(REG_RSDR);
> > + REG_PRINT(REG_DMARFC);
> > + REG_PRINT(REG_MIEN);
> > + REG_PRINT(REG_MISTA);
> > + REG_PRINT(REG_MGSTA);
> > + REG_PRINT(REG_MPCNT);
> > + writel(0x7FFF, (ether->reg + REG_MPCNT));
> > + REG_PRINT(REG_MRPC);
> > + REG_PRINT(REG_MRPCC);
> > + REG_PRINT(REG_MREPC);
> > + REG_PRINT(REG_DMARFS);
> > + REG_PRINT(REG_CTXDSA);
> > + REG_PRINT(REG_CTXBSA);
> > + REG_PRINT(REG_CRXDSA);
> > + REG_PRINT(REG_CRXBSA);
> > + REG_PRINT(REG_RXFSM);
> > + REG_PRINT(REG_TXFSM);
> > + REG_PRINT(REG_FSM0);
> > + REG_PRINT(REG_FSM1);
> > + REG_PRINT(REG_DCR);
> > + REG_PRINT(REG_DMMIR);
> > + REG_PRINT(REG_BISTR);
> > + DUMP_PRINT("\n");
> > +
> > + DUMP_PRINT("netif_queue %s\n\n", netif_queue_stopped(netdev) ?
> > + "Stopped" : "Running");
> > + if (ether->rdesc)
> > + DUMP_PRINT("napi is %s\n\n", test_bit(NAPI_STATE_SCHED,
> > + ðer->napi.state) ?
> > + "scheduled" :
> > + "not scheduled");
> > +
> &
[PATCH v1 1/2] dt-binding: net: document NPCM7xx EMC 10/100 DT bindings
Added device tree binding documentation for
Nuvoton NPCM7xx Ethernet MAC Controller (EMC) 10/100 RMII
Signed-off-by: Avi Fishman
---
.../bindings/net/nuvoton,npcm7xx-emc.txt | 38 +++
1 file changed, 38 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt
diff --git a/Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt
b/Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt
new file mode 100644
index ..a7ac3ca66de9
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt
@@ -0,0 +1,38 @@
+Nuvoton NPCM7XX 10/100 Ethernet MAC Controller (EMC)
+
+The NPCM7XX provides one or two Ethernet MAC RMII Controllers
+for WAN/LAN applications
+
+Required properties:
+- device_type : Should be "network"
+- compatible : "nuvoton,npcm750-emc" for Poleg NPCM7XX.
+- reg : Offset and length of the register set for the device.
+- interrupts : Contain the emc interrupts with flags for falling edge.
+first interrupt dedicated to Txirq
+second interrupt dedicated to Rxirq
+- phy-mode: Should be "rmii" (see ethernet.txt in the same directory)
+- clocks : phandle of emc reference clock.
+- resets : phandle to the reset control for this device.
+- use-ncsi: Use the NC-SI stack instead of an MDIO PHY
+
+Example:
+
+emc0: eth@f0825000 {
+ device_type = "network";
+ compatible = "nuvoton,npcm750-emc";
+ reg = <0xf0825000 0x1000>;
+ interrupts = ,
+;
+ phy-mode = "rmii";
+ clocks = <&clk NPCM7XX_CLK_AHB>;
+
+ #use-ncsi; /* add this to support ncsi */
+
+ clock-names = "clk_emc";
+ resets = <&rstc 6>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r1_pins
+&r1err_pins
+&r1md_pins>;
+ status = "okay";
+};
--
2.18.0
[PATCH v1 2/2] net: npcm: add NPCM7xx EMC 10/100 Ethernet driver
EMC Ethernet Media Access Controller supports 10/100 Mbps and RMII. This driver has been working on Nuvoton BMC NPCM7xx. Signed-off-by: Avi Fishman --- drivers/net/ethernet/nuvoton/Kconfig | 21 +- drivers/net/ethernet/nuvoton/Makefile |2 + drivers/net/ethernet/nuvoton/npcm7xx_emc.c | 2073 3 files changed, 2093 insertions(+), 3 deletions(-) create mode 100644 drivers/net/ethernet/nuvoton/npcm7xx_emc.c diff --git a/drivers/net/ethernet/nuvoton/Kconfig b/drivers/net/ethernet/nuvoton/Kconfig index 325e26c549f8..3820dd3bc4b7 100644 --- a/drivers/net/ethernet/nuvoton/Kconfig +++ b/drivers/net/ethernet/nuvoton/Kconfig @@ -6,8 +6,8 @@ config NET_VENDOR_NUVOTON bool "Nuvoton devices" default y - depends on ARM && ARCH_W90X900 - ---help--- + depends on ARM && (ARCH_W90X900 || ARCH_NPCM7XX) + help If you have a network (Ethernet) card belonging to this class, say Y. Note that the answer to this question doesn't directly affect the @@ -22,8 +22,23 @@ config W90P910_ETH depends on ARM && ARCH_W90X900 select PHYLIB select MII - ---help--- + help Say Y here if you want to use built-in Ethernet ports on w90p910 processor. +config NPCM7XX_EMC_ETH + bool "Nuvoton NPCM7XX Ethernet EMC" + depends on ARM && ARCH_NPCM7XX + select PHYLIB + select MII + help + Say Y here if you want to use built-in Ethernet MAC + on NPCM750 MCU. + +config NPCM7XX_EMC_ETH_DEBUG + bool "Nuvoton NPCM7XX Ethernet EMC debug" + depends on NPCM7XX_EMC_ETH + help + Say Y here if you want debug info via /proc/driver/npcm7xx_emc.x + endif # NET_VENDOR_NUVOTON diff --git a/drivers/net/ethernet/nuvoton/Makefile b/drivers/net/ethernet/nuvoton/Makefile index 66f6e728d54b..e32be694e987 100644 --- a/drivers/net/ethernet/nuvoton/Makefile +++ b/drivers/net/ethernet/nuvoton/Makefile @@ -3,4 +3,6 @@ # Makefile for the Nuvoton network device drivers. # +#Eternet 10/100 EMC obj-$(CONFIG_W90P910_ETH) += w90p910_ether.o +obj-$(CONFIG_NPCM7XX_EMC_ETH) += npcm7xx_emc.o diff --git a/drivers/net/ethernet/nuvoton/npcm7xx_emc.c b/drivers/net/ethernet/nuvoton/npcm7xx_emc.c new file mode 100644 index ..de56c7192b76 --- /dev/null +++ b/drivers/net/ethernet/nuvoton/npcm7xx_emc.c @@ -0,0 +1,2073 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2014-2019 Nuvoton Technology corporation. + +#ifdef CONFIG_NPCM7XX_EMC_ETH_DEBUG +#define DEBUG +#endif + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include + +#include +#include + +#include + +#include +#include + +#ifdef CONFIG_DEBUG_FS +static struct dentry *npcm7xx_fs_dir; +#endif + +#define MFSEL1_OFFSET 0x00C +#define MFSEL3_OFFSET 0x064 +#define INTCR_OFFSET 0x03C + +#define IPSRST1_OFFSET 0x020 + +#define DRV_MODULE_NAME"npcm7xx-emc" +#define DRV_MODULE_VERSION "3.90" + +/* Ethernet MAC Registers */ +#define REG_CAMCMR 0x00 +#define REG_CAMEN 0x04 +#define REG_CAMM_BASE 0x08 +#define REG_CAML_BASE 0x0c +#define REG_TXDLSA 0x88 +#define REG_RXDLSA 0x8C +#define REG_MCMDR 0x90 +#define REG_MIID 0x94 +#define REG_MIIDA 0x98 +#define REG_FFTCR 0x9C +#define REG_TSDR 0xa0 +#define REG_RSDR 0xa4 +#define REG_DMARFC 0xa8 +#define REG_MIEN 0xac +#define REG_MISTA 0xb0 +#define REG_MGSTA 0xb4 +#define REG_MPCNT 0xb8 +#define REG_MRPC 0xbc +#define REG_MRPCC 0xc0 +#define REG_MREPC 0xc4 +#define REG_DMARFS 0xc8 +#define REG_CTXDSA 0xcc +#define REG_CTXBSA 0xd0 +#define REG_CRXDSA 0xd4 +#define REG_CRXBSA 0xd8 + +/* EMC Diagnostic Registers */ +#define REG_RXFSM 0x200 +#define REG_TXFSM 0x204 +#define REG_FSM0 0x208 +#define REG_FSM1 0x20c +#define REG_DCR0x210 +#define REG_DMMIR 0x214 +#define REG_BISTR 0x300 + +/* mac controller bit */ +#define MCMDR_RXON BIT(0) +#define MCMDR_ALP BIT(1) +#define MCMDR_ACP BIT(3) +#define MCMDR_SPCRCBIT(5) +#define MCMDR_TXON BIT(8) +#define MCMDR_NDEF BIT(9) +#define MCMDR_FDUP BIT(18) +#define MCMDR_ENMDCBIT(19) +#define MCMDR_OPMODBIT(20) +#define SWRBIT(24) + +/* cam command regiser */ +#define CAMCMR_AUP BIT(0) +#define CAMCMR_AMP BIT(1) +#define CAMCMR_ABP BIT(2) +#define CAMCMR_CCAMBIT(3) +#define CAMCMR_ECMPBIT(4) + +/* cam enable regiser */ +#define CAM0EN BIT(0) + +/* mac mii controll
[PATCH v1 0/2] add NPCM7xx EMC 10/100 Ethernet driver
EMC Ethernet Media Access Controller supports 10/100 Mbps and RMII. This driver has been working on Nuvoton BMC NPCM7xx. Avi Fishman (2): dt-binding: net: document NPCM7xx EMC 10/100 DT bindings net: npcm: add NPCM7xx EMC 10/100 Ethernet driver .../bindings/net/nuvoton,npcm7xx-emc.txt | 38 + drivers/net/ethernet/nuvoton/Kconfig | 21 +- drivers/net/ethernet/nuvoton/Makefile |2 + drivers/net/ethernet/nuvoton/npcm7xx_emc.c| 2073 + 4 files changed, 2131 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt create mode 100644 drivers/net/ethernet/nuvoton/npcm7xx_emc.c -- 2.18.0
Re: RFC: remove Nuvoton w90x900/nuc900 platform?
Note that we we are going to add soon drivers/net/ethernet/nuvoton/npcm7xx_emc.c so maybe don't remove drivers/net/ethernet/nuvoton On Tue, Jul 30, 2019 at 4:01 PM Arnd Bergmann wrote: > > That wasn't it either, sorry for spamming the rest. I found one more > address for Zongshun at Huawei. > > On Tue, Jul 30, 2019 at 2:34 PM Arnd Bergmann wrote: > > > > Trying Wan Zongshun instead of > > the bouncing Wan ZongShun . > > (I assume you are the same person, sorry if not). > > > > On Tue, Jul 30, 2019 at 2:09 PM Arnd Bergmann wrote: > > > > > > As the mach-netx and mach-8695 platforms are being removed now, > > > I wonder whether we should do the same with w90x00: Here is what > > > I found after looking at the git history and external material for it. > > > > > > - The supported chips (nuc910/950/960) are no longer marketed > > > by the manufacturer > > > > > > - Newer chips from the same family (nuc97x, nuc980, n329x) > > > that are still marketed have Linux BSPs but those were never > > > submitted for upstream inclusion. > > > > > > - Wan ZongShun is listed as maintainer, but the last patch he wrote > > > was in 2011. > > > > > > - All patches to w90x900 platform specific files afterwards > > > are cleanups that were apparently done without access to > > > test hardware. > > > > > > - The http://www.mcuos.com/ website listed in the MAINTAINERS > > >file is no longer reachable. > > > > > > We do support the newer NPCM platform from Nuvoton. I don't think > > > there are any shared drivers between the two, but I've added its > > > maintainers to Cc anyway, in case they still (plan to) use one of > > > those drivers. > > > > > > If we decide that it's time to let go, I'll would the patches below. > > > > > > watchdog: remove w90x900 driver > > > spi: remove w90x900 driver > > > ASoC: remove w90x900/nuc900 platform drivers > > > fbdev: remove w90x900/nuc900 platform drivers > > > Input: remove w90x900 keyboard driver > > > Input: remove w90x900 touchscreen driver > > > mtd: rawnand: remove w90x900 driver > > > net: remove w90p910-ether driver > > > rtc: remove w90x900/nuc900 driver > > > usb: remove ehci-w90x900 driver > > > ARM: remove w90x900 platform > > > > > > Documentation/watchdog/watchdog-parameters.rst | 10 - > > > MAINTAINERS | 16 - > > > arch/arm/Kconfig | 21 +- > > > arch/arm/Makefile|1 - > > > arch/arm/configs/nuc910_defconfig| 51 - > > > arch/arm/configs/nuc950_defconfig| 67 -- > > > arch/arm/configs/nuc960_defconfig| 57 -- > > > arch/arm/mach-w90x900/Kconfig| 54 -- > > > arch/arm/mach-w90x900/Makefile | 20 - > > > arch/arm/mach-w90x900/Makefile.boot |4 - > > > arch/arm/mach-w90x900/clksel.c | 88 -- > > > arch/arm/mach-w90x900/clock.c| 121 --- > > > arch/arm/mach-w90x900/clock.h| 40 - > > > arch/arm/mach-w90x900/cpu.c | 238 - > > > arch/arm/mach-w90x900/cpu.h | 56 -- > > > arch/arm/mach-w90x900/dev.c | 537 --- > > > arch/arm/mach-w90x900/gpio.c | 150 --- > > > arch/arm/mach-w90x900/include/mach/entry-macro.S | 26 - > > > arch/arm/mach-w90x900/include/mach/hardware.h| 19 - > > > arch/arm/mach-w90x900/include/mach/irqs.h| 82 -- > > > arch/arm/mach-w90x900/include/mach/map.h | 153 --- > > > arch/arm/mach-w90x900/include/mach/mfp.h | 21 - > > > arch/arm/mach-w90x900/include/mach/regs-clock.h | 49 - > > > arch/arm/mach-w90x900/include/mach/regs-irq.h| 46 - > > > arch/arm/mach-w90x900/include/mach/regs-ldm.h| 248 - > > > arch/arm/mach-w90x900/include/mach/regs-serial.h | 54 -- > > > arch/arm/mach-w90x900/include/mach/uncompress.h | 43 - > > > arch/arm/mach-w90x900/irq.c | 212 - > > > arch/arm/mach-w90x900/mach-nuc910evb.c | 38 - > > > arch/arm/mach-w90x900/mach-nuc950evb.c | 42 - > > > arch/arm/mach-w90x900/mach-nuc960evb.c | 38 - > > > arch/arm/mach-w90x900/mfp.c | 197 > > > arch/arm/mach-w90x900/nuc910.c | 58 -- > > > arch/arm/mach-w90x900/nuc910.h | 17 - > > > arch/arm/mach-w90x900/nuc950.c | 52 -- > > > arch/arm/mach-w90x900/nuc950.h | 17 - > > > arch/arm/mach-w90x900/nuc960.c | 50 - > > > arch/arm/mach-w90x900/nuc960.h | 17 - > > > arch/arm/mach-w90x900/nuc9xx.h | 22 - > > > arch/arm/mach-w90x900/regs-ebi.h | 29 - > > > arch/arm/mach-w90x900/
[PATCH v2] mtd: spi-nor: Add Winbond w25q256jvm
Similar to w25q256 (besides not supporting QPI mode) but with different ID.
The "JVM" suffix is in the datasheet.
The datasheet indicates DUAL and QUAD are supported.
https://www.winbond.com/resource-files/w25q256jv%20spi%20revi%2010232018%20plus.pdf
Signed-off-by: Avi Fishman
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 03cc788511d5..74b41ec92414 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2151,6 +2151,8 @@ static const struct flash_info spi_nor_ids[] = {
{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "w25q256jvm", INFO(0xef7019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
--
2.18.0
[PATCH] [v5] clocksource/drivers/npcm: fix GENMASK and timer operation
NPCM7XX_Tx_OPER GENMASK bits where wrong, Since NPCM7XX_REG_TICR0 register reset value of those bits was 0, it did not cause an issue. in npcm7xx_timer_oneshot() the original NPCM7XX_REG_TCSR0 register was read again after masking it with ~NPCM7XX_Tx_OPER so the masking didn't take effect. npcm7xx_timer_periodic() was not wrong but it wrote to NPCM7XX_REG_TICR0 in a middle of read modify write to NPCM7XX_REG_TCSR0 which is confusing. npcm7xx_timer_oneshot() did wrong calculation Signed-off-by: Avi Fishman --- drivers/clocksource/timer-npcm7xx.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/timer-npcm7xx.c b/drivers/clocksource/timer-npcm7xx.c index 8a30da7f083b..9780ffd8010e 100644 --- a/drivers/clocksource/timer-npcm7xx.c +++ b/drivers/clocksource/timer-npcm7xx.c @@ -32,7 +32,7 @@ #define NPCM7XX_Tx_INTEN BIT(29) #define NPCM7XX_Tx_COUNTEN BIT(30) #define NPCM7XX_Tx_ONESHOT 0x0 -#define NPCM7XX_Tx_OPERGENMASK(27, 3) +#define NPCM7XX_Tx_OPERGENMASK(28, 27) #define NPCM7XX_Tx_MIN_PRESCALE0x1 #define NPCM7XX_Tx_TDR_MASK_BITS 24 #define NPCM7XX_Tx_MAX_CNT 0xFF @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct clock_event_device *evt) val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val |= NPCM7XX_START_ONESHOT_Tx; writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct clock_event_device *evt) struct timer_of *to = to_timer_of(evt); u32 val; + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); + val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); val |= NPCM7XX_START_PERIODIC_Tx; - writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); return 0; -- 2.18.0
Re: [PATCH] [v4] clocksource/drivers/npcm: fix GENMASK and timer operation
Please discard this. my mail tool corruppted it again. On Mon, Jul 29, 2019 at 7:50 PM Avi Fishman wrote: > > NPCM7XX_Tx_OPER GENMASK bits where wrong, > Since NPCM7XX_REG_TICR0 register reset value of those bits was 0, > it did not cause an issue. > in npcm7xx_timer_oneshot() the original NPCM7XX_REG_TCSR0 register was > read again after masking it with ~NPCM7XX_Tx_OPER so the masking didn't > take effect. > > npcm7xx_timer_periodic() was not wrong but it wrote to NPCM7XX_REG_TICR0 > in a middle of read modify write to NPCM7XX_REG_TCSR0 which is > confusing. > npcm7xx_timer_oneshot() did wrong calculation > > Signed-off-by: Avi Fishman > --- > drivers/clocksource/timer-npcm7xx.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/clocksource/timer-npcm7xx.c > b/drivers/clocksource/timer-npcm7xx.c > index 8a30da7f083b..9780ffd8010e 100644 > --- a/drivers/clocksource/timer-npcm7xx.c > +++ b/drivers/clocksource/timer-npcm7xx.c > @@ -32,7 +32,7 @@ > #define NPCM7XX_Tx_INTEN BIT(29) > #define NPCM7XX_Tx_COUNTEN BIT(30) > #define NPCM7XX_Tx_ONESHOT 0x0 > -#define NPCM7XX_Tx_OPERGENMASK(27, 3) > +#define NPCM7XX_Tx_OPERGENMASK(28, 27) > #define NPCM7XX_Tx_MIN_PRESCALE0x1 > #define NPCM7XX_Tx_TDR_MASK_BITS 24 > #define NPCM7XX_Tx_MAX_CNT 0xFF > @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct > clock_event_device *evt) > > val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > val &= ~NPCM7XX_Tx_OPER; > - > - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > val |= NPCM7XX_START_ONESHOT_Tx; > writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); > > @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct > clock_event_device *evt) > struct timer_of *to = to_timer_of(evt); > u32 val; > > + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); > + > val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > val &= ~NPCM7XX_Tx_OPER; > - > - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); > val |= NPCM7XX_START_PERIODIC_Tx; > - > writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); > > return 0; > -- > 2.18.0 -- Regards, Avi
[PATCH] [v4] clocksource/drivers/npcm: fix GENMASK and timer operation
NPCM7XX_Tx_OPER GENMASK bits where wrong, Since NPCM7XX_REG_TICR0 register reset value of those bits was 0, it did not cause an issue. in npcm7xx_timer_oneshot() the original NPCM7XX_REG_TCSR0 register was read again after masking it with ~NPCM7XX_Tx_OPER so the masking didn't take effect. npcm7xx_timer_periodic() was not wrong but it wrote to NPCM7XX_REG_TICR0 in a middle of read modify write to NPCM7XX_REG_TCSR0 which is confusing. npcm7xx_timer_oneshot() did wrong calculation Signed-off-by: Avi Fishman --- drivers/clocksource/timer-npcm7xx.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/timer-npcm7xx.c b/drivers/clocksource/timer-npcm7xx.c index 8a30da7f083b..9780ffd8010e 100644 --- a/drivers/clocksource/timer-npcm7xx.c +++ b/drivers/clocksource/timer-npcm7xx.c @@ -32,7 +32,7 @@ #define NPCM7XX_Tx_INTEN BIT(29) #define NPCM7XX_Tx_COUNTEN BIT(30) #define NPCM7XX_Tx_ONESHOT 0x0 -#define NPCM7XX_Tx_OPERGENMASK(27, 3) +#define NPCM7XX_Tx_OPERGENMASK(28, 27) #define NPCM7XX_Tx_MIN_PRESCALE0x1 #define NPCM7XX_Tx_TDR_MASK_BITS 24 #define NPCM7XX_Tx_MAX_CNT 0xFF @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct clock_event_device *evt) val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val |= NPCM7XX_START_ONESHOT_Tx; writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct clock_event_device *evt) struct timer_of *to = to_timer_of(evt); u32 val; + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); + val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); val |= NPCM7XX_START_PERIODIC_Tx; - writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); return 0; -- 2.18.0
Re: [PATCH] [v2] clocksource/drivers/npcm: fix GENMASK and timer operation
On Mon, Jul 15, 2019 at 6:25 PM Joe Perches wrote: > > On Mon, 2019-07-15 at 18:19 +0300, Avi Fishman wrote: > > clocksource/drivers/npcm: fix GENMASK and timer operation > > > > NPCM7XX_Tx_OPER GENMASK() changed from (27, 3) to (28, 27) > > > > in npcm7xx_timer_oneshot() the original NPCM7XX_REG_TCSR0 register was > > read again after masking it with ~NPCM7XX_Tx_OPER so the masking didn't > > take effect. > > > > npcm7xx_timer_periodic() was not wrong but it wrote to NPCM7XX_REG_TICR0 > > in a middle of read modify write to NPCM7XX_REG_TCSR0 which is > > confusing. > > You might mention how the original use of GENMASK(3, 27) > was defective or correct without effect. Done, see v3 of this patch. > > > Signed-off-by: Avi Fishman > > --- > > drivers/clocksource/timer-npcm7xx.c | 9 +++-- > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/clocksource/timer-npcm7xx.c > > b/drivers/clocksource/timer-npcm7xx.c > > index 8a30da7f083b..9780ffd8010e 100644 > > --- a/drivers/clocksource/timer-npcm7xx.c > > +++ b/drivers/clocksource/timer-npcm7xx.c > > @@ -32,7 +32,7 @@ > > #define NPCM7XX_Tx_INTEN BIT(29) > > #define NPCM7XX_Tx_COUNTEN BIT(30) > > #define NPCM7XX_Tx_ONESHOT 0x0 > > -#define NPCM7XX_Tx_OPERGENMASK(27, 3) > > +#define NPCM7XX_Tx_OPERGENMASK(28, 27) > > #define NPCM7XX_Tx_MIN_PRESCALE0x1 > > #define NPCM7XX_Tx_TDR_MASK_BITS 24 > > #define NPCM7XX_Tx_MAX_CNT 0xFF > > @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct > > clock_event_device *evt) > > > > val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > > val &= ~NPCM7XX_Tx_OPER; > > - > > - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > > val |= NPCM7XX_START_ONESHOT_Tx; > > writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); > > > > @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct > > clock_event_device *evt) > > struct timer_of *to = to_timer_of(evt); > > u32 val; > > > > + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); > > + > > val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); > > val &= ~NPCM7XX_Tx_OPER; > > - > > - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); > > val |= NPCM7XX_START_PERIODIC_Tx; > > - > > writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); > > > > return 0; > > > -- Regards, Avi
[PATCH] [v3] clocksource/drivers/npcm: fix GENMASK and timer operation
clocksource/drivers/npcm: fix GENMASK and timer operation NPCM7XX_Tx_OPER GENMASK() changed from (27, 3) to (28, 27) Since NPCM7XX_REG_TICR0 register reset value of those bits was 0, it did not cause an issue in npcm7xx_timer_oneshot() the original NPCM7XX_REG_TCSR0 register was read again after masking it with ~NPCM7XX_Tx_OPER so the masking didn't take effect. npcm7xx_timer_periodic() was not wrong but it wrote to NPCM7XX_REG_TICR0 in a middle of read modify write to NPCM7XX_REG_TCSR0 which is confusing. Signed-off-by: Avi Fishman --- drivers/clocksource/timer-npcm7xx.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/timer-npcm7xx.c b/drivers/clocksource/timer-npcm7xx.c index 8a30da7f083b..9780ffd8010e 100644 --- a/drivers/clocksource/timer-npcm7xx.c +++ b/drivers/clocksource/timer-npcm7xx.c @@ -32,7 +32,7 @@ #define NPCM7XX_Tx_INTEN BIT(29) #define NPCM7XX_Tx_COUNTEN BIT(30) #define NPCM7XX_Tx_ONESHOT 0x0 -#define NPCM7XX_Tx_OPERGENMASK(27, 3) +#define NPCM7XX_Tx_OPERGENMASK(28, 27) #define NPCM7XX_Tx_MIN_PRESCALE0x1 #define NPCM7XX_Tx_TDR_MASK_BITS 24 #define NPCM7XX_Tx_MAX_CNT 0xFF @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct clock_event_device *evt) val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val |= NPCM7XX_START_ONESHOT_Tx; writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct clock_event_device *evt) struct timer_of *to = to_timer_of(evt); u32 val; + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); + val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); val |= NPCM7XX_START_PERIODIC_Tx; - writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); return 0; -- 2.18.0
[PATCH] [v2] clocksource/drivers/npcm: fix GENMASK and timer operation
clocksource/drivers/npcm: fix GENMASK and timer operation NPCM7XX_Tx_OPER GENMASK() changed from (27, 3) to (28, 27) in npcm7xx_timer_oneshot() the original NPCM7XX_REG_TCSR0 register was read again after masking it with ~NPCM7XX_Tx_OPER so the masking didn't take effect. npcm7xx_timer_periodic() was not wrong but it wrote to NPCM7XX_REG_TICR0 in a middle of read modify write to NPCM7XX_REG_TCSR0 which is confusing. Signed-off-by: Avi Fishman --- drivers/clocksource/timer-npcm7xx.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/timer-npcm7xx.c b/drivers/clocksource/timer-npcm7xx.c index 8a30da7f083b..9780ffd8010e 100644 --- a/drivers/clocksource/timer-npcm7xx.c +++ b/drivers/clocksource/timer-npcm7xx.c @@ -32,7 +32,7 @@ #define NPCM7XX_Tx_INTEN BIT(29) #define NPCM7XX_Tx_COUNTEN BIT(30) #define NPCM7XX_Tx_ONESHOT 0x0 -#define NPCM7XX_Tx_OPERGENMASK(27, 3) +#define NPCM7XX_Tx_OPERGENMASK(28, 27) #define NPCM7XX_Tx_MIN_PRESCALE0x1 #define NPCM7XX_Tx_TDR_MASK_BITS 24 #define NPCM7XX_Tx_MAX_CNT 0xFF @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct clock_event_device *evt) val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val |= NPCM7XX_START_ONESHOT_Tx; writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct clock_event_device *evt) struct timer_of *to = to_timer_of(evt); u32 val; + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); + val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); val |= NPCM7XX_START_PERIODIC_Tx; - writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); return 0; -- 2.18.0
Re: [PATCH] clocksource/drivers/npcm: fix GENMASK and timer operation
Hi Thomas,
Thanks,
Avi
On Mon, Jul 15, 2019 at 3:37 PM Thomas Gleixner wrote:
>
> Avi,
>
> On Mon, 15 Jul 2019, Avi Fishman wrote:
>
> > NPCM7XX_Tx_OPER GENMASK was wrong,
>
> That part is already fixed upstream:
>
> 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK macro")
The automatic fix changed from
GENMASK(3, 27) to
GENMASK(27, 3)
I reviewd again the code to check how it worked so far and saw that it
should have been
GENMASK(28, 27) - this is a different value than 9bdd7bb3a844
For our fortune this wrong value didn't effect the our final write to
the register.
But still this should be fixed.
>
> > npcm7xx_timer_oneshot() did wrong calculation
>
> That changelog is pretty unspecific. It does not tell what is wrong and
> which consequences that has. Please be a bit more specific.
OK I will fix
>
> Thanks,
>
> tglx
--
Regards,
Avi
[PATCH] clocksource/drivers/npcm: fix GENMASK and timer operation
NPCM7XX_Tx_OPER GENMASK was wrong, npcm7xx_timer_oneshot() did wrong calculation Signed-off-by: Avi Fishman --- drivers/clocksource/timer-npcm7xx.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/timer-npcm7xx.c b/drivers/clocksource/timer-npcm7xx.c index 8a30da7f083b..9780ffd8010e 100644 --- a/drivers/clocksource/timer-npcm7xx.c +++ b/drivers/clocksource/timer-npcm7xx.c @@ -32,7 +32,7 @@ #define NPCM7XX_Tx_INTEN BIT(29) #define NPCM7XX_Tx_COUNTEN BIT(30) #define NPCM7XX_Tx_ONESHOT 0x0 -#define NPCM7XX_Tx_OPERGENMASK(27, 3) +#define NPCM7XX_Tx_OPERGENMASK(28, 27) #define NPCM7XX_Tx_MIN_PRESCALE0x1 #define NPCM7XX_Tx_TDR_MASK_BITS 24 #define NPCM7XX_Tx_MAX_CNT 0xFF @@ -84,8 +84,6 @@ static int npcm7xx_timer_oneshot(struct clock_event_device *evt) val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val |= NPCM7XX_START_ONESHOT_Tx; writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); @@ -97,12 +95,11 @@ static int npcm7xx_timer_periodic(struct clock_event_device *evt) struct timer_of *to = to_timer_of(evt); u32 val; + writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); + val = readl(timer_of_base(to) + NPCM7XX_REG_TCSR0); val &= ~NPCM7XX_Tx_OPER; - - writel(timer_of_period(to), timer_of_base(to) + NPCM7XX_REG_TICR0); val |= NPCM7XX_START_PERIODIC_Tx; - writel(val, timer_of_base(to) + NPCM7XX_REG_TCSR0); return 0; -- 2.18.0
Re: [PATCH 02/12] clocksource/drivers/npcm: Fix misuse of GENMASK macro
Hi, I noticed that this is totaly wrong, so I will fix here. If you wan I will put a separate patch. On Wed, Jul 10, 2019 at 8:04 AM Joe Perches wrote: > > Arguments are supposed to be ordered high then low. > > Signed-off-by: Joe Perches > --- > drivers/clocksource/timer-npcm7xx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clocksource/timer-npcm7xx.c > b/drivers/clocksource/timer-npcm7xx.c > index 7a9bb5532d99..8a30da7f083b 100644 > --- a/drivers/clocksource/timer-npcm7xx.c > +++ b/drivers/clocksource/timer-npcm7xx.c > @@ -32,7 +32,7 @@ > #define NPCM7XX_Tx_INTEN BIT(29) > #define NPCM7XX_Tx_COUNTEN BIT(30) > #define NPCM7XX_Tx_ONESHOT 0x0 > -#define NPCM7XX_Tx_OPERGENMASK(3, 27) > +#define NPCM7XX_Tx_OPERGENMASK(27, 3) It should be: +#define NPCM7XX_Tx_OPERGENMASK(28, 27) but I need to do another change. > #define NPCM7XX_Tx_MIN_PRESCALE0x1 > #define NPCM7XX_Tx_TDR_MASK_BITS 24 > #define NPCM7XX_Tx_MAX_CNT 0xFF > -- > 2.15.0 > -- Regards, Avi
Re: [PATCH] mtd: spi-nor: Add Winbond w25q256jvm
Hi Tudor, Boris & Tudor,
I see that you pushed this kind of commit of Winbond chip previously,
can you please approve also this?
On Tue, Jul 2, 2019 at 5:23 PM Avi Fishman wrote:
>
> Similar to w25q256 (besides not supporting QPI mode) but with different ID.
> The "JVM" suffix is in the datasheet.
> The datasheet indicates DUAL and QUAD are supported.
> https://www.winbond.com/resource-files/w25q256jv%20spi%20revi%2010232018%20plus.pdf
>
> Signed-off-by: Avi Fishman
> ---
> drivers/mtd/spi-nor/spi-nor.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 0c2ec1c21434..ccb217a24404 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2120,6 +2120,8 @@ static const struct flash_info spi_nor_ids[] = {
> { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
> { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
> { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + { "w25q256jvm", INFO(0xef7019, 0, 64 * 1024, 512,
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
> SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
>
> --
> 2.18.0
>
--
Regards,
Avi
[PATCH] mtd: spi-nor: Add Winbond w25q256jvm
Similar to w25q256 (besides not supporting QPI mode) but with different ID.
The "JVM" suffix is in the datasheet.
The datasheet indicates DUAL and QUAD are supported.
https://www.winbond.com/resource-files/w25q256jv%20spi%20revi%2010232018%20plus.pdf
Signed-off-by: Avi Fishman
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 0c2ec1c21434..ccb217a24404 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2120,6 +2120,8 @@ static const struct flash_info spi_nor_ids[] = {
{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "w25q256jvm", INFO(0xef7019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
--
2.18.0
[PATCH] mtd: spi-nor: Add Winbond w25q256jvm
Similar to w25q256 (besides not supporting QPI mode) but with different ID.
The "JVM" suffix is in the datasheet.
The datasheet indicates DUAL and QUAD are supported.
https://www.winbond.com/resource-files/w25q256jv%20spi%20revi%2010232018%20plus.pdf
Signed-off-by: Avi Fishman
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c
b/drivers/mtd/spi-nor/spi-nor.c index 0c2ec1c21434..ccb217a24404
100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2120,6 +2120,8 @@ static const struct flash_info spi_nor_ids[] = {
{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16, SECT_4K) },
{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "w25q256jvm", INFO(0xef7019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
--
2.18.0
--
Regards,
Avi
Re: [PATCH 5.2 v2 2/2] dt-binding: edac: add NPCM ECC documentation
On Wed, Jun 5, 2019 at 5:19 PM George Hung wrote:
>
> Add device tree documentation for Nuvoton BMC ECC
>
> Signed-off-by: George Hung
Reviewed-by: Avi Fishman
> ---
> .../bindings/edac/npcm7xx-sdram-edac.txt| 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
>
> diff --git a/Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
> b/Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
> new file mode 100644
> index ..dd4dac59a5bd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
> @@ -0,0 +1,17 @@
> +Nuvoton NPCM7xx SoC EDAC device driver
> +
> +The Nuvoton NPCM7xx SoC supports DDR4 memory with/without ECC and the driver
> +uses the EDAC framework to implement the ECC detection and corrtection.
> +
> +Required properties:
> +- compatible: should be "nuvoton,npcm7xx-sdram-edac"
> +- reg: Memory controller register set should be <0xf0824000 0x1000>
> +- interrupts: should be MC interrupt #25
> +
> +Example:
> +
> + mc: memory-controller@f0824000 {
> + compatible = "nuvoton,npcm7xx-sdram-edac";
> + reg = <0xf0824000 0x1000>;
> + interrupts = <0 25 4>;
> + };
> --
> 2.21.0
>
--
Regards,
Avi
Re: [PATCH 5.2 v2 1/2] edac: npcm: Add Nuvoton NPCM7xx EDAC driver
On Wed, Jun 5, 2019 at 5:18 PM George Hung wrote:
>
> Add support for the Nuvoton NPCM7xx SoC EDAC driver
>
> NPCM7xx ECC datasheet from nuvoton.israel-Poleg:
> "Cadence DDR Controller User’s Manual For DDR3 & DDR4 Memories"
>
> Tested: Forcing an ECC error event
>
> Write a value to the xor_check_bits parameter that will trigger
> an ECC event once that word is read
>
> For example, to force a single-bit correctable error on bit 0 of
> the user-word space shown, write 0x75 into that byte of the
> xor_check_bits parameter and then assert fwc (force write check)
> bit to 'b1' (mem base: 0xf0824000, xor_check_bits reg addr: 0x178)
>
> $ devmem 0xf0824178 32 0x7501
>
> To force a double-bit un-correctable error for the user-word space,
> write 0x03 into that byte of the xor_check_bits parameter
>
> $ devmem 0xf0824178 32 0x301
>
> Signed-off-by: George Hung
Reviewed-by: Avi Fishman
> ---
> MAINTAINERS | 6 +
> drivers/edac/Kconfig| 7 +
> drivers/edac/Makefile | 1 +
> drivers/edac/npcm7xx_edac.c | 424
> 4 files changed, 438 insertions(+)
> create mode 100644 drivers/edac/npcm7xx_edac.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a6954776a37e..9faf7a48eea2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5784,6 +5784,12 @@ L: linux-e...@vger.kernel.org
> S: Maintained
> F: drivers/edac/mpc85xx_edac.[ch]
>
> +EDAC-NPCM7XX
> +M: George Hung
> +S: Maintained
> +F: drivers/edac/npcm7xx_edac.c
> +F: Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
> +
> EDAC-PASEMI
> M: Egor Martovetsky
> L: linux-e...@vger.kernel.org
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 5e2e0348d460..d8834b3c9ec8 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -504,4 +504,11 @@ config EDAC_ASPEED
> First, ECC must be configured in the bootloader. Then, this driver
> will expose error counters via the EDAC kernel framework.
>
> +config EDAC_NPCM7XX
> + tristate "Nuvoton NPCM7xx DDR Memory Controller"
> + depends on ARCH_NPCM7XX
> + help
> + Support for error detection and correction on the
> + Nuvoton NPCM7xx DDR memory controller.
> +
> endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index 89ad4a84a0f6..ae70e4c02fd9 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -84,3 +84,4 @@ obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
> obj-$(CONFIG_EDAC_TI) += ti_edac.o
> obj-$(CONFIG_EDAC_QCOM)+= qcom_edac.o
> obj-$(CONFIG_EDAC_ASPEED) += aspeed_edac.o
> +obj-$(CONFIG_EDAC_NPCM7XX) += npcm7xx_edac.o
> diff --git a/drivers/edac/npcm7xx_edac.c b/drivers/edac/npcm7xx_edac.c
> new file mode 100644
> index ..2d2deb81e49c
> --- /dev/null
> +++ b/drivers/edac/npcm7xx_edac.c
> @@ -0,0 +1,424 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 Quanta Computer lnc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "edac_module.h"
> +
> +#define ECC_ENABLE BIT(24)
> +#define ECC_EN_INT_MASK0x7f87
> +
> +#define INT_STATUS_ADDR116
> +#define INT_ACK_ADDR 117
> +#define INT_MASK_ADDR 118
> +
> +#define ECC_EN_ADDR93
> +#define ECC_C_ADDR_ADDR98
> +#define ECC_C_DATA_ADDR100
> +#define ECC_C_ID_ADDR 101
> +#define ECC_C_SYND_ADDR99
> +#define ECC_U_ADDR_ADDR95
> +#define ECC_U_DATA_ADDR97
> +#define ECC_U_ID_ADDR 101
> +#define ECC_U_SYND_ADDR96
> +
> +#define ECC_ERROR -1
> +#define EDAC_MSG_SIZE 256
> +#define EDAC_MOD_NAME "npcm7xx-edac"
> +
> +struct ecc_error_signature_info {
> + u32 ecc_addr;
> + u32 ecc_data;
> + u32 ecc_id;
> + u32 ecc_synd;
> +};
> +
> +struct npcm7xx_ecc_int_status {
> + u32 int_mask;
> + u32 int_status;
> + u32 int_ack;
> + u32 ce_cnt;
> + u32 ue_cnt;
> + struct ecc_error_signature_info ceinfo;
> + struct ecc_error_signature_info ueinfo;
> +};
> +
> +struct npcm7xx_edac_priv {
> + void __iomem *baseaddr;
> + char message[EDAC_MSG_SIZE];
> + struct n
Re: [PATCH v2 06/15] arm: npcm: fix a leaked reference by adding missing of_node_put
On Tue, Mar 5, 2019 at 1:33 PM Wen Yang wrote:
>
> The call to of_get_next_child returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
> ./arch/arm/mach-npcm/platsmp.c:52:1-7: ERROR: missing of_node_put; acquired a
> node pointer with refcount incremented on line 31, but without a
> corresponding object release within this function.
> ./arch/arm/mach-npcm/platsmp.c:68:2-8: ERROR: missing of_node_put; acquired a
> node pointer with refcount incremented on line 60, but without a
> corresponding object release within this function.
>
> Signed-off-by: Wen Yang
> Reviewed-by: Florian Fainelli
> Cc: Avi Fishman
> Cc: Tomer Maimon
> Cc: Patrick Venture
> Cc: Nancy Yuen
> Cc: Brendan Higgins
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: open...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> v2->v1: add a missing space between "adding" and "missing"
>
> arch/arm/mach-npcm/platsmp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-npcm/platsmp.c b/arch/arm/mach-npcm/platsmp.c
> index 21633c7..fe63edc 100644
> --- a/arch/arm/mach-npcm/platsmp.c
> +++ b/arch/arm/mach-npcm/platsmp.c
> @@ -35,6 +35,7 @@ static int npcm7xx_smp_boot_secondary(unsigned int cpu,
> goto out;
> }
> gcr_base = of_iomap(gcr_np, 0);
> + of_node_put(gcr_np);
> if (!gcr_base) {
> pr_err("could not iomap gcr");
> ret = -ENOMEM;
> @@ -63,6 +64,7 @@ static void __init npcm7xx_smp_prepare_cpus(unsigned int
> max_cpus)
> return;
> }
> scu_base = of_iomap(scu_np, 0);
> + of_node_put(scu_np);
> if (!scu_base) {
> pr_err("could not iomap scu");
> return;
> --
> 2.9.5
>
Reviewed-by: Avi Fishman
--
Regards,
Avi
Re: [PATCH 06/15] arm: npcm: fix a leaked reference by addingmissing of_node_put
Reviewed-by: Avi Fishman
Thanks
On Fri, Mar 1, 2019 at 10:57 AM Wen Yang wrote:
>
> The call to of_get_next_child returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
> ./arch/arm/mach-npcm/platsmp.c:52:1-7: ERROR: missing of_node_put; acquired a
> node pointer with refcount incremented on line 31, but without a
> corresponding object release within this function.
> ./arch/arm/mach-npcm/platsmp.c:68:2-8: ERROR: missing of_node_put; acquired a
> node pointer with refcount incremented on line 60, but without a
> corresponding object release within this function.
>
> Signed-off-by: Wen Yang
> Cc: Avi Fishman
> Cc: Tomer Maimon
> Cc: Patrick Venture
> Cc: Nancy Yuen
> Cc: Brendan Higgins
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: open...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/mach-npcm/platsmp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-npcm/platsmp.c b/arch/arm/mach-npcm/platsmp.c
> index 21633c7..fe63edc 100644
> --- a/arch/arm/mach-npcm/platsmp.c
> +++ b/arch/arm/mach-npcm/platsmp.c
> @@ -35,6 +35,7 @@ static int npcm7xx_smp_boot_secondary(unsigned int cpu,
> goto out;
> }
> gcr_base = of_iomap(gcr_np, 0);
> + of_node_put(gcr_np);
> if (!gcr_base) {
> pr_err("could not iomap gcr");
> ret = -ENOMEM;
> @@ -63,6 +64,7 @@ static void __init npcm7xx_smp_prepare_cpus(unsigned int
> max_cpus)
> return;
> }
> scu_base = of_iomap(scu_np, 0);
> + of_node_put(scu_np);
> if (!scu_base) {
> pr_err("could not iomap scu");
> return;
> --
> 2.9.5
>
--
Regards,
Avi
Re: [PATCH] clk: npcm7xx: fix memory allocation
On Fri, Aug 24, 2018 at 2:18 AM Kees Cook wrote:
>
> On Thu, Aug 23, 2018 at 4:06 PM, Gustavo A. R. Silva
> wrote:
> > One of the more common cases of allocation size calculations is finding
> > the size of a structure that has a zero-sized array at the end, along
> > with memory for some number of elements for that array. For example:
> >
> > struct foo {
> > int stuff;
> > void *entry[];
> > };
> >
> > instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count,
> > GFP_KERNEL);
> >
> > Instead of leaving these open-coded and prone to type mistakes, we can
> > now use the new struct_size() helper:
> >
> > instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
> >
> > Notice that, currently, there is a bug during the allocation:
> >
> > sizeof(npcm7xx_clk_data) should be sizeof(*npcm7xx_clk_data)
> >
> > Fix this bug by using struct_size() in kzalloc()
> >
> > This issue was detected with the help of Coccinelle.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Gustavo A. R. Silva
>
> Reviewed-by: Kees Cook
Reviewed-by: Avi Fishman
>
> -Kees
>
> > ---
> > drivers/clk/clk-npcm7xx.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/clk/clk-npcm7xx.c b/drivers/clk/clk-npcm7xx.c
> > index 740af90..c5edf8f 100644
> > --- a/drivers/clk/clk-npcm7xx.c
> > +++ b/drivers/clk/clk-npcm7xx.c
> > @@ -558,8 +558,8 @@ static void __init npcm7xx_clk_init(struct device_node
> > *clk_np)
> > if (!clk_base)
> > goto npcm7xx_init_error;
> >
> > - npcm7xx_clk_data = kzalloc(sizeof(*npcm7xx_clk_data->hws) *
> > - NPCM7XX_NUM_CLOCKS + sizeof(npcm7xx_clk_data), GFP_KERNEL);
> > + npcm7xx_clk_data = kzalloc(struct_size(npcm7xx_clk_data, hws,
> > + NPCM7XX_NUM_CLOCKS), GFP_KERNEL);
> > if (!npcm7xx_clk_data)
> > goto npcm7xx_init_np_err;
> >
> > --
> > 2.7.4
> >
>
>
>
> --
> Kees Cook
> Pixel Security
--
Regards,
Avi
Re: [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields
+ my vote as Nuvoton's BMC FW provider. On Fri, Jul 13, 2018 at 10:07 PM wrote: > > >> Dell - Internal Use - Confidential > >Really? To a public mailing list? odd... > > Ha yea sorry - I was so excited to show my support, that I jumped the gun :) >
[PATCH v2 1/1] MAINTAINERS: add subfolders for nuvoton *npcm*
From: Avi Fishman Add several subfolders to look for *npcm* files under ARM/NUVOTON NPCM ARCHITECTURE Signed-off-by: Avi Fishman --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e0ce3c5f32e5..23c450adad44 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1727,7 +1727,10 @@ F: arch/arm/mach-npcm/ F: arch/arm/boot/dts/nuvoton-npcm* F: include/dt-bindings/clock/nuvoton,npcm7xx-clks.h F: drivers/*/*npcm* +F: drivers/*/*/*npcm* F: Documentation/*/*npcm* +F: Documentation/*/*/*npcm* +F: Documentation/*/*/*/*npcm* ARM/NUVOTON W90X900 ARM ARCHITECTURE M: Wan ZongShun -- 2.14.1
[PATCH v2 0/1] MAINTAINERS: add subfolders for nuvoton *npcm*
From: Avi Fishman Changes since version 1: - Follow Greg KH comment to add changelog test in addition to the commit subject Add several subfolders to look for *npcm* files under ARM/NUVOTON NPCM ARCHITECTURE Avi Fishman (1): MAINTAINERS: add subfolders for nuvoton *npcm* MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) -- 2.14.1
Re: [PATCH ipmi/kcs_bmc v1] ipmi: add an NPCM7xx KCS BMC driver
Thanks Haiyue,
this works for us, I am adding Tested-by: Avi Fishman
On Thu, Mar 22, 2018 at 3:50 PM, Haiyue Wang
wrote:
> This driver exposes the Keyboard Controller Style (KCS) interface on
> Novoton NPCM7xx SoCs as a character device. Such SOCs are commonly used
> as a BaseBoard Management Controller (BMC) on a server board, and KCS
> interface is commonly used to perform the in-band IPMI communication
> between the server and its BMC.
>
> Signed-off-by: Avi Fishman
Tested-by: Avi Fishman
> Signed-off-by: Haiyue Wang
> ---
> .../devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt | 39
> drivers/char/ipmi/Kconfig | 15 ++
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/kcs_bmc_npcm7xx.c| 204
> +
> 4 files changed, 259 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
> create mode 100644 drivers/char/ipmi/kcs_bmc_npcm7xx.c
>
> diff --git a/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
> b/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
> new file mode 100644
> index 000..3538a21
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
> @@ -0,0 +1,39 @@
> +* Nuvoton NPCM7xx KCS (Keyboard Controller Style) IPMI interface
> +
> +The Nuvoton SOCs (NPCM7xx) are commonly used as BMCs
> +(Baseboard Management Controllers) and the KCS interface can be
> +used to perform in-band IPMI communication with their host.
> +
> +Required properties:
> +- compatible : should be one of
> +"nuvoton,npcm750-kcs-bmc"
> +- interrupts : interrupt generated by the controller
> +- kcs_chan : The KCS channel number in the controller
> +
> +Example:
> +
> +lpc_kcs: lpc_kcs@f0007000 {
> +compatible = "nuvoton,npcm750-lpc-kcs", "simple-mfd", "syscon";
> +reg = <0xf0007000 0x40>;
> +reg-io-width = <1>;
> +
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges = <0x0 0xf0007000 0x40>;
> +
> +kcs1: kcs1@0 {
> +compatible = "nuvoton,npcm750-kcs-bmc";
> +reg = <0x0 0x40>;
> +interrupts = <0 9 4>;
> +kcs_chan = <1>;
> +status = "disabled";
> +};
> +
> +kcs2: kcs2@0 {
> +compatible = "nuvoton,npcm750-kcs-bmc";
> +reg = <0x0 0x40>;
> +interrupts = <0 9 4>;
> +kcs_chan = <2>;
> +status = "disabled";
> +};
> +};
> \ No newline at end of file
> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
> index 3bda116..470f976 100644
> --- a/drivers/char/ipmi/Kconfig
> +++ b/drivers/char/ipmi/Kconfig
> @@ -111,6 +111,21 @@ config ASPEED_KCS_IPMI_BMC
> The driver implements the BMC side of the KCS contorller, it
> provides the access of KCS IO space for BMC side.
>
> +config NPCM7XX_KCS_IPMI_BMC
> + depends on ARCH_NPCM7XX || COMPILE_TEST
> + select IPMI_KCS_BMC
> + select REGMAP_MMIO
> + tristate "NPCM7xx KCS IPMI BMC driver"
> + help
> + Provides a driver for the KCS (Keyboard Controller Style) IPMI
> + interface found on Nuvoton NPCM7xx SOCs.
> +
> + The driver implements the BMC side of the KCS contorller, it
> + provides the access of KCS IO space for BMC side.
> +
> + This support is also available as a module. If so, the module
> + will be called kcs_bmc_npcm7xx.
> +
> config ASPEED_BT_IPMI_BMC
> depends on ARCH_ASPEED || COMPILE_TEST
> depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
> diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
> index 21e9e87..7a3baf3 100644
> --- a/drivers/char/ipmi/Makefile
> +++ b/drivers/char/ipmi/Makefile
> @@ -24,3 +24,4 @@ obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
> obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
> obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> +obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
> diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> new file mode 100644
> index 000..7bc898c
> --- /dev/null
> +++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> @@ -0,0 +1,204 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Nuvoton Corporation.
> + * Copyright (c) 2018, Intel Corporation.
> + */
> +
> +#
Re: [PATCH 2/2] ARM: npcm: drop extraneous 'select' statements
So at least replace CACHE_L2X0 with MIGHT_HAVE_CACHE_L2X0 then CACHE_L2X0 will be selected by default and user can still remove it. On Thu, Mar 8, 2018 at 4:12 AM, Joel Stanley wrote: > On Thu, Mar 8, 2018 at 2:54 AM, Arnd Bergmann wrote: >> While looking at the build regression, I noticed that the >> platform selects a lot of other Kconfig symbols that it really >> should not: >> >> CPU_V7, ARM_GIC, HAVE_SMP, COMMON_CLK, GENERIC_CLOCKEVENTS, >> and CLKDEV_LOOKUP are all implied by ARCH_MULTI_V7, so they >> can be dropped. >> >> CACHE_L2X0, SMP and USB are meant to be user-selectable, we >> want to be able to turn those off for testing purposes. >> >> CPU_USE_DOMAINS looks completely misplaced here, we should not >> select that for an ARMv7 platform. >> >> Signed-off-by: Arnd Bergmann > > I had a similar patch queued for sending out. Thanks Arnd. > > Acked-by: Joel Stanley > > Cheers, > > Joel > >> --- >> arch/arm/mach-npcm/Kconfig | 18 -- >> 1 file changed, 18 deletions(-) >> >> diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig >> index 2bc6697c8d97..c6a16230e8ef 100644 >> --- a/arch/arm/mach-npcm/Kconfig >> +++ b/arch/arm/mach-npcm/Kconfig >> @@ -12,12 +12,6 @@ comment "NPCM7XX CPU type" >> config ARCH_NPCM750 >> depends on ARCH_NPCM >> bool "Support for NPCM750 BMC CPU (Poleg)" >> - select CACHE_L2X0 >> - select CPU_V7 >> - select ARM_GIC >> - select HAVE_SMP >> - select SMP >> - select SMP_ON_UP >> select HAVE_ARM_SCU >> select HAVE_ARM_TWD if SMP >> select ARM_ERRATA_720789 >> @@ -26,18 +20,6 @@ config ARCH_NPCM750 >> select ARM_ERRATA_794072 >> select PL310_ERRATA_588369 >> select PL310_ERRATA_727915 >> - select USB_EHCI_ROOT_HUB_TT >> - select USB_ARCH_HAS_HCD >> - select USB_ARCH_HAS_EHCI >> - select USB_EHCI_HCD >> - select USB_ARCH_HAS_OHCI >> - select USB_OHCI_HCD >> - select USB >> - select FIQ >> - select CPU_USE_DOMAINS >> - select GENERIC_CLOCKEVENTS >> - select CLKDEV_LOOKUP >> - select COMMON_CLK if OF >> select NPCM750_TIMER >> select MFD_SYSCON >> help >> -- >> 2.9.0 >>
Re: [PATCH] serial: 8250: Add Nuvoton NPCM UART
> From: joel.s...@gmail.com [mailto:joel.s...@gmail.com] On Behalf Of Joel
> Stanley
> Sent: Thursday, February 15, 2018 4:00 AM
>
> On Wed, Feb 14, 2018 at 3:22 AM, Andy Shevchenko
> wrote:
>> On Mon, Feb 12, 2018 at 6:48 AM, Joel Stanley wrote:
>>> The Nuvoton UART is almost compatible with the 8250 driver when
>>> probed via the 8250_of driver, however it requires some extra
>>> configuration at startup.
>>
>>
>>> + [PORT_NPCM] = {
>>> + .name = "Nuvoton 16550",
>>> + .fifo_size = 16,
>>> + .tx_loadsz = 16,
>>> + .fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10
>>> |
>>> + UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
>>> + .rxtrig_bytes = {1, 4, 8, 14},
>>> + .flags = UART_CAP_FIFO,
>>
>>> +
>>
>> Redundant.
>
> You are referring to the extra whitespace?
>
>>> + },
>>
>>> + /*
>>> +* Nuvoton calls the scratch register 'UART_TOR' (timeout
>>> +* register). Enable it, and set TIOC (timeout interrupt
>>> +* comparator) to be 0x20 for correct operation.
>>> +*/
>>> + serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE |
>>> + 0x20);
>>
>>> +/* Nuvoton NPCM UARTs have a custom divisor calculation */
>>> + return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
>>
>> Is there any link to datasheet?
>
> I have a copy of the datasheet under NDA. The Nuvoton guys might be able to
> help you out. Avi?
In the spec the calculation is as follows:
BaudOut = Selected UART Clock Source / ( 16 * [Divisor + 2] )
To translate it to our code is:
baud = port->uartclk / (16 * (Divisor + 2) )
So it should calculate without the "+ 2" inside as follow:
+ return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud) - 2;
In order to get the spec you can add somthing like that:
"For getting the NPCM7XX Data Sheet please contact bmc_market...@nuvoton.com".
BTW Andy, Intel has our Data Sheet under NDA, you can ask Mihm James
.
>
>>
>>> +/* Nuvoton UART */
>>> +#define PORT_NPCM 118
>>
>> We have gaps there. #40 is perfect place for this one.
>
> Ok, I will move it up. Thanks for the review.
>
> Cheers,
>
> Joel
>
Re: [PATCH v9 2/3] arm: dts: add Nuvoton NPCM750 device tree
On Tue, Feb 13, 2018 at 10:30 AM, Arnd Bergmann wrote: > On Tue, Feb 6, 2018 at 12:57 AM, Brendan Higgins > wrote: >> Add a common device tree for all Nuvoton NPCM750 BMCs and a board >> specific device tree for the NPCM750 (Poleg) evaluation board. >> >> Signed-off-by: Brendan Higgins >> Reviewed-by: Tomer Maimon >> Reviewed-by: Avi Fishman >> Reviewed-by: Joel Stanley >> Reviewed-by: Rob Herring >> Tested-by: Tomer Maimon >> Tested-by: Avi Fishman > ... >> + enable-method = "nuvoton,npcm7xx-smp"; > > I see this has already been reviewed quite a bit, but I'm curious > about the 'npcm7xx' > part here. Shouldn't that be a real chip name rather than a wildcard? > >Arnd There is a family of npcm7xx, some with SMP and some without. For those who has it, it is common for all to use the same "nuvoton,npcm7xx-smp". Avi
Re: [PATCH arm/aspeed/ast2500 v1] ipmi: add an Aspeed KCS IPMI BMC driver
Sounds great for us (Nuvoton). Avi. On Wed, Jan 17, 2018 at 8:32 AM, Wang, Haiyue wrote: > > > On 2018-01-17 07:06, Joel Stanley wrote: >> >> On Tue, Jan 16, 2018 at 2:59 PM, Corey Minyard wrote: >>> >>> On 01/16/2018 05:43 AM, Haiyue Wang wrote: The KCS (Keyboard Controller Style) interface is used to perform in-band IPMI communication between a server host and its BMC (BaseBoard Management Controllers). This driver exposes the KCS interface on ASpeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are commonly used as BMCs and this driver implements the BMC side of the KCS interface. >>> >>> >>> I thought we were going to unify the BMC ioctl interface? My preference >>> would be to >>> create a file named include/uapi/linux/ipmi-bmc.h and add the following: >>> >>> #define __IPMI_BMC_IOCTL_MAGIC0xb1 >>> #define IPMI_BMC_IOCTL_SMS_SET_ATN_IO(__IPMI_BMC_IOCTL_MAGIC, 0x00) >>> >>> to make it the same as BT. Then in bt-bmc.h, set BT_BMC_IOCTL_SMS_ATN to >>> IPMI_BMC_IOCTL_SMS_SET_ATN. Then add the KCS ioctls in ipmi-bmc.h and >>> use that. That way we stay backward compatible but we are unified. >>> >>> Since more KCS interfaces may come around, can you make the name more >>> specific? (I made this same error on bt-bmc,c, it should probably be >>> renamed.) >> >> Yes, we had a group of openbmc people get together recently and spoke >> about this. Unfortunately Haiyue wasn't there (but other Intel BMC >> people were). >> >> We've got code coming from another BMC vendor who will use the same >> userspace API. The intention is to unify ASPEED's KCS and BT, along >> with Nuvoton's KCS and BT, as you outlined above. > > Great design for common BMC code, thanks Joel & Corey. > > Then we need to divide the kcs-bmc.c into two files, one (still kcs-bmc.c) > is for handling IPMI KCS state > according to IPMI 2.0 specification, and also handing device misc > operations; another file is called such > as aspeed-kcs-bmc.c which handles ast2500 kcs controller. So that Nuvoton > can define nvvoton-kcs-bmc.c > low level API, and call the IPMI KCS function in kcs-bmc.c ? > > How about this idea ? If it makes sense, I will change the code for review > in patch v2. > >> Cheers, >> >> Joel > >
Re: [PATCH v4 1/3] arm: npcm: add basic support for Nuvoton BMCs
On Thu, Sep 7, 2017 at 8:09 AM, Brendan Higgins wrote: > On Wed, Sep 6, 2017 at 2:04 PM, Avi Fishman wrote: >> Sorry for sending again some mailing list rejected it due to HTML >> involved (althoug I tried Plain Text), Trying again. >> >> 2017-09-06 11:07 GMT+03:00 Brendan Higgins : >>> Adds basic support for the Nuvoton NPCM750 BMC. >>> >>> Signed-off-by: Brendan Higgins >>> --- >>> arch/arm/Kconfig | 2 + >>> arch/arm/Makefile| 1 + >>> arch/arm/mach-npcm/Kconfig | 50 + >>> arch/arm/mach-npcm/Makefile | 3 ++ >>> arch/arm/mach-npcm/headsmp.S | 17 + >>> arch/arm/mach-npcm/npcm7xx.c | 34 + >>> arch/arm/mach-npcm/platsmp.c | 89 >>> >>> 7 files changed, 196 insertions(+) >>> create mode 100644 arch/arm/mach-npcm/Kconfig >>> create mode 100644 arch/arm/mach-npcm/Makefile >>> create mode 100644 arch/arm/mach-npcm/headsmp.S >>> create mode 100644 arch/arm/mach-npcm/npcm7xx.c >>> create mode 100644 arch/arm/mach-npcm/platsmp.c >>> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>> index 61a0cb15067e..05543f1cfbde 100644 >>> --- a/arch/arm/Kconfig >>> +++ b/arch/arm/Kconfig >>> @@ -782,6 +782,8 @@ source "arch/arm/mach-netx/Kconfig" >>> >>> source "arch/arm/mach-nomadik/Kconfig" >>> >>> +source "arch/arm/mach-npcm/Kconfig" >>> + >>> source "arch/arm/mach-nspire/Kconfig" >>> >>> source "arch/arm/plat-omap/Kconfig" >>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile >>> index 47d3a1ab08d2..60ca50c7d762 100644 >>> --- a/arch/arm/Makefile >>> +++ b/arch/arm/Makefile >>> @@ -191,6 +191,7 @@ machine-$(CONFIG_ARCH_MEDIATEK) += mediatek >>> machine-$(CONFIG_ARCH_MXS) += mxs >>> machine-$(CONFIG_ARCH_NETX)+= netx >>> machine-$(CONFIG_ARCH_NOMADIK) += nomadik >>> +machine-$(CONFIG_ARCH_NPCM)+= npcm >>> machine-$(CONFIG_ARCH_NSPIRE) += nspire >>> machine-$(CONFIG_ARCH_OXNAS) += oxnas >>> machine-$(CONFIG_ARCH_OMAP1) += omap1 >>> diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig >>> new file mode 100644 >>> index ..d47061855439 >>> --- /dev/null >>> +++ b/arch/arm/mach-npcm/Kconfig >>> @@ -0,0 +1,50 @@ >>> +menuconfig ARCH_NPCM >>> + bool "Nuvoton NPCM Architecture" >>> + select ARCH_REQUIRE_GPIOLIB >>> + select USE_OF >>> + select PINCTRL >>> + select PINCTRL_NPCM7XX >>> + >>> +if ARCH_NPCM >>> + >>> +comment "NPCMX50 CPU type" >>> + >>> +config CPU_NPCM750 >>> + depends on ARCH_NPCM && ARCH_MULTI_V7 >>> + bool "Support for NPCM750 BMC CPU (Poleg)" >>> + select CACHE_L2X0 >>> + select CPU_V7 >>> + select ARM_GIC >>> + select HAVE_SMP >>> + select SMP >>> + select SMP_ON_UP >>> + select HAVE_ARM_SCU >>> + select HAVE_ARM_TWD if SMP >>> + select ARM_ERRATA_458693 >>> + select ARM_ERRATA_720789 >>> + select ARM_ERRATA_742231 >>> + select ARM_ERRATA_754322 >>> + select ARM_ERRATA_764369 >>> + select ARM_ERRATA_794072 >>> + select PL310_ERRATA_588369 >>> + select PL310_ERRATA_727915 >>> + select USB_EHCI_ROOT_HUB_TT >>> + select USB_ARCH_HAS_HCD >>> + select USB_ARCH_HAS_EHCI >>> + select USB_EHCI_HCD >>> + select USB_ARCH_HAS_OHCI >>> + select USB_OHCI_HCD >>> + select USB >>> + select FIQ >>> + select CPU_USE_DOMAINS >>> + select GENERIC_CLOCKEVENTS >>> + select CLKDEV_LOOKUP >>> + select COMMON_CLK if OF >>> + select NPCM750_TIMER >>> + select MFD_SYSCON >>> + help >>> + Support for NPCM750 BMC CPU (Poleg). >>> + >>> + Nuvoton NPCM750 BMC based on the Cortex A9. >>> + >>> +endif >>> diff --git a/arch/arm/mach-npcm/Makefile b/arch/arm/mach-npcm/Makefile >>> new file mode 100644 >>> index
Re: [PATCH v4 1/3] arm: npcm: add basic support for Nuvoton BMCs
Sorry for sending again some mailing list rejected it due to HTML involved (althoug I tried Plain Text), Trying again. 2017-09-06 11:07 GMT+03:00 Brendan Higgins : > Adds basic support for the Nuvoton NPCM750 BMC. > > Signed-off-by: Brendan Higgins > --- > arch/arm/Kconfig | 2 + > arch/arm/Makefile| 1 + > arch/arm/mach-npcm/Kconfig | 50 + > arch/arm/mach-npcm/Makefile | 3 ++ > arch/arm/mach-npcm/headsmp.S | 17 + > arch/arm/mach-npcm/npcm7xx.c | 34 + > arch/arm/mach-npcm/platsmp.c | 89 > > 7 files changed, 196 insertions(+) > create mode 100644 arch/arm/mach-npcm/Kconfig > create mode 100644 arch/arm/mach-npcm/Makefile > create mode 100644 arch/arm/mach-npcm/headsmp.S > create mode 100644 arch/arm/mach-npcm/npcm7xx.c > create mode 100644 arch/arm/mach-npcm/platsmp.c > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 61a0cb15067e..05543f1cfbde 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -782,6 +782,8 @@ source "arch/arm/mach-netx/Kconfig" > > source "arch/arm/mach-nomadik/Kconfig" > > +source "arch/arm/mach-npcm/Kconfig" > + > source "arch/arm/mach-nspire/Kconfig" > > source "arch/arm/plat-omap/Kconfig" > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 47d3a1ab08d2..60ca50c7d762 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -191,6 +191,7 @@ machine-$(CONFIG_ARCH_MEDIATEK) += mediatek > machine-$(CONFIG_ARCH_MXS) += mxs > machine-$(CONFIG_ARCH_NETX)+= netx > machine-$(CONFIG_ARCH_NOMADIK) += nomadik > +machine-$(CONFIG_ARCH_NPCM)+= npcm > machine-$(CONFIG_ARCH_NSPIRE) += nspire > machine-$(CONFIG_ARCH_OXNAS) += oxnas > machine-$(CONFIG_ARCH_OMAP1) += omap1 > diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig > new file mode 100644 > index ..d47061855439 > --- /dev/null > +++ b/arch/arm/mach-npcm/Kconfig > @@ -0,0 +1,50 @@ > +menuconfig ARCH_NPCM > + bool "Nuvoton NPCM Architecture" > + select ARCH_REQUIRE_GPIOLIB > + select USE_OF > + select PINCTRL > + select PINCTRL_NPCM7XX > + > +if ARCH_NPCM > + > +comment "NPCMX50 CPU type" > + > +config CPU_NPCM750 > + depends on ARCH_NPCM && ARCH_MULTI_V7 > + bool "Support for NPCM750 BMC CPU (Poleg)" > + select CACHE_L2X0 > + select CPU_V7 > + select ARM_GIC > + select HAVE_SMP > + select SMP > + select SMP_ON_UP > + select HAVE_ARM_SCU > + select HAVE_ARM_TWD if SMP > + select ARM_ERRATA_458693 > + select ARM_ERRATA_720789 > + select ARM_ERRATA_742231 > + select ARM_ERRATA_754322 > + select ARM_ERRATA_764369 > + select ARM_ERRATA_794072 > + select PL310_ERRATA_588369 > + select PL310_ERRATA_727915 > + select USB_EHCI_ROOT_HUB_TT > + select USB_ARCH_HAS_HCD > + select USB_ARCH_HAS_EHCI > + select USB_EHCI_HCD > + select USB_ARCH_HAS_OHCI > + select USB_OHCI_HCD > + select USB > + select FIQ > + select CPU_USE_DOMAINS > + select GENERIC_CLOCKEVENTS > + select CLKDEV_LOOKUP > + select COMMON_CLK if OF > + select NPCM750_TIMER > + select MFD_SYSCON > + help > + Support for NPCM750 BMC CPU (Poleg). > + > + Nuvoton NPCM750 BMC based on the Cortex A9. > + > +endif > diff --git a/arch/arm/mach-npcm/Makefile b/arch/arm/mach-npcm/Makefile > new file mode 100644 > index ..78416055b854 > --- /dev/null > +++ b/arch/arm/mach-npcm/Makefile > @@ -0,0 +1,3 @@ > +AFLAGS_headsmp.o += -march=armv7-a > + > +obj-$(CONFIG_CPU_NPCM750) += npcm7xx.o platsmp.o headsmp.o > diff --git a/arch/arm/mach-npcm/headsmp.S b/arch/arm/mach-npcm/headsmp.S > new file mode 100644 > index ..9fccbbd49ed4 > --- /dev/null > +++ b/arch/arm/mach-npcm/headsmp.S > @@ -0,0 +1,17 @@ > +/* > + * Copyright 2017 Google, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > + > +ENTRY(npcm7xx_secondary_startup) > + safe_svcmode_maskall r0 I saw you answered to Florian Fainelli that the BootRom is not starting the secondary CPU in SVC mode. Are you sure? In our engineering npcm7xx revision, Z1, the BootRom indeed started to run it in IRQ mode but we fixed it in the production version, A1, (quite long time ago), I hope you didn't get an EB with Z1 you can check that in BootBlock console print: > ADC CLK is set to 2500 >Last reset was CORST >vgaioen=1 and mux gspi. >A1 <<== this is what you should see, if you see Z1 we need to replace your >EB > + > + b secondary_startup > +ENDPROC(npcm7xx_seconda
