date:20170113

RE: [PATCH 1/2] dt-bindings: document renesas-ostm timer

2017-01-13 Thread Chris Brandt

Hi Geert,

Thank you for your review.


On Friday, January 13, 2017, Geert Uytterhoeven wrote:
> > +The OSTM comes with 2 independent channels.
> > +We will use the first channel (OSTM0) as a free running clocksource
> > +and the second channel (OSTM1) as a interrupt driven clock event.
> > +
> > +Additionally we will use the clocksource channel (OTSM0) for the
> > +system schedule timer sched_clock().
> 
> The above two sentences are software policy, not hardware description.
> Hence they do not belong in the DT bindings document.
> You can move them to the commit description, though.

OK.


> > +Required Properties:
> > +
> > +  - compatible: must be one or more of the following:
> > +- "renesas,ostm-r7s72100" for the r7s72100 OSTM
> 
> Please use "renesas,r7s72100-ostm" instead, to match current practices.

If I look at the current r7s72100.dtsi:

compatible = "renesas,r7s72100-cpg-clocks", "renesas,rz-cpg-clocks";
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
compatible = "renesas,scif-r7s72100", "renesas,scif";
compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
compatible = "renesas,mmcif-r7s72100", "renesas,sh-mmcif";
compatible = "renesas,sdhi-r7s72100";

Is "renesas,xxx-r7s7210" the old way, and "renesas,r7s72100-xxx" is the new 
way??



> > +  - reg: base address and length of the registers block for each timer
> channel.
> > +There should be 2 sets of addresses, one for each channel.
> > +
> > +  - interrupts: interrupt specifiers for the timers. There should be 2
> > +interupts, one for each channel.
> > +
> > +  - clocks: a list of phandle + clock-specifier pairs, one for each
> entry
> > +channel. There should be 2 sets, one for each channel.
> 
> Are the channels truly independent? If yes, I think it's better to have
> two separate device nodes, one for each channel.
> Each channel has its own module clock, so using separate devices means
> Runtime PM can manage both channels through their module clocks as soon as
> you add a "power-domains" property pointing to the clock domain controller.


Yes, technically they are independent channels.
The way the driver is currently written, 1 instance of the driver uses 2 
channels
for different things. Ch0 will be set up as a 'clocksource', and ch1 will be 
set up
as a 'clock event'.

As in:

static int __init ostm_timer_init(struct ostm_device *ostm)
{
int ret = 0;

/* ostm0 will be clock source */
ret = ostm_init_clksrc(ostm);
if (ret)
goto err;

/* use ostm0 as system scheduling clock */
ret = ostm_init_sched_clock(>clksrc);
if (ret)
goto err;

/* ostm1 will be clock event */
ret = ostm_init_clkevt(ostm);
err:
return ret;
}



Do you think it would be better if a driver instance only does 1 thing: Either
'clocksource' or 'clock event'??
Then, I would make 2 ostm nodes and pass in the mode I would like it operate in?

For example:

 {
mode = "clocksource";
status = "okay";
};

 {
mode = "clock-event";
status = "okay";
};



Thank you,
Chris

[PATCH] net: constify mdiobb_ops structures

2017-01-13 Thread Bhumika Goyal

Declare mdiobb_ops structures as const as they are only stored in the
ops field of mdiobb_ctrl structures. This field is of type const, so
mdiobb_ops structures having this property can be declared const too.
Done using Coccinelle:

@r disable optional_qualifier@
identifier x;
position p;
@@
static struct mdiobb_ops x@p={...};

@ok@
struct bb_info bitbang;
struct ravb_private priv;
struct ax_device ax;
struct mdio_gpio_info bb;
identifier r.x;
position p;
@@
(
bitbang.ctrl.ops=@p
|
priv.mdiobb.ops=@p
|
ax.bb_ctrl.ops=@p
|
bb.ctrl.ops=@p
)

@bad@
position p != {r.p,ok.p};
identifier r.x;
@@
x@p

@depends on !bad disable optional_qualifier@
identifier r.x;
@@
+const
struct mdiobb_ops x;

Before and after size details:

File size before:
   textdata bss dec hex filename
  132931203  16   1451238b0 net/ethernet/8390/ax88796.o
File size after:
   textdata bss dec hex filename
  133571139  16   1451238b0 net/ethernet/8390/ax88796.o

File size before: 
   textdata bss dec hex filename
   1440 100   01540 604 freescale/fs_enet/mii-bitbang.o
File size after: Remains the same

File size before:
   textdata bss dec hex filename
  19000 192  16   192084b08 net/ethernet/renesas/ravb_main.o
File size after: Remains the same

File size before:
   textdata bss dec hex filename
  285011568   8   30077757d net/ethernet/renesas/sh_eth.o
File size after:
   textdata bss dec hex filename
  285651504   8   30077757d net/ethernet/renesas/sh_eth.o

File size before:
   textdata bss dec hex filename
   1859 248   02107 83b drivers/net/phy/mdio-gpio.o
File size after:
   textdata bss dec hex filename
   1915 192   02107 83b drivers/net/phy/mdio-gpio.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/ethernet/8390/ax88796.c  | 2 +-
 drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c| 2 +-
 drivers/net/phy/mdio-gpio.c  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c 
b/drivers/net/ethernet/8390/ax88796.c
index b0a3b85..e977671 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -585,7 +585,7 @@ static int ax_bb_get_data(struct mdiobb_ctrl *ctrl)
return reg_memr & AX_MEMR_MDI ? 1 : 0;
 }
 
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = ax_bb_mdc,
.set_mdio_dir = ax_bb_dir,
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c 
b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
index 1f015ed..c8e5d88 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
@@ -100,7 +100,7 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
in_be32(bitbang->dat);
 }
 
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = mdc,
.set_mdio_dir = mdio_dir,
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692..1b0acd1 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -171,7 +171,7 @@ static int ravb_get_mdio_data(struct mdiobb_ctrl *ctrl)
 }
 
 /* MDIO bus control struct */
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = ravb_set_mdc,
.set_mdio_dir = ravb_set_mdio_dir,
diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 00fafab..6ef5dd8 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1052,7 +1052,7 @@ static void sh_mdc_ctrl(struct mdiobb_ctrl *ctrl, int bit)
 }
 
 /* mdio bus control struct */
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = sh_mdc_ctrl,
.set_mdio_dir = sh_mmd_ctrl,
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 27ab630..97333d5 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -122,7 +122,7 @@ static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
gpio_set_value_cansleep(bitbang->mdc, what ^ bitbang->mdc_active_low);
 }
 
