Re: [PATCH v2 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

[Magnus Damm]

Hi Joerg,

On Fri, Jan 27, 2017 at 8:47 PM, Joerg Roedel  wrote:
> On Mon, Jan 23, 2017 at 08:40:29PM +0900, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Bump up the maximum numbers of micro-TLBS to 48.
>>
>> Each IPMMU device instance get micro-TLB assignment via
>> the "iommus" property in DT. Older SoCs tend to use a
>> maximum number of 32 micro-TLBs per IPMMU instance however
>> newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
>>
>> At this point no SoC specific handling is done to validate
>> the maximum number of micro-TLBs, and because of that the
>> DT information is assumed to be within correct range for
>> each particular SoC.
>>
>> If needed in the future SoC specific feature flags can be
>> added to handle the maximum number of micro-TLBs without
>> requiring DT changes, however at this point this does not
>> seem necessary.
>>
>> Signed-off-by: Magnus Damm 
>
> I get a conflict when applying this to v4.10-rc5. What is this based on,
> any patches I missed?

Thanks for giving it a go. The second patch in this series should apply as-is:
[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding

However for driver code there are two series in between:
 [PATCH v6 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V6
 [PATCH v2 00/11] iommu/ipmmu-vmsa: r8a7795 support V2

For more detailed dependency information please see the cover letter!

Regarding the driver code please wait for "IPMMU multi-arch update V7"
that takes comments from Laurent into consideration. Hopefully I
should be able to send it out some time this week.

As for "[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding",
would it be possible to fast track mainline merge of that particular
DT binding patch? Can you take it in your tree?

To give some background, we already have the IPMMU DT binding for
older devices and the sister device r8a7795 in mainline, so the
r8a7796 DT binding is just a small incremental step. To make sure we
don't go too wild with DT changes we tend to require that the DT
binding change should be queued up before starting to merge changes to
DTS files. So currently some DT changes are blocking on that r8a7796
DT binding and it would be nice to unblock those if possible..

Thanks!

/ magnus

Re: [PATCH v6 2/3] mmc: sh_mobile_sdhi: explain clock bindings

[Rob Herring]

On Wed, Jan 25, 2017 at 03:28:09PM -0500, Chris Brandt wrote:
> In the case of a single clock source, you don't need names. However,
> if the controller has 2 clock sources, you need to name them correctly
> so the driver can find the 2nd one. The 2nd clock is for the internal
> card detect logic.
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v5:
> * add Reviewed-by: Geert Uytterhoeven
> * list number of clocks for each SoC
> * remove example because it already exists in mmc.txt
> v4:
> * just explain there might be 2 clocks, don't explain how
>   we will use them in the driver
> v3:
> * add more clarification about why there are sometimes 2 clocks
>   and what you should do with them.
> * remove 'status = "disabled"' from example
> v2:
> * fix spelling and change wording
> * changed clock name from "carddetect" to "cd"
> ---
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 13 +
>  1 file changed, 13 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v2 1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset control support

[Rob Herring]

On Wed, Jan 25, 2017 at 10:15:00AM +0100, Geert Uytterhoeven wrote:
> Document properties needed to use the Reset Control feature of the
> Renesas Clock Pulse Generator / Module Standby and Software Reset
> module.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - Change oneline summary to refer to dt-bindings.
> ---
>  Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 6 ++
>  1 file changed, 6 insertions(+)

Acked-by: Rob Herring 

RE: [RFC 0/5] Renesas RZ series pinctrl driver

[Chris Brandt]

On Monday, January 30, 2017, Laurent Pinchart wrote:
> > It depends on the actual hardware: while per-pin settings are suitable
> > for SoCs that have per-pin hardware configuration (e.g. RZ/A1), it's
> > not suitable for SoCs where that's not the case, and where the
> > hardware has group-wise configuration (e.g. on R-Car).
> >
> > Hence IMHO "the future of Renesas pin control" will remain a split
> > personality for a while ;-)
> >
> > Laurent: please kick me if you disagree...
> 
> I unfortunately agree. Maybe we could try to speed up the process by
> providing feedback to the hardware engineers ?

For what it's worth, I fired off my 'rant and rave' last week about the
current R-Car PFC block so I'll be curious to see what they say. Of
course, I'm on the RZ side of the company, so maybe someone on the R-Car
side might have better luck.


Chris

RE: [RFC 4/5] arm: dts: r7s1000: Add pincontroller node

[Chris Brandt]

Hi Jacopo,

On Monday, January 30, 2017, Laurent Pinchart wrote:
> > +   pinctrl: pinctrl@fcfe3000 {
> > +   compatible = "renesas,rza1-pinctrl";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   #pinctrl-cells = <2>;
> > +
> > +   reg = <0xfcfe3000 0xa30>, /* Pn, ..., PFCAEn */
> > + <0xfcfe7000 0x230>, /* PIBCn, ..., PIPCn */
> 
> What's the reason for splitting those registers in two sets ? Maybe you
> can explain that in the DT bindings documentation that this patch series
> is missing ;-)


I left this out of my review comments, but even though the chip designers left
a BIG HOLE in the memory map of the PFC controller, I don't think it will
'cost' you anything by just mapping the whole area (dead space and all) and
getting rid of the "high and low" memory indexing thing that you are doing
in the driver.
There is nothing mapped in that dead area anyway.



Chris

Re: [RFC 5/5] arm: dts: genmai: Add SCIF2 pin group

[Geert Uytterhoeven]

Hi Laurent,

On Mon, Jan 30, 2017 at 7:17 PM, Laurent Pinchart
 wrote:
> On Thursday 26 Jan 2017 12:51:03 Sergei Shtylyov wrote:
>> On 1/25/2017 9:09 PM, Jacopo Mondi wrote:
>> > + {
>> > +   pinctrl-names = "default";
>> > +   pinctrl-0 = <_pins>;
>> > +
>> > +   scif2_pins: serial2 {
>> > +   /* P3_0 as TxD2; P3_2 as RxD2 */
>> > +   renesas-rz,pins = ,
>>
>> The comma should be after the vendor prefix ("renesas").
>
> And the "-rz" suffix isn't needed, "renesas,pins" will do.

Then it can just become "pins"? Or not?

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: [RFC 2/5] pinctrl: rz-pfc: Add Renesas RZ/A1 pinctrl driver

[Chris Brandt]

Hi Jacopo,


On Wednesday, January 25, 2017, Jacopo Mondi wrote:
> + /* Port 5 */
> + RZ_PIN_NAME(5, 0), RZ_PIN_NAME(5, 1), RZ_PIN_NAME(5, 2),
> + RZ_PIN_NAME(5, 3), RZ_PIN_NAME(5, 4), RZ_PIN_NAME(5, 5),
> + RZ_PIN_NAME(5, 6), RZ_PIN_NAME(5, 7), RZ_PIN_NAME(5, 8),
> + RZ_PIN_NAME(5, 9), RZ_PIN_NAME(5, 10),

The RZ/A1L (basically a subset of RZ/A1H to reduce cost) uses
all 16 port pins on "port 5" so I'd like to include them as well.



> +static const struct of_device_id rza1_pinctrl_of_match[] = {
> + { .compatible = "renesas,rza1-pinctrl", },
> + { }
> +};

Since this PFC driver file is specifically for RZ/A1, I think a
better compatible string would be:

  .compatible = "renesas,r7s72100-renesas-pinctrl",


Chris

RE: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Chris Brandt]

Hi Jacopo,

On Wednesday, January 25, 2017, Jacopo Mondi wrote:
> +
> + return 0;
> +
> +free_map:
> + devm_kfree(rz_pinctrl->dev, *map);
> +free_fngrps:
> + devm_kfree(rz_pinctrl->dev, fngrps);
> +free_pins:
> + devm_kfree(rz_pinctrl->dev, mux_modes);
> + devm_kfree(rz_pinctrl->dev, grpins);
> + return ret;
> +}

Since one of the benefits of using devm_kzalloc is that if
the probe fails and returns an error, all the memory associated with
that device will automatically get freed, you 'might' not
need this code to free memory.

I say might because I'm not sure if returning an error here will
kill the driver or not. But, might be interesting to look into.


> +#define RZ_PIN_NAME(bank, pin)   
> \
> + PIN_##bank##_##pin
> +
> +#define RZ_PIN_DESC(b, p)\
> + { .number = RZ_PIN_NAME(b, p),  \
> +   .name = __stringify(RZ_PIN_NAME(b, p)),   \

The hardware manual uses the names "P1_0" for ports, so it might
be better to match that format for consistency.


Chris

Re: [RFC 0/5] Renesas RZ series pinctrl driver

[Laurent Pinchart]

Hi Geert,

On Monday 30 Jan 2017 17:08:11 Geert Uytterhoeven wrote:
> On Mon, Jan 30, 2017 at 2:51 PM, Linus Walleij wrote:
> > On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi wrote:
> >> after having discussed in great detail the RZ series per-pin PFC
> >> hardware peculiarities, this is a proposal for a possible pin-based pin
> >> controller driver for SoC devices of Renesas RZ family.
> >> 
> >> This RFC series adds a minimal driver infrastructure which supports pin
> >> multiplexing via explicit per-pin settings performed in device tree
> >> sources.
> >
> > I think this is what Laurent had in mind when he said something about
> > that he should have taken the per-pin approach from day 1.
> > 
> > I would especially like to see Laurent's review and ACK on this series
> > for that reason so we don't create something less than what he is
> > expecting for the future of Renesas pin control.
> 
> It depends on the actual hardware: while per-pin settings are suitable for
> SoCs that have per-pin hardware configuration (e.g. RZ/A1), it's not
> suitable for SoCs where that's not the case, and where the hardware has
> group-wise configuration (e.g. on R-Car).
> 
> Hence IMHO "the future of Renesas pin control" will remain a split
> personality for a while ;-)
> 
> Laurent: please kick me if you disagree...

I unfortunately agree. Maybe we could try to speed up the process by providing 
feedback to the hardware engineers ?

-- 
Regards,

Laurent Pinchart

Re: [RFC 4/5] arm: dts: r7s1000: Add pincontroller node

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Wednesday 25 Jan 2017 19:09:46 Jacopo Mondi wrote:
> Add pincontroller node compatible with the new Renesas RZ/A1
> pincontroller driver.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/arm/boot/dts/r7s72100.dtsi | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi
> b/arch/arm/boot/dts/r7s72100.dtsi index 3dd427d..764006d 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -171,6 +171,18 @@
>   };
>   };
> 
> + pinctrl: pinctrl@fcfe3000 {
> + compatible = "renesas,rza1-pinctrl";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + #pinctrl-cells = <2>;
> +
> + reg = <0xfcfe3000 0xa30>, /* Pn, ..., PFCAEn */
> +   <0xfcfe7000 0x230>, /* PIBCn, ..., PIPCn */

What's the reason for splitting those registers in two sets ? Maybe you can 
explain that in the DT bindings documentation that this patch series is 
missing ;-)

