Re: [GIT PULL FOR renesas-drivers] media: ADV748x driver

2017-06-12 Thread Geert Uytterhoeven
Hi Kieran,

On Tue, Jun 13, 2017 at 2:44 AM, Kieran Bingham  wrote:
> Please consider including this driver (based on linux-media/master) for 
> renesas-drivers.

Thanks, looks good!

> The following changes since commit 47f910f0e0deb880c2114811f7ea1ec115a19ee4:
>
>   [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev 
> (2017-06-08 16:55:25 -0300)
>
> are available in the git repository at:
>
>   g...@gitolite.kernel.org:pub/scm/linux/kernel/git/kbingham/rcar.git 
> adv748x/for-renesas-drivers

BTW, most people prefer "git://git.kernel.org/..."

>
> for you to fetch changes up to fdae35a2e755e7d2e06d652c2e64343b7f82fce1:
>
>   media: i2c: adv748x: add adv748x driver (2017-06-13 01:40:24 +0100)

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 v5 01/10] pinctrl: generic: Add bi-directional and output-enable

2017-06-12 Thread Dong Aisheng
On Mon, Jun 12, 2017 at 5:44 PM, jmondi  wrote:
> Hi Linus,
>
> On Sun, Jun 11, 2017 at 11:45:49PM +0200, Linus Walleij wrote:
>> On Fri, Jun 9, 2017 at 9:50 AM, jmondi  wrote:
>> > On Fri, Jun 09, 2017 at 03:26:57PM +0800, Dong Aisheng wrote:
>>
>> >> > I see three options here:
>> >> >
>> >> > 1) Add "output-buffer-enable" and "input-buffer-enable"
>> >> > we end up with
>> >> > "output-high"
>> >> > "output-low"
>> >> > "input-enable"
>> >> > "output-buffer-enable"
>> >> > "input-buffer-enable"
>> >> >
>> >> > 2) Add "output-buffer-enable" only
>> >> > we end up with
>> >> > "output-high"
>> >> > "output-low"
>> >> > "input-enable"
>> >> > "output-buffer-enable"
>> >> >
>> >> > Binding may be confusing as in one case we use "output-buffer-enable"
>> >> > while in the other "input-enable"
>> >> >
>> >> > 3) Add "output-enable" only
>> >> > "output-high"
>> >> > "output-low"
>> >> > "input-enable"
>> >> > "output-enable"
>> >> >
>> >> > As you, I don't like "output-enable" that much but it pairs better with
>> >> > "input-enable".
>> >> >
>> >> > I'll let you and DT people decide on this, as it's really an ABI 
>> >> > definition
>> >> > problem and you have better judgment there.
>> >> >
>> >>
>> >> What's the final decision of this?
>> >
>> > I admit a was buying a bit of time and post-poned the gentle ping for
>> > any final word on this. But since you're asking I'll second your
>> > question :)
>>
>> I suspect it is time to quote
>> Documentation/process/management-style.rst
>> (Torvalds):
>>
>> 1) Decisions
>>
>> Everybody thinks managers make decisions, and that decision-making is
>> important.  The bigger and more painful the decision, the bigger the
>> manager must be to make it.  That's very deep and obvious, but it's not
>> actually true.
>>
>> The name of the game is to **avoid** having to make a decision.  In
>> particular, if somebody tells you "choose (a) or (b), we really need you
>> to decide on this", you're in trouble as a manager.  The people you
>> manage had better know the details better than you, so if they come to
>> you for a technical decision, you're screwed.  You're clearly not
>> competent to make that decision for them.
>>
>> (It goes on, it's the best part of the entire Documentation/* dir in my
>> opinion, please take the time to read it in full.)
>>
>> So: what do you guys, using this feature, and Andy, who raised serious
>> concerns, think is the right binding? That is what *I* need to know.
>
> Fair enough :)
>
> I'll try to keep this short: I don't like "output-enable", and at the
> same time I don't think "output-high" and "output-low" fit well for
> this purpose, as they electrically means something different from what
> our (and IMX) use case is: enabling/disabling input/output
> buffers internal to pin controller/gpio block HW and not driving a value
> there.
>
> This seems clear to me from the "GPIO mode pitfalls" section of
> pinctrl.txt documentation examples and from the fact that generic bindings
> did not expose an "output" flag because if you drive an output line, you
> reasonably either drive it high or low.
>
> Unfortunately I cannot convince myself that the same reasons apply
> to the input use case.  Enabling input on a pin implies the pinctrl/gpio 
> driver
> has to enable any input buffer required to use that pin as a properly
> working input line, and enabling an input buffer implies being able to sense
> the line value from there, so I don't see that much use for 
> "input-buffer-enable"
> alone.
>
> So, even if bindings could look a bit weird as there won't be a direct
> matching between properties names used to enable input/output buffers,
> my vote is to add "output-buffer-enable" only, and keep using the
> already there "input-enable" properties for the input use case.
>

Yes, it may be a bit weird.
I'm not pad internal details expert and can't tell much difference between
output-enable and output-buffer-enable.
I just feel a bit confuse if only using output-buffer-enable.

If enable both input and output, it becomes:
pinctrl_xxx: gpios_xxx_grp {
pins = <
ULP1_PAD_PTD0__PTD0
>;
input-enable;
output-buffer-enable;
bias-pull-up;
};

How about still use output-enable in pairs to input-enable but explain more
in comments?
Aslo update 'input-enable' comment to 'enable input buffer'.
e.g.
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c
index 720a19f..96c83a4 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -172,6 +172,7 @@ static const struct pinconf_generic_params dt_params[] = {
{ "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
{ "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
{ "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
+   { "output-enable", PIN_CONFIG_OUTPUT_ENABLE, 1 },
{ "output-high", PIN_CONFIG_OUTPUT, 1, },
{ "output-low", PIN_CONFIG_OUTPUT, 0

[GIT PULL FOR renesas-drivers] media: ADV748x driver

2017-06-12 Thread Kieran Bingham
Hi Geert,

Please consider including this driver (based on linux-media/master) for 
renesas-drivers.

--
Regards

Kieran



The following changes since commit 47f910f0e0deb880c2114811f7ea1ec115a19ee4:

  [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev (2017-06-08 
16:55:25 -0300)

are available in the git repository at:

  g...@gitolite.kernel.org:pub/scm/linux/kernel/git/kbingham/rcar.git 
adv748x/for-renesas-drivers

for you to fetch changes up to fdae35a2e755e7d2e06d652c2e64343b7f82fce1:

  media: i2c: adv748x: add adv748x driver (2017-06-13 01:40:24 +0100)


Kieran Bingham (1):
  media: i2c: adv748x: add adv748x driver

 .../devicetree/bindings/media/i2c/adv748x.txt  |  96 +++
 MAINTAINERS|   6 +
 drivers/media/i2c/Kconfig  |  11 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/adv748x/Makefile |   7 +
 drivers/media/i2c/adv748x/adv748x-afe.c| 571 +
 drivers/media/i2c/adv748x/adv748x-core.c   | 907 +
 drivers/media/i2c/adv748x/adv748x-csi2.c   | 323 
 drivers/media/i2c/adv748x/adv748x-hdmi.c   | 652 +++
 drivers/media/i2c/adv748x/adv748x.h| 415 ++
 10 files changed, 2989 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt
 create mode 100644 drivers/media/i2c/adv748x/Makefile
 create mode 100644 drivers/media/i2c/adv748x/adv748x-afe.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-core.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-csi2.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-hdmi.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x.h


[PATCH v4 1/2] media: i2c: adv748x: add adv748x driver

2017-06-12 Thread Kieran Bingham
From: Kieran Bingham 

Provide support for the ADV7481 and ADV7482.

The driver is modelled with 4 subdevices to allow simultaneous streaming
from the AFE (Analog front end) and HDMI inputs though two CSI TX
entities.

The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
to the TXB CSI bus.

The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
and an earlier rework by Niklas Söderlund.

Signed-off-by: Kieran Bingham 

---

v2:
 - Implement DT parsing
 - adv748x: Add CSI2 entity
 - adv748x: Rework pad allocations and fmts
 - Give AFE 8 input pads and move pad defines
 - Use the enums to ensure pads are referenced correctly.
 - adv748x: Rename AFE/HDMI entities
   Now they are 'just afe' and 'just hdmi'
 - Reorder the entity enum and structures
 - Added pad-format for the CSI2 entities
 - CSI2 s_stream pass through
 - CSI2 control pass through (with link following)

v3:
 - dt: Extend DT documentation to specify interrupt mappings
 - simplify adv748x_parse_dt
 - core: Add banner to header file describing ADV748x variants
 - Use entity structure pointers rather than global state pointers where
   possible
 - afe: Reduce indent on afe_status
 - hdmi: Add error checking to the bt->pixelclock values.
 - Remove all unnecessary pad checks: handled by core
 - Fix all probe cleanup paths
 - adv748x_csi2_probe() now fails if it has no endpoint
 - csi2: Fix small oneliners for is_txa and get_remote_sd()
 - csi2: Fix checkpatch warnings
 - csi2: Fix up s_stream pass-through
 - csi2: Fix up Pixel Rate passthrough
 - csi2: simplify adv748x_csi2_get_pad_format()
 - Remove 'async notifiers' from AFE/HDMI
   Using async notifiers was overkill, when we have access to the
   subdevices internally and can register them directly.
 - Use state lock in control handlers and clean up s_ctrls
 - remove _interruptible mutex locks

v4:
 - all: Convert hex 0xXX to lowercase
 - all: Use defines instead of hardcoded register values
 - all: Use regmap
 - afe, csi2, hdmi: _probe -> _init
 - afe, csi2, hdmi: _remove -> _cleanup
 - afe, hdmi: Convert pattern generator to a control
 - afe, hdmi: get/set-fmt refactor
 - afe, hdmi, csi2: Convert to internal calls for pixelrate
 - afe: Allow the AFE to configure the Input Select from DT
 - afe: Reduce indent on adv748x_afe_status switch
 - afe: Remove ununsed macro definitions AIN0-7
 - afe: Remove extraneous control checks handled by core
 - afe: Comment fixups
 - afe: Rename error label
 - afe: Correct control names on the SDP
 - afe: Use AIN0-7 rather than AIN1-8 to match ports and MC pads
 - core: adv748x_parse_dt references to nodes, and catch multiple
   endpoints in a port.
 - core: adv748x_dt_cleanup to simplify releasing DT nodes
 - core: adv748x_print_info renamed to adv748x_identify_chip
 - core: reorganise ordering of probe sequence
 - core: No need for of_match_ptr
 - core: Fix up i2c read/writes (regmap still on todo list)
 - core: Set specific functions from the entities on subdev-init
 - core: Use kzalloc for state instead of devm
 - core: Improve probe error reporting
 - core: Track unknown BIT(6) in tx{a,b}_power
 - csi2: Improve adv748x_csi2_get_remote_sd as adv748x_csi2_get_source_sd
 - csi2: -EPIPE instead of -ENODEV
 - csi2: adv_dbg, instead of adv_info
 - csi2: adv748x_csi2_set_format fix
 - csi2: remove async notifier and sd member variables
 - csi2: register links from the CSI2
 - csi2: create virtual channel helper function
 - dt: Remove numbering from endpoints
 - dt: describe ports and interrupts as optional
 - dt: Re-tab
 - hdmi: adv748x_hdmi_have_signal -> adv748x_hdmi_has_signal
 - hdmi: fix adv748x_hdmi_read_pixelclock return checks
 - hdmi: improve adv748x_hdmi_set_video_timings
 - hdmi: Fix tmp variable as polarity
 - hdmi: Improve adv748x_hdmi_s_stream
 - hdmi: Clean up adv748x_hdmi_s_ctrl register definitions and usage
 - hdmi: Fix up adv748x_hdmi_s_dv_timings with macro names for register
 - hdmi: Add locking to adv748x_hdmi_g_dv_timings
   writes and locking
 - hdmi: adv748x_hdmi_set_de_timings function added to clarify DE writes
 - hdmi: Use CP in control register naming to match component processor
 - hdmi: clean up adv748x_hdmi_query_dv_timings()
 - KConfig: Fix up dependency and capitalisation


 Documentation/devicetree/bindings/media/i2c/adv748x.txt |  96 +-
 MAINTAINERS |   6 +-
 drivers/media/i2c/Kconfig   |  11 +-
 drivers/media/i2c/Makefile  |   1 +-
 drivers/media/i2c/adv748x/Makefile  |   7 +-
 drivers/media/i2c/adv748x/adv748x-afe.c | 571 ++-
 drivers/media/i2c/adv748x/adv748x-core.c| 907 +-
 drivers/media/i2c/adv748x/adv748x-csi2.c| 323 +++-
 drivers/media/i2c/adv748x/adv748x-hdmi.c| 652 ++-
 drivers/media/i2c/adv748x/adv748x.h | 415 -
 10 files changed, 2989 insertions(+)
 create mode 100

[PATCH v4 2/2] arm64: dts: renesas: salvator-x: Add ADV7482 support

2017-06-12 Thread Kieran Bingham
From: Kieran Bingham 

Provide ADV7482, and the needed connectors

Signed-off-by: Kieran Bingham 

v4:
 - dt: Rebase to dts/renesas/salvator-x.dtsi
 - dt: Use AIN0-7 rather than AIN1-8

 arch/arm64/boot/dts/renesas/salvator-x.dtsi | 123 +-
 1 file changed, 123 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-x.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
index 937bdf8842f2..c073baf6aeb7 100644
--- a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
@@ -68,6 +68,16 @@
enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
};
 
+   cvbs-in {
+   compatible = "composite-video-connector";
+   label = "CVBS IN";
+
+   port {
+   cvbs_con: endpoint {
+   };
+   };
+   };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
@@ -183,6 +193,17 @@
};
};
 
+   hdmi-in {
+   compatible = "hdmi-connector";
+   label = "HDMI IN";
+   type = "a";
+
+   port {
+   hdmi_in_con: endpoint {
+   };
+   };
+   };
+
vga {
compatible = "vga-connector";
 
@@ -260,6 +281,51 @@
};
 };
 
+&csi20 {
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   csi20_in: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   remote-endpoint = <&adv7482_txb>;
+   };
+   };
+   };
+};
+
+&csi40 {
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi40_in: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1 2 3 4>;
+   remote-endpoint = <&adv7482_txa>;
+   };
+   };
+   };
+};
+
+&cvbs_con {
+   port {
+   cvbs_in: endpoint {
+   remote-endpoint = <&adv7482_ain7>;
+   };
+   };
+};
+
 &du {
pinctrl-0 = <&du_pins>;
pinctrl-names = "default";
@@ -294,6 +360,14 @@
clock-frequency = <32768>;
 };
 
+&hdmi_in_con {
+   port {
+   hdmi_in: endpoint {
+   remote-endpoint = <&adv7482_hdmi>;
+   };
+   };
+};
+
 &hsusb {
status = "okay";
 };
@@ -358,6 +432,55 @@
 