-static struct mdiobb_ops mdio_gpio_ops = {
+static const struct mdiobb_ops mdio_gpio_ops = {
.owner = THIS_MODULE,
.set_mdc = mdc_set,
.set_mdio_dir = mdio_dir,
-- 
1.9.1

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

2017-01-13 Thread Chris Brandt

Hi Geert,

On Friday, January 13, 2017, Geert Uytterhoeven wrote:
> > In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if
> > there are 2 clocks specified (in DT or platform data), it
> > automatically enables the 2nd clock (forever) and just uses the 1st
> clock as the on/off clock?
> 
> Of course the driver can handle the second interrupt, if you update the
> binding, and add support code for that...

Of course my idea is that I would only have to update the bindings for
RZ/A1...not any other device.

My only question is, today sh_mobile_sdhi.c uses this:

   priv->clk = devm_clk_get(>dev, NULL);

to get the clock. But if there is a 2nd clock...how do I know the
string id name to look to replace NULL with??

Or...for the RZ/A1 dtsi, should I just give the 2 clocks names:

clocks = <_clks R7S72100_CLK_SDHI00,
_clks R7S72100_CLK_SDHI01>;
clock-names = "core", "cd";

and then in the code do:

struct *cd_clk;
cd_clk = devm_clk_get(>dev, "cd");
if (cd_clk) {
clk_prepare_enable(cd_clk);
}

  (this simple 1-line fix patch is getting a lot more complicated)

Thanks,
Chris

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

2017-01-13 Thread Geert Uytterhoeven

Hi Chris,

On Fri, Jan 13, 2017 at 6:16 PM, Chris Brandt  wrote:
>> > But...that would make me think on boot it would be set to '01' (setting 
>> > prohibited).
>>
>> Yeah, running with enabled SDHI core and disabled card detect sounds silly.
>
> I just did some testing and with only 1 clock enabled ('01'), the core works 
> but
> card detect doesn't work. If you boot with the card in, you can read it fine, 
> but
> if you pull it...no removal is detected.
> As soon as I turn the other clock on ('00'), card detect magically starts 
> working.
>
> So from my experiments:
>
>   00: SD Host Interface 1 Module runs.
>   >> everything works
>
>   01: Setting prohibited.
>   >> core runs, but no card detect
>
>   10: Only card detect block in SD Host Interface 1 Module runs.
>   >> SDHI address space all 00s (core not running)
>
>   11: Clock supply to SD Host Interface 1 Module is halted
>   >> nothing works (of course)
>
>
>> So typically you want to use 10 when idle, and 00 when active.
>
> I wonder if that would mean the system would get a CD interrupt. Of course
> if no ISR registered (SDHI not enabled), the kernel would throw it away.
>
>
>> No there isn't. That's another reason why a full-fledged clock driver with
>> tables in C is a better idea than trying to describe all clocks in DT.
>> The new CPG/MSSR based driver (renesas-cpg-mssr.c) supports "critical
>> module clocks" through CLK_ENABLE_HAND_OFF. Unfortunately that flag hasn't
>> made it upstream, so I really should convert the driver to use the new
>> CLK_IS_CRITICAL instead...
>
> So basically at the moment you're tell me it's going to stay broke (unless 
> it's
> enabled in u-boot).
>
> In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if there
> are 2 clocks specified (in DT or platform data), it automatically enables
> the 2nd clock (forever) and just uses the 1st clock as the on/off clock?

Of course the driver can handle the second interrupt, if you update the
binding, and add support code for that...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

2017-01-13 Thread Chris Brandt

Hi Geert,


> > But...that would make me think on boot it would be set to '01' (setting 
> > prohibited).
> 
> Yeah, running with enabled SDHI core and disabled card detect sounds silly.

I just did some testing and with only 1 clock enabled ('01'), the core works but
card detect doesn't work. If you boot with the card in, you can read it fine, 
but
if you pull it...no removal is detected.
As soon as I turn the other clock on ('00'), card detect magically starts 
working.

So from my experiments:

  00: SD Host Interface 1 Module runs.
  >> everything works

  01: Setting prohibited.
  >> core runs, but no card detect

  10: Only card detect block in SD Host Interface 1 Module runs.
  >> SDHI address space all 00s (core not running)

  11: Clock supply to SD Host Interface 1 Module is halted
  >> nothing works (of course)


> So typically you want to use 10 when idle, and 00 when active.

I wonder if that would mean the system would get a CD interrupt. Of course
if no ISR registered (SDHI not enabled), the kernel would throw it away.


> No there isn't. That's another reason why a full-fledged clock driver with
> tables in C is a better idea than trying to describe all clocks in DT.
> The new CPG/MSSR based driver (renesas-cpg-mssr.c) supports "critical
> module clocks" through CLK_ENABLE_HAND_OFF. Unfortunately that flag hasn't
> made it upstream, so I really should convert the driver to use the new
> CLK_IS_CRITICAL instead...

So basically at the moment you're tell me it's going to stay broke (unless it's
enabled in u-boot).


In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if there
are 2 clocks specified (in DT or platform data), it automatically enables
the 2nd clock (forever) and just uses the 1st clock as the on/off clock?



Chris

Re: [git pull] pinctrl: sh-pfc: Updates for v4.11

2017-01-13 Thread Linus Walleij

On Fri, Jan 13, 2017 at 3:00 PM, Geert Uytterhoeven
 wrote:

> Hi Linus,
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
>   Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/sh-pfc-for-v4.11-tag1
>
> for you to fetch changes up to 0e4e4999aac16641f47699e8929693b83a7a4d64:

Pulled this in and pushed the branch to the build servers,
thanks!

Yours,
Linus Walleij

Re: [PATCH net] ravb: do not use zero-length alighment DMA request

2017-01-13 Thread Sergei Shtylyov


Hello!

On 01/13/2017 04:09 PM, Simon Horman wrote:


From: Masaru Nagai 

Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length


   OK but you forgot to use "descriptor" ISO "request" in the subject. :-)


followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] [ cut here ]
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 
4.10.0-rc3-1-gf13ad2db193f #162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: 80063b1f1900 task.stack: 80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [] lr : [] pstate: 
81c5
[   20.436019] sp : 80063a71f9b0
[   20.439327] x29: 80063a71f9b0 x28: 80063a20d500
[   20.444636] x27: 08ed5000 x26: 
[   20.449944] x25: 00067abe2adc x24: 
[   20.455252] x23: 0020 x22: 0001
[   20.460559] x21: 00175ffe x20: 80063b2a0010
[   20.465866] x19:  x18: cae6fb20
[   20.471173] x17: a09ba018 x16: 087c8b70
[   20.476480] x15: a084f588 x14: a09cfa14
[   20.481787] x13: cae87ff0 x12: 0063abe2
[   20.487098] x11: 08096360 x10: 80063abe2adc
[   20.492407] x9 :  x8 : 
[   20.497718] x7 :  x6 : 08ed50d0
[   20.503028] x5 :  x4 : 0001
[   20.508338] x3 :  x2 : 00067abe2adc
[   20.513648] x1 : bafff000 x0 : 
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0x80063a71c000)
[   20.526798] Stack: (0x80063a71f9b0 to 0x80063a72)
[   20.532543] f9a0:   80063a71fa30 
0839c680
[   20.540374] f9c0: 80063b2a0010 80063b2a0010 0001 

[   20.548204] f9e0: 006e 80063b23c000 80063b23c000 

[   20.556034] fa00: 80063b23c000 80063a20d500 00013b1f1900 

[   20.563864] fa20: 80063ffd18e0 80063b2a0010 80063a71fa60 
0839cd10
[   20.571694] fa40: 80063b2a0010  80063ffd18e0 
00067abe2adc
[   20.579524] fa60: 80063a71fa90 08096380 80063b2a0010 

[   20.587353] fa80:  0001 80063a71fac0 
0864f770
[   20.595184] faa0: 80063b23caf0   
0140
[   20.603014] fac0: 80063a71fb60 087e6498 80063a20d500 
80063b23c000
[   20.610843] fae0:  08daeaf0  
08daeb00
[   20.618673] fb00: 80063a71fc0c 08da7000 80063b23c090 
80063a44f000
[   20.626503] fb20:  08daeb00 80063a71fc0c 
08da7000
[   20.634333] fb40: 80063b23c090  80060037 
087e63d8
[   20.642163] fb60: 80063a71fbc0 08807510 80063a692400 
80063a20d500
[   20.649993] fb80: 80063a44f000 80063b23c000 80063a69249c 