> +   <0xfcfe7B00 0x430>; /* JPPR0, ..., JPIBC0 */

s/B/b/

> + };
> +
>   scif0: serial@e8007000 {
>   compatible = "renesas,scif-r7s72100", "renesas,scif";
>   reg = <0xe8007000 64>;

-- 
Regards,

Laurent Pinchart

Re: [RFC 3/5] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

[Laurent Pinchart]

On Thursday 26 Jan 2017 20:52:33 Geert Uytterhoeven wrote:
> On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi wrote:
> > Add dt-bindings header for Renesas RZ pincontroller.
> > The header defines macros for pin description and alternate function
> > numbers.
> > 
> > Signed-off-by: Jacopo Mondi 
> > ---
> > 
> >  include/dt-bindings/pinctrl/pinctrl-renesas-rz.h | 19 +++
> >  1 file changed, 19 insertions(+)
> >  create mode 100644 include/dt-bindings/pinctrl/pinctrl-renesas-rz.h
> > 
> > diff --git a/include/dt-bindings/pinctrl/pinctrl-renesas-rz.h
> > b/include/dt-bindings/pinctrl/pinctrl-renesas-rz.h new file mode 100644
> > index 000..92816d4
> > --- /dev/null
> > +++ b/include/dt-bindings/pinctrl/pinctrl-renesas-rz.h
> > @@ -0,0 +1,19 @@
> > +/*
> > + * Defines macros and constants for Renesas RZ pin controller and muxer
> > + */
> > +
> > +#ifndef __DT_BINDINGS_PINCTRL_RENESAS_RZ_H
> > +#define __DT_BINDINGS_PINCTRL_RENESAS_RZ_H
> > +
> > +#define RZ_PIN(b, p) b p
> 
> And the advantage of this macro is?
> 
> > +#define ALTERNATE_FUNC_1   0
> > +#define ALTERNATE_FUNC_2   1
> > +#define ALTERNATE_FUNC_3   2
> > +#define ALTERNATE_FUNC_4   3
> > +#define ALTERNATE_FUNC_5   4
> > +#define ALTERNATE_FUNC_6   5
> > +#define ALTERNATE_FUNC_7   6
> > +#define ALTERNATE_FUNC_8   7
> 
> I have mixed feelings about these macros:
>   1. They're long to type,
>   2. They just map from n to n-1.
> 
> Why not use plain numbers 1..8 (the alternate function numbering in the
> datasheet is 1-based), and subtract 1 in the C code?

I was about to mention the same. I think you can drop this patch and use the 
numbers directly.

-- 
Regards,

Laurent Pinchart

Re: [RFC fixes 1/2] arm: dts: genmai: Configure RIIC2 pins

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Friday 27 Jan 2017 17:47:07 Jacopo Mondi wrote:
> Add pin configuration for RIIC2 pins interface.
> The i2c2 is connected to internal eeprom.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/arm/boot/dts/r7s72100-genmai.dts | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
> b/arch/arm/boot/dts/r7s72100-genmai.dts index ea649c7..0068a1a 100644
> --- a/arch/arm/boot/dts/r7s72100-genmai.dts
> +++ b/arch/arm/boot/dts/r7s72100-genmai.dts
> @@ -40,13 +40,19 @@
> 
>   {
>   pinctrl-names = "default";
> - pinctrl-0 = <_pins>;
> + pinctrl-0 = <_pins _pins>;

Referencing the SCIF2 and I2C2 pins nodes from the pinctrl node will result in 
the corresponding pins being configured when the pinctrl driver is probed. You 
could move this to the SCIF2 and I2C2 DT nodes, to have the pins configured as 
part of the probe sequence of the corresponding drivers. The advantage would 
be that pins would only be configured if the corresponding devices are enabled 
and get probed by a driver. This could save a bit of power if the boot loader 
configured the pins in low-power mode and the devices were unused (although in 
this very specific case I don't think it will make a difference).

> 
>   scif2_pins: serial2 {
>   /* P3_0 as TxD2; P3_2 as RxD2 */
>   renesas-rz,pins = ,
> ;
>   };
> +
> + i2c2_pins: i2c2 {
> + /* RIIC2: P1_4 as SCL, P1_5 as SDA */
> + renesas-rz,pins = ,
> +   ;
> + };
>  };
> 
>  _clk {

-- 
Regards,

Laurent Pinchart

Re: [RFC 5/5] arm: dts: genmai: Add SCIF2 pin group

[Laurent Pinchart]

Hello,

On Thursday 26 Jan 2017 12:51:03 Sergei Shtylyov wrote:
> On 1/25/2017 9:09 PM, Jacopo Mondi wrote:
> > Add  TxD and RxD pin configuration for SCIF2 serial communication
> > interface on r7s72100 Genmai board.
> > 
> > Signed-off-by: Jacopo Mondi 
> > ---
> > 
> >  arch/arm/boot/dts/r7s72100-genmai.dts | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
> > b/arch/arm/boot/dts/r7s72100-genmai.dts index 118a8e2..ea649c7 100644
> > --- a/arch/arm/boot/dts/r7s72100-genmai.dts
> > +++ b/arch/arm/boot/dts/r7s72100-genmai.dts
> 
> [...]
> 
> > @@ -34,6 +35,18 @@
> > #address-cells = <1>;
> > #size-cells = <1>;
> > };
> > +

That's not needed.

> > +};
> > +
> > + {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins>;
> > +
> > +   scif2_pins: serial2 {
> > +   /* P3_0 as TxD2; P3_2 as RxD2 */
> > +   renesas-rz,pins = ,
> 
> The comma should be after the vendor prefix ("renesas").

And the "-rz" suffix isn't needed, "renesas,pins" will do.

-- 
Regards,

Laurent Pinchart

RE: [RFC fixes 0/2] FIX: Renesas RZ series pinctrl driver

[Chris Brandt]

Hi Jacopo,

On Monday, January 30, 2017, Jacopo Mondi wrote:
> > Note that the I2C pin need to be configured at "bi-directional" but
> > there is no way to specify that from DT, so that has to be added as a
> parameter.
> 
> That's something I would like to discuss quite soon.
> One general thing I would like is having the so-called "additional
> parameters" part of the SoC driver module, as my gut feeling is that
> different PFC hw requires different configuration options.

In the API I used for the current RZ/A1 BSP, I used an extra parameter
to pass in any non-normal settings.


> In example, the RZ/A1 SoC requires the input/output direction of the pin
> to be specified even when the alternate function is supposed to drive it
> (in order to enable/disable input buffer). The same applies to bi-
> directional port control as you pointed out in your example (bi-
> directional enables input buffer, but that's a consequence of how hw works
> there).
> 
> I'm almost sure the same won't be required by all existing and forth-
> coming Renesas SoCs with a pin-based PFC hardware, but maybe other
> parameters I cannot think of right now will have to be specified instead.

I would guess for one reason or another, there is always some exception
in the hardware manual when it comes to pins settings. Meaning, there are
restrictions in the I/O pad circuits that the HW designers find it easier
to tell the SW guys to deal with it instead of trying to make it 'automatic'
in HW.
So...you'll always have the need for an extra parameter.


> If we want to keep the configuration flags SoC-specific, the most easy way
> to pass them down from core module to SoC module would be compressing the
> alternate function number and other configurations in a single u32.
> 
> In that case the dts will look like:
> 
> renesasa,rz-pins = ;
> 
> We could even add a parameter to separate ALTERNATE_FUNCTION from the
> additional configurations, but I don't see any advantage in doing this at
> the moment.

As I said, I made "additional configs" a separate parameter, but combining
it with ALTERNATE_FUNC_# is fine with me. I have not seen an SoC that allowed
any more than 8 different functions per pin, so you have lots of bits
in u32 in order to set flags bits.

However, as already mentioned by Geert, "ALTERNATE_FUNC_#" is too long of
a name. Just "ALT_#" is fine.

renesasa,rz-pins = ;

Geert's suggestion was to just use the actual number (1-8), ALT_# might make
it easier to decode if you are combining multiple things into a single u32.

There is one more ideabut I heist to suggest it.
You just pass in the port and alternate function number, and you do a lookup
table for settings such as bi-direction or port direction register.
You only put into the table the pin settings that are "not normal".

The benefit is that the user doesn't have to know what pins needs what special
tweak/flag/settingbut of course it start to make the driver more complex.



Chris

Re: [RFC 0/5] Renesas RZ series pinctrl driver

[jacopo mondi]

Hi Tony,

On 30/01/2017 16:53, Tony Lindgren wrote:

* Linus Walleij  [170130 05:53]:

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:


   after having discussed in great detail the RZ series per-pin PFC hardware
peculiarities, this is a proposal for a possible pin-based pin controller
driver for SoC devices of Renesas RZ family.

This RFC series adds a minimal driver infrastructure which supports pin
multiplexing via explicit per-pin settings performed in device tree sources.


I think this is what Laurent had in mind when he said something about
that he should have taken the per-pin approach from day 1.

I would especially like to see Laurent's review and ACK on this series
for that reason so we don't create something less than what he is
expecting for the future of Renesas pin control.

The series as such seems fine and is reusing Tony's work to generalize
pin controllers putting functions and groups into the device tree in a nice
way, which makes it relevant for him to have a look as well, if he has
time.


Well I don't have the series in my inbox, but browsing through
the patchwork seems OK. The things to check would be:


Sorry about this, I thought sending to linux-gpio was enough.
We'll keep you in the loop now...



1. Do you guys really need RZ_PIN_DESC? Just let pinctrl
   framework generate the names, then do some simple user
   space tool that decodes the debugfs output. If you really
   need names, allow the consumer to set the name like we do
   for GPIOs and interrupts when requesting the resource.



Well, more than names I have used the RZ_PIN_DESC macro as an extended 
version of the PINCTRL_PIN one, to set bank and pin fields of the 
rz_pin_desc structure that describes a pin.


The proposed DTS syntax identifies pins by their position (bank:pin) 
instead that by index, so I need to have those information available in 
pin description to identify them.



2. Make sure you're using hardware offsets for any indexing
   to avoid adding artificial mapping tables between the driver
   and the the dts file. Many times new features are enabled
   between SoC revisions and a numbered index gets out of sync
   and needs constant patching just like we have for interrupt
   numbers earlier.. I don't think that's an issue with this
   series, but please check one more time for easy maintenance :)



As we describe pins "by position", if I got your comment properly, we 
should be safe, as indexes are purely incremental values from [0-npins].


I know pinctrl-single (and other drivers such as imx one if I'm not 
wrong) uses pin indexes to calculate register offsets. This series 
doesn't but uses the [bank:pin] couple for that purpose instead.


Thanks
   j



Regards,

Tony

Re: [PATCH v2 0/3] sh_eth: E-DMAC interrupt mask cleanups

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 29 Jan 2017 15:06:39 +0300

>Here's a set of 3 patches against DaveM's 'net-next.git' repo. The main 
> goal
> of this set is to stop using the bare numbers for the E-DMAC interrupt masks.
> 
> [1/3] sh_eth: rename EESIPR bits
> [2/3] sh_eth: add missing EESIPR bits
> [3/3] sh_eth: stop using bare numbers for EESIPR values

Series applied, thank you.

Re: [RFC fixes 0/2] FIX: Renesas RZ series pinctrl driver

[jacopo mondi]

Hi Chris,
   thanks for testing the series

On 27/01/2017 22:09, Chris Brandt wrote:

Hi Jacopo,

On Friday, January 27, 2017, Jacopo Mondi wrote:

Hello,
   sorry if I'm sending 2 patches on top of an RFC series with comments
still pending, but these patches enabled me to properly test pin
configuration sequence in order to access the internal EEPROM through
RIIC2 interface on pins 1_4 and 1_5.

The outcome is a bugfix to RZ/A1 pincontroller driver which [2/2] applies
on.

When sending v2 of the whole series I'll probably squash these, but if
someone is testing the RFC series I wanted to make sure he does not waste
his time with a broken driver.

Thanks
   j

Jacopo Mondi (2):
  arm: dts: genmai: Configure RIIC2 pins
  pinctrl: rz-pfc: Fix RZ/A1 pin function configuration

 arch/arm/boot/dts/r7s72100-genmai.dts |  8 -  drivers/pinctrl/rz-
pfc/pinctrl-rza1.c | 55 +++
 2 files changed, 43 insertions(+), 20 deletions(-)



Preliminary testing shows that I2C pin muxing works. Nice job!

Testing:
- RZ/A1H RSK board
- u-boot modified to make sure pins are put back to GPIO-IN
- RIIC ch3 is connected to a I2C port expander that has 3 LEDs attached
- using a heartbeat kernel thread that blinks the LEDs

Of course, more testing is needed to make sure there is no "smoke and mirrors"
going on like there was with the MSTP clock driver ;)


Note that the I2C pin need to be configured at "bi-directional" but there is
no way to specify that from DT, so that has to be added as a parameter.


That's something I would like to discuss quite soon.
One general thing I would like is having the so-called "additional 
parameters" part of the SoC driver module, as my gut feeling is that 
different PFC hw requires different configuration options.


In example, the RZ/A1 SoC requires the input/output direction of the pin 
to be specified even when the alternate function is supposed to drive it 
(in order to enable/disable input buffer). The same applies to 
bi-directional port control as you pointed out in your example 
(bi-directional enables input buffer, but that's a consequence of how hw 
works there).


I'm almost sure the same won't be required by all existing and 
forth-coming Renesas SoCs with a pin-based PFC hardware, but maybe other 
parameters I cannot think of right now will have to be specified instead.


If we want to keep the configuration flags SoC-specific, the most easy 
way to pass them down from core module to SoC module would be 
compressing the alternate function number and other configurations in a 
single u32.


In that case the dts will look like:

renesasa,rz-pins = ;

We could even add a parameter to separate ALTERNATE_FUNCTION from the 
additional configurations, but I don't see any advantage in doing this 
at the moment.


Can people with a broader knowledge of Renesas' SoC series ack/nack my 
assumptions here?


Thanks
   j

Re: [RFC 0/5] Renesas RZ series pinctrl driver

[Tony Lindgren]

* Linus Walleij  [170130 05:53]:
> On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  
> wrote:
> 
> >after having discussed in great detail the RZ series per-pin PFC hardware
> > peculiarities, this is a proposal for a possible pin-based pin controller
> > driver for SoC devices of Renesas RZ family.
> >
> > This RFC series adds a minimal driver infrastructure which supports pin
> > multiplexing via explicit per-pin settings performed in device tree sources.
> 
> I think this is what Laurent had in mind when he said something about
> that he should have taken the per-pin approach from day 1.
> 
> I would especially like to see Laurent's review and ACK on this series
> for that reason so we don't create something less than what he is
> expecting for the future of Renesas pin control.
> 
> The series as such seems fine and is reusing Tony's work to generalize
> pin controllers putting functions and groups into the device tree in a nice
> way, which makes it relevant for him to have a look as well, if he has
> time.

Well I don't have the series in my inbox, but browsing through
the patchwork seems OK. The things to check would be:

1. Do you guys really need RZ_PIN_DESC? Just let pinctrl
   framework generate the names, then do some simple user
   space tool that decodes the debugfs output. If you really
   need names, allow the consumer to set the name like we do
   for GPIOs and interrupts when requesting the resource.

2. Make sure you're using hardware offsets for any indexing
   to avoid adding artificial mapping tables between the driver
   and the the dts file. Many times new features are enabled
   between SoC revisions and a numbered index gets out of sync
   and needs constant patching just like we have for interrupt
   numbers earlier.. I don't think that's an issue with this
   series, but please check one more time for easy maintenance :)