shunt-resistor-micro-ohms = <5000>;
};
+
+   video-receiver@70 {
+   compatible = "adi,adv7482";
+   reg = <0x70>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   interrupt-parent = <&gpio6>;
+   interrupt-names = "intrq1", "intrq2";
+   interrupts = <30 IRQ_TYPE_LEVEL_LOW>,
+<31 IRQ_TYPE_LEVEL_LOW>;
+
+   port@7 {
+   reg = <7>;
+
+   adv7482_ain7: endpoint {
+   remote-endpoint = <&cvbs_in>;
+   };
+   };
+
+   port@8 {
+   reg = <8>;
+
+   adv7482_hdmi: endpoint {
+   remote-endpoint = <&hdmi_in>;
+   };
+   };
+
+   port@10 {
+   reg = <10>;
+
+   adv7482_txa: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1 2 3 4>;
+   remote-endpoint = <&csi40_in>;
+   };
+   };
+
+   port@11 {
+   reg = <11>;
+
+   adv7482_txb: endpoint {
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   remote-endpoint = <&csi20_in>;
+   };
+   };
+   };
 };
 
 &i2c_dvfs {
-- 
git-series 0.9.1


[PATCH v4 0/2] ADV748x HDMI/Analog video receiver

2017-06-12 Thread Kieran Bingham
From: Kieran Bingham 

This is a driver for the Analog Devices ADV748x device, and follows on from a
previous posting by Niklas Söderlund [0] of an earlier incarnation of this
driver.

Aside from a few bug fixes, and considerable refactoring this driver:
 - is refactored to multiple object files
 - defines multiple sub devices for the output paths.
 - has independent controls for both HDMI and Analog video paths

 - Specifies 'endpoint' matching instead of 'device' in async framework

These patches are based up on Niklas' pending RVin work [1] and Sakari's fwnode
series [2]

This version is the culmination of large refactoring and development, and I
believe is ready (or near) for mainline integration.

ADV748x
===
The ADV7481 and ADV7482 support two video pipelines which can run independently
of each other, with each pipeline terminating in a CSI-2 output: TXA (4-Lane)
and TXB (1-Lane)

The ADV7480 (Not yet included here), ADV7481, and ADV7482 are all derivatives,
with the following features

Analog   HDMI  MHL  4-Lane  1-Lane
  In  In CSI CSI
 ADV7480   XX X
 ADV7481  XXX X   X
 ADV7482  XX  X   X

Implementation
==

This RFC creates 4 entities. AFE (CVBS/Analog In), HDMI, TXA and TXB.  At probe
time, the DT is parsed to identify the endpoints for each of these nodes, and
those are used for async matching of the CSI2 (TXA/TXB) entities in the master
driver. The HDMI and AFE entities are then registered after a successful
registration of both the CSI2 entities.

(Known) Future Todo's
=

Further potential development areas include:
 - ADV7480 Support (No AFE)
 - MHL support (Not present on ADV7482)
 - EDID support
 - CEC Support
 - Configurable I2C addressing
 - Interrupt handling for format changes and hotplug detect.

However, this driver is functional without the above, and these developments
can be written when required.

References
==
[0] http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg05196.html
[1] https://git.ragnatech.se/linux rcar-vin-elinux-v7
[2] https://www.mail-archive.com/linux-media@vger.kernel.org/msg111332.html

v1/RFC:
 - Initial posting

v2:
 - Reworked DT parsing and entities

v3:
 - Refreshed with lots of fixups from Sakari's review comments

v4:
 - Many changes all round, following Laurent's review and extensive development
 - Now uses regmap
 - AFE port numbering has been changed to match the entity pads
 -

Kieran Bingham (2):
  media: i2c: adv748x: add adv748x driver
  arm64: dts: renesas: salvator-x: Add ADV7482 support

 Documentation/devicetree/bindings/media/i2c/adv748x.txt |  96 +-
 MAINTAINERS |   6 +-
 arch/arm64/boot/dts/renesas/salvator-x.dtsi | 123 +-
 drivers/media/i2c/Kconfig   |  11 +-
 drivers/media/i2c/Makefile  |   1 +-
 drivers/media/i2c/adv748x/Makefile  |   7 +-
 drivers/media/i2c/adv748x/adv748x-afe.c | 571 ++-
 drivers/media/i2c/adv748x/adv748x-core.c| 907 +-
 drivers/media/i2c/adv748x/adv748x-csi2.c| 323 +++-
 drivers/media/i2c/adv748x/adv748x-hdmi.c| 652 ++-
 drivers/media/i2c/adv748x/adv748x.h | 415 -
 11 files changed, 3112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt
 create mode 100644 drivers/media/i2c/adv748x/Makefile
 create mode 100644 drivers/media/i2c/adv748x/adv748x-afe.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-core.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-csi2.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-hdmi.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x.h

base-commit: 287d20fda775908006c5d64a15cd65244578ed01
-- 
git-series 0.9.1


Re: [PATCH v2] net: phy: Make phy_ethtool_ksettings_get return void

2017-06-12 Thread kbuild test robot
Hi Yuval,

[auto build test ERROR on net-next/master]
[also build test ERROR on next-20170609]
[cannot apply to v4.12-rc5]
[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/Yuval-Shaia/net-phy-Make-phy_ethtool_ksettings_get-return-void/20170613-005407
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c: In function 
'xgene_get_link_ksettings':
>> drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:134:10: error: void 
>> value not ignored as it ought to be
  return phy_ethtool_ksettings_get(phydev, cmd);
 ^~
   drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:140:11: error: void 
value not ignored as it ought to be
   return phy_ethtool_ksettings_get(phydev, cmd);
  ^~
--
   drivers/net/ethernet/apm/xgene-v2/ethtool.c: In function 
'xge_get_link_ksettings':
>> drivers/net/ethernet/apm/xgene-v2/ethtool.c:160:9: error: void value not 
>> ignored as it ought to be
 return phy_ethtool_ksettings_get(phydev, cmd);
^~
   drivers/net/ethernet/apm/xgene-v2/ethtool.c:161:1: warning: control reaches 
end of non-void function [-Wreturn-type]
}
^

vim +134 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c

e6ad7673 Iyappan Subramanian 2014-08-07  118strcpy(info->version, 
XGENE_DRV_VERSION);
e6ad7673 Iyappan Subramanian 2014-08-07  119snprintf(info->fw_version, 
ETHTOOL_FWVERS_LEN, "N/A");
e6ad7673 Iyappan Subramanian 2014-08-07  120sprintf(info->bus_info, "%s", 
pdev->name);
e6ad7673 Iyappan Subramanian 2014-08-07  121  }
e6ad7673 Iyappan Subramanian 2014-08-07  122  
36a19b29 Philippe Reynes 2016-09-11  123  static int 
xgene_get_link_ksettings(struct net_device *ndev,
36a19b29 Philippe Reynes 2016-09-11  124
struct ethtool_link_ksettings *cmd)
e6ad7673 Iyappan Subramanian 2014-08-07  125  {
e6ad7673 Iyappan Subramanian 2014-08-07  126struct xgene_enet_pdata *pdata 
= netdev_priv(ndev);
971d3a44 Philippe Reynes 2016-09-11  127struct phy_device *phydev = 
ndev->phydev;
36a19b29 Philippe Reynes 2016-09-11  128u32 supported;
e6ad7673 Iyappan Subramanian 2014-08-07  129  
326dde3e Iyappan Subramanian 2017-05-18  130if 
(phy_interface_mode_is_rgmii(pdata->phy_mode)) {
e6ad7673 Iyappan Subramanian 2014-08-07  131if (phydev == NULL)
e6ad7673 Iyappan Subramanian 2014-08-07  132return -ENODEV;
e6ad7673 Iyappan Subramanian 2014-08-07  133  
36a19b29 Philippe Reynes 2016-09-11 @134return 
phy_ethtool_ksettings_get(phydev, cmd);
5e6a024b Iyappan Subramanian 2014-10-13  135} else if (pdata->phy_mode == 
PHY_INTERFACE_MODE_SGMII) {
52d1fd99 Iyappan Subramanian 2016-07-25  136if (pdata->mdio_driver) 
{
52d1fd99 Iyappan Subramanian 2016-07-25  137if (!phydev)
52d1fd99 Iyappan Subramanian 2016-07-25  138return 
-ENODEV;
52d1fd99 Iyappan Subramanian 2016-07-25  139  
36a19b29 Philippe Reynes 2016-09-11  140return 
phy_ethtool_ksettings_get(phydev, cmd);
52d1fd99 Iyappan Subramanian 2016-07-25  141}
52d1fd99 Iyappan Subramanian 2016-07-25  142  

:: The code at line 134 was first introduced by commit
:: 36a19b299536746f5c01d7716dac962f831e4d38 net: ethernet: apm: xgene: use 
new api ethtool_{get|set}_link_ksettings

:: TO: Philippe Reynes 
:: CC: David S. Miller 

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


.config.gz
Description: application/gzip


Re: [PATCH v2] net: phy: Make phy_ethtool_ksettings_get return void

2017-06-12 Thread David Miller
From: David Miller 
Date: Mon, 12 Jun 2017 10:25:25 -0400 (EDT)

> From: Yuval Shaia 
> Date: Mon, 12 Jun 2017 17:15:08 +0300
> 
>> Make return value void since function never return meaningfull value
>> 
>> Signed-off-by: Yuval Shaia 
>> Acked-by: Sergei Shtylyov 
>> ---
>> v0 ->v1:
>>  * These files were missing in v0
>>  * drivers/net/ethernet/renesas/ravb_main.c
>>  * drivers/net/ethernet/renesas/sh_eth.c
>>  * drivers/net/ethernet/ti/netcp_ethss.c
>>  * Add Acked-by: Sergei Shtylyov
>> v1 -> v2:
>>  * Adjust to net-next tree
> 
> Applied, thank you.

Reverted, please test your build properly:

drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c: In function 
‘xgene_get_link_ksettings’:
drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:134:10: error: void value 
not ignored as it ought to be
   return phy_ethtool_ksettings_get(phydev, cmd);
  ^
drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:140:11: error: void value 
not ignored as it ought to be
return phy_ethtool_ksettings_get(phydev, cmd);
   ^
scripts/Makefile.build:302: recipe for target 
'drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.o' failed


Re: [PATCH v7 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

2017-06-12 Thread Niklas Söderlund
Hi Hans,

Thanks for your comments.

On 2017-05-29 13:16:23 +0200, Hans Verkuil wrote:
> On 05/24/2017 02:13 AM, Niklas Söderlund wrote:
> > From: Niklas Söderlund 
> > 
> > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> > supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> > hardware blocks are connected between the video sources and the video
> > grabbers (VIN).
> > 
> > Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >   drivers/media/platform/rcar-vin/Kconfig |  12 +
> >   drivers/media/platform/rcar-vin/Makefile|   1 +
> >   drivers/media/platform/rcar-vin/rcar-csi2.c | 867 
> > 
> >   3 files changed, 880 insertions(+)
> >   create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> > 
> > diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> > b/drivers/media/platform/rcar-vin/Kconfig
> > index af4c98b44d2e22cb..6875f30c1ae42631 100644
> > --- a/drivers/media/platform/rcar-vin/Kconfig
> > +++ b/drivers/media/platform/rcar-vin/Kconfig
> > @@ -1,3 +1,15 @@
> > +config VIDEO_RCAR_CSI2
> > +   tristate "R-Car MIPI CSI-2 Receiver"
> > +   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> > +   depends on ARCH_RENESAS || COMPILE_TEST
> > +   select V4L2_FWNODE
> > +   ---help---
> > + Support for Renesas R-Car MIPI CSI-2 receiver.
> > + Supports R-Car Gen3 SoCs.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called rcar-csi2.
> > +
> >   config VIDEO_RCAR_VIN
> > tristate "R-Car Video Input (VIN) Driver"
> > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> > MEDIA_CONTROLLER
> > diff --git a/drivers/media/platform/rcar-vin/Makefile 
> > b/drivers/media/platform/rcar-vin/Makefile
> > index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> > --- a/drivers/media/platform/rcar-vin/Makefile
> > +++ b/drivers/media/platform/rcar-vin/Makefile
> > @@ -1,3 +1,4 @@
> >   rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
> > +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
> >   obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > new file mode 100644
> > index ..1175f1fe4b139a13
> > --- /dev/null
> > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > @@ -0,0 +1,867 @@
> > +/*
> > + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> > + *
> > + * Copyright (C) 2017 Renesas Electronics Corp.
> > + *
> > + * This program is free software; you can redistribute  it and/or modify it
> > + * under  the terms of  the GNU General  Public License as published by the
> > + * Free Software Foundation;  either version 2 of the  License, or (at your
> > + * option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Register offsets and bits */
> > +
> > +/* Control Timing Select */
> > +#define TREF_REG   0x00
> > +#define TREF_TREF  (1 << 0)
> > +
> > +/* Software Reset */
> > +#define SRST_REG   0x04
> > +#define SRST_SRST  (1 << 0)
> > +
> > +/* PHY Operation Control */
> > +#define PHYCNT_REG 0x08
> > +#define PHYCNT_SHUTDOWNZ   (1 << 17)
> > +#define PHYCNT_RSTZ(1 << 16)
> > +#define PHYCNT_ENABLECLK   (1 << 4)
> > +#define PHYCNT_ENABLE_3(1 << 3)
> > +#define PHYCNT_ENABLE_2(1 << 2)
> > +#define PHYCNT_ENABLE_1(1 << 1)
> > +#define PHYCNT_ENABLE_0(1 << 0)
> > +
> > +/* Checksum Control */
> > +#define CHKSUM_REG 0x0c
> > +#define CHKSUM_ECC_EN  (1 << 1)
> > +#define CHKSUM_CRC_EN  (1 << 0)
> > +
> > +/*
> > + * Channel Data Type Select
> > + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> > + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> > + */
> > +#define VCDT_REG   0x10
> > +#define VCDT2_REG  0x14
> > +#define VCDT_VCDTN_EN  (1 << 15)
> > +#define VCDT_SEL_VC(n) (((n) & 0x3) << 8)
> > +#define VCDT_SEL_DTN_ON(1 << 6)
> > +#define VCDT_SEL_DT(n) (((n) & 0x3f) << 0)
> > +
> > +/* Frame Data Type Select */
> > +#define FRDT_REG   0x18
> > +
> > +/* Field Detection Control */
> > +#define FLD_REG0x1c
> > +#define FLD_FLD_NUM(n) (((n) & 0xff) << 16)
> > +#define FLD_FLD_EN4(1 << 3)
> > +#define FLD_FLD_EN3(1 << 2)
> > +#define FLD_FLD_EN2(1 << 1)
> > +#define 

Re: [PATCH v2] net: phy: Make phy_ethtool_ksettings_get return void

2017-06-12 Thread David Miller
From: Yuval Shaia 
Date: Mon, 12 Jun 2017 17:15:08 +0300

> Make return value void since function never return meaningfull value
> 
> Signed-off-by: Yuval Shaia 
> Acked-by: Sergei Shtylyov 
> ---
> v0 ->v1:
>   * These files were missing in v0
>   * drivers/net/ethernet/renesas/ravb_main.c
>   * drivers/net/ethernet/renesas/sh_eth.c
>   * drivers/net/ethernet/ti/netcp_ethss.c
>   * Add Acked-by: Sergei Shtylyov
> v1 -> v2:
>   * Adjust to net-next tree

Applied, thank you.


Re: [GIT PULL FOR renesas-drivers] mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC

2017-06-12 Thread Wolfram Sang

> > This pull request is based on mmc/next.
> 
> Unfortunately Ulf rebases mmc/next regularly, causing lots of conflicts.

Maybe we could ask him to stop doing that? I was taught "never rebase
anything going into linux-next" back then for exactly those reasons.



signature.asc
Description: PGP signature


[PATCH v2] net: phy: Make phy_ethtool_ksettings_get return void

2017-06-12 Thread Yuval Shaia
Make return value void since function never return meaningfull value

Signed-off-by: Yuval Shaia 
Acked-by: Sergei Shtylyov 
---
v0 ->v1:
* These files were missing in v0
* drivers/net/ethernet/renesas/ravb_main.c
* drivers/net/ethernet/renesas/sh_eth.c
* drivers/net/ethernet/ti/netcp_ethss.c
* Add Acked-by: Sergei Shtylyov
v1 -> v2:
* Adjust to net-next tree
---
 drivers/net/ethernet/broadcom/b44.c|  3 ++-
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |  3 ++-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c |  4 +++-
 drivers/net/ethernet/broadcom/tg3.c|  4 +++-
 drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c |  6 ++
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c  |  4 +++-
 drivers/net/ethernet/marvell/mv643xx_eth.c |  5 ++---
 drivers/net/ethernet/renesas/ravb_main.c   | 14 +++---
 drivers/net/ethernet/renesas/sh_eth.c  |  5 ++---
 drivers/net/ethernet/ti/cpsw.c |  9 +
 drivers/net/ethernet/ti/netcp_ethss.c  |  8 +++-
 drivers/net/phy/phy.c  | 10 +-
 drivers/net/usb/lan78xx.c  |  2 +-
 include/linux/phy.h|  4 ++--
 net/dsa/slave.c|  9 +
 15 files changed, 47 insertions(+), 43 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/b44.c 
b/drivers/net/ethernet/broadcom/b44.c
index 5b95bb4..9873d2d 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -1836,7 +1836,8 @@ static int b44_get_link_ksettings(struct net_device *dev,
 
if (bp->flags & B44_FLAG_EXTERNAL_PHY) {
BUG_ON(!dev->phydev);
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c 
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 50d88d3..34ebb40 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1453,7 +1453,8 @@ static int bcm_enet_get_link_ksettings(struct net_device 
*dev,
if (priv->has_phy) {
if (!dev->phydev)
return -ENODEV;
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
} else {
cmd->base.autoneg = 0;
cmd->base.speed = (priv->force_speed_100) ?
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index a205a9f..daca1c9 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -477,7 +477,9 @@ static int bcmgenet_get_link_ksettings(struct net_device 
*dev,
if (!priv->phydev)
return -ENODEV;
 
-   return phy_ethtool_ksettings_get(priv->phydev, cmd);
+   phy_ethtool_ksettings_get(priv->phydev, cmd);
+
+   return 0;
 }
 
 static int bcmgenet_set_link_ksettings(struct net_device *dev,
diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 537d571..d600c41 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12097,7 +12097,9 @@ static int tg3_get_link_ksettings(struct net_device 
*dev,
if (!(tp->phy_flags & TG3_PHYFLG_IS_CONNECTED))
return -EAGAIN;
phydev = mdiobus_get_phy(tp->mdio_bus, tp->phy_addr);
-   return phy_ethtool_ksettings_get(phydev, cmd);
+   phy_ethtool_ksettings_get(phydev, cmd);
+
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
index 15571e2..aad825088 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
@@ -75,16 +75,14 @@ static char dpaa_stats_global[][ETH_GSTRING_LEN] = {
 static int dpaa_get_link_ksettings(struct net_device *net_dev,
   struct ethtool_link_ksettings *cmd)
 {
-   int err;
-
if (!net_dev->phydev) {
netdev_dbg(net_dev, "phy device not initialized\n");
return 0;
}
 
-   err = phy_ethtool_ksettings_get(net_dev->phydev, cmd);
+   phy_ethtool_ksettings_get(net_dev->phydev, cmd);
 
-   return err;
+   return 0;
 }
 
 static int dpaa_set_link_ksettings(struct net_device *net_dev,
diff --git a/drivers/net/ethernet/freescale/ucc_geth_ethtool.c 
b/drivers/net/ethernet/freescale/ucc_geth_ethtool.c
index b642990..4df282e 100644
--- a/dr

Re: [PATCH v8 3/8] media: i2c: max2175: Add MAX2175 support

2017-06-12 Thread Geert Uytterhoeven
Hi Hans,

On Mon, Jun 12, 2017 at 3:50 PM, Hans Verkuil  wrote:
> On 06/12/2017 03:26 PM, Ramesh Shanmugasundaram wrote:
>> This patch adds driver support for the MAX2175 chip. This is Maxim
>> Integrated's RF to Bits tuner front end chip designed for software-defined
>> radio solutions. This driver exposes the tuner as a sub-device instance
>> with standard and custom controls to configure the device.
>>
>> Signed-off-by: Ramesh Shanmugasundaram
>> 
>
>
> Sorry, got this sparse warning:
>
> /home/hans/work/build/media-git/drivers/media/i2c/max2175.c: In function
> 'max2175_poll_timeout':
> /home/hans/work/build/media-git/drivers/media/i2c/max2175.c:385:21: warning:
> '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
> 1000, timeout_ms * 1000);
>   ~~~^~~
>
> The smatch warnings are now gone.
>
> If you can make a v9 for just this patch?

This is not an issue with the max2175 driver, but with the
regmap_read_poll_timeout() macro:

#define regmap_read_poll_timeout(map, addr, val, cond, sleep_us,
timeout_us) \
({ \
...
if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \

For increased safety, and to avoid this warning, "timeout_us" should be
inside parentheses.

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] sh_eth: add support for changing MTU

2017-06-12 Thread David Miller
From: Niklas Söderlund 
Date: Mon, 12 Jun 2017 10:39:03 +0200

> The hardware supports the MTU to be changed and the driver it self is
> somewhat prepared to support this. This patch hooks up the callbacks to
> be able to change the MTU from user-space.
> 
> Signed-off-by: Niklas Söderlund 
> Acked-by: Sergei Shtylyov 

Applied to net-next, thanks.


Re: [PATCH v1] net/phy: Make phy_ethtool_ksettings_get return void

2017-06-12 Thread David Miller
From: Yuval Shaia 
Date: Mon, 12 Jun 2017 10:42:33 +0300

> Make return value void since function never return meaningfull value
> 
> Signed-off-by: Yuval Shaia 
> Acked-by: Sergei Shtylyov 
> ---
> Re-sending since last time forgot to add netdev-list
> v0 ->v1:
>   * These files were missing in v0
>   * drivers/net/ethernet/renesas/ravb_main.c
>   * drivers/net/ethernet/renesas/sh_eth.c
>   * drivers/net/ethernet/ti/netcp_ethss.c
>   * Add Acked-by: Sergei Shtylyov

This doesn't apply cleanly to net-next at all.

Please respin against an uptodate net-next tree, thank you.


Re: [PATCH v8 3/8] media: i2c: max2175: Add MAX2175 support

2017-06-12 Thread Hans Verkuil

On 06/12/2017 03:26 PM, Ramesh Shanmugasundaram wrote:

This patch adds driver support for the MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 


Sorry, got this sparse warning:

/home/hans/work/build/media-git/drivers/media/i2c/max2175.c: In function 
'max2175_poll_timeout':
/home/hans/work/build/media-git/drivers/media/i2c/max2175.c:385:21: warning: '*' in boolean context, suggest '&&' instead 
[-Wint-in-bool-context]

1000, timeout_ms * 1000);
  ~~~^~~

The smatch warnings are now gone.

If you can make a v9 for just this patch?

Regards,

Hans


[PATCH v8 1/8] media: v4l2-ctrls: Reserve controls for MAX217X

2017-06-12 Thread Ramesh Shanmugasundaram
Reserve controls for MAX217X RF to Bits tuner family. These hybrid
radio receiver chips are highly programmable and hence reserving 32
controls.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Laurent Pinchart 
---
 include/uapi/linux/v4l2-controls.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 0d2e1e01fbd5..83b28b41123f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -180,6 +180,11 @@ enum v4l2_colorfx {
  * We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_TC358743_BASE(V4L2_CID_USER_BASE + 0x1080)
 
+/* The base for the max217x driver controls.
+ * We reserve 32 controls for this driver
+ */
+#define V4L2_CID_USER_MAX217X_BASE (V4L2_CID_USER_BASE + 0x1090)
+
 /* MPEG-class control IDs */
 /* The MPEG controls are applicable to all codec controls
  * and the 'MPEG' part of the define is historical */
-- 
2.12.2



[PATCH v8 4/8] media: Add new SDR formats PC16, PC18 & PC20

2017-06-12 Thread Ramesh Shanmugasundaram
This patch adds support for the three new SDR formats. These formats
were prefixed with "planar" indicating I & Q data are not interleaved
as in other formats. Here, I & Q data constitutes the top half and bottom
half of the received buffer respectively.

V4L2_SDR_FMT_PCU16BE - 14-bit complex (I & Q) unsigned big-endian sample
inside 16-bit. V4L2 FourCC: PC16

V4L2_SDR_FMT_PCU18BE - 16-bit complex (I & Q) unsigned big-endian sample
inside 18-bit. V4L2 FourCC: PC18

V4L2_SDR_FMT_PCU20BE - 18-bit complex (I & Q) unsigned big-endian sample
inside 20-bit. V4L2 FourCC: PC20

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
 include/uapi/linux/videodev2.h   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 4f27cfa134a1..ce40183d9daa 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1229,6 +1229,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
+   case V4L2_SDR_FMT_PCU16BE:  descr = "Planar Complex U16BE"; break;
+   case V4L2_SDR_FMT_PCU18BE:  descr = "Planar Complex U18BE"; break;
+   case V4L2_SDR_FMT_PCU20BE:  descr = "Planar Complex U20BE"; break;
case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data"; 
break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2b8feb86d09e..45cf7359822c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -669,6 +669,9 @@ struct v4l2_pix_format {
 #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /* complex 
s8 */
 #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /* complex 
s14le */
 #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /* real 
u12le */
+#define V4L2_SDR_FMT_PCU16BE v4l2_fourcc('P', 'C', '1', '6') /* planar 
complex u16be */
+#define V4L2_SDR_FMT_PCU18BE v4l2_fourcc('P', 'C', '1', '8') /* planar 
complex u18be */
+#define V4L2_SDR_FMT_PCU20BE v4l2_fourcc('P', 'C', '2', '0') /* planar 
complex u20be */
 
 /* Touch formats - used for Touch devices */
 #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 
16-bit signed deltas */
-- 
2.12.2



[PATCH v8 7/8] media: platform: rcar_drif: Add DRIF support

2017-06-12 Thread Ramesh Shanmugasundaram
This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
device represents a channel and each channel can have one or two
sub-channels respectively depending on the target board.

DRIF supports only Rx functionality. It receives samples from a RF
frontend tuner chip it is interfaced with. The combination of DRIF and the
tuner device, which is registered as a sub-device, determines the receive
sample rate and format.

In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
the tuner device, which can be provided by a third party vendor. DRIF acts
as a slave device and the tuner device acts as a master transmitting the
samples. The driver allows asynchronous binding of a tuner device that
is registered as a v4l2 sub-device. The driver can learn about the tuner
it is interfaced with based on port endpoint properties of the device in
device tree. The V4L2 SDR device inherits the controls exposed by the
tuner device.

The device can also be configured to use either one or both of the data
pins at runtime based on the master (tuner) configuration.

Signed-off-by: Ramesh Shanmugasundaram 
---
v8:
 - Fixed smatch warnings in two places.
v7:
 - Added COMPILE_TEST to rcar_drif (Hans added it in last pull request).
v6:
 - Used fwnode_ apis wherever applicable.
 - Cleaned up debug prints.
---
 drivers/media/platform/Kconfig |   25 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_drif.c | 1498 
 3 files changed, 1524 insertions(+)
 create mode 100644 drivers/media/platform/rcar_drif.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 288d3b0dc812..a2fc37d0d29e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -538,3 +538,28 @@ config VIDEO_STI_HDMI_CEC
  between compatible devices.
 
 endif #CEC_PLATFORM_DRIVERS
+
+menuconfig SDR_PLATFORM_DRIVERS
+   bool "SDR platform devices"
+   depends on MEDIA_SDR_SUPPORT
+   default n
+   ---help---
+ Say Y here to enable support for platform-specific SDR Drivers.
+
+if SDR_PLATFORM_DRIVERS
+
+config VIDEO_RCAR_DRIF
+   tristate "Renesas Digitial Radio Interface (DRIF)"
+   depends on VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select VIDEOBUF2_VMALLOC
+   ---help---
+ Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is Digital
+ Radio Interface that interfaces with an RF front end chip. It is a
+ receiver of digital data which uses DMA to transfer received data to
+ a configured location for an application to use.
+
+ To compile this driver as a module, choose M here; the module
+ will be called rcar_drif.
+
+endif # SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c3588d570f5d..4cfbb9d0c6cf 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
+obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/rcar_drif.c 
b/drivers/media/platform/rcar_drif.c
new file mode 100644
index ..522364ff0d5d
--- /dev/null
+++ b/drivers/media/platform/rcar_drif.c
@@ -0,0 +1,1498 @@
+/*
+ * R-Car Gen3 Digital Radio Interface (DRIF) driver
+ *
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * The R-Car DRIF is a receive only MSIOF like controller with an
+ * external master device driving the SCK. It receives data into a FIFO,
+ * then this driver uses the SYS-DMAC engine to move the data from
+ * the device to memory.
+ *
+ * Each DRIF channel DRIFx (as per datasheet) contains two internal
+ * channels DRIFx0 & DRIFx1 within itself with each having its own resources
+ * like module clk, register set, irq and dma. These internal channels share
+ * common CLK & SYNC from master. The two data pins D0 & D1 shall be
+ * considered to represent the two internal channels. This internal split
+ * is not visible to the master device.
+ *
+ * Depending on the master device, a DRIF channel can use
+ *  (1)

[PATCH v8 8/8] MAINTAINERS: Add entry for R-Car DRIF & MAX2175 drivers

2017-06-12 Thread Ramesh Shanmugasundaram
Add maintainter entry for the R-Car DRIF and MAX2175 drivers.

Signed-off-by: Ramesh Shanmugasundaram 
---
 MAINTAINERS | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bdd1fe5..cfa78fe5142a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8031,6 +8031,16 @@ S:   Maintained
 F: Documentation/hwmon/max20751
 F: drivers/hwmon/max20751.c
 
+MAX2175 SDR TUNER DRIVER
+M: Ramesh Shanmugasundaram 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/max2175.txt
+F: Documentation/media/v4l-drivers/max2175.rst
+F: drivers/media/i2c/max2175*
+F: include/uapi/linux/max2175.h
+
 MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
 L: linux-hw...@vger.kernel.org
 S: Orphan
@@ -8111,6 +8121,15 @@ L:   linux-...@vger.kernel.org
 S: Maintained
 F: drivers/iio/dac/cio-dac.c
 
+MEDIA DRIVERS FOR RENESAS - DRIF
+M: Ramesh Shanmugasundaram 
+L: linux-me...@vger.kernel.org
+L: linux-renesas-soc@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Supported
+F: Documentation/devicetree/bindings/media/renesas,drif.txt
+F: drivers/media/platform/rcar_drif.c
+
 MEDIA DRIVERS FOR RENESAS - FCP
 M: Laurent Pinchart 
 L: linux-me...@vger.kernel.org
-- 
2.12.2



[PATCH v8 3/8] media: i2c: max2175: Add MAX2175 support

2017-06-12 Thread Ramesh Shanmugasundaram
This patch adds driver support for the MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 
---
v8:
 - Fixed smatch warnings in max2175_load_from_rom().
v7:
 - Made I2S enable/disable control as private (Mauro).
v6:
 - Addressed Sakari's comments. They are:
- Added uapi header file.
- Added newline at the end of the function before return.
- Cleaned up header file inclusion.
- Used fwnode_ apis whereever applicable.
- Cleaned up debug statements.
- Removed separate dir for max2175.
v5:
 - sck -> Sample clock is clarified in driver documentation (Hans)
 - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
---
 Documentation/media/v4l-drivers/index.rst   |1 +
 Documentation/media/v4l-drivers/max2175.rst |   62 ++
 drivers/media/i2c/Kconfig   |   12 +
 drivers/media/i2c/Makefile  |2 +
 drivers/media/i2c/max2175.c | 1453 +++
 drivers/media/i2c/max2175.h |  109 ++
 include/uapi/linux/max2175.h|   28 +
 7 files changed, 1667 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175.c
 create mode 100644 drivers/media/i2c/max2175.h
 create mode 100644 include/uapi/linux/max2175.h

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 90fe22a6414a..2e24d6806052 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
ivtv
+   max2175
meye
omap3isp
omap4_camera
diff --git a/Documentation/media/v4l-drivers/max2175.rst 
b/Documentation/media/v4l-drivers/max2175.rst
new file mode 100644
index ..04478c25d57a
--- /dev/null
+++ b/Documentation/media/v4l-drivers/max2175.rst
@@ -0,0 +1,62 @@
+Maxim Integrated MAX2175 RF to bits tuner driver
+
+
+The MAX2175 driver implements the following driver-specific controls:
+
+``V4L2_CID_MAX2175_I2S_ENABLE``
+---
+Enable/Disable I2S output of the tuner. This is a private control
+that can be accessed only using the subdev interface.
+Refer to Documentation/media/kapi/v4l2-controls for more details.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - I2S output is disabled.
+* - ``(1)``
+  - I2S output is enabled.
+
+``V4L2_CID_MAX2175_HSLS``
+-
+The high-side/low-side (HSLS) control of the tuner for a given band.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - The LO frequency position is below the desired frequency.
+* - ``(1)``
+  - The LO frequency position is above the desired frequency.
+
+``V4L2_CID_MAX2175_RX_MODE (menu)``
+---
+The Rx mode controls a number of preset parameters of the tuner like
+sample clock (sck), sampling rate etc. These multiple settings are
+provided under one single label called Rx mode in the datasheet. The
+list below shows the supported modes with a brief description.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``"Europe modes"``
+* - ``"FM 1.2" (0)``
+  - This configures FM band with a sample rate of 0.512 million
+samples/sec with a 10.24 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures VHF band with a sample rate of 2.048 million
+samples/sec with a 32.768 MHz sck.
+
+* - ``"North America modes"``
+* - ``"FM 1.0" (0)``
+  - This configures FM band with a sample rate of 0.7441875 million
+samples/sec with a 14.88375 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures FM band with a sample rate of 0.372 million
+samples/sec with a 7.441875 MHz sck.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e2475c82..c0e6e78883b0 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -796,6 +796,18 @@ config VIDEO_SAA6752HS
  To compile this driver as a module, choose M here: the
  module will be called saa6752hs.
 
+comment "SDR tuner chips"
+
+config SDR_MAX2175
+   tristate "Maxim 2175 RF to Bits tuner"
+   depends on VIDEO_V4L2 && MEDIA_SDR_SUPPORT && I2C
+   ---help---
+ Support for Maxim 2175 tuner. It is an advanced analog/digital
+ radio receiver with RF-to-Bits front-end designed for SDR solutions.
+
+

[PATCH v8 5/8] doc_rst: media: New SDR formats PC16, PC18 & PC20

2017-06-12 Thread Ramesh Shanmugasundaram
This patch adds documentation for the three new SDR formats

V4L2_SDR_FMT_PCU16BE
V4L2_SDR_FMT_PCU18BE
V4L2_SDR_FMT_PCU20BE

Signed-off-by: Ramesh Shanmugasundaram 
---
 .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst  | 54 +
 Documentation/media/uapi/v4l/sdr-formats.rst   |  3 ++
 4 files changed, 167 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
new file mode 100644
index ..2de1b1a0f517
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU16BE:
+
+**
+V4L2_SDR_FMT_PCU16BE ('PC16')
+**
+
+Planar complex unsigned 16-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 16 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[13:6]`
+  -  I'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[13:6]`
+  -  I'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[13:6]`
+  -  Q'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[13:6]`
+  -  Q'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
new file mode 100644
index ..da8b26bf6b95
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU18BE:
+
+**
+V4L2_SDR_FMT_PCU18BE ('PC18')
+**
+
+Planar complex unsigned 18-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 18 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[17:10]`
+  -  I'\ :sub:`0[9:2]`
+  -  I'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[17:10]`
+  -  I'\ :sub:`1[9:2]`
+  -  I'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[17:10]`
+  -  Q'\ :sub:`0[9:2]`
+  -  Q'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[17:10]`
+  -  Q'\ :sub:`1[9:2]`
+  -  Q'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
new file mode 100644
index ..5499eed39477
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
@@ -0,0 +1,54 @@
+.. -*- coding: utf-8; mode: rst -*-
+.. _V4L2-SDR-FMT-PCU20BE:
+
+**
+V4L2_SDR_FMT_PCU20BE ('PC20')
+**
+
+Planar complex unsigned 20-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 20 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within

[PATCH v8 0/8] Add V4L2 SDR (DRIF & MAX2175) driver

2017-06-12 Thread Ramesh Shanmugasundaram
Hi Mauro, Hans,

This patch set contains two drivers
 - Renesas R-Car Digital Radio Interface (DRIF) driver
 - Maxim's MAX2175 RF to Bits tuner driver

These patches were based on top of media_tree.
commit: 47f910f0e0deb880c2114811f7ea1ec115a19ee4

These two drivers combined together expose a V4L2 SDR device that is compliant
with the V4L2 framework [1]. Agreed review comments are incorporated in this
series.

The rcar_drif device is modelled using "renesas,bonding" property. The
discussion on this property is available here [2].

Change history:

v7 -> v8:
 - Added MAINTAINERS entry for both drivers
 - Fixed smatch warnings on both drivers (Thank you Hans)

v6 -> v7:
 - MAX2175 I2S enable/disable control is made private (Mauro #v4l)
 - Added COMPILE_TEST to rcar_drif in Kconfig (Hans)

v5 -> v6:
 - Addressed Sakari's comments & rebased to his branch.
 - Used fwnode_ instead of of_ apis whereever applicable.

v4 -> v5:
 - Minor documentation changes. Refer individual patches.

v3 -> v4:
 - Added ACKs
rcar_drif:
 - Incorporated a number of review comments from Laurent on DRIF driver.
 - Addressed comments from Rob and Laurent on bindings.
max2175:
 - Minor changes addressing Hans and Laurent's comments

v2 -> v3:
rcar_drif:
 - Reduced DRIF DT properties to expose tested I2S mode only (Hans - discussion 
on #v4l)
 - Fixed error path clean up of ctrl_hdl on rcar_drif

v1 -> v2:
 - SDR formats renamed as "planar" instead of sliced (Hans)
 - Documentation formatting correction (Laurent)

 rcar_drif:
 - DT model using "bonding" property
 - Addressed Laurent's coments on bindings - DT optional parameters rename & 
rework
 - Addressed Han's comments on driver
 - Addressed Geert's comments on DT

 max2175:
 - Avoided scaling using method proposed by Antti. Thanks
 - Bindings is a separate patch (Rob)
 - Addressed Rob's comment on bindings
 - Added Custom controls documentation (Laurent)

[1] v4l2-compliance report:
root@salvator-x:~# v4l2-compliance -S /dev/swradio0
v4l2-compliance SHA   : d57bb8af0c71d82b702e35a7362aa077189dd593

Driver Info:
Driver name   : rcar_drif
Card type : R-Car DRIF
Bus info  : platform:R-Car DRIF
Driver version: 4.12.0
Capabilities  : 0x8531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/swradio0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second sdr open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 1

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 2

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)

[PATCH v8 6/8] dt-bindings: media: Add Renesas R-Car DRIF binding

2017-06-12 Thread Ramesh Shanmugasundaram
Add binding documentation for Renesas R-Car Digital Radio Interface
(DRIF) controller.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/renesas,drif.txt | 176 +
 1 file changed, 176 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt 
b/Documentation/devicetree/bindings/media/renesas,drif.txt
new file mode 100644
index ..39516b94c28f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
@@ -0,0 +1,176 @@
+Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
+
+
+R-Car Gen3 DRIF is a SPI like receive only slave device. A general
+representation of DRIF interfacing with a master device is shown below.
+
++-++-+
+| |-SCK--->|CLK  |
+|   Master|-SS>|SYNC  DRIFn (slave)  |
+| |-SD0--->|D0   |
+| |-SD1--->|D1   |
++-++-+
+
+As per datasheet, each DRIF channel (drifn) is made up of two internal
+channels (drifn0 & drifn1). These two internal channels share the common
+CLK & SYNC. Each internal channel has its own dedicated resources like
+irq, dma channels, address space & clock. This internal split is not
+visible to the external master device.
+
+The device tree model represents each internal channel as a separate node.
+The internal channels sharing the CLK & SYNC are tied together by their
+phandles using a property called "renesas,bonding". For the rest of
+the documentation, unless explicitly stated, the word channel implies an
+internal channel.
+
+When both internal channels are enabled they need to be managed together
+as one (i.e.) they cannot operate alone as independent devices. Out of the
+two, one of them needs to act as a primary device that accepts common
+properties of both the internal channels. This channel is identified by a
+property called "renesas,primary-bond".
+
+To summarize,
+   - When both the internal channels that are bonded together are enabled,
+ the zeroth channel is selected as primary-bond. This channels accepts
+ properties common to all the members of the bond.
+   - When only one of the bonded channels need to be enabled, the property
+ "renesas,bonding" or "renesas,primary-bond" will have no effect. That
+ enabled channel can act alone as any other independent device.
+
+Required properties of an internal channel:
+---
+- compatible:  "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 
SoC.
+   "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible 
device.
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
+- reg: offset and length of that channel.
+- interrupts: associated with that channel.
+- clocks: phandle and clock specifier of that channel.
+- clock-names: clock input name string: "fck".
+- dmas: phandles to the DMA channels.
+- dma-names: names of the DMA channel: "rx".
+- renesas,bonding: phandle to the other channel.
+
+Optional properties of an internal channel:
+---
+- power-domains: phandle to the respective power domain.
+
+Required properties of an internal channel when:
+   - It is the only enabled channel of the bond (or)
+   - If it acts as primary among enabled bonds
+
+- pinctrl-0: pin control group to be used for this channel.
+- pinctrl-names: must be "default".
+- renesas,primary-bond: empty property indicating the channel acts as primary
+   among the bonded channels.
+- port: child port node corresponding to the data input, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional endpoint property:
+---
+- sync-active: Indicates sync signal polarity, 0/1 for low/high respectively.
+  This property maps to SYNCAC bit in the hardware manual. The
+  default is 1 (active high).
+
+Example:
+
+
+(1) Both internal channels enabled:
+---
+
+When interfacing with a third party tuner device with two data pins as shown
+below.
+
++-++-+
+| |-SCK--->|CLK  |
+|   Master|-SS>|SYNC  DRIFn (slave)  |
+|  

[PATCH v8 2/8] dt-bindings: media: Add MAX2175 binding description

2017-06-12 Thread Ramesh Shanmugasundaram
Add device tree binding documentation for MAX2175 RF to bits tuner
device.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/i2c/max2175.txt  | 59 ++
 .../devicetree/bindings/property-units.txt |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
b/Documentation/devicetree/bindings/media/i2c/max2175.txt
new file mode 100644
index ..02b4e9cd7b1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
@@ -0,0 +1,59 @@
+Maxim Integrated MAX2175 RF to Bits tuner
+-
+
+The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
+RF to Bits® front-end designed for software-defined radio solutions.
+
+Required properties:
+
+- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
+- clocks: clock specifier.
+- port: child port node corresponding to the I2S output, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional properties:
+
+- maxim,master   : phandle to the master tuner if it is a slave. This
+   is used to define two tuners in diversity mode
+   (1 master, 1 slave). By default each tuner is an
+   individual master.
+- maxim,refout-load   : load capacitance value (in picofarads) on reference
+   output drive level. The possible load values are:
+0 (default - refout disabled)
+   10
+   20
+   30
+   40
+   60
+   70
+- maxim,am-hiz-filter : empty property indicates the AM Hi-Z filter is used
+   in this hardware for AM antenna input.
+
+Example:
+
+
+Board specific DTS file
+
+/* Fixed XTAL clock node */
+maxim_xtal: clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <36864000>;
+};
+
+/* A tuner device instance under i2c bus */
+max2175_0: tuner@60 {
+   compatible = "maxim,max2175";
+   reg = <0x60>;
+   clocks = <&maxim_xtal>;
+   maxim,refout-load = <10>;
+
+   port {
+   max2175_0_ep: endpoint {
+   remote-endpoint = <&slave_rx_device>;
+   };
+   };
+
+};
diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d79f6c0..7c9f6ee918f1 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -28,6 +28,7 @@ Electricity
 -ohms  : Ohms
 -micro-ohms: micro Ohms
 -microvolt : micro volts
+-picofarads: picofarads
 
 Temperature
 
-- 
2.12.2



Re: [PATCH 1/2] soc: renesas: rcar-sysc: Use GENPD_FLAG_ALWAYS_ON

2017-06-12 Thread Ulf Hansson
On 12 June 2017 at 11:23, Geert Uytterhoeven  wrote:
> Improve handling of always-on PM domains by using the
> GENPD_FLAG_ALWAYS_ON flag introduced in commit ffaa42e8a40b7f10 ("PM /
> Domains: Enable users of genpd to specify always on PM domains").
>
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  drivers/soc/renesas/rcar-sysc.c | 28 
>  drivers/soc/renesas/rcar-sysc.h |  2 --
>  2 files changed, 4 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
> index dcad5c42a5e81c87..7c8da3c90011422f 100644
> --- a/drivers/soc/renesas/rcar-sysc.c
> +++ b/drivers/soc/renesas/rcar-sysc.c
> @@ -181,17 +181,6 @@ static int rcar_sysc_pd_power_off(struct 
> generic_pm_domain *genpd)
> struct rcar_sysc_pd *pd = to_rcar_pd(genpd);
>
> pr_debug("%s: %s\n", __func__, genpd->name);
> -
> -   if (pd->flags & PD_NO_CR) {
> -   pr_debug("%s: Cannot control %s\n", __func__, genpd->name);
> -   return -EBUSY;
> -   }
> -
> -   if (pd->flags & PD_BUSY) {
> -   pr_debug("%s: %s busy\n", __func__, genpd->name);
> -   return -EBUSY;
> -   }
> -
> return rcar_sysc_power_down(&pd->ch);
>  }
>
> @@ -200,12 +189,6 @@ static int rcar_sysc_pd_power_on(struct 
> generic_pm_domain *genpd)
> struct rcar_sysc_pd *pd = to_rcar_pd(genpd);
>
> pr_debug("%s: %s\n", __func__, genpd->name);
> -
> -   if (pd->flags & PD_NO_CR) {
> -   pr_debug("%s: Cannot control %s\n", __func__, genpd->name);
> -   return 0;
> -   }
> -
> return rcar_sysc_power_up(&pd->ch);
>  }
>
> @@ -223,8 +206,7 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd 
> *pd)
>  * only be turned off if the CPU is not in use.
>  */
> pr_debug("PM domain %s contains %s\n", name, "CPU");
> -   pd->flags |= PD_BUSY;
> -   gov = &pm_domain_always_on_gov;
> +   genpd->flags |= GENPD_FLAG_ALWAYS_ON;
> } else if (pd->flags & PD_SCU) {
> /*
>  * This domain contains an SCU and cache-controller, and
> @@ -232,19 +214,17 @@ static void __init rcar_sysc_pd_setup(struct 
> rcar_sysc_pd *pd)
>  * not in use.
>  */
> pr_debug("PM domain %s contains %s\n", name, "SCU");
> -   pd->flags |= PD_BUSY;
> -   gov = &pm_domain_always_on_gov;
> +   genpd->flags |= GENPD_FLAG_ALWAYS_ON;
> } else if (pd->flags & PD_NO_CR) {
> /*
>  * This domain cannot be turned off.
>  */
> -   pd->flags |= PD_BUSY;
> -   gov = &pm_domain_always_on_gov;
> +   genpd->flags |= GENPD_FLAG_ALWAYS_ON;
> }
>
> if (!(pd->flags & (PD_CPU | PD_SCU))) {
> /* Enable Clock Domain for I/O devices */
> -   genpd->flags = GENPD_FLAG_PM_CLK;
> +   genpd->flags |= GENPD_FLAG_PM_CLK;
> if (has_cpg_mstp) {
> genpd->attach_dev = cpg_mstp_attach_dev;
> genpd->detach_dev = cpg_mstp_detach_dev;
> diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
> index 07edb049a401196c..1a5bebaf54ba191c 100644
> --- a/drivers/soc/renesas/rcar-sysc.h
> +++ b/drivers/soc/renesas/rcar-sysc.h
> @@ -20,8 +20,6 @@
>  #define PD_SCU BIT(1)  /* Area contains SCU and L2 cache */
>  #define PD_NO_CR   BIT(2)  /* Area lacks PWR{ON,OFF}CR registers */
>
> -#define PD_BUSYBIT(3)  /* Busy, for internal use only */
> -
>  #define PD_CPU_CR  PD_CPU/* CPU area has CR (R-Car H1) */
>  #define PD_CPU_NOCRPD_CPU | PD_NO_CR /* CPU area lacks CR (R-Car Gen2/3) 
> */
>  #define PD_ALWAYS_ON   PD_NO_CR  /* Always-on area */
> --
> 2.7.4
>


Re: [PATCH 2/2] ARM: shmobile: pm-rmobile: Use GENPD_FLAG_ALWAYS_ON

2017-06-12 Thread Ulf Hansson
On 12 June 2017 at 11:23, Geert Uytterhoeven  wrote:
> Improve handling of always-on PM domains by using the
> GENPD_FLAG_ALWAYS_ON flag introduced in commit ffaa42e8a40b7f10 ("PM /
> Domains: Enable users of genpd to specify always on PM domains").
>
> Note that the PM domain containing the serial console is still handled
> locally.
>
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe


> ---
>  arch/arm/mach-shmobile/pm-rmobile.c | 19 ---
>  1 file changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/pm-rmobile.c 
> b/arch/arm/mach-shmobile/pm-rmobile.c
> index 175bd3d91ebcbcb4..e5fa6a3cf1ddf159 100644
> --- a/arch/arm/mach-shmobile/pm-rmobile.c
> +++ b/arch/arm/mach-shmobile/pm-rmobile.c
> @@ -130,7 +130,7 @@ static void rmobile_init_pm_domain(struct 
> rmobile_pm_domain *rmobile_pd)
> struct generic_pm_domain *genpd = &rmobile_pd->genpd;
> struct dev_power_governor *gov = rmobile_pd->gov;
>
> -   genpd->flags = GENPD_FLAG_PM_CLK;
> +   genpd->flags |= GENPD_FLAG_PM_CLK;
> genpd->dev_ops.active_wakeup= rmobile_pd_active_wakeup;
> genpd->power_off= rmobile_pd_power_down;
> genpd->power_on = rmobile_pd_power_up;
> @@ -140,14 +140,6 @@ static void rmobile_init_pm_domain(struct 
> rmobile_pm_domain *rmobile_pd)
> pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
>  }
>
> -static int rmobile_pd_suspend_busy(void)
> -{
> -   /*
> -* This domain should not be turned off.
> -*/
> -   return -EBUSY;
> -}
> -
>  static int rmobile_pd_suspend_console(void)
>  {
> /*
> @@ -260,8 +252,7 @@ static void __init rmobile_setup_pm_domain(struct 
> device_node *np,
>  * only be turned off if the CPU is not in use.
>  */
> pr_debug("PM domain %s contains CPU\n", name);
> -   pd->gov = &pm_domain_always_on_gov;
> -   pd->suspend = rmobile_pd_suspend_busy;
> +   pd->genpd.flags |= GENPD_FLAG_ALWAYS_ON;
> break;
>
> case PD_CONSOLE:
> @@ -277,8 +268,7 @@ static void __init rmobile_setup_pm_domain(struct 
> device_node *np,
>  * is not in use.
>  */
> pr_debug("PM domain %s contains Coresight-ETM\n", name);
> -   pd->gov = &pm_domain_always_on_gov;
> -   pd->suspend = rmobile_pd_suspend_busy;
> +   pd->genpd.flags |= GENPD_FLAG_ALWAYS_ON;
> break;
>
> case PD_MEMCTL:
> @@ -287,8 +277,7 @@ static void __init rmobile_setup_pm_domain(struct 
> device_node *np,
>  * should only be turned off if memory is not in use.
>  */
> pr_debug("PM domain %s contains MEMCTL\n", name);
> -   pd->gov = &pm_domain_always_on_gov;
> -   pd->suspend = rmobile_pd_suspend_busy;
> +   pd->genpd.flags |= GENPD_FLAG_ALWAYS_ON;
> break;
>
> case PD_NORMAL:
> --
> 2.7.4
>


Re: [PATCH] ravb: add wake-on-lan support via magic packet

2017-06-12 Thread Geert Uytterhoeven
Hi Niklas,

On Mon, Jun 12, 2017 at 1:32 PM, Niklas Söderlund
 wrote:
> On 2017-05-18 10:52:25 +0200, Geert Uytterhoeven wrote:
>> On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
>>  wrote:
>> > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
>> >> On Tue, May 16, 2017 at 1:01 PM, Simon Horman  wrote:
>> >> > Is there some way for - e.g. the driver - to not enable WoL on Gen3 SoCs
>> >> > until the clock issues is sorted out? I'm quite happy to enable features
>> >> > where they work; not so much where they don't.
>> >>
>> >> Agreed.
>> >>
>> >> One workaround could be to disable/enable the module clock in the WoL
>> >> resume path, to make sure it is enabled.  Once the enable count reaches
>> >> 0, CCF will know it's disabled, and will really enable next time.
>> >> You may need a double disable/double enable though, without testing I
>> >> don't know remember the enable count is 1 or 2 at that point (due to PM
>> >> runtime).
>> >
>> > I thought about this but it feels like such a hack I did not dare
>> > suggest it :-) But at the same time it would be nice to enable WoL for
>> > the s2idle use-case where it works. Only resume from PSCI with WoL
>> > enabled that is broken, and WoL in PSCI suspend will never work :-)
>>
>> Indeed.
>>
>> > How about I add another patch in v2 on-top of this that adds the clock
>> > disable/enable hack? That way it's clear that this is a workaround and
>> > once we have support for suspend/resume in CPG/MSSR just that patch can
>> > be reverted? Or is it cleaner to fold it in to this patch with a big
>> > comment that this is a workaround? Or is it maybe better to hold of on
>> > this until CPG/MSSR supports suspend/resume?
>>
>> Personally, I would have no problems of having the workaround integrated (and
>> documented, of course) in the WoL patch, as it avoids having broken PSCI
>> suspend in between WoL-without-workaround and a separate workaround.
>
> You have now posted '[PATCH/RFC] clk: renesas: cpg-mssr: Restore module
> clock registers during resume' which solves this issue. Do you think it
> would be OK for me to resubmit this patch due to an unrelated fix and
> state that it depends on your patch or do you feel it still would be
> valuable to include a workaround in the RAVB driver as to not make it
> dependent on your patch?

The the module clock restore patch fixes the issue, I think it's too immature
to upstream.  Applying your WoL patch as-is does introduce a regression if
WoL is enabled (although you could debate that it's not a regression, as WoL
couldn't be enabled before, but a generic userspace may try to do that anyway).

If the workaround isn't too ugly, I would include it.

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] ravb: add wake-on-lan support via magic packet

2017-06-12 Thread Niklas Söderlund
Hi Geert,

On 2017-05-18 10:52:25 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Tue, May 16, 2017 at 2:16 PM, Niklas Söderlund
>  wrote:
> > On 2017-05-16 13:36:21 +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 16, 2017 at 1:01 PM, Simon Horman  wrote:
> >> > Is there some way for - e.g. the driver - to not enable WoL on Gen3 SoCs
> >> > until the clock issues is sorted out? I'm quite happy to enable features
> >> > where they work; not so much where they don't.
> >>
> >> Agreed.
> >>
> >> One workaround could be to disable/enable the module clock in the WoL
> >> resume path, to make sure it is enabled.  Once the enable count reaches
> >> 0, CCF will know it's disabled, and will really enable next time.
> >> You may need a double disable/double enable though, without testing I
> >> don't know remember the enable count is 1 or 2 at that point (due to PM
> >> runtime).
> >
> > I thought about this but it feels like such a hack I did not dare
> > suggest it :-) But at the same time it would be nice to enable WoL for
> > the s2idle use-case where it works. Only resume from PSCI with WoL
> > enabled that is broken, and WoL in PSCI suspend will never work :-)
> 
> Indeed.
> 
> > How about I add another patch in v2 on-top of this that adds the clock
> > disable/enable hack? That way it's clear that this is a workaround and
> > once we have support for suspend/resume in CPG/MSSR just that patch can
> > be reverted? Or is it cleaner to fold it in to this patch with a big
> > comment that this is a workaround? Or is it maybe better to hold of on
> > this until CPG/MSSR supports suspend/resume?
> 
> Personally, I would have no problems of having the workaround integrated (and
> documented, of course) in the WoL patch, as it avoids having broken PSCI
> suspend in between WoL-without-workaround and a separate workaround.

You have now posted '[PATCH/RFC] clk: renesas: cpg-mssr: Restore module 
clock registers during resume' which solves this issue. Do you think it 
would be OK for me to resubmit this patch due to an unrelated fix and 
state that it depends on your patch or do you feel it still would be 
valuable to include a workaround in the RAVB driver as to not make it 
dependent on your patch?

> 
> It's not that dissimilar from the initial R-Car Gen3 support patch limiting
> ravb to 100 Mbps.
> 
> 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

-- 
Regards,
Niklas Söderlund


Re: ravb WoL interrupt flood

2017-06-12 Thread Niklas Söderlund
Hi Geert,

On 2017-05-30 12:29:24 +0200, Niklas Söderlund wrote:
> Hi Geert,
> 
> Thanks for the report. I did run a 200+ loop suspend/resume without 
> issues so this error is probably hard to reproduce or something changed 
> since v4.11-rc1 which if IIRC was the base I used to do the tests.
> 
> All I can think of is that if the interface was down at the time the 
> system was suspend. There is a bug in  the driver which is in 
> renesas-drivers related to that. But given that you woken up by WoL that 
> is probably not the case :-)
> 
> I will do more tests and see if I can reproduce this once I'm back in 
> Stockholm.

I have now done over a 500 suspend/resume loops and not been able to see 
this :-(

I have run it with and without your '[PATCH/RFC] clk: renesas: cpg-mssr: 
Restore module clock registers during resume' patch but no noticeable 
difference.

I had a small cleanup in my patch which would differ from the one you 
use. The diff is only in effect when resuming from s2ram so it should 
have no effect here but still it is a change. My plan is to submit the 
version with this fix for tomorrows renesas-drivers and then rerun my 
tests using that. If I still can't reproduce it then I think I will 
submit a v2 of my WoL patch to the ML, do this sounds like an OK plan to 
you?

> 
> 
> On 2017-05-30 11:23:23 +0200, Geert Uytterhoeven wrote:
> > Hi Niklas,
> > 
> > I just got a flood of messages after WoL from s2idle on r8a7795/salvator-x:
> > 
> > [  802.341060] ravb e680.ethernet eth0: ignoring interrupt, rx
> > status 0x0001, rx mask 0x0001,
> > [  802.350369] ravb e680.ethernet eth0: tx
> > status 0x, tx mask 0x0001.
> > [  802.359684] ravb e680.ethernet eth0: ignoring interrupt, rx
> > status 0x0001, rx mask 0x0001,
> > [  802.368993] ravb e680.ethernet eth0: tx
> > status 0x, tx mask 0x0001.
> > [  802.378308] ravb e680.ethernet eth0: ignoring interrupt, rx
> > status 0x0001, rx mask 0x0001,
> > [  802.387616] ravb e680.ethernet eth0: tx
> > status 0x, tx mask 0x0001.
> > [  802.396931] ravb e680.ethernet eth0: ignoring interrupt, rx
> > status 0x0001, rx mask 0x0001,
> > [  802.406240] ravb e680.ethernet eth0: tx
> > status 0x, tx mask 0x0001.
> > ...
> > 
> > Unfortunately I cannot reproduce it.
> > 
> > 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
> 
> -- 
> Regards,
> Niklas Söderlund

-- 
Regards,
Niklas Söderlund


Re: [RFC PATCH v2 0/2] mmc: core: process ECC errors raised in stop cmds

2017-06-12 Thread Wolfram Sang
On Mon, Jun 12, 2017 at 10:30:27AM +0200, Ulf Hansson wrote:
> On 8 April 2017 at 22:20, Wolfram Sang  
> wrote:
> > Here is the second RFC for handling ECC errors flagged in the stop command
> > after a multiblock transfer. It is still RFC because I could only test it by
> > inducing ECC errors in software (see patch for TMIO below). Shimoda-san, can
> > you try this series with the SD tester again? That would be very kind.
> >
> > Other than that, I hope the patch descriptions and comments explain the 
> > single
> > steps. Looking forward for thoughts.
> 
> Apologize for the delay!
> 
> I looked into these and the changes seems reasonable. I have applied
> them for next to allow them to get some test coverage.

Awesome, thanks Ulf!



signature.asc
Description: PGP signature


Re: [PATCH/RFC] clk: renesas: cpg-mssr: Restore module clock registers during resume

2017-06-12 Thread Niklas Söderlund
Hi Geert,

Thanks for your patch.

On 2017-06-07 13:58:38 +0200, Geert Uytterhoeven wrote:
> During PSCI system suspend, R-Car Gen3 SoCs are powered down, and their
> clock register state is lost.  Note that as the boot loader skips most
> initialization after resume, clock register state differs from the state
> encountered during normal system boot, too.
> 
> Hence after s2ram, some operations may fail because module clocks are
> disabled, while drivers expect them to be still enabled.  E.g. EtherAVB
> fails when Wake-on-LAN has been enabled using "ethtool -s eth0 wol g":
> 
> ravb e680.ethernet eth0: failed to switch device to config mode
> ravb e680.ethernet eth0: device will be stopped after h/w processes 
> are done.
> ravb e680.ethernet eth0: failed to switch device to config
> PM: Device e680.ethernet failed to resume: error -110
> 
> To fix this, restore all bits of the SMSTPCR registers that have ever
> been written to by Linux.
> 
> Note that while this fixes EtherAVB operation after resume from s2ram,
> EtherAVB cannot be used as an actual wake-up source from s2ram, only
> from s2idle, due to PSCI limitations.

I tested this on H3 ES1.0 for EtherAVB and it now works as you describe 
above after s2ram \o/.

Tested-by: Niklas Söderlund 

> 
> TODO: Restore other clock registers, which requires clock-specific code.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Niklas Söderlund 

> ---
> Tested on Salvator-X (R-Car H3 and M3-W), and Koelsch (R-Car M2-W).
> 
>  drivers/clk/renesas/renesas-cpg-mssr.c | 56 
> ++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c 
> b/drivers/clk/renesas/renesas-cpg-mssr.c
> index 7bf164ad64ebd8ef..0f23ad17fba979ac 100644
> --- a/drivers/clk/renesas/renesas-cpg-mssr.c
> +++ b/drivers/clk/renesas/renesas-cpg-mssr.c
> @@ -106,6 +106,8 @@ static const u16 srcr[] = {
>   * @num_core_clks: Number of Core Clocks in clks[]
>   * @num_mod_clks: Number of Module Clocks in clks[]
>   * @last_dt_core_clk: ID of the last Core Clock exported to DT
> + * @smstpcr_shadow[].mask: Mask of SMSTPCR[] bits ever written to
> + * @smstpcr_shadow[].val: Last bit values written to SMSTPCR[]
>   */
>  struct cpg_mssr_priv {
>  #ifdef CONFIG_RESET_CONTROLLER
> @@ -119,6 +121,11 @@ struct cpg_mssr_priv {
>   unsigned int num_core_clks;
>   unsigned int num_mod_clks;
>   unsigned int last_dt_core_clk;
> +
> + struct {
> + u32 mask;
> + u32 val;
> + } smstpcr_shadow[ARRAY_SIZE(smstpcr)];
>  };
>  
>  
> @@ -161,6 +168,12 @@ static int cpg_mstp_clock_endisable(struct clk_hw *hw, 
> bool enable)
>  
>   spin_unlock_irqrestore(&priv->rmw_lock, flags);
>  
> + priv->smstpcr_shadow[reg].mask |= bitmask;
> + if (enable)
> + priv->smstpcr_shadow[reg].val &= ~bitmask;
> + else
> + priv->smstpcr_shadow[reg].val |= bitmask;
> +
>   if (!enable)
>   return 0;
>  
> @@ -727,6 +740,7 @@ static int __init cpg_mssr_probe(struct platform_device 
> *pdev)
>   if (!clks)
>   return -ENOMEM;
>  
> + dev_set_drvdata(dev, priv);
>   priv->clks = clks;
>   priv->num_core_clks = info->num_total_core_clks;
>   priv->num_mod_clks = info->num_hw_mod_clks;
> @@ -763,10 +777,52 @@ static int __init cpg_mssr_probe(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static int cpg_mssr_resume_noirq(struct device *dev)
> +{
> + struct cpg_mssr_priv *priv = dev_get_drvdata(dev);
> + unsigned int reg, i;
> + u32 value, mask;
> +
> + for (reg = 0; reg < ARRAY_SIZE(priv->smstpcr_shadow); reg++) {
> + /* Restore bits ever written to */
> + mask = priv->smstpcr_shadow[reg].mask;
> + if (!mask)
> + continue;
> +
> + value = readl(priv->base + SMSTPCR(reg));
> + value &= ~mask;
> + value |= priv->smstpcr_shadow[reg].val;
> + writel(value, priv->base + SMSTPCR(reg));
> +
> + /* Wait until enabled clocks are really enabled */
> + mask &= ~priv->smstpcr_shadow[reg].val;
> + if (!mask)
> + continue;
> +
> + for (i = 1000; i > 0; --i) {
> + value = readl(priv->base + MSTPSR(reg));
> + if (!(value & mask))
> + break;
> + cpu_relax();
> + }
> +
> + if (!i)
> + dev_warn(dev, "Failed to enable SMSTP %p[0x%x]\n",
> +  priv->base + SMSTPCR(reg), value & mask);
> + }
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops cpg_mssr_pm = {
> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(NULL, cpg_mssr_resume_noirq)
> +};
> +
>  static struct platform_driver cpg_mssr_driver = {
>   .driver = {
>   .name   = "renesas-cpg-mssr",
>  

[PATCH v2] media: fdp1: Support ES2 platforms

2017-06-12 Thread Kieran Bingham
From: Kieran Bingham 

The new Renesas R-Car H3 ES2.0 platforms have a new hw version register.
Update the driver accordingly, defaulting to the new hw revision, and
differentiating the older revision as ES1

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/rcar_fdp1.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/rcar_fdp1.c 
b/drivers/media/platform/rcar_fdp1.c
index 42f25d241edd..159786b052f3 100644
--- a/drivers/media/platform/rcar_fdp1.c
+++ b/drivers/media/platform/rcar_fdp1.c
@@ -258,8 +258,9 @@ MODULE_PARM_DESC(debug, "activate debug info");
 
 /* Internal Data (HW Version) */
 #define FD1_IP_INTDATA 0x0800
-#define FD1_IP_H3  0x02010101
+#define FD1_IP_H3_ES1  0x02010101
 #define FD1_IP_M3W 0x02010202
+#define FD1_IP_H3  0x02010203
 
 /* LUTs */
 #define FD1_LUT_DIF_ADJ0x1000
@@ -2359,12 +2360,15 @@ static int fdp1_probe(struct platform_device *pdev)
 
hw_version = fdp1_read(fdp1, FD1_IP_INTDATA);
switch (hw_version) {
-   case FD1_IP_H3:
-   dprintk(fdp1, "FDP1 Version R-Car H3\n");
+   case FD1_IP_H3_ES1:
+   dprintk(fdp1, "FDP1 Version R-Car H3 ES1\n");
break;
case FD1_IP_M3W:
dprintk(fdp1, "FDP1 Version R-Car M3-W\n");
break;
+   case FD1_IP_H3:
+   dprintk(fdp1, "FDP1 Version R-Car H3\n");
+   break;
default:
dev_err(fdp1->dev, "FDP1 Unidentifiable (0x%08x)\n",
hw_version);
-- 
2.7.4



Re: [PATCH] media: fdp1: Support ES2 platforms

2017-06-12 Thread Geert Uytterhoeven
Hi Kieran, Laurent,

On Sat, Jun 10, 2017 at 9:54 AM, Laurent Pinchart
 wrote:
> On Friday 09 Jun 2017 18:15:48 Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> The new Renesas R-Car H3 ES2.0 platforms have an updated hw version
>> register. Update the driver accordingly.
>>
>> Signed-off-by: Kieran Bingham 

Thanks, seems to work fine (as in: no more complaints from the driver).

>> --- a/drivers/media/platform/rcar_fdp1.c
>> +++ b/drivers/media/platform/rcar_fdp1.c
>> @@ -260,6 +260,7 @@ MODULE_PARM_DESC(debug, "activate debug info");
>>  #define FD1_IP_INTDATA   0x0800
>>  #define FD1_IP_H30x02010101
>>  #define FD1_IP_M3W   0x02010202
>> +#define FD1_IP_H3_ES20x02010203
>
> Following our global policy of treating ES2 as the default, how about renaming
> FDP1_IP_H3 to FDP1_IP_H3_ES1 and adding a new FD1_IP_H3 for ES2 ? The messages
> below should be updated as well.

Yes, that sounds good.

>>  /* LUTs */
>>  #define FD1_LUT_DIF_ADJ  0x1000
>> @@ -2365,6 +2366,9 @@ static int fdp1_probe(struct platform_device *pdev)
>>   case FD1_IP_M3W:
>>   dprintk(fdp1, "FDP1 Version R-Car M3-W\n");
>>   break;
>> + case FD1_IP_H3_ES2:
>> + dprintk(fdp1, "FDP1 Version R-Car H3-ES2\n");

Please drop dashes between SoC names and revisions.

>> + break;
>>   default:
>>   dev_err(fdp1->dev, "FDP1 Unidentifiable (0x%08x)\n",
>>   hw_version);

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


[PATCH] MAINTAINERS: Add entry for R-Car DRIF & MAX2175 drivers

2017-06-12 Thread Ramesh Shanmugasundaram
Add maintainter entry for the R-Car DRIF and MAX2175 drivers.

Signed-off-by: Ramesh Shanmugasundaram 
---
Hi Hans,

   Added the missing MAINTAINTERS entry on top of this
   
(https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg15081.html)
   series as requested.

Thanks,
Ramesh.
---
 MAINTAINERS | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bdd1fe5..cfa78fe5142a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8031,6 +8031,16 @@ S:   Maintained
 F: Documentation/hwmon/max20751
 F: drivers/hwmon/max20751.c
 
+MAX2175 SDR TUNER DRIVER
+M: Ramesh Shanmugasundaram 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/max2175.txt
+F: Documentation/media/v4l-drivers/max2175.rst
+F: drivers/media/i2c/max2175*
+F: include/uapi/linux/max2175.h
+
 MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
 L: linux-hw...@vger.kernel.org
 S: Orphan
@@ -8111,6 +8121,15 @@ L:   linux-...@vger.kernel.org
 S: Maintained
 F: drivers/iio/dac/cio-dac.c
 
+MEDIA DRIVERS FOR RENESAS - DRIF
+M: Ramesh Shanmugasundaram 
+L: linux-me...@vger.kernel.org
+L: linux-renesas-soc@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Supported
+F: Documentation/devicetree/bindings/media/renesas,drif.txt
+F: drivers/media/platform/rcar_drif.c
+
 MEDIA DRIVERS FOR RENESAS - FCP
 M: Laurent Pinchart 
 L: linux-me...@vger.kernel.org
-- 
2.12.2



Re: [GIT PULL FOR renesas-drivers] mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC

2017-06-12 Thread Geert Uytterhoeven
Hi Simon,

On Mon, Jun 12, 2017 at 11:47 AM, Simon Horman
 wrote:
> please consider pulling changes to add support for R-Car Gen3 SDHI DMAC.
>
> This gives a significant performance boost;
> the headline figure is 9.5MB/s -> 39.7MB/s.
>
> This pull request is based on mmc/next.

Unfortunately Ulf rebases mmc/next regularly, causing lots of conflicts.

> The following changes since commit 6e75316c15df8333506377743c75fcd626193849:
>
>   mmc: tmio: make sure SDIO gets reinitialized after resume (2017-05-30 
> 11:51:55 +0200)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> topic/sdhi-gen3-dma-2017
>
> for you to fetch changes up to fd9437fc8884f039ba4a510ac99d350fd693b0dc:
>
>   mmc: renesas-sdhi: remove gen3 support from sysc dmac driver (2017-06-08 
> 15:03:03 +0200)

So feel free to rebase the top 5 commits on top of today's mmc/next (and
risk new conflicts if/when Ulf rebases his tree again tonight), or let me handle
that tomorrow myself ;-)

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


[GIT PULL FOR renesas-drivers] mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC

2017-06-12 Thread Simon Horman
Hi Geert,

please consider pulling changes to add support for R-Car Gen3 SDHI DMAC.

This gives a significant performance boost;
the headline figure is 9.5MB/s -> 39.7MB/s.

This pull request is based on mmc/next.

The following changes since commit 6e75316c15df8333506377743c75fcd626193849:

  mmc: tmio: make sure SDIO gets reinitialized after resume (2017-05-30 
11:51:55 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdhi-gen3-dma-2017

for you to fetch changes up to fd9437fc8884f039ba4a510ac99d350fd693b0dc:

  mmc: renesas-sdhi: remove gen3 support from sysc dmac driver (2017-06-08 
15:03:03 +0200)


Simon Horman (4):
  mmc: sh_mobile_sdhi: set max_segs and max_blk_count values R-Car Gen3
  mmc: tmio: add complete to DMA ops
  mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC
  mmc: renesas-sdhi: remove gen3 support from sysc dmac driver

Yoshihiro Shimoda (1):
  mmc: tmio: add max_segs and max_blk_count in tmio_mmc_data

 drivers/mmc/host/Kconfig  |  17 ++
 drivers/mmc/host/Makefile |   8 +-
 drivers/mmc/host/renesas_sdhi.h   |   2 +
 drivers/mmc/host/renesas_sdhi_core.c  |   2 +
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 275 ++
 drivers/mmc/host/renesas_sdhi_sys_dmac.c  |  23 +--
 drivers/mmc/host/tmio_mmc.h   |   2 +
 drivers/mmc/host/tmio_mmc_core.c  |  16 +-
 include/linux/mfd/tmio.h  |   2 +
 9 files changed, 319 insertions(+), 28 deletions(-)
 create mode 100644 drivers/mmc/host/renesas_sdhi_internal_dmac.c


Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

2017-06-12 Thread jmondi
Hi Linus,

On Sun, Jun 11, 2017 at 11:45:49PM +0200, Linus Walleij wrote:
> On Fri, Jun 9, 2017 at 9:50 AM, jmondi  wrote:
> > On Fri, Jun 09, 2017 at 03:26:57PM +0800, Dong Aisheng wrote:
>
> >> > I see three options here:
> >> >
> >> > 1) Add "output-buffer-enable" and "input-buffer-enable"
> >> > we end up with
> >> > "output-high"
> >> > "output-low"
> >> > "input-enable"
> >> > "output-buffer-enable"
> >> > "input-buffer-enable"
> >> >
> >> > 2) Add "output-buffer-enable" only
> >> > we end up with
> >> > "output-high"
> >> > "output-low"
> >> > "input-enable"
> >> > "output-buffer-enable"
> >> >
> >> > Binding may be confusing as in one case we use "output-buffer-enable"
> >> > while in the other "input-enable"
> >> >
> >> > 3) Add "output-enable" only
> >> > "output-high"
> >> > "output-low"
> >> > "input-enable"
> >> > "output-enable"
> >> >
> >> > As you, I don't like "output-enable" that much but it pairs better with
> >> > "input-enable".
> >> >
> >> > I'll let you and DT people decide on this, as it's really an ABI 
> >> > definition
> >> > problem and you have better judgment there.
> >> >
> >>
> >> What's the final decision of this?
> >
> > I admit a was buying a bit of time and post-poned the gentle ping for
> > any final word on this. But since you're asking I'll second your
> > question :)
>
> I suspect it is time to quote
> Documentation/process/management-style.rst
> (Torvalds):
>
> 1) Decisions
>
> Everybody thinks managers make decisions, and that decision-making is
> important.  The bigger and more painful the decision, the bigger the
> manager must be to make it.  That's very deep and obvious, but it's not
> actually true.
>
> The name of the game is to **avoid** having to make a decision.  In
> particular, if somebody tells you "choose (a) or (b), we really need you
> to decide on this", you're in trouble as a manager.  The people you
> manage had better know the details better than you, so if they come to
> you for a technical decision, you're screwed.  You're clearly not
> competent to make that decision for them.
>
> (It goes on, it's the best part of the entire Documentation/* dir in my
> opinion, please take the time to read it in full.)
>
> So: what do you guys, using this feature, and Andy, who raised serious
> concerns, think is the right binding? That is what *I* need to know.

Fair enough :)

I'll try to keep this short: I don't like "output-enable", and at the
same time I don't think "output-high" and "output-low" fit well for
this purpose, as they electrically means something different from what
our (and IMX) use case is: enabling/disabling input/output
buffers internal to pin controller/gpio block HW and not driving a value
there.

This seems clear to me from the "GPIO mode pitfalls" section of
pinctrl.txt documentation examples and from the fact that generic bindings
did not expose an "output" flag because if you drive an output line, you
reasonably either drive it high or low.

Unfortunately I cannot convince myself that the same reasons apply
to the input use case.  Enabling input on a pin implies the pinctrl/gpio driver
has to enable any input buffer required to use that pin as a properly
working input line, and enabling an input buffer implies being able to sense
the line value from there, so I don't see that much use for 
"input-buffer-enable"
alone.

So, even if bindings could look a bit weird as there won't be a direct
matching between properties names used to enable input/output buffers,
my vote is to add "output-buffer-enable" only, and keep using the
already there "input-enable" properties for the input use case.

Thanks
   j

>
> Yours,
> Linus Walleij


[PATCH 2/2] arm64: dts: r8a7796: Add reset control properties for audio

2017-06-12 Thread Geert Uytterhoeven
Note that the audio module has resets for the Serial Sound Interfaces
only.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 3c749fd7b61f7b7f..766dd71a188a1202 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1285,6 +1285,16 @@
  "dvc.0", "dvc.1",
  "clk_a", "clk_b", "clk_c", "clk_i";
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+   resets = <&cpg 1005>,
+<&cpg 1006>, <&cpg 1007>,
+<&cpg 1008>, <&cpg 1009>,
+<&cpg 1010>, <&cpg 1011>,
+<&cpg 1012>, <&cpg 1013>,
+<&cpg 1014>, <&cpg 1015>;
+   reset-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6",
+ "ssi.5", "ssi.4", "ssi.3", "ssi.2",
+ "ssi.1", "ssi.0";
status = "disabled";
 
rcar_sound,dvc {
-- 
2.7.4



[PATCH 1/2] arm64: dts: r8a7795: Add reset control properties for audio

2017-06-12 Thread Geert Uytterhoeven
Note that the audio module has resets for the Serial Sound Interfaces
only.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 65c914bba08235a5..18651d39a89a8b54 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1119,6 +1119,16 @@
  "dvc.0", "dvc.1",
  "clk_a", "clk_b", "clk_c", "clk_i";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+   resets = <&cpg 1005>,
+<&cpg 1006>, <&cpg 1007>,
+<&cpg 1008>, <&cpg 1009>,
+<&cpg 1010>, <&cpg 1011>,
+<&cpg 1012>, <&cpg 1013>,
+<&cpg 1014>, <&cpg 1015>;
+   reset-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6",
+ "ssi.5", "ssi.4", "ssi.3", "ssi.2",
+ "ssi.1", "ssi.0";
status = "disabled";
 
rcar_sound,dvc {
-- 
2.7.4



[PATCH 0/2] arm64: dts: renesas: Add reset control properties for audio

2017-06-12 Thread Geert Uytterhoeven
Hi Simon, Magnus, Morimoto-san,

This patch series describes all resets wired to the audio modules on
R-Car Gen3 SoCs, following the DT binding update in commit
5f440c48c5d5a11f ("ASoC: rsnd: Document optional reset properties") in
sound-asoc/for-next.

Thanks!

Geert Uytterhoeven (2):
  arm64: dts: r8a7795: Add reset control properties for audio
  arm64: dts: r8a7796: Add reset control properties for audio

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 10 ++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 10 ++
 2 files changed, 20 insertions(+)

-- 
2.7.4

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


[GIT PULL] Second Round of Renesas ARM Based SoC Fixes for v4.12

2017-06-12 Thread Simon Horman
Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM based SoC fixes for v4.12.

It splits LCD mux and gpio into separate nodes as different values
for the output-high property are required.

This pull request is based on the previous round of
such requests, tagged as renesas-fixes-for-v4.12,
which I have already sent a pull-request for.


The following changes since commit 7b4ccb3c466f62bbf2f4dd5d6a143d945a6f3051:

  soc: renesas: Provide dummy rcar_rst_read_mode_pins() for compile-testing 
(2017-04-28 10:07:36 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-fixes2-for-v4.12

for you to fetch changes up to 13132b3f44d3600983aceb7e9920b8ebb55a7cf8:

  ARM: dts: armadillo800eva: Split LCD mux and gpio (2017-06-08 15:44:55 +0200)


Second Round of Renesas ARM Based SoC Fixes for v4.12

* Split LCD mux and gpio on armadillo800eva board


Geert Uytterhoeven (1):
  ARM: dts: armadillo800eva: Split LCD mux and gpio

 arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 ++
 1 file changed, 2 insertions(+)


[PATCH] ARM: dts: armadillo800eva: Split LCD mux and gpio

2017-06-12 Thread Simon Horman
From: Geert Uytterhoeven 

Configuration of the lcd0 pinmux group and GPIO hog for the external
GPIO mux are done using a single device node, causing the "output-high"
property to be applied to both.  This will fail for the pinmux group,
but doesn't cause any harm, as the failure is ignored silently.

However, after "pinctrl: sh-pfc: propagate errors on group config", the
failure will become fatal, leading to a broken display:

sh-pfc e605.pin-controller: pin_config_group_set op failed for group 102
sh-pfc e605.pin-controller: Error applying setting, reverse things back
sh-pfc e605.pin-controller: failed to select default state

Move the GPIO hog to its own node to fix this.

Fixes: ffd2f9a5afb730b9 ("ARM: shmobile: armadillo800eva dts: Add pinctrl and 
gpio-hog for lcdc0")
Signed-off-by: Geert Uytterhoeven 
Acked-by: Laurent Pinchart 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts 
b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
index 7885075428bb..1788e186a512 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
@@ -266,7 +266,9 @@
lcd0_pins: lcd0 {
groups = "lcd0_data24_0", "lcd0_lclk_1", "lcd0_sync";
function = "lcd0";
+   };
 
+   lcd0_mux {
/* DBGMD/LCDC0/FSIA MUX */
gpio-hog;
gpios = <176 0>;
-- 
2.1.4



[PATCH 0/2] renesas: sysc: Use GENPD_FLAG_ALWAYS_ON

2017-06-12 Thread Geert Uytterhoeven
Hi Simon, Magnus,

Commit ffaa42e8a40b7f10 ("PM / Domains: Enable users of genpd to specify
always on PM domains") introduced a new flag GENPD_FLAG_ALWAYS_ON, which
allows to remove some code for drivers handling always-on PM domains.

This series does that for the Renesas R-Car SYSC driver (used on R-Car
Gen2 and Gen3, and RZ/G1) and the R-Mobile SYSC driver (used on R-Mobile
APE6 and A1, and SH-Mobile AG5).

Note that on R/SH-Mobile, the PM domain containing the serial console is
still handled locally.

Tested on:
  - r8a7790/koelsch and r8a7795/salvator-x,
  - r8a73a4/ape6evm, r8a7740/armadillo, sh73a0/kzm9g.

Thanks!

Geert Uytterhoeven (2):
  soc: renesas: rcar-sysc: Use GENPD_FLAG_ALWAYS_ON
  ARM: shmobile: pm-rmobile: Use GENPD_FLAG_ALWAYS_ON

 arch/arm/mach-shmobile/pm-rmobile.c | 19 ---
 drivers/soc/renesas/rcar-sysc.c | 28 
 drivers/soc/renesas/rcar-sysc.h |  2 --
 3 files changed, 8 insertions(+), 41 deletions(-)

-- 
2.7.4

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


[PATCH 1/2] soc: renesas: rcar-sysc: Use GENPD_FLAG_ALWAYS_ON

2017-06-12 Thread Geert Uytterhoeven
Improve handling of always-on PM domains by using the
GENPD_FLAG_ALWAYS_ON flag introduced in commit ffaa42e8a40b7f10 ("PM /
Domains: Enable users of genpd to specify always on PM domains").

Signed-off-by: Geert Uytterhoeven 
---
 drivers/soc/renesas/rcar-sysc.c | 28 
 drivers/soc/renesas/rcar-sysc.h |  2 --
 2 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index dcad5c42a5e81c87..7c8da3c90011422f 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -181,17 +181,6 @@ static int rcar_sysc_pd_power_off(struct generic_pm_domain 
*genpd)
struct rcar_sysc_pd *pd = to_rcar_pd(genpd);
 
pr_debug("%s: %s\n", __func__, genpd->name);
-
-   if (pd->flags & PD_NO_CR) {
-   pr_debug("%s: Cannot control %s\n", __func__, genpd->name);
-   return -EBUSY;
-   }
-
-   if (pd->flags & PD_BUSY) {
-   pr_debug("%s: %s busy\n", __func__, genpd->name);
-   return -EBUSY;
-   }
-
return rcar_sysc_power_down(&pd->ch);
 }
 
@@ -200,12 +189,6 @@ static int rcar_sysc_pd_power_on(struct generic_pm_domain 
*genpd)
struct rcar_sysc_pd *pd = to_rcar_pd(genpd);
 
pr_debug("%s: %s\n", __func__, genpd->name);
-
-   if (pd->flags & PD_NO_CR) {
-   pr_debug("%s: Cannot control %s\n", __func__, genpd->name);
-   return 0;
-   }
-
return rcar_sysc_power_up(&pd->ch);
 }
 
@@ -223,8 +206,7 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd 
*pd)
 * only be turned off if the CPU is not in use.
 */
pr_debug("PM domain %s contains %s\n", name, "CPU");
-   pd->flags |= PD_BUSY;
-   gov = &pm_domain_always_on_gov;
+   genpd->flags |= GENPD_FLAG_ALWAYS_ON;
} else if (pd->flags & PD_SCU) {
/*
 * This domain contains an SCU and cache-controller, and
@@ -232,19 +214,17 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd 
*pd)
 * not in use.
 */
pr_debug("PM domain %s contains %s\n", name, "SCU");
-   pd->flags |= PD_BUSY;
-   gov = &pm_domain_always_on_gov;
+   genpd->flags |= GENPD_FLAG_ALWAYS_ON;
} else if (pd->flags & PD_NO_CR) {
/*
 * This domain cannot be turned off.
 */
-   pd->flags |= PD_BUSY;
-   gov = &pm_domain_always_on_gov;
+   genpd->flags |= GENPD_FLAG_ALWAYS_ON;
}
 
if (!(pd->flags & (PD_CPU | PD_SCU))) {
/* Enable Clock Domain for I/O devices */
-   genpd->flags = GENPD_FLAG_PM_CLK;
+   genpd->flags |= GENPD_FLAG_PM_CLK;
if (has_cpg_mstp) {
genpd->attach_dev = cpg_mstp_attach_dev;
genpd->detach_dev = cpg_mstp_detach_dev;
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 07edb049a401196c..1a5bebaf54ba191c 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -20,8 +20,6 @@
 #define PD_SCU BIT(1)  /* Area contains SCU and L2 cache */
 #define PD_NO_CR   BIT(2)  /* Area lacks PWR{ON,OFF}CR registers */
 
-#define PD_BUSYBIT(3)  /* Busy, for internal use only */
-
 #define PD_CPU_CR  PD_CPU/* CPU area has CR (R-Car H1) */
 #define PD_CPU_NOCRPD_CPU | PD_NO_CR /* CPU area lacks CR (R-Car Gen2/3) */
 #define PD_ALWAYS_ON   PD_NO_CR  /* Always-on area */
-- 
2.7.4



[PATCH 2/2] ARM: shmobile: pm-rmobile: Use GENPD_FLAG_ALWAYS_ON

2017-06-12 Thread Geert Uytterhoeven
Improve handling of always-on PM domains by using the
GENPD_FLAG_ALWAYS_ON flag introduced in commit ffaa42e8a40b7f10 ("PM /
Domains: Enable users of genpd to specify always on PM domains").

Note that the PM domain containing the serial console is still handled
locally.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/mach-shmobile/pm-rmobile.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-shmobile/pm-rmobile.c 
b/arch/arm/mach-shmobile/pm-rmobile.c
index 175bd3d91ebcbcb4..e5fa6a3cf1ddf159 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -130,7 +130,7 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain 
*rmobile_pd)
struct generic_pm_domain *genpd = &rmobile_pd->genpd;
struct dev_power_governor *gov = rmobile_pd->gov;
 
-   genpd->flags = GENPD_FLAG_PM_CLK;
+   genpd->flags |= GENPD_FLAG_PM_CLK;
genpd->dev_ops.active_wakeup= rmobile_pd_active_wakeup;
genpd->power_off= rmobile_pd_power_down;
genpd->power_on = rmobile_pd_power_up;
@@ -140,14 +140,6 @@ static void rmobile_init_pm_domain(struct 
rmobile_pm_domain *rmobile_pd)
pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
 }
 
-static int rmobile_pd_suspend_busy(void)
-{
-   /*
-* This domain should not be turned off.
-*/
-   return -EBUSY;
-}
-
 static int rmobile_pd_suspend_console(void)
 {
/*
@@ -260,8 +252,7 @@ static void __init rmobile_setup_pm_domain(struct 
device_node *np,
 * only be turned off if the CPU is not in use.
 */
pr_debug("PM domain %s contains CPU\n", name);
-   pd->gov = &pm_domain_always_on_gov;
-   pd->suspend = rmobile_pd_suspend_busy;
+   pd->genpd.flags |= GENPD_FLAG_ALWAYS_ON;
break;
 
case PD_CONSOLE:
@@ -277,8 +268,7 @@ static void __init rmobile_setup_pm_domain(struct 
device_node *np,
 * is not in use.
 */
pr_debug("PM domain %s contains Coresight-ETM\n", name);
-   pd->gov = &pm_domain_always_on_gov;
-   pd->suspend = rmobile_pd_suspend_busy;
+   pd->genpd.flags |= GENPD_FLAG_ALWAYS_ON;
break;
 
case PD_MEMCTL:
@@ -287,8 +277,7 @@ static void __init rmobile_setup_pm_domain(struct 
device_node *np,
 * should only be turned off if memory is not in use.
 */
pr_debug("PM domain %s contains MEMCTL\n", name);
-   pd->gov = &pm_domain_always_on_gov;
-   pd->suspend = rmobile_pd_suspend_busy;
+   pd->genpd.flags |= GENPD_FLAG_ALWAYS_ON;
break;
 
case PD_NORMAL:
-- 
2.7.4



Re: [PATCH 0/4] arm64: renesas: Add support for Salvator-XS

2017-06-12 Thread Simon Horman
On Fri, Jun 09, 2017 at 01:43:45PM +0200, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> The Renesas Salvator-XS (Salvator-X 2nd version) development board can
> be equipped with either an R-Car H3 ES2.0 or M3-W ES1.x SiP, which are
> pin-compatible.
> 
> This patch series adds initial support for the Renesas Salvator-XS
> development board equipped with an R-Car H3 ES2.0 SiP.  The support
> level is similar to the existing support for Salvator-X with the same
> SiP.  See below for exceptions.
> 
> The Salvator-XS board is similar but not identical to the already
> supported Salvator-X board.  To avoid duplication, the common parts are
> extracted first into its own .dtsi file.
> Noteworthy differences are:
>   - The main clock crystal ticks at a slightly different rate.
>   - On R-Car H3 ES2.0, SATA no longer uses dedicated pins, but shares
> them with the second PCIe channel.  To cater for this, a MAX4888B
> multiplexer has been added to Salvator-XS.  As the default hardware
> configuration enables PCIe, I disabled SATA.
>   - The Versaclock5 clock generator has been replaced by a similar
> member of the Versaclock6 family.  As the latter is not supported by
> Linux yet, I left it out.
>   - The USB3.0 micro-B connector is replaced by a USB2.0 micro-AB
> connector (both are not yet supported, so no change is needed now).
> 
> Dependencies:
>   - renesas-devel-20170608-v4.12-rc4,
>   - "arm64: dts: salvator-x: Add missing index to PWM pinctrl subnode
> name".
> 
> For your convenience, I've pushed this series, its dependencies, and a
> few related driver changes to the topic/r8a7795-salvator-xs branch of
> the git repository at
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
> 
> This has been tested on Salvator-XS with R-Car H3 ES2.0, and Salvator-X
> with R-Car H3 ES1.0.
> 
> Thanks!

Thanks, I have queued this up for v4.13.


Re: [PATCH v2] ARM: dts: r8a779x: Fix PCI bus dtc warnings

2017-06-12 Thread Simon Horman
On Fri, Jun 09, 2017 at 05:50:40PM +0200, Geert Uytterhoeven wrote:
> From: Rob Herring 
> 
> The bogus 'device_type = "pci"' confuses dtc, causing lots of totally
> unrelated warnings.  After fixing that, real warnings like
> 
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_reg): Node 
> /pci@ee09/usb@0,1 PCI unit address format error, expected "1,0"
> 
> are left.  Correct the unit-addresses and reg properties of the subnodes
> to fix these.
> 
> Signed-off-by: Rob Herring 
> [geert: Improve description]
> Signed-off-by: Geert Uytterhoeven 

Thanks, I have queued this up for v4.13.


Re: [PATCH] arm64: dts: salvator-x: Add missing index to PWM pinctrl subnode name

2017-06-12 Thread Simon Horman
On Thu, Jun 08, 2017 at 03:45:00PM +0200, Geert Uytterhoeven wrote:
> R-Car Gen3 SoCs contain multiple PWM modules.  Hence to avoid conflicts,
> pinctrl subnodes for PWM should include indices referring to their
> instances.
> 
> Fixes: b33be33670217533 ("arm64: dts: salvator-x: Add panel backlight 
> support")
> Signed-off-by: Geert Uytterhoeven 

Thanks. I have queued this up for v4.13 as it fixes a patch which
has been accepted by the ARM-SoC maintainers for v4.13.


[PATCH v3] sh_eth: add support for changing MTU

2017-06-12 Thread Niklas Söderlund
The hardware supports the MTU to be changed and the driver it self is
somewhat prepared to support this. This patch hooks up the callbacks to
be able to change the MTU from user-space.

Signed-off-by: Niklas Söderlund 
Acked-by: Sergei Shtylyov 
---

Based on v4.12-rc1 and tested on Renesas R-Car Koelsch M2.

Test procedure:

1. On host set MTU to something large (9000) was used for this test.

2. On target set MTU to something other then 1500, in this test the max
   MTU of 1978 is used.

3. Send ping with large payload and observe that it works.

   ping -M do -s 1954 

   The reason for 1954 instead of 1982 is two fold:

   1. On Linux (different on Mac IIRC) the ICMP/ping implementation
  do not encapsulate the 28 byte ICMP (8) + IP (20).
   2. The driver internally reserve 4 bytes of transmission buffer for
  an optional VLAN header (4). And since no VLAN is used in this
  setup the additional 4 bytes can carry data.

4. For extra verification the packet flow is inspected using tcpdump to
   verify that there is no packet fragmentation.

* Changes since v2
- Changed subject from 'sh_eth: add support to change MTU' to 'sh_eth: add 
  support for changing MTU' as suggested by Sergei.
- Changed variable name of struct net_device from dev to ndev, thanks Sergei!
- Fixed typo.

* Changes since v1
- Fix spelling mistake in comment, thanks Sergei!
- Add Acked-by from Sergei.


 drivers/net/ethernet/renesas/sh_eth.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index f68c4db656eda846..2be46e4a32913972 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -2558,6 +2558,17 @@ static int sh_eth_do_ioctl(struct net_device *ndev, 
struct ifreq *rq, int cmd)
return phy_mii_ioctl(phydev, rq, cmd);
 }
 
+static int sh_eth_change_mtu(struct net_device *ndev, int new_mtu)
+{
+   if (netif_running(ndev))
+   return -EBUSY;
+
+   ndev->mtu = new_mtu;
+   netdev_update_features(ndev);
+
+   return 0;
+}
+
 /* For TSU_POSTn. Please refer to the manual about this (strange) bitfields */
 static void *sh_eth_tsu_get_post_reg_offset(struct sh_eth_private *mdp,
int entry)
@@ -3029,6 +3040,7 @@ static const struct net_device_ops sh_eth_netdev_ops = {
.ndo_set_rx_mode= sh_eth_set_rx_mode,
.ndo_tx_timeout = sh_eth_tx_timeout,
.ndo_do_ioctl   = sh_eth_do_ioctl,
+   .ndo_change_mtu = sh_eth_change_mtu,
.ndo_validate_addr  = eth_validate_addr,
.ndo_set_mac_address= eth_mac_addr,
 };
@@ -3043,6 +3055,7 @@ static const struct net_device_ops sh_eth_netdev_ops_tsu 
= {
.ndo_vlan_rx_kill_vid   = sh_eth_vlan_rx_kill_vid,
.ndo_tx_timeout = sh_eth_tx_timeout,
.ndo_do_ioctl   = sh_eth_do_ioctl,
+   .ndo_change_mtu = sh_eth_change_mtu,
.ndo_validate_addr  = eth_validate_addr,
.ndo_set_mac_address= eth_mac_addr,
 };
@@ -3171,6 +3184,13 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
}
sh_eth_set_default_cpu_data(mdp->cd);
 
+   /* User's manual states max MTU should be 2048 but due to the
+* alignment calculations in sh_eth_ring_init() the practical
+* MTU is a bit less. Maybe this can be optimized some more.
+*/
+   ndev->max_mtu = 2000 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
+   ndev->min_mtu = ETH_MIN_MTU;
+
/* set function */
if (mdp->cd->tsu)
ndev->netdev_ops = &sh_eth_netdev_ops_tsu;
-- 
2.13.1



Re: [RFC PATCH v2 0/2] mmc: core: process ECC errors raised in stop cmds

2017-06-12 Thread Ulf Hansson
On 8 April 2017 at 22:20, Wolfram Sang  wrote:
> Here is the second RFC for handling ECC errors flagged in the stop command
> after a multiblock transfer. It is still RFC because I could only test it by
> inducing ECC errors in software (see patch for TMIO below). Shimoda-san, can
> you try this series with the SD tester again? That would be very kind.
>
> Other than that, I hope the patch descriptions and comments explain the single
> steps. Looking forward for thoughts.

Apologize for the delay!

I looked into these and the changes seems reasonable. I have applied
them for next to allow them to get some test coverage.

Thanks and kind regards
Uffe

>
> Kind regards,
>
>Wolfram
>
> Changes since RFC v1:
>
> * rebased to mmc/next as of today
> * reworded commit message for patch 1
> * added tested-tag from Shimoda-san for patch 1
> * added patch 2
>
> Wolfram Sang (2):
>   mmc: core: check also R1 response for stop commands
>   mmc: core: for data errors, take response of stop cmd into account
>
>  drivers/mmc/core/block.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> Patch to simulate ECC errors:
>
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index a2d92f10501bdd..9773c7e5e4d154 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -553,6 +553,8 @@ void tmio_mmc_do_data_irq(struct tmio_mmc_host *host)
> }
>
> if (stop) {
> +   static unsigned int induce_cnt = 0;
> +
> if (stop->opcode != MMC_STOP_TRANSMISSION || stop->arg)
> dev_err(&host->pdev->dev, "unsupported stop: 
> CMD%u,0x%x. We did CMD12,0\n",
> stop->opcode, stop->arg);
> @@ -560,6 +562,9 @@ void tmio_mmc_do_data_irq(struct tmio_mmc_host *host)
> /* fill in response from auto CMD12 */
> stop->resp[0] = sd_ctrl_read16_and_16_as_32(host, 
> CTL_RESPONSE);
>
> +   if (induce_cnt++ % 100 == 0)
> +   stop->resp[0] |= R1_CARD_ECC_FAILED;
> +
> sd_ctrl_write16(host, CTL_STOP_INTERNAL_ACTION, 0);
> }
>
> --
> 2.11.0
>


Re: [PATCH v7 0/7] Add V4L2 SDR (DRIF & MAX2175) driver

2017-06-12 Thread Hans Verkuil

Hi Ramesh,

Can you post a patch on top of this series adding entries for these two
drivers to the MAINTAINERS file?

That's missing in this series.

Thanks!

Hans

On 06/09/2017 05:07 PM, Ramesh Shanmugasundaram wrote:

Hi Mauro, Hans,

This patch set contains two drivers
  - Renesas R-Car Digital Radio Interface (DRIF) driver
  - Maxim's MAX2175 RF to Bits tuner driver

These patches were based on top of media_tree.
commit: 47f910f0e0deb880c2114811f7ea1ec115a19ee4

These two drivers combined together expose a V4L2 SDR device that is compliant
with the V4L2 framework [1]. Agreed review comments are incorporated in this
series.

The rcar_drif device is modelled using "renesas,bonding" property. The
discussion on this property is available here [2].

Change history:

v6 -> v7:
  - MAX2175 I2S enable/disable control is made private (Mauro #v4l)
  - Added COMPILE_TEST to rcar_drif in Kconfig (Hans)

v5 -> v6:
  - Addressed Sakari's comments & rebased to his branch.
  - Used fwnode_ instead of of_ apis whereever applicable.

v4 -> v5:
  - Minor documentation changes. Refer individual patches.

v3 -> v4:
  - Added ACKs
rcar_drif:
  - Incorporated a number of review comments from Laurent on DRIF driver.
  - Addressed comments from Rob and Laurent on bindings.
max2175:
  - Minor changes addressing Hans and Laurent's comments

v2 -> v3:
rcar_drif:
  - Reduced DRIF DT properties to expose tested I2S mode only (Hans - 
discussion on #v4l)
  - Fixed error path clean up of ctrl_hdl on rcar_drif

v1 -> v2:
  - SDR formats renamed as "planar" instead of sliced (Hans)
  - Documentation formatting correction (Laurent)

  rcar_drif:
  - DT model using "bonding" property
  - Addressed Laurent's coments on bindings - DT optional parameters rename & 
rework
  - Addressed Han's comments on driver
  - Addressed Geert's comments on DT

  max2175:
  - Avoided scaling using method proposed by Antti. Thanks
  - Bindings is a separate patch (Rob)
  - Addressed Rob's comment on bindings
  - Added Custom controls documentation (Laurent)

[1] v4l2-compliance report:
root@salvator-x:~# v4l2-compliance -S /dev/swradio0
v4l2-compliance SHA   : d57bb8af0c71d82b702e35a7362aa077189dd593

Driver Info:
 Driver name   : rcar_drif
 Card type : R-Car DRIF
 Bus info  : platform:R-Car DRIF
 Driver version: 4.12.0
 Capabilities  : 0x8531
 SDR Capture
 Tuner
 Read/Write
 Streaming
 Extended Pix Format
 Device Capabilities
 Device Caps   : 0x0531
 SDR Capture
 Tuner
 Read/Write
 Streaming
 Extended Pix Format

Compliance test for device /dev/swradio0 (not using libv4l2):

Required ioctls:
 test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
 test second sdr open: OK
 test VIDIOC_QUERYCAP: OK
 test VIDIOC_G/S_PRIORITY: OK
 test for unlimited opens: OK

Debug ioctls:
 test VIDIOC_DBG_G/S_REGISTER: OK
 test VIDIOC_LOG_STATUS: OK

Input ioctls:
 test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK
 test VIDIOC_G/S_FREQUENCY: OK
 test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
 test VIDIOC_ENUMAUDIO: OK (Not Supported)
 test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
 test VIDIOC_G/S_AUDIO: OK (Not Supported)
 Inputs: 0 Audio Inputs: 0 Tuners: 1

Output ioctls:
 test VIDIOC_G/S_MODULATOR: OK (Not Supported)
 test VIDIOC_G/S_FREQUENCY: OK
 test VIDIOC_ENUMAUDOUT: OK (Not Supported)
 test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
 test VIDIOC_G/S_AUDOUT: OK (Not Supported)
 Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
 test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
 test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
 test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
 test VIDIOC_G/S_EDID: OK (Not Supported)

 Control ioctls:
 test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
 test VIDIOC_QUERYCTRL: OK
 test VIDIOC_G/S_CTRL: OK
 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
 Standard Controls: 5 Private Controls: 2

 Format ioctls:
 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
 test VIDIOC_G/S_PARM: OK (Not Supported)
 test VIDIOC_G_FBUF: OK (Not Supported)
 test VIDIOC_G_FMT: OK
 test VIDIOC_TRY_FMT: OK
 test VIDIOC_S_FMT: OK
 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
 test Cropping: OK (Not Supported)
 test Composing: OK (Not Supported)
 

[PATCH v1] net/phy: Make phy_ethtool_ksettings_get return void

2017-06-12 Thread Yuval Shaia
Make return value void since function never return meaningfull value

Signed-off-by: Yuval Shaia 
Acked-by: Sergei Shtylyov 
---
Re-sending since last time forgot to add netdev-list
v0 ->v1:
* These files were missing in v0
* drivers/net/ethernet/renesas/ravb_main.c
* drivers/net/ethernet/renesas/sh_eth.c
* drivers/net/ethernet/ti/netcp_ethss.c
* Add Acked-by: Sergei Shtylyov
---
 drivers/net/ethernet/broadcom/b44.c|  3 ++-
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |  3 ++-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c |  4 +++-
 drivers/net/ethernet/broadcom/tg3.c|  4 +++-
 drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c |  6 ++
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c  |  4 +++-
 drivers/net/ethernet/marvell/mv643xx_eth.c |  5 ++---
 drivers/net/ethernet/renesas/ravb_main.c   | 14 +++---
 drivers/net/ethernet/renesas/sh_eth.c  |  5 ++---
 drivers/net/ethernet/ti/cpsw.c |  9 +
 drivers/net/ethernet/ti/netcp_ethss.c  |  8 +++-
 drivers/net/phy/phy.c  | 10 +-
 drivers/net/usb/lan78xx.c  |  2 +-
 include/linux/phy.h|  4 ++--
 net/dsa/slave.c|  9 +
 15 files changed, 47 insertions(+), 43 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/b44.c 
b/drivers/net/ethernet/broadcom/b44.c
index 5b95bb4..9873d2d 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -1836,7 +1836,8 @@ static int b44_get_link_ksettings(struct net_device *dev,
 
if (bp->flags & B44_FLAG_EXTERNAL_PHY) {
BUG_ON(!dev->phydev);
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c 
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 50d88d3..34ebb40 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1453,7 +1453,8 @@ static int bcm_enet_get_link_ksettings(struct net_device 
*dev,
if (priv->has_phy) {
if (!dev->phydev)
return -ENODEV;
-   return phy_ethtool_ksettings_get(dev->phydev, cmd);
+   phy_ethtool_ksettings_get(dev->phydev, cmd);
+   return 0;
} else {
cmd->base.autoneg = 0;
cmd->base.speed = (priv->force_speed_100) ?
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index a205a9f..daca1c9 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -477,7 +477,9 @@ static int bcmgenet_get_link_ksettings(struct net_device 
*dev,
if (!priv->phydev)
return -ENODEV;
 
-   return phy_ethtool_ksettings_get(priv->phydev, cmd);
+   phy_ethtool_ksettings_get(priv->phydev, cmd);
+
+   return 0;
 }
 
 static int bcmgenet_set_link_ksettings(struct net_device *dev,
diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 537d571..d600c41 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12097,7 +12097,9 @@ static int tg3_get_link_ksettings(struct net_device 
*dev,
if (!(tp->phy_flags & TG3_PHYFLG_IS_CONNECTED))
return -EAGAIN;
phydev = mdiobus_get_phy(tp->mdio_bus, tp->phy_addr);
-   return phy_ethtool_ksettings_get(phydev, cmd);
+   phy_ethtool_ksettings_get(phydev, cmd);
+
+   return 0;
}
 
supported = (SUPPORTED_Autoneg);
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
index 15571e2..aad825088 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
@@ -75,16 +75,14 @@ static char dpaa_stats_global[][ETH_GSTRING_LEN] = {
 static int dpaa_get_link_ksettings(struct net_device *net_dev,
   struct ethtool_link_ksettings *cmd)
 {
-   int err;
-
if (!net_dev->phydev) {
netdev_dbg(net_dev, "phy device not initialized\n");
return 0;
}
 
-   err = phy_ethtool_ksettings_get(net_dev->phydev, cmd);
+   phy_ethtool_ksettings_get(net_dev->phydev, cmd);
 
-   return err;
+   return 0;
 }
 
 static int dpaa_set_link_ksettings(struct net_device *net_dev,
diff --git a/drivers/net/ethernet/freescale/ucc_geth_ethtool.c 
b/drivers/net/ethernet/freescale/ucc_geth_ethtool.c
index b642990..4df282e 100644