[   20.657823] fba0:  80063a087800 80063b23c000 
80063a20d500
[   20.665653] fbc0: 80063a71fc10 087e67dc 80063a20d500 
80063a692400
[   20.673483] fbe0: 80063b23c000  80063a44f000 
80063a69249c
[   20.681312] fc00: 80063a5f1a10 00103a087800 80063a71fc70 
087e6b24
[   20.689142] fc20: 80063a5f1a80 80063a71fde8 000f 
05ea
[   20.696972] fc40: 80063a5f1a10  000f 
0887fbd0
[   20.704802] fc60: fff43a5f1a80  80063a71fc80 
08880240
[   20.712632] fc80: 80063a71fd90 087c7a34 80063afc7180 

[   20.720462] fca0: cae6fe18 0014 6000 
0015
[   20.728292] fcc0: 0123 00ce 088d2000 
80063b1f1900
[   20.736122] fce0: 8933 08e7cb80 80063a71fd80 
087c50a4
[   20.743951] fd00: 8933 08e7cb80 08e7cb80 
001e
[   20.751781] fd20:

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

2017-01-13 Thread Geert Uytterhoeven

Hi Chris,

On Fri, Jan 13, 2017 at 3:44 PM, Chris Brandt  wrote:
> On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
>> This is strange. There are two SDHI channels, but the STBCR12
>> documentation (all versions up to rev. 3.00) says the register has MSTP
>> bits for four SD host interfaces?
>>
>> Can you please enlighten me? Thanks!
>
> If you look in the rev 3.00 manual for RZ/A1H, in section
> "50.3.2 Card Detect/Write Protect", it says:
>
> * Power-Down mode at Card removal
>   SD Host Interface module is halted by the MSTP123 bit to MSTP120 bit in 
> Standby Control Register 12
>   (STBCR12). If these bits of each channel in STBCR12 are set to 10, low 
> power consumption is achieved at Card
>   removal. See section 55, Power-Down Modes
>
>
> So, there are 2 clock sources for each SDHI channel, and the setting
> Options are:
>   SD Host Interface 0 Module Stop
>   00: SD Host Interface 0 Module runs.
>   01: Setting prohibited.
>   10: Only card detect block in SD Host Interface 0 Module runs.
>   11: Clock supply to SD Host Interface 0 Module is halted

So typically you want to use 10 when idle, and 00 when active.

> Previously I've been running with '00' because I was turning EVERYTHING on
> in u-boot.
> Yesterday, I tested with just '10' and things seem to work OK
> for me.
>
> Since the sh_mobile_sdhi/tmio driver only allows for 1 clock per channel,
> '10' is my only choice for the DT.
>
> However, looking at a previous BSP for RZ/A1, the driver
> arch/arm/mach-shmobile/clock-r7s72100.c had this:
>
>
> static struct clk mstp_clks[MSTP_NR] = {
> [MSTP123] = SH_CLK_MSTP8(_clk, STBCR12, 3, 0), /* SDHI00 
> */
> [MSTP122] = SH_CLK_MSTP8(_clk, STBCR12, 2,
> CLK_ENABLE_ON_INIT),   /* SDHI01 
> */
> [MSTP121] = SH_CLK_MSTP8(_clk, STBCR12, 1, 0), /* SDHI10 
> */
> [MSTP120] = SH_CLK_MSTP8(_clk, STBCR12, 0,
> CLK_ENABLE_ON_INIT),   /* SDHI11 
> */
>
>
> But...that would make me think on boot it would be set to '01' (setting 
> prohibited).

Yeah, running with enabled SDHI core and disabled card detect sounds silly.

> I'm going to try and find if "setting prohibited" really just means:
> "you can set it this way...but nothing is really going to work unless you
> enable the other clock".
>
> If that is the case, is there a DT equivalent to "CLK_ENABLE_ON_INIT" that
> I can do for MSTP120(SDHI11) and MSTP120(SDHI01) so they are both cleared
> on boot???

No there isn't. That's another reason why a full-fledged clock driver with
tables in C is a better idea than trying to describe all clocks in DT.
The new CPG/MSSR based driver (renesas-cpg-mssr.c) supports "critical
module clocks" through CLK_ENABLE_HAND_OFF. Unfortunately that flag hasn't
made it upstream, so I really should convert the driver to use the new
CLK_IS_CRITICAL instead...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

RE: [PATCH 3/3] ARM: dts: rskrza1: add ostm DT support

2017-01-13 Thread Chris Brandt

Hi Geert and Sergei,

On Friday, January 13, 2017, Geert Uytterhoeven wrote:
> On Thu, Jan 12, 2017 at 8:01 PM, Chris Brandt 
> wrote:
> > --- a/arch/arm/boot/dts/r7s72100.dtsi
> > +++ b/arch/arm/boot/dts/r7s72100.dtsi
> > @@ -513,7 +513,8 @@
> > interrupts =  >   GIC_SPI 103 IRQ_TYPE_EDGE_RISING>;
> >
> > -   clocks = <_clks R7S72100_CLK_OSTM0>, <_clks
> R7S72100_CLK_OSTM1>;
> > +   clocks = <_clks R7S72100_CLK_OSTM0>,
> > +<_clks R7S72100_CLK_OSTM1>;
> 
> I think this change should be folded into "[PATCH 2/3] ARM: dts: r7s72100:
> add ostm to device tree" ;-)

Oops, I think I got things a little screwed up when git rebasing and
reordering and such.

Thanks for the review!

Chris

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

2017-01-13 Thread Chris Brandt

Hi Geert,

On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> This is strange. There are two SDHI channels, but the STBCR12
> documentation (all versions up to rev. 3.00) says the register has MSTP
> bits for four SD host interfaces?
> 
> Can you please enlighten me? Thanks!

If you look in the rev 3.00 manual for RZ/A1H, in section
"50.3.2 Card Detect/Write Protect", it says:

* Power-Down mode at Card removal
  SD Host Interface module is halted by the MSTP123 bit to MSTP120 bit in 
Standby Control Register 12
  (STBCR12). If these bits of each channel in STBCR12 are set to 10, low power 
consumption is achieved at Card
  removal. See section 55, Power-Down Modes

So, there are 2 clock sources for each SDHI channel, and the setting
Options are:
  SD Host Interface 0 Module Stop
  00: SD Host Interface 0 Module runs.
  01: Setting prohibited.
  10: Only card detect block in SD Host Interface 0 Module runs.
  11: Clock supply to SD Host Interface 0 Module is halted

Previously I've been running with '00' because I was turning EVERYTHING on
in u-boot.
Yesterday, I tested with just '10' and things seem to work OK
for me.

Since the sh_mobile_sdhi/tmio driver only allows for 1 clock per channel,
'10' is my only choice for the DT.

However, looking at a previous BSP for RZ/A1, the driver 
arch/arm/mach-shmobile/clock-r7s72100.c had this:

static struct clk mstp_clks[MSTP_NR] = {
[MSTP123] = SH_CLK_MSTP8(_clk, STBCR12, 3, 0), /* SDHI00 */
[MSTP122] = SH_CLK_MSTP8(_clk, STBCR12, 2,
CLK_ENABLE_ON_INIT),   /* SDHI01 */
[MSTP121] = SH_CLK_MSTP8(_clk, STBCR12, 1, 0), /* SDHI10 */
[MSTP120] = SH_CLK_MSTP8(_clk, STBCR12, 0,
CLK_ENABLE_ON_INIT),   /* SDHI11 */

But...that would make me think on boot it would be set to '01' (setting 
prohibited).

I'm going to try and find if "setting prohibited" really just means:
"you can set it this way...but nothing is really going to work unless you
enable the other clock".

If that is the case, is there a DT equivalent to "CLK_ENABLE_ON_INIT" that
I can do for MSTP120(SDHI11) and MSTP120(SDHI01) so they are both cleared
on boot???

Thanks,
Chris

[git pull] clk: renesas: Updates for v4.11

2017-01-13 Thread Geert Uytterhoeven

Hi Mike, Stephen,

The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/clk-renesas-for-v4.11-tag1

for you to fetch changes up to e6bdf28eff475a026b922abe78ae710e7179bdf7:

  clk: renesas: r8a7796: Add MSIOF controller clocks (2016-12-27 10:56:08 +0100)


clk: renesas: Updates for v4.11

  - Add CAN and MSIOF related clocks for R-Car M3-W.

Thanks for pulling!

Chris Paterson (3):
  clk: renesas: r8a7796: Add CAN peripheral clock
  clk: renesas: r8a7796: Add CANFD clock
  clk: renesas: r8a7796: Add CAN FD peripheral clock

Hiromitsu Yamasaki (1):
  clk: renesas: r8a7796: Add MSIOF controller clocks

 drivers/clk/renesas/r8a7796-cpg-mssr.c | 9 +
 1 file changed, 9 insertions(+)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH net] ravb: do not use zero-length alighment DMA request

2017-01-13 Thread Simon Horman

On Fri, Jan 13, 2017 at 02:09:00PM +0100, Simon Horman wrote:
> From: Masaru Nagai 
> 
> Due to alignment requirements of the hardware transmissions are split into
> two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
> followed by a descriptor for rest of the packet.
> 
> In the case of IP packets the first descriptor will never be zero due to
> the way that the stack aligns buffers for IP packets. However, for non-IP
> packets it may be zero.

...

Apologies, I forgot to include v2 in the subject prefix.

[PATCH net] ravb: do not use zero-length alighment DMA request

2017-01-13 Thread Simon Horman

From: Masaru Nagai 

Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] [ cut here ]
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 
4.10.0-rc3-1-gf13ad2db193f #162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: 80063b1f1900 task.stack: 80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [] lr : [] pstate: 
81c5
[   20.436019] sp : 80063a71f9b0
[   20.439327] x29: 80063a71f9b0 x28: 80063a20d500
[   20.444636] x27: 08ed5000 x26: 
[   20.449944] x25: 00067abe2adc x24: 
[   20.455252] x23: 0020 x22: 0001
[   20.460559] x21: 00175ffe x20: 80063b2a0010
[   20.465866] x19:  x18: cae6fb20
[   20.471173] x17: a09ba018 x16: 087c8b70
[   20.476480] x15: a084f588 x14: a09cfa14
[   20.481787] x13: cae87ff0 x12: 0063abe2
[   20.487098] x11: 08096360 x10: 80063abe2adc
[   20.492407] x9 :  x8 : 
[   20.497718] x7 :  x6 : 08ed50d0
[   20.503028] x5 :  x4 : 0001
[   20.508338] x3 :  x2 : 00067abe2adc
[   20.513648] x1 : bafff000 x0 : 
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0x80063a71c000)
[   20.526798] Stack: (0x80063a71f9b0 to 0x80063a72)
[   20.532543] f9a0:   80063a71fa30 
0839c680
[   20.540374] f9c0: 80063b2a0010 80063b2a0010 0001 