Regards,

Tony

Re: [git pull] pinctrl: sh-pfc: Updates for v4.11 (take two)

[Linus Walleij]

On Fri, Jan 27, 2017 at 10:21 AM, Geert Uytterhoeven
 wrote:

> The following changes since commit 0e4e4999aac16641f47699e8929693b83a7a4d64:
>
>   pinctrl: sh-pfc: r8a7796: Add HSCIF pins, groups, and functions (2016-12-27 
> 10:57:39 +0100)
>
> 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-tag2
>
> for you to fetch changes up to 07254d835dfc1e06a8cdfb565e7371176a4b93f9:
>
>   pinctrl: sh-pfc: r8a7791: Add ADI pinconf support (2017-01-20 14:23:40 
> +0100)

Pulled into the pinctrl devel branch for v4.11.

Yours,
Linus Walleij

Re: [RFC 0/5] Renesas RZ series pinctrl driver

[Linus Walleij]

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:

>after having discussed in great detail the RZ series per-pin PFC hardware
> peculiarities, this is a proposal for a possible pin-based pin controller
> driver for SoC devices of Renesas RZ family.
>
> This RFC series adds a minimal driver infrastructure which supports pin
> multiplexing via explicit per-pin settings performed in device tree sources.

I think this is what Laurent had in mind when he said something about
that he should have taken the per-pin approach from day 1.