[   20.548204] f9e0: 006e 80063b23c000 80063b23c000 

[   20.556034] fa00: 80063b23c000 80063a20d500 00013b1f1900 

[   20.563864] fa20: 80063ffd18e0 80063b2a0010 80063a71fa60 
0839cd10
[   20.571694] fa40: 80063b2a0010  80063ffd18e0 
00067abe2adc
[   20.579524] fa60: 80063a71fa90 08096380 80063b2a0010 

[   20.587353] fa80:  0001 80063a71fac0 
0864f770
[   20.595184] faa0: 80063b23caf0   
0140
[   20.603014] fac0: 80063a71fb60 087e6498 80063a20d500 
80063b23c000
[   20.610843] fae0:  08daeaf0  
08daeb00
[   20.618673] fb00: 80063a71fc0c 08da7000 80063b23c090 
80063a44f000
[   20.626503] fb20:  08daeb00 80063a71fc0c 
08da7000
[   20.634333] fb40: 80063b23c090  80060037 
087e63d8
[   20.642163] fb60: 80063a71fbc0 08807510 80063a692400 
80063a20d500
[   20.649993] fb80: 80063a44f000 80063b23c000 80063a69249c 

[   20.657823] fba0:  80063a087800 80063b23c000 
80063a20d500
[   20.665653] fbc0: 80063a71fc10 087e67dc 80063a20d500 
80063a692400
[   20.673483] fbe0: 80063b23c000  80063a44f000 
80063a69249c
[   20.681312] fc00: 80063a5f1a10 00103a087800 80063a71fc70 
087e6b24
[   20.689142] fc20: 80063a5f1a80 80063a71fde8 000f 
05ea
[   20.696972] fc40: 80063a5f1a10  000f 
0887fbd0
[   20.704802] fc60: fff43a5f1a80  80063a71fc80 
08880240
[   20.712632] fc80: 80063a71fd90 087c7a34 80063afc7180 

[   20.720462] fca0: cae6fe18 0014 6000 
0015
[   20.728292] fcc0: 0123 00ce 088d2000 
80063b1f1900
[   20.736122] fce0: 8933 08e7cb80 80063a71fd80 
087c50a4
[   20.743951] fd00: 8933 08e7cb80 08e7cb80 
001e
[   20.751781] fd20: 80063a71fe4c 0300 0123 

[   20.759611] fd40:  80063b1f 000e

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

2017-01-13 Thread Geert Uytterhoeven

Hi Robin,

On Fri, Jan 13, 2017 at 1:17 PM, Robin Murphy  wrote:
> On 13/01/17 11:59, Geert Uytterhoeven wrote:
>> On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy  wrote:
>>> On 13/01/17 11:07, Geert Uytterhoeven wrote:
 Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
 This allows to allocate physically contiguous DMA buffers on arm64
 systems with an IOMMU.
>>>
>>> Can anyone explain what this attribute is actually used for? I've never
>>> quite figured it out.
>>
>> My understanding is that DMA_ATTR_FORCE_CONTIGUOUS is needed when using
>> an IOMMU but wanting the buffers to be both contiguous in IOVA space and
>> physically contiguous to allow passing to devices without IOMMU.
>>
>> Main users are graphic and remote processors.
>
> Sure, I assumed it must be to do with buffer sharing, but the systems
> I'm aware of which have IOMMUs in their media subsystems tend to have
> them in front of every IP block involved, so I was curious as to what
> bit of non-IOMMU hardware wanted to play too. The lone in-tree use in
> the Exynos DRM driver was never very revealing, and the new one I see in
> the Qualcomm PIL driver frankly looks redundant to me.

I'll let the GPU-literate people comment on that...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] dmaengine: rcar-dmac: unmap slave resource when channel is freed

2017-01-13 Thread Vinod Koul

On Wed, Jan 11, 2017 at 03:39:31PM +0100, Niklas Söderlund wrote:
> The slave mapping should be removed together with other channel
> resources when the channel is freed. If it's not unmapped it will hang
> around forever after the channel is freed.

Applied, thanks


-- 
~Vinod

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

2017-01-13 Thread Robin Murphy

On 13/01/17 11:59, Geert Uytterhoeven wrote:
> Hi Robin,
> 
> On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy  wrote:
>> On 13/01/17 11:07, Geert Uytterhoeven wrote:
>>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
>>> This allows to allocate physically contiguous DMA buffers on arm64
>>> systems with an IOMMU.
>>
>> Can anyone explain what this attribute is actually used for? I've never
>> quite figured it out.
> 
> My understanding is that DMA_ATTR_FORCE_CONTIGUOUS is needed when using
> an IOMMU but wanting the buffers to be both contiguous in IOVA space and
> physically contiguous to allow passing to devices without IOMMU.
> 
> Main users are graphic and remote processors.

Sure, I assumed it must be to do with buffer sharing, but the systems
I'm aware of which have IOMMUs in their media subsystems tend to have
them in front of every IP block involved, so I was curious as to what
bit of non-IOMMU hardware wanted to play too. The lone in-tree use in
the Exynos DRM driver was never very revealing, and the new one I see in
the Qualcomm PIL driver frankly looks redundant to me.

Robin.

>>> --- a/drivers/iommu/dma-iommu.c
>>> +++ b/drivers/iommu/dma-iommu.c
> 
>>> @@ -265,6 +272,20 @@ static struct page **__iommu_dma_alloc_pages(unsigned 
>>> int count,
>>>   /* IOMMU can map any pages, so himem can also be used here */
>>>   gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
>>>
>>> + if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
>>> + int order = get_order(count << PAGE_SHIFT);
>>> + struct page *page;
>>> +
>>> + page = dma_alloc_from_contiguous(dev, count, order);
>>> + if (!page)
>>> + return NULL;
>>> +
>>> + while (count--)
>>> + pages[i++] = page++;
>>> +
>>> + return pages;
>>> + }
>>> +
>>
>> This is really yuck. Plus it's entirely pointless to go through the
>> whole page array/scatterlist dance when we know the buffer is going to
>> be physically contiguous - it should just be allocate, map, done. I'd
>> much rather see standalone iommu_dma_{alloc,free}_contiguous()
>> functions, and let the arch code handle dispatching appropriately.
> 
> Fair enough.
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
>

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

2017-01-13 Thread Simon Horman

On Thu, Jan 12, 2017 at 07:33:51PM +0300, Sergei Shtylyov wrote:
> On 01/12/2017 04:18 PM, Simon Horman wrote:
> 
> >...
> >
>   Here, it stop once an untransmitted buffer is encountered...
> >>>
> >>>Yes, I see that now.
> >>>
> >>>I wonder if we should:
> >>>
> >>>a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
> >>>  (current behaviour) or all buffers (new behaviour).
> >>>b) provide a different version of this loop in ravb_ring_free()
> >>>
> >>>What are your thoughts?
> >>
> >>   I'm voting for (b).
> >
> >Ok, something like this?
> >
> >@@ -215,6 +225,30 @@ static void ravb_ring_free(struct net_device *ndev, int 
> >q)
> > }
> >
> > if (priv->tx_ring[q]) {
> >+for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; 
> >priv->dirty_tx[q]++) {
> 
>You're still copying the loop logic from ravb_tx_free() while we (I
> think) need a simple loop over all the descriptor ring.

I thought the above may be better as it seems to me that only descriptors
in the range described above could need to be freed. But simpler may be
better. And I also noticed several other problems with the code I posted
yesterday afternoon.

How about something like this?

@@ -215,6 +225,17 @@ static void ravb_ring_free(struct net_device *ndev, int q)
}
 
if (priv->tx_ring[q]) {
+   for (i = 0; i < priv->num_tx_ring[q] * NUM_TX_DESC; i++) {
+   struct ravb_tx_desc *desc = >tx_ring[q][i];
+
+   if (desc->die_dt != DT_EEMPTY) {
+   u32 size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+
+   dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(desc->dptr),
+size, DMA_TO_DEVICE);
+   }
+   }
ring_size = sizeof(struct ravb_tx_desc) *
(priv->num_tx_ring[q] * NUM_TX_DESC + 1);
dma_free_coherent(ndev->dev.parent, ring_size, priv->tx_ring[q],

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

2017-01-13 Thread Geert Uytterhoeven

Hi Robin,

On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy  wrote:
> On 13/01/17 11:07, Geert Uytterhoeven wrote:
>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
>> This allows to allocate physically contiguous DMA buffers on arm64
>> systems with an IOMMU.
>
> Can anyone explain what this attribute is actually used for? I've never
> quite figured it out.

My understanding is that DMA_ATTR_FORCE_CONTIGUOUS is needed when using
an IOMMU but wanting the buffers to be both contiguous in IOVA space and
physically contiguous to allow passing to devices without IOMMU.

Main users are graphic and remote processors.

>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c

>> @@ -265,6 +272,20 @@ static struct page **__iommu_dma_alloc_pages(unsigned 
>> int count,
>>   /* IOMMU can map any pages, so himem can also be used here */
>>   gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
>>
>> + if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
>> + int order = get_order(count << PAGE_SHIFT);
>> + struct page *page;
>> +
>> + page = dma_alloc_from_contiguous(dev, count, order);
>> + if (!page)
>> + return NULL;
>> +
>> + while (count--)
>> + pages[i++] = page++;
>> +
>> + return pages;
>> + }
>> +
>
> This is really yuck. Plus it's entirely pointless to go through the
> whole page array/scatterlist dance when we know the buffer is going to
> be physically contiguous - it should just be allocate, map, done. I'd
> much rather see standalone iommu_dma_{alloc,free}_contiguous()
> functions, and let the arch code handle dispatching appropriately.

Fair enough.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

2017-01-13 Thread Robin Murphy

On 13/01/17 11:07, Geert Uytterhoeven wrote:
> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
> This allows to allocate physically contiguous DMA buffers on arm64
> systems with an IOMMU.

Can anyone explain what this attribute is actually used for? I've never
quite figured it out.

> Note that as this uses the CMA allocator, setting this attribute has a
> runtime-dependency on CONFIG_DMA_CMA, just like on arm32.
> 
> For arm64 systems using swiotlb, no changes are needed to support the
> allocation of physically contiguous DMA buffers:
>   - swiotlb always uses physically contiguous buffers (up to
> IO_TLB_SEGSIZE = 128 pages),
>   - arm64's __dma_alloc_coherent() already calls
> dma_alloc_from_contiguous() when CMA is available.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  arch/arm64/mm/dma-mapping.c |  4 ++--
>  drivers/iommu/dma-iommu.c   | 44 ++--
>  include/linux/dma-iommu.h   |  2 +-
>  3 files changed, 37 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 1d7d5d2881db7c19..5fba14a21163e41f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -589,7 +589,7 @@ static void *__iommu_alloc_attrs(struct device *dev, 
> size_t size,
>   addr = dma_common_pages_remap(pages, size, VM_USERMAP, prot,
> __builtin_return_address(0));
>   if (!addr)
> - iommu_dma_free(dev, pages, iosize, handle);
> + iommu_dma_free(dev, pages, iosize, handle, attrs);
>   } else {
>   struct page *page;
>   /*
> @@ -642,7 +642,7 @@ static void __iommu_free_attrs(struct device *dev, size_t 
> size, void *cpu_addr,
>  
>   if (WARN_ON(!area || !area->pages))
>   return;
> - iommu_dma_free(dev, area->pages, iosize, );
> + iommu_dma_free(dev, area->pages, iosize, , attrs);
>   dma_common_free_remap(cpu_addr, size, VM_USERMAP);
>   } else {
>   iommu_dma_unmap_page(dev, handle, iosize, 0, 0);
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 2db0d641cf4505b5..b991e8dc35c5 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct iommu_dma_msi_page {
>   struct list_headlist;
> @@ -238,15 +239,21 @@ static void __iommu_dma_unmap(struct iommu_domain 
> *domain, dma_addr_t dma_addr)
>   __free_iova(iovad, iova);
>  }
>  
> -static void __iommu_dma_free_pages(struct page **pages, int count)
> +static void __iommu_dma_free_pages(struct device *dev, struct page **pages,
> +int count, unsigned long attrs)
>  {
> - while (count--)
> - __free_page(pages[count]);
> + if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
> + dma_release_from_contiguous(dev, pages[0], count);
> + } else {
> + while (count--)
> + __free_page(pages[count]);
> + }
>   kvfree(pages);
>  }
>  
> -static struct page **__iommu_dma_alloc_pages(unsigned int count,
> - unsigned long order_mask, gfp_t gfp)
> +static struct page **__iommu_dma_alloc_pages(struct device *dev,
> + unsigned int count, unsigned long order_mask, gfp_t gfp,
> + unsigned long attrs)
>  {
>   struct page **pages;
>   unsigned int i = 0, array_size = count * sizeof(*pages);
> @@ -265,6 +272,20 @@ static struct page **__iommu_dma_alloc_pages(unsigned 
> int count,
>   /* IOMMU can map any pages, so himem can also be used here */
>   gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
>  
> + if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
> + int order = get_order(count << PAGE_SHIFT);
> + struct page *page;
> +
> + page = dma_alloc_from_contiguous(dev, count, order);
> + if (!page)
> + return NULL;
> +
> + while (count--)
> + pages[i++] = page++;
> +
> + return pages;
> + }
> +

This is really yuck. Plus it's entirely pointless to go through the
whole page array/scatterlist dance when we know the buffer is going to
be physically contiguous - it should just be allocate, map, done. I'd
much rather see standalone iommu_dma_{alloc,free}_contiguous()
functions, and let the arch code handle dispatching appropriately.

Robin.

>   while (count) {
>   struct page *page = NULL;
>   unsigned int order_size;
> @@ -294,7 +315,7 @@ static struct page **__iommu_dma_alloc_pages(unsigned int 
> count,
>   __free_pages(page, order);
>   }
>   if (!page) {
> - __iommu_dma_free_pages(pages, i);
> +

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

2017-01-13 Thread kbuild test robot

Hi Nikita,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc3 next-20170112]
[cannot apply to arm64/for-next/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nikita-Yushchenko/dma-mapping-let-arch-know-origin-of-dma-range-passed-to-arch_setup_dma_ops/20170113-152733
config: x86_64-randconfig-u0-01131618 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/acpi/scan.c: In function 'acpi_dma_configure':
>> drivers/acpi/scan.c:1388:2: error: too many arguments to function 
>> 'arch_setup_dma_ops'
 arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, false, iommu,
 ^~
   In file included from drivers/acpi/scan.c:15:0:
   include/linux/dma-mapping.h:611:20: note: declared here
static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base,
   ^~

vim +/arch_setup_dma_ops +1388 drivers/acpi/scan.c

  1382  iommu = iort_iommu_configure(dev);
  1383  
  1384  /*
  1385   * Assume dma valid range starts at 0 and covers the whole
  1386   * coherent_dma_mask.
  1387   */
> 1388  arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, false, 
> iommu,
  1389 attr == DEV_DMA_COHERENT);
  1390  }
  1391  EXPORT_SYMBOL_GPL(acpi_dma_configure);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

2017-01-13 Thread kbuild test robot

Hi Nikita,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc3 next-20170112]
[cannot apply to arm64/for-next/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nikita-Yushchenko/dma-mapping-let-arch-know-origin-of-dma-range-passed-to-arch_setup_dma_ops/20170113-152733
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   arch/arm64/mm/dma-mapping.c: In function 'dma_set_mask':
>> arch/arm64/mm/dma-mapping.c:210:6: error: 'mask' undeclared (first use in 
>> this function)
 if (mask > dev->archdata.parent_dma_mask)
 ^~~~
   arch/arm64/mm/dma-mapping.c:210:6: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/mask +210 arch/arm64/mm/dma-mapping.c

   204  }
   205  
   206  int dma_set_mask(struct device *dev, u64 dma_mask)
   207  {
   208  const struct dma_map_ops *ops = get_dma_ops(dev);
   209  
 > 210  if (mask > dev->archdata.parent_dma_mask)
   211  mask = dev->archdata.parent_dma_mask;
   212  
   213  if (ops->set_dma_mask)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v4 2/2] dt-bindings: iio: document MAX11100 ADC