I would especially like to see Laurent's review and ACK on this series
for that reason so we don't create something less than what he is
expecting for the future of Renesas pin control.

The series as such seems fine and is reusing Tony's work to generalize
pin controllers putting functions and groups into the device tree in a nice
way, which makes it relevant for him to have a look as well, if he has
time.

Yours,
Linus Walleij

Re: [PATCH/RFC] iommu/dma: Per-domain flag to control size-alignment

[Robin Murphy]

On 30/01/17 07:20, Yoshihiro Shimoda wrote:
> Hi Robin, Magnus,
> 
>> -Original Message-
>> From: Robin Murphy
>> Sent: Saturday, January 28, 2017 2:38 AM
>>
>> Hi Magnus,
>>
>> On 27/01/17 06:24, Magnus Damm wrote:
>>> From: Magnus Damm 
>>>
>>> Introduce the flag "no_size_align" to allow disabling size-alignment
>>> on a per-domain basis. This follows the suggestion by the comment
>>> in the code, however a per-device control may be preferred?
>>>
>>> Needed to make virtual space contiguous for certain devices.
>>
>> That sounds very suspicious - a single allocation is contiguous with
>> itself by definition, and anyone relying on multiple allocations being
>> contiguous with one another is doing it wrong, because there's no way we
>> could ever guarantee that (with this allocator, at any rate). I'd be
>> very reticent to touch this without a specific example of what problem
>> it solves.
> 
> Thank you for the comment! This patch was from my request.
> But, I completely misunderstood this "size-alignment" behavior.
> And, my concern was already resolved by the following patch at last April:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/iommu?id=809eac54cdd62c67afea1e17080e681dfa33dc09
> 
> So, no one needs this patch anymore.

Cool, thanks for the clarification :)

Robin.

> 
> Best regards,
> Yoshihiro Shimoda
> 

Re: [PATCH v7 0/2] clocksource: Add renesas-ostm timer driver

[Daniel Lezcano]

On Fri, Jan 27, 2017 at 03:02:13PM -0500, Chris Brandt wrote:
> This patch set adds a new clocksource driver that uses the OS Timer
> (OSTM) that exists in the R7S72100 (RZ/A1) SoC.
> 
> The operation of the driver was tested with a simple user application
> that does multiple calls to nanosleep() and gettimeofday().
> 
> The purpose of adding this driver is to get better time keeping
> accuracy over the default MTU2 clocksource timer.
> 
> v7:
> * initialize *ostm_clk=NULL to remove 'may be used uninitialized'
>   warning. Reported by "kbuild test robot"

Hi Chris,

I queued up the patches for 4.11.

Thanks !

  -- Daniel