2017-01-13 Thread Jacopo Mondi

Add device tree bindings documentation for Maxim MAX11100 single-channel
ADC

Signed-off-by: Jacopo Mondi 
---
 .../devicetree/bindings/iio/adc/max11100.txt  | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/max11100.txt 
b/Documentation/devicetree/bindings/iio/adc/max11100.txt
new file mode 100644
index 000..ad0bc31
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/max11100.txt
@@ -0,0 +1,19 @@
+* Maxim max11100 Analog to Digital Converter (ADC)
+
+Required properties:
+  - compatible: Should be "maxim,max11100"
+  - reg: the adc unit address
+  - vref-supply: phandle to the regulator that provides reference voltage
+
+Optional properties:
+  - spi-max-frequency: SPI maximum frequency
+
+Example:
+
+max11100: adc@0 {
+compatible = "maxim,max11100";
+reg = <0>;
+vref-supply = <_vref>;
+spi-max-frequency = <24>;
+};
+
-- 
2.7.4

[PATCH v4 1/2] iio: adc: Add Maxim MAX11100 driver

2017-01-13 Thread Jacopo Mondi

From: Jacopo Mondi 

Add iio driver for Maxim MAX11100 single-channel ADC.

Signed-off-by: Jacopo Mondi 
Tested-by: Marek Vasut 

---
 drivers/iio/adc/Kconfig|   9 +++
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/max11100.c | 187 +
 3 files changed, 197 insertions(+)
 create mode 100644 drivers/iio/adc/max11100.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 38bc319..c32bc7a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -307,6 +307,15 @@ config MAX1027
  To compile this driver as a module, choose M here: the module will be
  called max1027.
 
+config MAX11100
+   tristate "Maxim max11100 ADC driver"
+   depends on SPI_MASTER
+   help
+ Say yes here to build support for Maxim max11100 SPI ADC
+
+ To compile this driver as a module, choose M here: the module will be
+ called max11100.
+
 config MAX1363
tristate "Maxim max1363 ADC driver"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index d36c4be..5684369 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
 obj-$(CONFIG_LTC2485) += ltc2485.o
 obj-$(CONFIG_MAX1027) += max1027.o
+obj-$(CONFIG_MAX11100) += max11100.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
new file mode 100644
index 000..78e2a45
--- /dev/null
+++ b/drivers/iio/adc/max11100.c
@@ -0,0 +1,187 @@
+/*
+ * iio/adc/max11100.c
+ * Maxim max11100 ADC Driver with IIO interface
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2016 Jacopo Mondi
+ *
+ * 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 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * LSB is the ADC single digital step
+ * 1 LSB = (vref_mv / 2 ^ 16)
+ *
+ * LSB is used to calculate analog voltage value
+ * from the number of ADC steps count
+ *
+ * Ain = (count * LSB)
+ */
+#define MAX11100_LSB_DIV   (1 << 16)
+
+struct max11100_state {
+   const struct max11100_chip_desc *desc;
+   struct regulator *vref_reg;
+   struct spi_device *spi;
+};
+
+static struct iio_chan_spec max11100_channels[] = {
+   { /* [0] */
+   .type = IIO_VOLTAGE,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+   },
+};
+
+static struct max11100_chip_desc {
+   unsigned int num_chan;
+   const struct iio_chan_spec *channels;
+} max11100_desc = {
+   .num_chan = ARRAY_SIZE(max11100_channels),
+   .channels = max11100_channels,
+};
+
+static int max11100_read_single(struct iio_dev *indio_dev, int *val)
+{
+   int ret;
+   struct max11100_state *state = iio_priv(indio_dev);
+   uint8_t buffer[3];
+
+   ret = spi_read(state->spi, buffer, sizeof(buffer));
+   if (ret) {
+   dev_err(_dev->dev, "SPI transfer failed\n");
+   return ret;
+   }
+
+   /* the first 8 bits sent out from ADC must be 0s */
+   if (buffer[0]) {
+   dev_err(_dev->dev, "Invalid value: buffer[0] != 0\n");
+   return -EINVAL;
+   }
+
+   *val = (buffer[1] << 8) | buffer[2];
+
+   return 0;
+}
+
+static int max11100_read_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int *val, int *val2, long info)
+{
+   int ret, vref_uv;
+   struct max11100_state *state = iio_priv(indio_dev);
+
+   switch (info) {
+   case IIO_CHAN_INFO_RAW:
+   ret = max11100_read_single(indio_dev, val);
+   if (ret)
+   return ret;
+
+   return IIO_VAL_INT;
+
+   case IIO_CHAN_INFO_SCALE:
+   vref_uv = regulator_get_voltage(state->vref_reg);
+   if (vref_uv < 0)
+   /* dummy regulator "get_voltage" returns -EINVAL */
+   return -EINVAL;
+
+   *val =  vref_uv / 1000;
+   *val2 = MAX11100_LSB_DIV;
+   return IIO_VAL_FRACTIONAL;
+   }
+
+   return -EINVAL;
+}
+
+static const struct iio_info max11100_info = {
+   .driver_module = THIS_MODULE,
+   .read_raw = max11100_read_raw,
+};
+
+static int max11100_probe(struct spi_device *spi)
+{
+   int ret;
+   struct iio_dev *indio_dev;
+   struct max11100_state *state;
+
+   indio_dev = devm_iio_device_alloc(>dev, sizeof(*state));
+   if

[PATCH v4 0/2] iio: adc: Add Maxim MAX11100 driver

2017-01-13 Thread Jacopo Mondi

Hello,
   sending out v4 splitting device tree bindings documentation and actual ADC
driver.
No changes in driver code since v3.

Same question for iio maintainers here:
I would like to have clarified the measure unit returned by read_raw().
Currently (value_raw * value_scale) return the ADC input value in mV.
While testing the patch I've been questioned if that should not actually
be in uV. This is easily achievable making _scale return a value in uV.
I have found no mention of this in the ABI documentation as it speaks of
generic voltage.
Can we have a final word on this?

Thanks Marek for having tested this.

v1 -> v2:
- incorporated pmeerw's review comments
- retrieve vref from dts and use that to convert read_raw result
  to mV
- add device tree bindings documentation

v2 -> v3:
- add _SCALE bit of read_raw function and change _RAW bit accordingly
- call regulator_get_voltage when accessing the _SCALE part of read_raw
  and not during probe
- add back remove function as regulator has to be disabled when detaching
  the module. Do not use devm_ version of iio_register/unregister functions
  anymore but do unregister in the remove.
- remove mutex as access to SPI bus is protected by SPI core. Thanks marex

v3 -> v4:
- split device tree binding documentation and actual ADC driver
- add "reg" to the list of required properties and use a better
  namimg for the adc device node in bindings documentation as suggested
  by Geert.

Jacopo Mondi (2):
  iio: adc: Add Maxim MAX11100 driver
  dt-bindings: iio: document MAX11100 ADC

 .../devicetree/bindings/iio/adc/max11100.txt   |  19 +++
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/max11100.c | 187 +
 4 files changed, 216 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.txt
 create mode 100644 drivers/iio/adc/max11100.c

-- 
2.7.4

Re: [PATCH 3/3] ARM: dts: rskrza1: add ostm DT support

2017-01-13 Thread Sergei Shtylyov


Hello!

On 1/12/2017 10:01 PM, Chris Brandt wrote:


Signed-off-by: Chris Brandt 

[...]

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 247bbe0..974c084 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -513,7 +513,8 @@
interrupts = ;

-   clocks = <_clks R7S72100_CLK_OSTM0>, <_clks 
R7S72100_CLK_OSTM1>;
+   clocks = <_clks R7S72100_CLK_OSTM0>,
+<_clks R7S72100_CLK_OSTM1>;


   Unintended change?


status = "disabled";
};
 };


MBR, Sergei

Re: [PATCH v3] iio: adc: Add Maxim MAX11100 driver

2017-01-13 Thread jacopo mondi


Hi Geert,

On 13/01/2017 09:27, Geert Uytterhoeven wrote:

Hi Jacopo,

On Thu, Jan 12, 2017 at 11:51 PM, Jacopo Mondi
 wrote:

From: Jacopo Mondi 

Add IIO driver for Maxim MAX11100 single-channel ADC.
Add DT bindings documentation.

Signed-off-by: Jacopo Mondi 
Tested-by: Marek Vasut 



 .../devicetree/bindings/iio/adc/max11100.txt   |  17 ++
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/max11100.c | 187 +
 4 files changed, 214 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.txt
 create mode 100644 drivers/iio/adc/max11100.c


When submitting a new driver with DT bindings, please split off the
DT binding docs in a separate patch, and CC devicet...@vger.kernel.org,
Rob Herring, and Mark Rutland.

scripts/get_maintainer.pl is your friend ;-)

Reviewing DT binding docs only...



Let me send this out again split in 2...
people reviewing the adc driver can comment here or in v4, as they prefer

Thanks
   j



new file mode 100644
index 000..6877c11
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/max11100.txt
@@ -0,0 +1,17 @@
+* Maxim max11100 Analog to Digital Converter (ADC)
+
+Required properties:
+  - compatible: Should be "maxim,max11100"
+  - vref-supply: phandle to the regulator that provides reference voltage


As this is an SPI slave device, there should be a "reg" property.


+
+Optional properties:
+  - spi-max-frequency: SPI maximum frequency
+
+Example:
+
+adc0: max11100@0 {


As per ePAPR Section 2.2.2 "Generic Names Recommendation", node names
should be "somewhat generic, reflecting the function of the device and
not its precise programming model.".
The label property defines a human readable string describing a device.
Hence "max11100: adc@0" is more appropriate.


+compatible = "maxim,max11100";


Missing "reg = <0>;" matching the unit-address above.


+vref-supply = <_vref>;
+spi-max-frequency = <24>;
+};


Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 3/3] ARM: dts: rskrza1: add ostm DT support

2017-01-13 Thread Geert Uytterhoeven

Hi Chris,

On Thu, Jan 12, 2017 at 8:01 PM, Chris Brandt  wrote:
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -513,7 +513,8 @@
> interrupts =GIC_SPI 103 IRQ_TYPE_EDGE_RISING>;
>
> -   clocks = <_clks R7S72100_CLK_OSTM0>, <_clks 
> R7S72100_CLK_OSTM1>;
> +   clocks = <_clks R7S72100_CLK_OSTM0>,
> +<_clks R7S72100_CLK_OSTM1>;

I think this change should be folded into "[PATCH 2/3] ARM: dts: r7s72100: add
ostm to device tree" ;-)

> status = "disabled";
> };
>  };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

2017-01-13 Thread Wolfram Sang

> Sorry for missing these.
> I have queued them up for v4.11.

Thank you!



signature.asc
Description: PGP signature

Re: [PATCH 1/3] ARM: dts: r7s72100: add ostm clock to device tree

2017-01-13 Thread Geert Uytterhoeven

On Thu, Jan 12, 2017 at 8:01 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

2017-01-13 Thread Simon Horman

On Thu, Jan 12, 2017 at 11:43:53PM +0100, Wolfram Sang wrote:
> On Wed, Jan 04, 2017 at 06:39:52PM +0100, Wolfram Sang wrote:
> > Simon,
> > 
> > as Ulf picked up the driver patches for HS200 support, it is now safe to 
> > pick
> > up the DTS patches, I'd say? I rebased them to the dt-for-4.11 branch.
> > 
> > All the best,
> > 
> >Wolfram
> > 
> > 
> > Wolfram Sang (2):
> >   arm64: dts: r8a7795: enable HS200 for eMMC
> >   arm64: dts: r8a7796: enable HS200 for eMMC
> > 
> >  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
> >  arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 1 +
> >  2 files changed, 2 insertions(+)
> 
> Ping :)

Sorry for missing these.
I have queued them up for v4.11.

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

2017-01-13 Thread Simon Horman

On Thu, Jan 12, 2017 at 08:34:26PM +, Chris Brandt wrote:
> Hi Geert,
> 
> On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> > This is strange. There are two SDHI channels, but the STBCR12
> > documentation (all versions up to rev. 3.00) says the register has MSTP
> > bits for four SD host interfaces?
> > 
> > Can you please enlighten me? Thanks!
> 
> Ya, I saw that. There are 2 bits per SDHI channel. I did check and just
> enabling the one works fine.
> 
> Honestly, I'm not sure why there are two clock enables.
> 
> I'll go back and ask the design team if they can tell me why there are 2.
> 
> As I said, I just re-tested and it works fine, but you can hold off on the
> patch if you want until I come up with a real explanation.

I'd prefer to hold off on this for now.

Re: [PATCH 1/2] dt-bindings: document renesas-ostm timer

2017-01-13 Thread Geert Uytterhoeven

Hi Chris,

On Thu, Jan 12, 2017 at 7:59 PM, Chris Brandt  wrote:
> Signed-off-by: Chris Brandt 
> ---
>  .../devicetree/bindings/timer/renesas,ostm.txt | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt 
> b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
> new file mode 100644
> index 000..46e1f27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
> @@ -0,0 +1,36 @@
> +* Renesas OS Timer (OSTM)
> +
> +The OSTM comes with 2 independent channels.
> +We will use the first channel (OSTM0) as a free running clocksource and the
> +second channel (OSTM1) as a interrupt driven clock event.
> +
> +Additionally we will use the clocksource channel (OTSM0) for the system
> +schedule timer sched_clock().

The above two sentences are software policy, not hardware description.
Hence they do not belong in the DT bindings document.
You can move them to the commit description, though.

> +
> +Required Properties:
> +
> +  - compatible: must be one or more of the following:
> +- "renesas,ostm-r7s72100" for the r7s72100 OSTM

Please use "renesas,r7s72100-ostm" instead, to match current practices.

> +- "renesas,ostm" for any OSTM
> +  This is a fallback for the above renesas,ostm-* entries
> +
> +  - reg: base address and length of the registers block for each timer 
> channel.
> +There should be 2 sets of addresses, one for each channel.
> +
> +  - interrupts: interrupt specifiers for the timers. There should be 2
> +interupts, one for each channel.
> +
> +  - clocks: a list of phandle + clock-specifier pairs, one for each entry
> +channel. There should be 2 sets, one for each channel.

Are the channels truly independent? If yes, I think it's better to have two
separate device nodes, one for each channel.
Each channel has its own module clock, so using separate devices means
Runtime PM can manage both channels through their module clocks as soon as
you add a "power-domains" property pointing to the clock domain controller.

> +Example: R7S72100 (RZ/A1H) OSTM node
> +
> +   ostm: ostm@fcfec000 {
> +   compatible = "renesas,ostm-r7s72100", "renesas,ostm";
> +   reg = <0xfcfec000 0x30>,
> + <0xfcfec400 0x30>;
> +   interrupts =  + GIC_SPI 103 IRQ_TYPE_EDGE_RISING>;
> +
> +   clocks = <_clks R7S72100_CLK_OSTM0>, <_clks 
> R7S72100_CLK_OSTM1>;
> +   };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3] iio: adc: Add Maxim MAX11100 driver

2017-01-13 Thread Geert Uytterhoeven

Hi Jacopo,

On Thu, Jan 12, 2017 at 11:51 PM, Jacopo Mondi
 wrote:
> From: Jacopo Mondi 
>
> Add IIO driver for Maxim MAX11100 single-channel ADC.
> Add DT bindings documentation.
>
> Signed-off-by: Jacopo Mondi 
> Tested-by: Marek Vasut 

>  .../devicetree/bindings/iio/adc/max11100.txt   |  17 ++
>  drivers/iio/adc/Kconfig|   9 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/max11100.c | 187 
> +
>  4 files changed, 214 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.txt
>  create mode 100644 drivers/iio/adc/max11100.c

When submitting a new driver with DT bindings, please split off the
DT binding docs in a separate patch, and CC devicet...@vger.kernel.org,
Rob Herring, and Mark Rutland.

scripts/get_maintainer.pl is your friend ;-)

Reviewing DT binding docs only...

> new file mode 100644
> index 000..6877c11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/max11100.txt
> @@ -0,0 +1,17 @@
> +* Maxim max11100 Analog to Digital Converter (ADC)
> +
> +Required properties:
> +  - compatible: Should be "maxim,max11100"
> +  - vref-supply: phandle to the regulator that provides reference voltage

As this is an SPI slave device, there should be a "reg" property.

> +
> +Optional properties:
> +  - spi-max-frequency: SPI maximum frequency
> +
> +Example:
> +
> +adc0: max11100@0 {

As per ePAPR Section 2.2.2 "Generic Names Recommendation", node names
should be "somewhat generic, reflecting the function of the device and
not its precise programming model.".
The label property defines a human readable string describing a device.
Hence "max11100: adc@0" is more appropriate.

> +compatible = "maxim,max11100";

Missing "reg = <0>;" matching the unit-address above.

> +vref-supply = <_vref>;
> +spi-max-frequency = <24>;
> +};

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

RE: [PATCH 1/2] dt-bindings: document renesas-ostm timer

[PATCH] net: constify mdiobb_ops structures

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

Re: [git pull] pinctrl: sh-pfc: Updates for v4.11

Re: [PATCH net] ravb: do not use zero-length alighment DMA request

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

RE: [PATCH 3/3] ARM: dts: rskrza1: add ostm DT support

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

[git pull] clk: renesas: Updates for v4.11

Re: [PATCH net] ravb: do not use zero-length alighment DMA request

[PATCH net] ravb: do not use zero-length alighment DMA request

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

Re: [PATCH] dmaengine: rcar-dmac: unmap slave resource when channel is freed

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

Re: [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports

[PATCH v4 2/2] dt-bindings: iio: document MAX11100 ADC

[PATCH v4 1/2] iio: adc: Add Maxim MAX11100 driver

[PATCH v4 0/2] iio: adc: Add Maxim MAX11100 driver

Re: [PATCH 3/3] ARM: dts: rskrza1: add ostm DT support

Re: [PATCH v3] iio: adc: Add Maxim MAX11100 driver

Re: [PATCH 3/3] ARM: dts: rskrza1: add ostm DT support

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

Re: [PATCH 1/3] ARM: dts: r7s72100: add ostm clock to device tree

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

Re: [PATCH 1/2] dt-bindings: document renesas-ostm timer

Re: [PATCH v3] iio: adc: Add Maxim MAX11100 driver

33 matches

Site Navigation

Mail list logo

Footer information