Re: [PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

Hi Laurent

Thank you for your feedback

> > +* NOTES
> > +*  N = (n + 1), M = (m + 1), P = 2
> > +*  2000 < fvco < 4096Mhz
> 
> Are you sure that the fvco constraint is really 2kHz, and not 2GHz ? 2kHz - 
> 4GHz would be a surprisingly large range.

It is 2kHz. This is came from HW team, and indicated
on HW design sheet (?)

> > +*  Basically M=1
> 
> Why is this ?

This is came from HW team, too.
They are assuming M=1, basically.
But yes confusable, let's remove it from comment.
m is started from 0 (= M=1), no need to explain.

> > +   for (m = 0; m < 4; m++) {
> > +   for (n = 119; n > 38; n--) {
> > +   unsigned long long fvco = input * 2 * (n + 1) / (m + 1);
> 
> This code runs for Gen3 only, so unsigned long would be enough. The rest of 
> the function already relies on native support for 64-bit calculation. If you 
> wanted to run this on a 32-bit CPU, you would likely need to do_div() for the 
> division, and convert input to u64 to avoid integer overflows, otherwise the 
> calculation will be performed on 32-bit before a final conversion to 64-bit.
(snip)
> > +   if ((fvco < 2000) ||
> > +   (fvco > 409600ll))
> 
> No need for the inner parentheses, and you can write both conditions on a 
> single line. Furthemore 4096 MHz will fit in a 32-bit number, so there's no 
> need for the ll.

Yes, but compiled by 32bit too, right ?
Without this "ll", 32bit compiler say

warning: this decimal constant is unsigned only in ISO C90

# anyway, I will add this assumption (= used only by 64bit CPU)
# on comment to avoid future confusion

> I think you can then drop the output >= 40 check inside the inner 
> fdpll loop, as the output frequency can't be higher than 4GHz if the VCO 
> frequency isn't.

I think code has

if (output >= 4)

This is 400MHz, not 4GHz

> > for (fdpll = 1; fdpll < 32; fdpll++) {
> > unsigned long output;
> 
> The output frequency on the line below can be calculated with
> 
>   output = fvco / 2 / (fdpll + 1)
> 
> to avoid the multiplication by (n + 1) and division by (m + 1).

It is nice idea to avoid extra calculation.
I will use this idea, and add extrate comment to avoid confusion

Best regards
---
Kuninori Morimoto

Re: [RFC PATCH 1/3] kms-tests: Provide .gitignore

[Kieran Bingham]

On 14/12/17 00:25, Kieran Bingham wrote:
> From: Kieran Bingham 

Ahem - Please excuse that person - he's not meant to be working.

> From: Kieran Bingham 

This guy is.

One day I'll acknowledge that my e-mail aliasing is completely overcomplicated.

--
George (Must be one of my other alter-egos)



> 
> Provide an initial .gitignore file to hide python related
> files that may be created in an active workspace
> 
> Signed-off-by: Kieran Bingham 
> ---
>  .gitignore | 4 
>  1 file changed, 4 insertions(+)
>  create mode 100644 .gitignore
> 
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index ..8df6f4ad55ab
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,4 @@
> +*.log
> +*.swp
> +*.pyc
> +__pycache__
> 

[RFC PATCH 2/3] rcar_vin: Provide VIN configuration helpers

[Kieran Bingham]

From: Kieran Bingham 

From: Kieran Bingham 

To handle capturing frames through the RCar VIN subsystem we must
correctly configure the device links and identify the device nodes
to capture from.

Implement a helper class to abstract and handle the VIN objects

Signed-off-by: Kieran Bingham 
---
 tests/rcar_vin.py | 107 +++-
 1 file changed, 107 insertions(+)
 create mode 100755 tests/rcar_vin.py

diff --git a/tests/rcar_vin.py b/tests/rcar_vin.py
new file mode 100755
index ..77923617edb6
--- /dev/null
+++ b/tests/rcar_vin.py
@@ -0,0 +1,107 @@
+#!/usr/bin/python3
+
+import os
+import glob
+
+# model strings are null terminated:
+rcar_gen3_models = [
+'Renesas Salvator-X board based on r8a7795 ES1.x\0',
+'Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+\0',
+'Renesas Salvator-X board based on r8a7796\0',
+'Renesas Eagle board based on r8a77970\0',
+]
+
+rcar_gen3_vin = [
+'e6ef',
+'e6ef1000',
+'e6ef2000',
+'e6ef3000',
+'e6ef4000',
+'e6ef5000',
+'e6ef6000',
+'e6ef7000',
+]
+
+rcar_gen3_csi2 = [
+'fea8',
+'fea9',
+'feaa',
+'feab',
+]
+
+
+class MediaController(object):
+def __init__(self, device):
+for f in glob.glob("/dev/media*"):
+print(f)
+self.cmd = "/usr/bin/media-ctl -d " + device + " "
+
+def reset(self):
+os.system(self.cmd + "-r")
+
+
+class ADV748x(object):
+entities = ['afe', 'hdmi', 'txa', 'txb']
+
+def __init__(self, i2c_addr):
+self.basename = "adv748x " + i2c_addr
+
+def entity_name(self, entity):
+return self.basename + " " + entity
+
+
+class RCar_VIN_G3(object):
+def __init__(self):
+self.model = open('/proc/device-tree/model', 'r').read()
+if self.model not in rcar_gen3_models:
+raise ValueError('Not a supported R-Car Gen3 platform: ' + 
self.model)
+
+# Perhaps we need an interface or python bindings for media controller
+def mc_get_mdev(self):
+for f in glob.glob("/dev/media*"):
+print(f)
+
+def vin_v4l2_device(self, idx):
+''' Return the V4L2 device path (such as /dev/video23) for a given VIN 
'''
+path = "/sys/devices/platform/soc/" + rcar_gen3_vin[idx] + 
".video/video4linux/video*"
+path = glob.glob(path)[0]
+return "/dev/" + os.path.basename(path)
+
+def vin_name(self, idx):
+return "rcar_vin " + rcar_gen3_vin[idx] + ".video"
+
+def csi2_name(self, idx):
+return "rcar_csi2 " + rcar_gen3_csi2[idx] + ".csi2"
+
+def hdmi_in(self):
+print("Configure for HDMI input")
+
+
+###
+# Selftesting
+
+def selftest_MediaController():
+mc = MediaController("/dev/media0")
+mc.reset()
+
+
+def selftest_RCar_VIN_G3():
+target = RCar_VIN_G3()
+print("Detected: " + target.model)
+print("Identifying VIN devices:")
+for i in range(8):
+print("vin" + str(i) + ": " + target.vin_v4l2_device(i))
+target.mc_get_mdev()
+target.hdmi_in()
+
+
+def selftest_ADV748x():
+adv = ADV748x("4-0070")
+print("ADV748x Entities:")
+for e in adv.entities:
+print("" + e + ": " + adv.entity_name(e))
+
+if __name__ == "__main__":
+selftest_MediaController()
+selftest_ADV748x()
+selftest_RCar_VIN_G3()
-- 
git-series 0.9.1

[RFC PATCH 3/3] tests: Add a DU->VIN loopback test

[Kieran Bingham]

From: Kieran Bingham 

From: Kieran Bingham 

Provide an initial test which outputs an image over HDMI using the R-Car DU,
and captures from HDMI-in on the same board.

This test is targetted specifically to the Salvator-X(S) with an ADV748x
HDMI input, and the R-Car VIN driver as a capture interface.

Whilst the media device to collect frames from is automatically detected, the
media controller links and formats are not automatically set up, and thus the
capture pipeline must be correctly defined before running the test.

This can be done using the helper script 'yavta-hdmi.sh' in vin-tests.

Signed-off-by: Kieran Bingham 
---
 tests/kms-test-vin-loopback.py | 198 ++-
 1 file changed, 198 insertions(+)
 create mode 100755 tests/kms-test-vin-loopback.py

diff --git a/tests/kms-test-vin-loopback.py b/tests/kms-test-vin-loopback.py
new file mode 100755
index ..f77ce290efab
--- /dev/null
+++ b/tests/kms-test-vin-loopback.py
@@ -0,0 +1,198 @@
+#!/usr/bin/python3
+
+import kmstest
+import pykms
+import selectors
+
+from rcar_vin import RCar_VIN_G3
+
+class VINLoopbackTest(kmstest.KMSTest):
+""" Output a test image on a specific HDMI connector and capture using an 
HDMI
+cable looped back to the VIN HDMI input device. """
+
+def handle_page_flip(self, frame, time):
+if self.flips == 1:
+self.logger.log("first page flip frame %u time %f" % (frame, time))
+self.frame_start = frame
+self.time_start = time
+
+if self.stop_requested:
+self.logger.log("last page flip frame %u time %f" % (frame, time))
+self.frame_end = frame
+self.time_end = time
+self.loop.stop()
+self.stop_requested = False
+return
+
+# Flip between two constant (identical) pre-created buffers
+fb = self.fbs[self.front_buf]
+self.front_buf = self.front_buf ^ 1
+
+source = kmstest.Rect(0, 0, fb.width, fb.height)
+destination = kmstest.Rect(0, 0, fb.width, fb.height)
+self.atomic_plane_set(self.plane, self.crtc, source, destination, fb)
+
+def stop_page_flip(self):
+self.stop_requested = True
+self.cap.stream_off()
+
+def configure_vin(self, mode):
+vin = RCar_VIN_G3().vin_v4l2_device(0)
+self.logger.log("Using VIN : " + vin)
+
+# Capture frames using VIN
+self.vid = pykms.VideoDevice(vin)
+self.cap = self.vid.capture_streamer
+self.cap.set_port(0)
+self.cap.set_format(self.pixfmt, mode.hdisplay, mode.vdisplay)
+self.cap.set_queue_size(len(self.vin))
+self.captured = 0
+self.failures = 0
+
+for fb in self.vin:
+self.cap.queue(fb)
+
+self.cap.stream_on()
+
+self.loop.register(self.cap.fd, selectors.EVENT_READ, 
self.handle_frame_capture)
+
+
+def handle_frame_capture(self, fileobj, events):
+if self.stop_requested:
+return
+
+fb = self.cap.dequeue()
+diff = pykms.compare_framebuffers(fb, self.fbs[self.front_buf])
+
+self.logger.log("Frame Capture: " + str(self.captured) + " with 
difference " + str(diff))
+
+if diff:
+filename = "/tmp/captured{}.{}x{}.raw".format(str(self.captured), 
str(self.mode.hdisplay), str(self.mode.vdisplay))
+pykms.save_raw_frame(fb, filename)
+self.logger.log("Corrupt frame written to " + filename)
+self.failures += 1
+
+self.cap.queue(fb)
+self.captured += 1
+
+# Stop capturing after 10 frames
+if self.captured >= 10:
+self.stop_page_flip()
+
+
+def get_connector(self, name):
+for connector in self.card.connectors:
+# Skip unless we are HDMI-A-1
+if connector.fullname == "HDMI-A-1":
+return connector
+
+def main(self):
+connector_name = "HDMI-A-1"
+
+self.start("VIN Loopback on connector %s" % connector_name)
+
+connector = self.get_connector(connector_name)
+if connector is None:
+self.skip("HDMI output connector not found")
+return
+
+# Skip disconnected connectors
+if not connector.connected():
+self.skip("unconnected connector")
+return
+
+# Find a CRTC suitable for the connector
+crtc = connector.get_current_crtc()
+if not crtc:
+crtcs = connector.get_possible_crtcs()
+if len(crtcs) == 0:
+self.skip("No CRTC available")
+return
+
+crtc = crtcs[0]
+
+self.crtc = crtc
+
+# Find a plane suitable for the CRTC
+for plane in self.card.planes:
+if plane.supports_crtc(crtc):
+self.plane = plane
+break
+

[RFC PATCH 0/3] [RFC] Video HDMI Loop-back Test

[Kieran Bingham]

From: Kieran Bingham 

This short series works towards providing automated system validation by
introducing the ability to capture frames using the R-Car VIN device with an
HDMI cable connected to our HDMI output of the DU.

To support this test, relevant patches and support must be provided by kmsxx
which has been posted separately [0]:
 [PATCH 0/4] kms++util: Provide validation helpers

This series provides an rcar_vin module to assist in detecting and identifying
the correct video device to use for the video capture device.

The rcar_vin module provides a lot of code which is not used specifically by
the following kms-test-vin-loopback test but is kept in the module as an RFC
and to stimulate discussion on implementing convenient helpers to wrap our
R-Car interfaces in python modules, especially as so much platform knowledge is
required to set up a capture.

Finally the VIN loopback test is added which uses two pre-filled display
buffers to simulate an active running display but with constant content.

The display output is then captured by setting up a VideoDevice interface and
registering a handler (handle_frame_capture) to process buffers when the are
presented by the VIN driver.

The captured frames are compared against the constant output buffer - and
written to file in the event that there are any differences to allow for visual
inspection and analysis.

This test currently highlights potential colour space conversion issues in YUYV
pipelines, and a non-determined error in ARGB configured pipelines which will
be investigated separately.

Further future possibilities here:
 - Automatically configure the media device and links with a media-ctl 
abstraction
 - Add meta-data into the output frames so that they can be correctly matched
   against incoming captured frames. (I'm thinking adding a QR code to each 
frame)

--
Regards

Kieran

[0] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg21303.html

Kieran Bingham (3):
  kms-tests: Provide .gitignore
  rcar_vin: Provide VIN configuration helpers
  tests: Add a DU->VIN loopback test

 .gitignore |   4 +-
 tests/kms-test-vin-loopback.py | 198 ++-
 tests/rcar_vin.py  | 107 ++-
 3 files changed, 309 insertions(+)
 create mode 100644 .gitignore
 create mode 100755 tests/kms-test-vin-loopback.py
 create mode 100755 tests/rcar_vin.py

base-commit: 724e38e6c5f511030d7cbdcd40ccc3d0f8749981
-- 
git-series 0.9.1

[RFC PATCH 1/3] kms-tests: Provide .gitignore

[Kieran Bingham]

From: Kieran Bingham 

From: Kieran Bingham 

Provide an initial .gitignore file to hide python related
files that may be created in an active workspace

Signed-off-by: Kieran Bingham 
---
 .gitignore | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index ..8df6f4ad55ab
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,4 @@
+*.log
+*.swp
+*.pyc
+__pycache__
-- 
git-series 0.9.1

Re: [PATCH] kmstest.py: Update to th latest kmsxx Python bindings

[Kieran Bingham]

Hi Laurent,

Thankyou for this patch. It successfully allows me to use the latest kmsxx,
rather than a much older base that I had been sat on.

Your commit title could do with an 'e' after 'th', but otherwise this patch is
good :D

On 07/12/17 18:33, Laurent Pinchart wrote:
> Commit 706a44abb3aa ("Update to latest pybind11") of kmsxx broke the
> test suite by changing the signature of the AtomicRequest::commit
> function. Update the test suite accordingly.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  tests/kmstest.py | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> The aforementioned commit also broke the test suite due to two other issues
> that need to be fixed in kmsxx. Two patches have been submitted for upstream
> inclusion, they can in the meantime be found at
> 
>   git://git.ideasonboard.com/renesas/kmsxx.git master
> 
> diff --git a/tests/kmstest.py b/tests/kmstest.py
> index 45d619c7a9be..7de785edd1e3 100755
> --- a/tests/kmstest.py
> +++ b/tests/kmstest.py
> @@ -238,7 +238,7 @@ class KMSTest(object):
>  if sync:
>  return req.commit_sync(True)
>  else:
> -return req.commit(self, True)
> +return req.commit(0, True)
>  
>  def atomic_crtc_mode_set(self, crtc, connector, mode, fb=None, 
> sync=False):
>  """Perform a mode set on the given connector and CRTC. The 
> framebuffer,
> @@ -268,7 +268,7 @@ class KMSTest(object):
>  if sync:
>  return req.commit_sync(True)
>  else:
> -return req.commit(self, True)
> +return req.commit(0, True)
>  
>  def atomic_plane_set(self, plane, crtc, source, destination, fb, 
> sync=False):
>  req = pykms.AtomicReq(self.card)
> @@ -287,7 +287,7 @@ class KMSTest(object):
>  if sync:
>  return req.commit_sync()
>  else:
> -return req.commit(self)
> +return req.commit(0)
>  
>  def atomic_planes_disable(self, sync=True):
>  req = pykms.AtomicReq(self.card)
> @@ -297,7 +297,7 @@ class KMSTest(object):
>  if sync:
>  return req.commit_sync()
>  else:
> -return req.commit(self)
> +return req.commit(0)
>  
>  def __handle_page_flip(self, frame, time):
>  self.flips += 1
> 

Re: [PATCH 0/4] kms++util: Provide validation helpers

[Kieran Bingham]

Hi Tomi,

Apologies that I didn't make it particularly clear, but I should have prefixed
this series title with a nice big [RFC] :-D

This is ongoing work to support loop-back validation on our platforms.

Regards

Kieran

On 13/12/17 23:10, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Our kms-tests test suite for verifying the R-Car DU is based on kmsxx.
> 
> We are implementing a 'loop-back' validator, by providing an HDMI cable from
> the display output directly into the HDMI receiver on the same development
> board.
> 
> By using the existing VideoStreamer and pyvid objects, we can capture the 
> output
> and compare to provide automated display validation.
> 
> As an effort to commence this process, this series implements a basic frame
> buffer comparison, which expects identical frame sizes to operate.
> 
> This could be could be expanded upon later to provide a more detailed
> comparison at the pixel level later, but this serves as an initial starting
> point to quickly verify if the data captured matches the data that we 
> expected.
> 
> Kieran Bingham (4):
>   videodevice: Fix minor spacing
>   py: pyvid: Provide stream_off binding
>   kms++util: Add verification module
>   kms++util: Add frame compare functionality
> 
>  kms++util/inc/kms++util/kms++util.h |  3 ++-
>  kms++util/src/verification.cpp  | 52 ++-
>  kms++util/src/videodevice.cpp   |  2 +-
>  py/pykms/pykmsutil.cpp  |  7 -
>  py/pykms/pyvid.cpp  |  1 +-
>  5 files changed, 64 insertions(+), 1 deletion(-)
>  create mode 100644 kms++util/src/verification.cpp
> 
> base-commit: fee73296cae1a4984e18c8d8ee8e50ab217b1e4a
> 

[PATCH 4/4] kms++util: Add frame compare functionality

[Kieran Bingham]

From: Kieran Bingham 

Provide a means to compare two identically sized framebuffers.

This basic implementation expects the two buffers to have the same
formats and sizes, and will return zero for identical frames, or a
positive float representing and average difference otherwise.

Signed-off-by: Kieran Bingham 
---
 kms++util/inc/kms++util/kms++util.h |  1 +-
 kms++util/src/verification.cpp  | 31 ++-
 py/pykms/pykmsutil.cpp  |  2 ++-
 3 files changed, 34 insertions(+)

diff --git a/kms++util/inc/kms++util/kms++util.h 
b/kms++util/inc/kms++util/kms++util.h
index 431de0bb159a..753cee189451 100644
--- a/kms++util/inc/kms++util/kms++util.h
+++ b/kms++util/inc/kms++util/kms++util.h
@@ -29,6 +29,7 @@ void draw_color_bar(IFramebuffer& buf, int old_xpos, int 
xpos, int width);
 void draw_test_pattern(IFramebuffer , YUVType yuvt = YUVType::BT601_Lim);
 
 void save_raw_frame(IFramebuffer& fb, const char *filename);
+float compare_framebuffers(IFramebuffer& a, IFramebuffer& b);
 }
 
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
diff --git a/kms++util/src/verification.cpp b/kms++util/src/verification.cpp
index 3210bb144d2b..a46d6f924095 100644
--- a/kms++util/src/verification.cpp
+++ b/kms++util/src/verification.cpp
@@ -18,4 +18,35 @@ void save_raw_frame(IFramebuffer& fb, const char *filename)
os->write((char*)fb.map(i), fb.size(i));
 }
 
+float compare_framebuffers(IFramebuffer& a, IFramebuffer& b)
+{
+   unsigned int i;
+   unsigned int pixels = a.width() * a.height();
+   uint8_t *pa = a.map(0);
+   uint8_t *pb = b.map(0);
+
+   float diff = 0;
+
+   if (a.format() != b.format())
+   throw std::invalid_argument("Pixel formats differ...");
+
+   if ((a.width() != b.width() ||
+   (a.height() != b.height(
+   throw std::invalid_argument("Frame sizes differ...");
+
+   // Formats are identical, so num_planes are already identical
+   for (i = 0; i < a.num_planes(); i++) {
+   if ((a.offset(i) != b.offset(i)) ||
+   (a.stride(i) != b.stride(i)))
+   throw std::invalid_argument("Planes differ...");
+   }
+
+   // Simple byte comparisons to start.
+   // This expects a frame to be identical, including non-visible data.
+   for (i = 0; i < a.size(0) && i < b.size(0); i++)
+   diff += abs(pa[i] - pb[i]);
+
+   return diff / pixels;
+}
+
 }
diff --git a/py/pykms/pykmsutil.cpp b/py/pykms/pykmsutil.cpp
index 2d741751ba75..b86690a3d306 100644
--- a/py/pykms/pykmsutil.cpp
+++ b/py/pykms/pykmsutil.cpp
@@ -64,4 +64,6 @@ void init_pykmstest(py::module )
m.def("save_raw_frame", [](Framebuffer& fb, const char * filename) {
save_raw_frame(fb, filename);
});
+   m.def("compare_framebuffers", [](Framebuffer& a, Framebuffer& b) {
+   return compare_framebuffers(a, b); } );
 }
-- 
git-series 0.9.1

[PATCH 0/4] kms++util: Provide validation helpers

[Kieran Bingham]

From: Kieran Bingham 

Our kms-tests test suite for verifying the R-Car DU is based on kmsxx.

We are implementing a 'loop-back' validator, by providing an HDMI cable from
the display output directly into the HDMI receiver on the same development
board.

By using the existing VideoStreamer and pyvid objects, we can capture the output
and compare to provide automated display validation.

As an effort to commence this process, this series implements a basic frame
buffer comparison, which expects identical frame sizes to operate.

This could be could be expanded upon later to provide a more detailed
comparison at the pixel level later, but this serves as an initial starting
point to quickly verify if the data captured matches the data that we expected.

Kieran Bingham (4):
  videodevice: Fix minor spacing
  py: pyvid: Provide stream_off binding
  kms++util: Add verification module
  kms++util: Add frame compare functionality

 kms++util/inc/kms++util/kms++util.h |  3 ++-
 kms++util/src/verification.cpp  | 52 ++-
 kms++util/src/videodevice.cpp   |  2 +-
 py/pykms/pykmsutil.cpp  |  7 -
 py/pykms/pyvid.cpp  |  1 +-
 5 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 kms++util/src/verification.cpp

base-commit: fee73296cae1a4984e18c8d8ee8e50ab217b1e4a
-- 
git-series 0.9.1

[PATCH 1/4] videodevice: Fix minor spacing

[Kieran Bingham]

From: Kieran Bingham 

Provide a space between the return type and the function definition

Signed-off-by: Kieran Bingham 
---
 kms++util/src/videodevice.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kms++util/src/videodevice.cpp b/kms++util/src/videodevice.cpp
index e21916bcd06b..efe1678d031e 100644
--- a/kms++util/src/videodevice.cpp
+++ b/kms++util/src/videodevice.cpp
@@ -436,7 +436,7 @@ void VideoStreamer::queue(DumbFramebuffer* fb)
v4l2_queue_dmabuf(m_fd, idx, fb, get_buf_type(m_type));
 }
 
-DumbFramebuffer*VideoStreamer::dequeue()
+DumbFramebuffer* VideoStreamer::dequeue()
 {
uint32_t idx = v4l2_dequeue(m_fd, get_buf_type(m_type));
 
-- 
git-series 0.9.1

[PATCH 2/4] py: pyvid: Provide stream_off binding

[Kieran Bingham]

From: Kieran Bingham 

The videodevice module defines a stream_off function call, but this is
not available in the python bindings interface.

Provide the binding of VideoStreamer::stream_off.

Signed-off-by: Kieran Bingham 
---
 py/pykms/pyvid.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/py/pykms/pyvid.cpp b/py/pykms/pyvid.cpp
index 6a6080e4b2b7..92006c404038 100644
--- a/py/pykms/pyvid.cpp
+++ b/py/pykms/pyvid.cpp
@@ -34,5 +34,6 @@ void init_pyvid(py::module )
.def("queue", ::queue)
.def("dequeue", ::dequeue)
.def("stream_on", ::stream_on)
+   .def("stream_off", ::stream_off)
;
 }
-- 
git-series 0.9.1

[PATCH 3/4] kms++util: Add verification module

[Kieran Bingham]

From: Kieran Bingham 

Provide a util module to provide helpers involved in validation and verification
of data frames.

The first addition is a raw frame binary output with bindings to python modelled
on Tomi's implementation in wbcap.

Signed-off-by: Kieran Bingham 
---
 kms++util/inc/kms++util/kms++util.h |  2 ++
 kms++util/src/verification.cpp  | 21 +
 py/pykms/pykmsutil.cpp  |  5 +
 3 files changed, 28 insertions(+)
 create mode 100644 kms++util/src/verification.cpp

diff --git a/kms++util/inc/kms++util/kms++util.h 
b/kms++util/inc/kms++util/kms++util.h
index 8e45b0df3cde..431de0bb159a 100644
--- a/kms++util/inc/kms++util/kms++util.h
+++ b/kms++util/inc/kms++util/kms++util.h
@@ -27,6 +27,8 @@ void draw_text(IFramebuffer& buf, uint32_t x, uint32_t y, 
const std::string& str
 void draw_color_bar(IFramebuffer& buf, int old_xpos, int xpos, int width);
 
 void draw_test_pattern(IFramebuffer , YUVType yuvt = YUVType::BT601_Lim);
+
+void save_raw_frame(IFramebuffer& fb, const char *filename);
 }
 
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
diff --git a/kms++util/src/verification.cpp b/kms++util/src/verification.cpp
new file mode 100644
index ..3210bb144d2b
--- /dev/null
+++ b/kms++util/src/verification.cpp
@@ -0,0 +1,21 @@
+
+#include 
+#include 
+
+#include 
+
+using namespace std;
+
+namespace kms
+{
+
+void save_raw_frame(IFramebuffer& fb, const char *filename)
+{
+   unique_ptr os;
+   os = unique_ptr(new ofstream(filename, ofstream::binary));
+
+   for (unsigned i = 0; i < fb.num_planes(); ++i)
+   os->write((char*)fb.map(i), fb.size(i));
+}
+
+}
diff --git a/py/pykms/pykmsutil.cpp b/py/pykms/pykmsutil.cpp
index 518d5eaa88f0..2d741751ba75 100644
--- a/py/pykms/pykmsutil.cpp
+++ b/py/pykms/pykmsutil.cpp
@@ -59,4 +59,9 @@ void init_pykmstest(py::module )
} );
m.def("draw_text", [](Framebuffer& fb, uint32_t x, uint32_t y, const 
string& str, RGB color) {
draw_text(fb, x, y, str, color); } );
+
+   // Verification and Validation
+   m.def("save_raw_frame", [](Framebuffer& fb, const char * filename) {
+   save_raw_frame(fb, filename);
+   });
 }
-- 
git-series 0.9.1

[PATCH/RFC v1.1] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

[Laurent Pinchart]

When the DU sources its frames from a VSP, it performs no memory access
and thus has no requirements on imported dma-buf memory types. In
particular the DU could import a physically non-contiguous buffer that
would later be mapped contiguously through the VSP IOMMU.

This use case isn't supported at the moment as the GEM CMA helpers will
reject any non-contiguous buffer, and the DU isn't connected to an IOMMU
that can make the buffer contiguous for DMA. Fix this by implementing a
custom .gem_prime_import_sg_table() operation that accepts all imported
dma-buf regardless of the number of scatterlist entries.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Duplicate the imported scatter gather table in
  rcar_du_vsp_plane_prepare_fb()

This patch fixes a bug of the previous version and is posted in case anyone
would like to test the implementation. I still plan to give Noralf's GEM
library a try as an alternative approach to this series.

 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.h |  7 +++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 34 ++
 4 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 48c166f925a3..d999231f98c7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = {
.gem_prime_import   = drm_gem_prime_import,
.gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+   .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 566d1a948c8f..2dd0c2ba047d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -148,6 +149,44 @@ const struct rcar_du_format_info *rcar_du_format_info(u32 
fourcc)
  * Frame buffer
  */
 
+struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device 
*dev,
+   struct dma_buf_attachment *attach,
+   struct sg_table *sgt)
+{
+   struct rcar_du_device *rcdu = dev->dev_private;
+   struct drm_gem_cma_object *cma_obj;
+   struct drm_gem_object *gem_obj;
+   int ret;
+
+   if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
+   return drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
+
+   /* Create a CMA GEM buffer. */
+   cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
+   if (!cma_obj)
+   return ERR_PTR(-ENOMEM);
+   gem_obj = _obj->base;
+
+   ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size);
+   if (ret)
+   goto error;
+
+   ret = drm_gem_create_mmap_offset(gem_obj);
+   if (ret) {
+   drm_gem_object_release(gem_obj);
+   goto error;
+   }
+
+   cma_obj->paddr = 0;
+   cma_obj->sgt = sgt;
+
+   return gem_obj;
+
+error:
+   kfree(cma_obj);
+   return ERR_PTR(ret);
+}
+
 int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
 {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
index 07951d5fe38b..10b2bb0f0df9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
@@ -16,10 +16,13 @@
 
 #include 
 
+struct dma_buf_attachment;
 struct drm_file;
 struct drm_device;
+struct drm_gem_object;
 struct drm_mode_create_dumb;
 struct rcar_du_device;
+struct sg_table;
 
 struct rcar_du_format_info {
u32 fourcc;
@@ -36,4 +39,8 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu);
 int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
 
+struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device 
*dev,
+   struct dma_buf_attachment *attach,
+   struct sg_table *sgt);
+
 #endif /* __RCAR_DU_KMS_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 2c260c33840b..73fdc814aa39 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -224,10 +224,36 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane 
*plane,
  

[PATCH 4/4] spi: sh-msiof: Document hardware limitations related to chip selects

[Geert Uytterhoeven]

Guide users to maintain the proper balance between native and GPIO chip
selects.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/spi/sh-msiof.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt 
b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index bc8c16a6cfc82685..80710f0f04489174 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -41,6 +41,16 @@ Optional properties:
   0: MSIOF_SYNC
   1: MSIOF_SS1
   2: MSIOF_SS2
+Hardware limitations related to chip selects:
+  - Native chip selects are always deasserted in
+between transfers that are part of the same
+message.  Use cs-gpios to work around this.
+  - All slaves using native chip selects must use the
+same spi-cs-high configuration.  Use cs-gpios to
+work around this.
+  - When using GPIO chip selects, at least one native
+chip select must be left unused, as it will be
+driven anyway.
 - dmas : Must contain a list of two references to DMA
 specifiers, one for transmission, and one for
 reception.
-- 
2.7.4

[PATCH 1/4] spi: sh-msiof: Avoid writing to registers from spi_master.setup()

[Geert Uytterhoeven]

The spi_master.setup() callback must not change configuration registers,
as that could corrupt I/O that is in progress for other SPI slaves.

The only exception is the configuration of the native chip select
polarity in SPI master mode, as a wrong chip select polarity will cause
havoc during all future transfers to any other SPI slave.

Hence stop writing to registers in sh_msiof_spi_setup(), unless it is
the first call for a controller using a native chip select, or unless
native chip select polarity has changed (note that you'll loose anyway
if I/O is in progress).  Even then, only do what is strictly necessary,
instead of calling sh_msiof_spi_set_pin_regs().

Signed-off-by: Geert Uytterhoeven 
---
 drivers/spi/spi-sh-msiof.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 81a9144f5442cdb4..2704abb11ea41fd0 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -55,6 +55,8 @@ struct sh_msiof_spi_priv {
void *rx_dma_page;
dma_addr_t tx_dma_addr;
dma_addr_t rx_dma_addr;
+   bool native_cs_inited;
+   bool native_cs_high;
bool slave_aborted;
 };
 
@@ -528,8 +530,7 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
 {
struct device_node  *np = spi->master->dev.of_node;
struct sh_msiof_spi_priv *p = spi_master_get_devdata(spi->master);
-
-   pm_runtime_get_sync(>pdev->dev);
+   u32 clr, set, tmp;
 
if (!np) {
/*
@@ -539,19 +540,31 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
spi->cs_gpio = (uintptr_t)spi->controller_data;
}
 
-   /* Configure pins before deasserting CS */
-   sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL),
- !!(spi->mode & SPI_CPHA),
- !!(spi->mode & SPI_3WIRE),
- !!(spi->mode & SPI_LSB_FIRST),
- !!(spi->mode & SPI_CS_HIGH));
-
-   if (spi->cs_gpio >= 0)
+   if (spi->cs_gpio >= 0) {
gpio_set_value(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
+   return 0;
+   }
 
+   if (spi_controller_is_slave(p->master))
+   return 0;
 
-   pm_runtime_put(>pdev->dev);
+   if (p->native_cs_inited &&
+   (p->native_cs_high == !!(spi->mode & SPI_CS_HIGH)))
+   return 0;
 
+   /* Configure native chip select mode/polarity early */
+   clr = MDR1_SYNCMD_MASK;
+   set = MDR1_TRMD | TMDR1_PCON | MDR1_SYNCMD_SPI;
+   if (spi->mode & SPI_CS_HIGH)
+   clr |= BIT(MDR1_SYNCAC_SHIFT);
+   else
+   set |= BIT(MDR1_SYNCAC_SHIFT);
+   pm_runtime_get_sync(>pdev->dev);
+   tmp = sh_msiof_read(p, TMDR1) & ~clr;
+   sh_msiof_write(p, TMDR1, tmp | set);
+   pm_runtime_put(>pdev->dev);
+   p->native_cs_high = spi->mode & SPI_CS_HIGH;
+   p->native_cs_inited = true;
return 0;
 }
 
-- 
2.7.4

[PATCH 0/4] spi: sh-msiof: Multi-slave enhancements

[Geert Uytterhoeven]

Hi Mark², Rob,

This patch series enhances the Renesas MSIOF SPI controller driver for
multiple SPI slave devices.

The first patch fixes the classical pitfall of writing to configuration
registers from the spi_master.setup() callback, where possible.
The second patch extends support from 1 to 3 native chip selects,
The third patch fixes the use of GPIOs as chip selects on modern
platform using DT instead of board code.
The last patch documents hardware limitations related to chip selects,
to guide board designers and DTS writers.

This has been tested with:
  - Three 25LC040 SPI EEPROMs, using GPIO chip selects due to MSIOF
hardware limitations (verified with a logic analyzer),
  - Multiple 74HC595 shift registers feeding lots of blinkenlights,
using only native chipselects, only GPIO chip selects, and a healthy
mix of both.

Thanks for your comments!

Geert Uytterhoeven (4):
  spi: sh-msiof: Avoid writing to registers from spi_master.setup()
  spi: sh-msiof: Extend support to 3 native chip selects
  spi: sh-msiof: Implement cs-gpios configuration
  spi: sh-msiof: Document hardware limitations related to chip selects

 Documentation/devicetree/bindings/spi/sh-msiof.txt |  16 ++-
 drivers/spi/spi-sh-msiof.c | 111 +
 2 files changed, 107 insertions(+), 20 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 2/4] spi: sh-msiof: Extend support to 3 native chip selects

[Geert Uytterhoeven]

Currently only the MSIOF_SYNC signal can be used as a native chip
select.  Extend support to up to 3 native chipselects using the
MSIOF_SS1 and MSIOF_SS2 signals.

Inspired by a patch in the BSP by Hiromitsu Yamasaki.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/spi/sh-msiof.txt |  6 +-
 drivers/spi/spi-sh-msiof.c | 18 +-
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt 
b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index bdd83959019c7883..bc8c16a6cfc82685 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -36,7 +36,11 @@ Required properties:
 
 Optional properties:
 - clocks   : Must contain a reference to the functional clock.
-- num-cs   : Total number of chip-selects (default is 1)
+- num-cs   : Total number of chip selects (default is 1).
+Up to 3 native chip selects are supported:
+  0: MSIOF_SYNC
+  1: MSIOF_SS1
+  2: MSIOF_SS2
 - dmas : Must contain a list of two references to DMA
 specifiers, one for transmission, and one for
 reception.
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 2704abb11ea41fd0..9bdc292aa050cb16 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -60,6 +60,8 @@ struct sh_msiof_spi_priv {
bool slave_aborted;
 };
 
+#define MAX_SS 3   /* Maximum number of native chip selects */
+
 #define TMDR1  0x00/* Transmit Mode Register 1 */
 #define TMDR2  0x04/* Transmit Mode Register 2 */
 #define TMDR3  0x08/* Transmit Mode Register 3 */
@@ -93,6 +95,8 @@ struct sh_msiof_spi_priv {
 #define MDR1_XXSTP  0x0001 /* Transmission/Reception Stop on FIFO */
 /* TMDR1 */
 #define TMDR1_PCON  0x4000 /* Transfer Signal Connection */
+#define TMDR1_SYNCCH_MASK 0xc00 /* Synchronization Signal Channel Select */
+#define TMDR1_SYNCCH_SHIFT  26 /* 0=MSIOF_SYNC, 1=MSIOF_SS1, 2=MSIOF_SS2 */
 
 /* TMDR2 and RMDR2 */
 #define MDR2_BITLEN1(i)(((i) - 1) << 24) /* Data Size (8-32 bits) */
@@ -326,7 +330,7 @@ static u32 sh_msiof_spi_get_dtdl_and_syncdl(struct 
sh_msiof_spi_priv *p)
return val;
 }
 
-static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
+static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p, u32 ss,
  u32 cpol, u32 cpha,
  u32 tx_hi_z, u32 lsb_first, u32 cs_high)
 {
@@ -344,10 +348,13 @@ static void sh_msiof_spi_set_pin_regs(struct 
sh_msiof_spi_priv *p,
tmp |= !cs_high << MDR1_SYNCAC_SHIFT;
tmp |= lsb_first << MDR1_BITLSB_SHIFT;
tmp |= sh_msiof_spi_get_dtdl_and_syncdl(p);
-   if (spi_controller_is_slave(p->master))
+   if (spi_controller_is_slave(p->master)) {
sh_msiof_write(p, TMDR1, tmp | TMDR1_PCON);
-   else
-   sh_msiof_write(p, TMDR1, tmp | MDR1_TRMD | TMDR1_PCON);
+   } else {
+   sh_msiof_write(p, TMDR1,
+  tmp | MDR1_TRMD | TMDR1_PCON |
+  (ss < MAX_SS ? ss : 0) << TMDR1_SYNCCH_SHIFT);
+   }
if (p->master->flags & SPI_MASTER_MUST_TX) {
/* These bits are reserved if RX needs TX */
tmp &= ~0x;
@@ -575,7 +582,8 @@ static int sh_msiof_prepare_message(struct spi_master 
*master,
const struct spi_device *spi = msg->spi;
 
/* Configure pins before asserting CS */
-   sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL),
+   sh_msiof_spi_set_pin_regs(p, spi->chip_select,
+ !!(spi->mode & SPI_CPOL),
  !!(spi->mode & SPI_CPHA),
  !!(spi->mode & SPI_3WIRE),
  !!(spi->mode & SPI_LSB_FIRST),
-- 
2.7.4

[PATCH 3/4] spi: sh-msiof: Implement cs-gpios configuration

[Geert Uytterhoeven]

The current support for GPIO chip selects assumes the GPIOs have been
configured by platform code or the boot loader.  This includes pinmux
setup and GPIO direction.  Hence it does not work as expected when just
described in DT using the "cs-gpios" property.

Fix this by:
  1. using devm_gpiod_get_index() to request the GPIO, and thus
 configure pinmux, if needed,
  2. configuring the GPIO direction is the spi_master.setup() callback.

Use gpio_is_valid() instead of a check on positive numbers.

Note that when using GPIO chip selects, at least one native chip select
must be left unused, as that native chip select will be driven anyway,
and (global) native chip select polarity must be taken into account.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/spi/spi-sh-msiof.c | 66 +-
 1 file changed, 59 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 9bdc292aa050cb16..8aa5c7b910d9ca93 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -55,6 +56,7 @@ struct sh_msiof_spi_priv {
void *rx_dma_page;
dma_addr_t tx_dma_addr;
dma_addr_t rx_dma_addr;
+   unsigned short unused_ss;
bool native_cs_inited;
bool native_cs_high;
bool slave_aborted;
@@ -547,8 +549,8 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
spi->cs_gpio = (uintptr_t)spi->controller_data;
}
 
-   if (spi->cs_gpio >= 0) {
-   gpio_set_value(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
+   if (gpio_is_valid(spi->cs_gpio)) {
+   gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
return 0;
}
 
@@ -580,14 +582,20 @@ static int sh_msiof_prepare_message(struct spi_master 
*master,
 {
struct sh_msiof_spi_priv *p = spi_master_get_devdata(master);
const struct spi_device *spi = msg->spi;
+   u32 ss, cs_high;
 
/* Configure pins before asserting CS */
-   sh_msiof_spi_set_pin_regs(p, spi->chip_select,
- !!(spi->mode & SPI_CPOL),
+   if (gpio_is_valid(spi->cs_gpio)) {
+   ss = p->unused_ss;
+   cs_high = p->native_cs_high;
+   } else {
+   ss = spi->chip_select;
+   cs_high = !!(spi->mode & SPI_CS_HIGH);
+   }
+   sh_msiof_spi_set_pin_regs(p, ss, !!(spi->mode & SPI_CPOL),
  !!(spi->mode & SPI_CPHA),
  !!(spi->mode & SPI_3WIRE),
- !!(spi->mode & SPI_LSB_FIRST),
- !!(spi->mode & SPI_CS_HIGH));
+ !!(spi->mode & SPI_LSB_FIRST), cs_high);
return 0;
 }
 
@@ -1091,6 +1099,45 @@ static struct sh_msiof_spi_info 
*sh_msiof_spi_parse_dt(struct device *dev)
 }
 #endif
 
+static int sh_msiof_get_cs_gpios(struct sh_msiof_spi_priv *p)
+{
+   struct device *dev = >pdev->dev;
+   unsigned int used_ss_mask = 0;
+   unsigned int cs_gpios = 0;
+   unsigned int num_cs, i;
+   int ret;
+
+   ret = gpiod_count(dev, "cs");
+   if (ret <= 0)
+   return 0;
+
+   num_cs = max_t(unsigned int, ret, p->master->num_chipselect);
+   for (i = 0; i < num_cs; i++) {
+   struct gpio_desc *gpiod;
+
+   gpiod = devm_gpiod_get_index(dev, "cs", i, GPIOD_ASIS);
+   if (!IS_ERR(gpiod)) {
+   cs_gpios++;
+   continue;
+   }
+
+   if (PTR_ERR(gpiod) != -ENOENT)
+   return PTR_ERR(gpiod);
+
+   if (i >= MAX_SS) {
+   dev_err(dev, "Invalid native chip select %d\n", i);
+   return -EINVAL;
+   }
+   used_ss_mask |= BIT(i);
+   }
+   p->unused_ss = ffz(used_ss_mask);
+   if (cs_gpios && p->unused_ss >= MAX_SS) {
+   dev_err(dev, "No unused native chip select available\n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 static struct dma_chan *sh_msiof_request_dma_chan(struct device *dev,
enum dma_transfer_direction dir, unsigned int id, dma_addr_t port_addr)
 {
@@ -1304,13 +1351,18 @@ static int sh_msiof_spi_probe(struct platform_device 
*pdev)
if (p->info->rx_fifo_override)
p->rx_fifo_size = p->info->rx_fifo_override;
 
+   /* Setup GPIO chip selects */
+   master->num_chipselect = p->info->num_chipselect;
+   ret = sh_msiof_get_cs_gpios(p);
+   if (ret)
+   goto err1;
+
/* init master code */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
master->mode_bits |= SPI_LSB_FIRST | SPI_3WIRE;
master->flags = chipdata->master_flags;

[PATCH 5/5] v4l2: async: Add debug output to v4l2-async module

[Jacopo Mondi]

The v4l2-async module operations are quite complex to follow, due to the
asynchronous nature of subdevices and notifiers registration and
matching procedures. In order to help with debugging of failed or
erroneous matching between a subdevice and the notifier collected
async_subdevice it gets matched against, introduce a few dev_dbg() calls
in v4l2_async core operations.

Protect the debug operations with a Kconfig defined symbol, to make sure
when debugging is disabled, no additional code or data is added to the
module.

Notifiers are identified by the name of the subdevice or v4l2_dev they are
registered by, while subdevice matching which now happens on endpoints,
need a longer description built walking the fwnode graph backwards
collecting parent nodes names (otherwise we would have had printouts
like: "Matching "endpoint" with "endpoint"" which are not that useful).

Signed-off-by: Jacopo Mondi 

---
For fwnodes backed by OF, I may have used the "%pOF" format modifier to
get the full node name instead of parsing the fwnode graph by myself with
"v4l2_async_fwnode_full_name()". Unfortunately I'm not aware of anything
like "%pOF" for ACPI backed fwnodes. Also, walking the fwnode graph by
myself allows me to reduce the depth, to reduce the debug messages output
length which is anyway long enough to result disturbing on a 80columns
terminal window.
---

 drivers/media/v4l2-core/Kconfig  |  8 
 drivers/media/v4l2-core/v4l2-async.c | 81 
 2 files changed, 89 insertions(+)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index a35c336..8331736 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -17,6 +17,14 @@ config VIDEO_ADV_DEBUG
  V4L devices.
  In doubt, say N.

+config VIDEO_V4L2_ASYNC_DEBUG
+   bool "Enable debug functionalities for V4L2 async module"
+   depends on VIDEO_V4L2
+   default n
+   ---help---
+ Say Y here to enable debug output in V4L2 async module.
+ In doubt, say N.
+
 config VIDEO_FIXED_MINOR_RANGES
bool "Enable old-style fixed minor ranges on drivers/video devices"
default n
diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index c13a781..307e1a5 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -8,6 +8,10 @@
  * published by the Free Software Foundation.
  */

+#if defined(CONFIG_VIDEO_V4L2_ASYNC_DEBUG)
+#define DEBUG
+#endif
+
 #include 
 #include 
 #include 
@@ -25,6 +29,52 @@
 #include 
 #include 

+#if defined(CONFIG_VIDEO_V4L2_ASYNC_DEBUG)
+#define V4L2_ASYNC_FWNODE_NAME_LEN 512
+
+static void __v4l2_async_fwnode_full_name(char *name,
+ unsigned int len,
+ unsigned int max_depth,
+ struct fwnode_handle *fwnode)
+{
+   unsigned int buf_len = len < V4L2_ASYNC_FWNODE_NAME_LEN ?
+  len : V4L2_ASYNC_FWNODE_NAME_LEN;
+   char __tmp[V4L2_ASYNC_FWNODE_NAME_LEN];
+   struct fwnode_handle *parent;
+
+   memset(name, 0, buf_len);
+   buf_len -= snprintf(__tmp, buf_len, "%s", fwnode_get_name(fwnode));
+
+   parent = fwnode;
+   while ((parent = fwnode_get_parent(parent)) && buf_len &&
+   --max_depth) {
+   buf_len -= snprintf(name, buf_len, "%s/%s",
+   fwnode_get_name(parent), __tmp);
+   strcpy(__tmp, name);
+   }
+}
+
+static void v4l2_async_fwnode_full_name(char *name,
+   unsigned int len,
+   struct fwnode_handle *fwnode)
+{
+   /*
+* Usually 4 as nesting level is sufficient to identify an
+* endpoint firmware node uniquely.
+*/
+   __v4l2_async_fwnode_full_name(name, len, 4, fwnode);
+}
+
+#else /* CONFIG_VIDEO_V4L2_ASYNC_DEBUG */
+#define V4L2_ASYNC_FWNODE_NAME_LEN 0
+
+static void v4l2_async_fwnode_full_name(char *name,
+   unsigned int len,
+   struct fwnode_handle *fwnode)
+{
+}
+#endif /* CONFIG_VIDEO_V4L2_ASYNC_DEBUG */
+
 static struct device *v4l2_async_notifier_dev(
struct v4l2_async_notifier *notifier)
 {
@@ -54,9 +104,12 @@ static void v4l2_async_notifier_call_unbind(struct 
v4l2_async_notifier *n,

 static int v4l2_async_notifier_call_complete(struct v4l2_async_notifier *n)
 {
+   struct device *dev = v4l2_async_notifier_dev(n);
if (!n->ops || !n->ops->complete)
return 0;

+   dev_dbg(dev, "Complete notifier \"%s\"\n", fwnode_get_name(n->owner));
+
return n->ops->complete(n);
 }

@@ -100,8 +153,17 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
struct v4l2_async_notifier 

[PATCH 3/5] include: v4l2_async: Add 'owner' field to notifier

[Jacopo Mondi]

Notifiers can be registered as root notifiers (identified by a 'struct
v4l2_device *') or subdevice notifiers (identified by a 'struct
v4l2_subdev *'). In order to identify a notifier no matter if it is root
or not, add a 'struct fwnode_handle *owner' field, whose name can be
printed out for debug purposes.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/v4l2-core/v4l2-async.c | 2 ++
 include/media/v4l2-async.h   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index a6bddff..0a1bf1d 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -447,6 +447,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
return -EINVAL;
 
notifier->v4l2_dev = v4l2_dev;
+   notifier->owner = dev_fwnode(v4l2_dev->dev);
 
ret = __v4l2_async_notifier_register(notifier);
if (ret)
@@ -465,6 +466,7 @@ int v4l2_async_subdev_notifier_register(struct v4l2_subdev 
*sd,
return -EINVAL;
 
notifier->sd = sd;
+   notifier->owner = dev_fwnode(sd->dev);
 
ret = __v4l2_async_notifier_register(notifier);
if (ret)
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 6152434..a15c01d 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -106,6 +106,7 @@ struct v4l2_async_notifier_operations {
  * @v4l2_dev:  v4l2_device of the root notifier, NULL otherwise
  * @sd:sub-device that registered the notifier, NULL otherwise
  * @parent:parent notifier
+ * @owner: reference to notifier fwnode_handle, mostly useful for debug
  * @waiting:   list of struct v4l2_async_subdev, waiting for their drivers
  * @done:  list of struct v4l2_subdev, already probed
  * @list:  member in a global list of notifiers
@@ -118,6 +119,7 @@ struct v4l2_async_notifier {
struct v4l2_device *v4l2_dev;
struct v4l2_subdev *sd;
struct v4l2_async_notifier *parent;
+   struct fwnode_handle *owner;
struct list_head waiting;
struct list_head done;
struct list_head list;
-- 
2.7.4

[PATCH 1/5] v4l: async: Use endpoint node, not device node, for fwnode match

[Jacopo Mondi]

From: Sakari Ailus 

V4L2 async framework can use both device's fwnode and endpoints's fwnode
for matching the async sub-device with the sub-device. In order to proceed
moving towards endpoint matching assign the endpoint to the async
sub-device.

As most async sub-device drivers (and the related hardware) only supports
a single endpoint, use the first endpoint found. This works for all
current drivers --- we only ever supported a single async sub-device per
device to begin with.

For async devices that have no endpoints, continue to use the fwnode
related to the device. This includes e.g. lens devices.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/am437x/am437x-vpfe.c|  2 +-
 drivers/media/platform/atmel/atmel-isc.c   |  2 +-
 drivers/media/platform/atmel/atmel-isi.c   |  2 +-
 drivers/media/platform/davinci/vpif_capture.c  |  2 +-
 drivers/media/platform/exynos4-is/media-dev.c  | 14 ++
 drivers/media/platform/pxa_camera.c|  2 +-
 drivers/media/platform/qcom/camss-8x16/camss.c |  2 +-
 drivers/media/platform/rcar_drif.c |  2 +-
 drivers/media/platform/stm32/stm32-dcmi.c  |  2 +-
 drivers/media/platform/ti-vpe/cal.c|  2 +-
 drivers/media/platform/xilinx/xilinx-vipp.c| 16 +---
 drivers/media/v4l2-core/v4l2-async.c   |  8 ++--
 drivers/media/v4l2-core/v4l2-fwnode.c  |  2 +-
 13 files changed, 39 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
b/drivers/media/platform/am437x/am437x-vpfe.c
index 0997c64..892d9e9 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -2493,7 +2493,7 @@ vpfe_get_pdata(struct platform_device *pdev)
if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
sdinfo->vpfe_param.vdpol = 1;
 
-   rem = of_graph_get_remote_port_parent(endpoint);
+   rem = of_graph_get_remote_endpoint(endpoint);
if (!rem) {
dev_err(>dev, "Remote device at %pOF not found\n",
endpoint);
diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 13f1c1c..c8bb60e 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -2044,7 +2044,7 @@ static int isc_parse_dt(struct device *dev, struct 
isc_device *isc)
if (!epn)
break;
 
-   rem = of_graph_get_remote_port_parent(epn);
+   rem = of_graph_get_remote_endpoint(epn);
if (!rem) {
dev_notice(dev, "Remote device at %pOF not found\n",
   epn);
diff --git a/drivers/media/platform/atmel/atmel-isi.c 
b/drivers/media/platform/atmel/atmel-isi.c
index e900995..eafdf91 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -1119,7 +1119,7 @@ static int isi_graph_parse(struct atmel_isi *isi, struct 
device_node *node)
if (!ep)
return -EINVAL;
 
-   remote = of_graph_get_remote_port_parent(ep);
+   remote = of_graph_get_remote_endpoint(ep);
if (!remote) {
of_node_put(ep);
return -EINVAL;
diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index a89367a..e150d75 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1572,7 +1572,7 @@ vpif_capture_get_pdata(struct platform_device *pdev)
if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
chan->vpif_if.vd_pol = 1;
 
-   rem = of_graph_get_remote_port_parent(endpoint);
+   rem = of_graph_get_remote_endpoint(endpoint);
if (!rem) {
dev_dbg(>dev, "Remote device at %pOF not found\n",
endpoint);
diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index c15596b..c6b0220 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -409,7 +409,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
 
pd->mux_id = (endpoint.base.port - 1) & 0x1;
 
-   rem = of_graph_get_remote_port_parent(ep);
+   rem = of_graph_get_remote_endpoint(ep);
of_node_put(ep);
if (rem == NULL) {
v4l2_info(>v4l2_dev, "Remote device at %pOF not found\n",
@@ -1360,11 +1360,17 @@ static int subdev_notifier_bound(struct 
v4l2_async_notifier *notifier,
int i;
 
/* Find platform data for this sensor subdev */
-   for (i = 0; i < ARRAY_SIZE(fmd->sensor); i++)
-  

[PATCH 2/5] device property: Add fwnode_get_name() operation

[Jacopo Mondi]

Add operation to retrieve the device name from a fwnode handle.

Signed-off-by: Jacopo Mondi 
---
 drivers/acpi/property.c  |  6 ++
 drivers/base/property.c  | 12 
 drivers/of/property.c|  6 ++
 include/linux/fwnode.h   |  2 ++
 include/linux/property.h |  1 +
 5 files changed, 27 insertions(+)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index e26ea20..1e3971c 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1186,6 +1186,11 @@ acpi_fwnode_property_read_string_array(const struct 
fwnode_handle *fwnode,
   val, nval);
 }
 
+static const char *acpi_fwnode_get_name(const struct fwnode_handle *fwnode)
+{
+   return acpi_dev_name(to_acpi_device_node(fwnode));
+}
+
 static struct fwnode_handle *
 acpi_fwnode_get_named_child_node(const struct fwnode_handle *fwnode,
 const char *childname)
@@ -1281,6 +1286,7 @@ static int acpi_fwnode_graph_parse_endpoint(const struct 
fwnode_handle *fwnode,
acpi_fwnode_property_read_string_array, \
.get_parent = acpi_node_get_parent, \
.get_next_child_node = acpi_get_next_subnode,   \
+   .get_name = acpi_fwnode_get_name,   \
.get_named_child_node = acpi_fwnode_get_named_child_node, \
.get_reference_args = acpi_fwnode_get_reference_args,   \
.graph_get_next_endpoint =  \
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 851b1b6..a87b4a9 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -950,6 +950,18 @@ int device_add_properties(struct device *dev,
 EXPORT_SYMBOL_GPL(device_add_properties);
 
 /**
+ * fwnode_get_name - Return the fwnode_handle name
+ * @fwnode: Firmware node to get name from
+ *
+ * Returns a pointer to the firmware node name
+ */
+const char *fwnode_get_name(const struct fwnode_handle *fwnode)
+{
+   return fwnode_call_ptr_op(fwnode, get_name);
+}
+EXPORT_SYMBOL(fwnode_get_name);
+
+/**
  * fwnode_get_next_parent - Iterate to the node's parent
  * @fwnode: Firmware whose parent is retrieved
  *
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 8ad33a4..6c195a8 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -875,6 +875,11 @@ of_fwnode_property_read_string_array(const struct 
fwnode_handle *fwnode,
of_property_count_strings(node, propname);
 }
 
+static const char *of_fwnode_get_name(const struct fwnode_handle *fwnode)
+{
+   return of_node_full_name(to_of_node(fwnode));
+}
+
 static struct fwnode_handle *
 of_fwnode_get_parent(const struct fwnode_handle *fwnode)
 {
@@ -988,6 +993,7 @@ const struct fwnode_operations of_fwnode_ops = {
.property_present = of_fwnode_property_present,
.property_read_int_array = of_fwnode_property_read_int_array,
.property_read_string_array = of_fwnode_property_read_string_array,
+   .get_name = of_fwnode_get_name,
.get_parent = of_fwnode_get_parent,
.get_next_child_node = of_fwnode_get_next_child_node,
.get_named_child_node = of_fwnode_get_named_child_node,
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 411a84c..5d3a8c6 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -57,6 +57,7 @@ struct fwnode_reference_args {
  *  otherwise.
  * @property_read_string_array: Read an array of string properties. Return zero
  * on success, a negative error code otherwise.
+ * @get_name: Return the fwnode name.
  * @get_parent: Return the parent of an fwnode.
  * @get_next_child_node: Return the next child node in an iteration.
  * @get_named_child_node: Return a child node with a given name.
@@ -81,6 +82,7 @@ struct fwnode_operations {
(*property_read_string_array)(const struct fwnode_handle *fwnode_handle,
  const char *propname, const char **val,
  size_t nval);
+   const char *(*get_name)(const struct fwnode_handle *fwnode);
struct fwnode_handle *(*get_parent)(const struct fwnode_handle *fwnode);
struct fwnode_handle *
(*get_next_child_node)(const struct fwnode_handle *fwnode,
diff --git a/include/linux/property.h b/include/linux/property.h
index f6189a3..0fc464f 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -78,6 +78,7 @@ int fwnode_property_get_reference_args(const struct 
fwnode_handle *fwnode,
   unsigned int nargs, unsigned int index,
   struct fwnode_reference_args *args);
 
+const char *fwnode_get_name(const struct fwnode_handle *fwnode);
 struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle *fwnode);
 struct fwnode_handle 

[PATCH 4/5] v4l2: async: Postpone subdev_notifier registration

[Jacopo Mondi]

Currently, subdevice notifiers are tested against all available
subdevices as soon as they get registered. It often happens anyway
that the subdevice they are connected to is not yet initialized, as
it usually gets registered later in drivers' code. This makes debug
of v4l2_async particularly painful, as identifying a notifier with
an unitialized subdevice is tricky as they don't have a valid
'struct device *' or 'struct fwnode_handle *' to be identified with.

In order to make sure that the notifier's subdevices is initialized
when the notifier is tesed against available subdevices post-pone the
actual notifier registration at subdevice registration time.

It is worth noting that post-poning registration of a subdevice notifier
does not impact on the completion of the notifiers chain, as even if a
subdev notifier completes as soon as it gets registered, the complete()
call chain cannot be upscaled as long as the subdevice the notifiers
belongs to is not registered.

Also, it is now safe to access a notifier 'struct device *' as we're now
sure it is properly initialized when the notifier is actually
registered.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/v4l2-core/v4l2-async.c | 65 +++-
 include/media/v4l2-async.h   |  2 ++
 2 files changed, 43 insertions(+), 24 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 0a1bf1d..c13a781 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -25,6 +25,13 @@
 #include 
 #include 

+static struct device *v4l2_async_notifier_dev(
+   struct v4l2_async_notifier *notifier)
+{
+   return notifier->v4l2_dev ? notifier->v4l2_dev->dev :
+   notifier->sd->dev;
+}
+
 static int v4l2_async_notifier_call_bound(struct v4l2_async_notifier *n,
  struct v4l2_subdev *subdev,
  struct v4l2_async_subdev *asd)
@@ -124,19 +131,6 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
return NULL;
 }

-/* Find the sub-device notifier registered by a sub-device driver. */
-static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
-   struct v4l2_subdev *sd)
-{
-   struct v4l2_async_notifier *n;
-
-   list_for_each_entry(n, _list, list)
-   if (n->sd == sd)
-   return n;
-
-   return NULL;
-}
-
 /* Get v4l2_device related to the notifier if one can be found. */
 static struct v4l2_device *v4l2_async_notifier_find_v4l2_dev(
struct v4l2_async_notifier *notifier)
@@ -160,7 +154,7 @@ static bool v4l2_async_notifier_can_complete(

list_for_each_entry(sd, >done, async_list) {
struct v4l2_async_notifier *subdev_notifier =
-   v4l2_async_find_subdev_notifier(sd);
+   sd->subdev_notifier;

if (subdev_notifier &&
!v4l2_async_notifier_can_complete(subdev_notifier))
@@ -228,7 +222,7 @@ static int v4l2_async_match_notify(struct 
v4l2_async_notifier *notifier,
/*
 * See if the sub-device has a notifier. If not, return here.
 */
-   subdev_notifier = v4l2_async_find_subdev_notifier(sd);
+   subdev_notifier = sd->subdev_notifier;
if (!subdev_notifier || subdev_notifier->parent)
return 0;

@@ -294,7 +288,7 @@ static void v4l2_async_notifier_unbind_all_subdevs(

list_for_each_entry_safe(sd, tmp, >done, async_list) {
struct v4l2_async_notifier *subdev_notifier =
-   v4l2_async_find_subdev_notifier(sd);
+   sd->subdev_notifier;

if (subdev_notifier)
v4l2_async_notifier_unbind_all_subdevs(subdev_notifier);
@@ -371,8 +365,7 @@ static bool v4l2_async_notifier_fwnode_has_async_subdev(

 static int __v4l2_async_notifier_register(struct v4l2_async_notifier *notifier)
 {
-   struct device *dev =
-   notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL;
+   struct device *dev = v4l2_async_notifier_dev(notifier);
struct v4l2_async_subdev *asd;
int ret;
int i;
@@ -383,6 +376,8 @@ static int __v4l2_async_notifier_register(struct 
v4l2_async_notifier *notifier)
INIT_LIST_HEAD(>waiting);
INIT_LIST_HEAD(>done);

+   notifier->owner = dev_fwnode(dev);
+
mutex_lock(_lock);

for (i = 0; i < notifier->num_subdevs; i++) {
@@ -421,6 +416,7 @@ static int __v4l2_async_notifier_register(struct 
v4l2_async_notifier *notifier)

/* Keep also completed notifiers on the list */
list_add(>list, _list);
+   notifier->registered = true;

mutex_unlock(_lock);

@@ -447,7 +443,7 @@ int v4l2_async_notifier_register(struct 

[PATCH 0/5] Add debug output to v4l2-async

[Jacopo Mondi]

Hello Sakari,
   while testing rcar-vin setup on top of your RFC (included in the series)
that moves the framework to perform endpoint matching, I realized how hard is
to follow what happens with asynchronous notifiers, sub-notifiers and
sub-devices.

In order to better understand what happens and ease debug of v4l2-async
operations I have introduced some dev_dbg() output, protected by a Kconfig
option.

Before being able to properly identify (sub-)notifiers and subdevices I had to
extend fwnode_* framework to support a new .get_name() operation, and modify
v4l2_async to make sure notifiers always have a valid fwnode_handle field to
be identified with.

I have tested this only with not yet mainlined drivers (rcar-vin, rcar-csi2,
max9286) each of them performing non-trivial endpoint matching. Also I only
tested this on OF based systems (not tested on ACPI).
This considered, I am copying linux-media anyhow for feedbacks.

Thanks
   j

Jacopo Mondi (4):
  device property: Add fwnode_get_name() operation
  include: v4l2_async: Add 'owner' field to notifier
  v4l2: async: Postpone subdev_notifier registration
  v4l2: async: Add debug output to v4l2-async module

Sakari Ailus (1):
  v4l: async: Use endpoint node, not device node, for fwnode match

 drivers/acpi/property.c|   6 +
 drivers/base/property.c|  12 ++
 drivers/media/platform/am437x/am437x-vpfe.c|   2 +-
 drivers/media/platform/atmel/atmel-isc.c   |   2 +-
 drivers/media/platform/atmel/atmel-isi.c   |   2 +-
 drivers/media/platform/davinci/vpif_capture.c  |   2 +-
 drivers/media/platform/exynos4-is/media-dev.c  |  14 ++-
 drivers/media/platform/pxa_camera.c|   2 +-
 drivers/media/platform/qcom/camss-8x16/camss.c |   2 +-
 drivers/media/platform/rcar_drif.c |   2 +-
 drivers/media/platform/stm32/stm32-dcmi.c  |   2 +-
 drivers/media/platform/ti-vpe/cal.c|   2 +-
 drivers/media/platform/xilinx/xilinx-vipp.c|  16 ++-
 drivers/media/v4l2-core/Kconfig|   8 ++
 drivers/media/v4l2-core/v4l2-async.c   | 152 +
 drivers/media/v4l2-core/v4l2-fwnode.c  |   2 +-
 drivers/of/property.c  |   6 +
 include/linux/fwnode.h |   2 +
 include/linux/property.h   |   1 +
 include/media/v4l2-async.h |   4 +
 20 files changed, 200 insertions(+), 41 deletions(-)

--
2.7.4

Re: [PATCH] mmc: renesas_sdhi: Add MODULE_LICENSE

[Wolfram Sang]

On Wed, Dec 13, 2017 at 11:33:00AM +0900, Yoshihiro Shimoda wrote:
> From: Masaharu Hayakawa 
> 
> The following error occurs when loading renesas_sdhi_core.c module,
> so add MODULE_LICENSE("GPL v2").
> 
>  renesas_sdhi_core: module license 'unspecified' taints kernel.
> 
> Signed-off-by: Masaharu Hayakawa 
> Fixes: 9d08428afb72 ("mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main 
> module file")
> Cc:  # v4.13+
> [Shimoda: Added Fixes tag and Cc to the stable ML]
> Signed-off-by: Yoshihiro Shimoda 

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH] Revert "ravb: add workaround for clock when resuming with WoL enabled"

[David Miller]

From: Geert Uytterhoeven 
Date: Mon, 11 Dec 2017 09:54:09 +0100

> This reverts commit fbf3d034f2ff6264183cfa6845770e8cc2a986c8.
> 
> As of commit 560869100b99a3da ("clk: renesas: cpg-mssr: Restore module
> clocks during resume"), the workaround is no longer needed.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied, thanks.

Applied "ASoC: rsnd: Add device tree support for r8a774[35]" to the asoc tree

[Mark Brown]

The patch

   ASoC: rsnd: Add device tree support for r8a774[35]

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From b0a858a47a7889757dbc9ac9872685955eaa5cc0 Mon Sep 17 00:00:00 2001
From: Biju Das 
Date: Tue, 12 Dec 2017 18:09:15 +
Subject: [PATCH] ASoC: rsnd: Add device tree support for r8a774[35]

Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
(r8a774[35]) sound modules are identical to the R-Car Gen2 family.
No driver change is needed as the fallback compatible string
"renesas,rcar_sound-gen2" activates the right code in the driver.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt 
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 085bec364caf..b3c28bdcc268 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -4,7 +4,7 @@ Renesas R-Car sound
 * Modules
 =
 
-Renesas R-Car sound is constructed from below modules
+Renesas R-Car and RZ/G sound is constructed from below modules
 (for Gen2 or later)
 
  SCU   : Sampling Rate Converter Unit
@@ -334,9 +334,11 @@ Required properties:
 
 - compatible   : "renesas,rcar_sound-", fallbacks
  "renesas,rcar_sound-gen1" if generation1, and
- "renesas,rcar_sound-gen2" if generation2
+ "renesas,rcar_sound-gen2" if generation2 (or 
RZ/G1)
  "renesas,rcar_sound-gen3" if generation3
  Examples with soctypes are:
+   - "renesas,rcar_sound-r8a7743" (RZ/G1M)
+   - "renesas,rcar_sound-r8a7745" (RZ/G1E)
- "renesas,rcar_sound-r8a7778" (R-Car M1A)
- "renesas,rcar_sound-r8a7779" (R-Car H1)
- "renesas,rcar_sound-r8a7790" (R-Car H2)
-- 
2.15.1

Re: [PATCH 3/6] i2c: add 'set_sda' to bus_recovery_info

[Andy Shevchenko]

On Tue, 2017-12-05 at 16:31 +0100, Linus Walleij wrote:
> On Tue, Dec 5, 2017 at 2:38 PM, Wolfram Sang 
> wrote:
> 


> Two statice inlines in 
> named
> 
> int gpiod_is output()
> int gpiod_is_input()

Ha, just proposed similar.

> 
> should conform to Rusty Russell's API hierarchy.
> 
> Interested in fixing it, or should I?
> I can almost ACK it before you write the patch.

I vote for this type of API, and agree with Wolfram !_get_direction() is
confusing.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH 3/6] i2c: add 'set_sda' to bus_recovery_info

[Andy Shevchenko]

On Mon, 2017-12-04 at 13:36 +0100, Wolfram Sang wrote:
> This will be needed when we want to create STOP conditions, too,
> later.
> Create the needed fields and populate them for the GPIO case if the
> GPIO
> is set to output.

> +#include 
>  #include 

I think it should be not done like this. (Yes, I know why you did that)

Perhaps Linus will accept a patch to move direction flags to some header
feasible via consumer.h.

Linus?

Or if we wish to hide:

static inline bool gpiod_is_direction_out() {}
static inline bool gpiod_is_direction_in() {}

>   if (gpiod_get_direction(bri->sda_gpiod) == GPIOF_DIR_OUT)

P.S. Yep, I saw some other upstreamed patch doing this kind of
comparison.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH 2/6] i2c: add identifier in declarations for i2c_bus_recovery

[Andy Shevchenko]

On Mon, 2017-12-04 at 13:36 +0100, Wolfram Sang wrote:
> No reason to have them undefined, so let's add them.
> 

>   int (*recover_bus)(struct i2c_adapter *);
>  
> - int (*get_scl)(struct i2c_adapter *);
> - void (*set_scl)(struct i2c_adapter *, int val);
> - int (*get_sda)(struct i2c_adapter *);
> + int (*get_scl)(struct i2c_adapter *adap);
> + void (*set_scl)(struct i2c_adapter *adap, int val);
> + int (*get_sda)(struct i2c_adapter *adap);
>  
>   void (*prepare_recovery)(struct i2c_adapter *);
>   void (*unprepare_recovery)(struct i2c_adapter *);

It seems inconsistent with the rest of the members even from this
visible piece.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH] gpio: Add helpers to determin direction of gpiods

[Wolfram Sang]

> > You need to fix the kerneldoc for 'gpiod_get_direction", too. It still
> > mentions GPIOF_DIR_*.
> 
> More places? I can't find them!

drivers/gpio/gpiolib.c

Line 198 in both 4.15-rc3 and linux-next.

Or as I said, the kerneldoc of gpiod_get_direction ;)

> Together with Geert's comments I start to lean towards actually
> just creating two new #defines in .
> 
> It has the upside that we can also check the return value
> for errors.

Sounds good, in deed.



signature.asc
Description: PGP signature

Re: [PATCH] gpio: Add helpers to determin direction of gpiods

[Linus Walleij]

On Tue, Dec 12, 2017 at 11:42 PM, Wolfram Sang  wrote:

>>  Documentation/gpio/consumer.txt | 14 +++---
>
> You need to fix the kerneldoc for 'gpiod_get_direction", too. It still
> mentions GPIOF_DIR_*.

More places? I can't find them!

I thought the patch removed that here:

-This function will return either GPIOF_DIR_IN or GPIOF_DIR_OUT.
+This function will return either 1 (input) or 0 (output). There are also
+these convenience helpers:

I can only find it in Documentation/gpio/gpio-legacy.txt which is
fine.

>> +static inline bool gpiod_is_input(struct gpio_desc *desc)
>> +{
>> + int ret = gpiod_get_direction(desc);
>> + if (ret < 0) {
>> + pr_err("GPIO: failed to get direction\n");
>
> Is that really helpful for the user if we don't say which GPIO failed?

I would have to add yet more APIs to do that.

Hm.

Together with Geert's comments I start to lean towards actually
just creating two new #defines in .

It has the upside that we can also check the return value
for errors.

Yours,
Linus Walleij

Re: [PATCH v2] ASoC: rsnd: Add device tree support for r8a774[35]

[Geert Uytterhoeven]

On Wed, Dec 13, 2017 at 2:35 PM, Biju Das  wrote:
> Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
> (r8a774[35]) sound modules are identical to the R-Car Gen2 family.
> No driver change is needed as the fallback compatible string
> "renesas,rcar_sound-gen2" activates the right code in the driver.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

[PATCH v2] ASoC: rsnd: Add device tree support for r8a774[35]

[Biju Das]

Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
(r8a774[35]) sound modules are identical to the R-Car Gen2 family.
No driver change is needed as the fallback compatible string
"renesas,rcar_sound-gen2" activates the right code in the driver.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
v1-->v2
 Updated the subject line.

 Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt 
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 085bec3..b3c28bd 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -4,7 +4,7 @@ Renesas R-Car sound
 * Modules
 =
 
-Renesas R-Car sound is constructed from below modules
+Renesas R-Car and RZ/G sound is constructed from below modules
 (for Gen2 or later)
 
  SCU   : Sampling Rate Converter Unit
@@ -334,9 +334,11 @@ Required properties:
 
 - compatible   : "renesas,rcar_sound-", fallbacks
  "renesas,rcar_sound-gen1" if generation1, and
- "renesas,rcar_sound-gen2" if generation2
+ "renesas,rcar_sound-gen2" if generation2 (or 
RZ/G1)
  "renesas,rcar_sound-gen3" if generation3
  Examples with soctypes are:
+   - "renesas,rcar_sound-r8a7743" (RZ/G1M)
+   - "renesas,rcar_sound-r8a7745" (RZ/G1E)
- "renesas,rcar_sound-r8a7778" (R-Car M1A)
- "renesas,rcar_sound-r8a7779" (R-Car H1)
- "renesas,rcar_sound-r8a7790" (R-Car H2)
-- 
1.9.1

Re: [PATCH 1/2] dt-bindings: thermal: rcar: Add device tree support for r8a7743

[Geert Uytterhoeven]

On Wed, Dec 13, 2017 at 11:57 AM, Biju Das  wrote:
> Add thermal sensor support for r8a7743 SoC. The Renesas RZ/G1M
> (r8a7743) thermal sensor module is identical to the R-Car Gen2 family.
>
> No driver change is needed due to the fallback compatible value
> "renesas,rcar-gen2-thermal".
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH] dt-bindings: ASoC: rsnd: Add device tree support for r8a774[35]

[Biju Das]

Hi all,

Thanks for the feedback, I will send a v2.

Regards,
Biju

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: 13 December 2017 12:56
> To: Geert Uytterhoeven 
> Cc: Biju Das ; Liam Girdwood
> ; Rob Herring ; Mark Rutland
> ; Simon Horman ; Magnus
> Damm ; Chris Paterson
> ; Fabrizio Castro
> ; ALSA Development Mailing List  de...@alsa-project.org>; Linux-Renesas 
> Subject: Re: [PATCH] dt-bindings: ASoC: rsnd: Add device tree support for
> r8a774[35]
>
> On Wed, Dec 13, 2017 at 01:34:40PM +0100, Geert Uytterhoeven wrote:
>
> > The confusing part here is that for most[*] subsystems, patches
> > touching only DT bindings should have a "dt-bindings" prefix, while
> > patches touching both DT bindings and driver code should have the drivers'
> subsystem prefix.
>
> > [*] I think you're about the only maintainer who insists on patches
> > touching only DT bindings having the drivers' subsystem prefix, which
> > people tend to forget, if they're even aware of that rule...
>
> > Can we improve this?
>
> This is something Rob's been pushing which seems like a step back to me so 
> I've
> been pushing back on it - it's causing problems for me spotting things I need 
> to
> look at and later on in review (including my scripting, which does pay 
> attention
> to subject lines).  I suspect I'm at the upper end of people getting lots of
> irrelevant stuff in copy which doesn't help here.


[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH v1 07/10] v4l: i2c: Copy ov772x soc_camera sensor driver

[Philippe Ombredanne]

Jacopo,

On Wed, Nov 15, 2017 at 11:56 AM, Jacopo Mondi
 wrote:
> Copy the soc_camera based driver in v4l2 sensor driver directory.
> This commit just copies the original file without modifying it.
>
> Signed-off-by: Jacopo Mondi 



> --- /dev/null
> +++ b/drivers/media/i2c/ov772x.c
> @@ -0,0 +1,1124 @@
> +/*
> + * ov772x Camera Driver
> + *
> + * Copyright (C) 2008 Renesas Solutions Corp.
> + * Kuninori Morimoto 
> + *
> + * Based on ov7670 and soc_camera_platform driver,
> + *
> + * Copyright 2006-7 Jonathan Corbet 
> + * Copyright (C) 2008 Magnus Damm
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */

You may want to use the new SPDX ids as documented in Thomas doc
patches instead of the loner legalese?
-- 
Cordially
Philippe Ombredanne

Re: [PATCH] dt-bindings: ASoC: rsnd: Add device tree support for r8a774[35]

[Mark Brown]

On Wed, Dec 13, 2017 at 01:34:40PM +0100, Geert Uytterhoeven wrote:

> The confusing part here is that for most[*] subsystems, patches touching
> only DT bindings should have a "dt-bindings" prefix, while patches touching
> both DT bindings and driver code should have the drivers' subsystem prefix.

> [*] I think you're about the only maintainer who insists on patches touching
> only DT bindings having the drivers' subsystem prefix, which people tend to
> forget, if they're even aware of that rule...

> Can we improve this?

This is something Rob's been pushing which seems like a step back to me
so I've been pushing back on it - it's causing problems for me spotting
things I need to look at and later on in review (including my scripting,
which does pay attention to subject lines).  I suspect I'm at the upper
end of people getting lots of irrelevant stuff in copy which doesn't
help here.


signature.asc
Description: PGP signature

Re: [PATCH] dt-bindings: ASoC: rsnd: Add device tree support for r8a774[35]

[Geert Uytterhoeven]

Hi Mark,

On Wed, Dec 13, 2017 at 1:20 PM, Mark Brown  wrote:
> On Tue, Dec 12, 2017 at 06:09:15PM +, Biju Das wrote:
>> Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
>> (r8a774[35]) sound modules are identical to the R-Car Gen2 family.
>> No driver change is needed as the fallback compatible string
>> "renesas,rcar_sound-gen2" activates the right code in the driver.
>
> Please submit patches using subject lines reflecting the style for the
> subsystem.  This makes it easier for people to identify relevant
> patches.  Look at what existing commits in the area you're changing are
> doing and make sure your subject lines visually resemble what they're
> doing.

The confusing part here is that for most[*] subsystems, patches touching
only DT bindings should have a "dt-bindings" prefix, while patches touching
both DT bindings and driver code should have the drivers' subsystem prefix.

[*] I think you're about the only maintainer who insists on patches touching
only DT bindings having the drivers' subsystem prefix, which people tend to
forget, if they're even aware of that rule...

Can we improve this?

Thanks!

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] dt-bindings: ASoC: rsnd: Add device tree support for r8a774[35]

[Mark Brown]

On Tue, Dec 12, 2017 at 06:09:15PM +, Biju Das wrote:
> Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
> (r8a774[35]) sound modules are identical to the R-Car Gen2 family.
> No driver change is needed as the fallback compatible string
> "renesas,rcar_sound-gen2" activates the right code in the driver.

Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.


signature.asc
Description: PGP signature

Re: [PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies

[Hans Verkuil]

On 15/11/17 11:56, Jacopo Mondi wrote:
> Remove soc_camera framework dependencies from tw9910 sensor driver.
> - Handle clock directly
> - Register async subdevice
> - Add platform specific enable/disable functions
> - Adjust build system
> 
> This commit does not remove the original soc_camera based driver.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/i2c/Kconfig  |  9 ++
>  drivers/media/i2c/Makefile |  1 +
>  drivers/media/i2c/tw9910.c | 80 
> ++
>  include/media/i2c/tw9910.h |  6 
>  4 files changed, 75 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index ff251ce..bbd77ee 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -415,6 +415,15 @@ config VIDEO_TW9906
> To compile this driver as a module, choose M here: the
> module will be called tw9906.
> 
> +config VIDEO_TW9910
> + tristate "Techwell TW9910 video decoder"
> + depends on VIDEO_V4L2 && I2C
> + ---help---
> +   Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called tw9910.
> +
>  config VIDEO_VPX3220
>   tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index b2459a1..835784a 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
>  obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
>  obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
>  obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
> +obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
>  obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
>  obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
>  obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
> diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
> index bdb5e0a..f422da2 100644
> --- a/drivers/media/i2c/tw9910.c
> +++ b/drivers/media/i2c/tw9910.c
> @@ -16,6 +16,7 @@
>   * published by the Free Software Foundation.
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -25,9 +26,7 @@
>  #include 
>  #include 
> 
> -#include 
>  #include 
> -#include 
>  #include 
> 
>  #define GET_ID(val)  ((val & 0xF8) >> 3)
> @@ -228,7 +227,7 @@ struct tw9910_scale_ctrl {
> 
>  struct tw9910_priv {
>   struct v4l2_subdev  subdev;
> - struct v4l2_clk *clk;
> + struct clk  *clk;
>   struct tw9910_video_info*info;
>   const struct tw9910_scale_ctrl  *scale;
>   v4l2_std_id norm;
> @@ -582,13 +581,40 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
>  }
>  #endif
> 
> +static int tw9910_power_on(struct tw9910_priv *priv)
> +{
> + int ret;
> +
> + if (priv->info->platform_enable) {
> + ret = priv->info->platform_enable();
> + if (ret)
> + return ret;
> + }
> +
> + if (priv->clk)
> + return clk_enable(priv->clk);
> +
> + return 0;
> +}
> +
> +static int tw9910_power_off(struct tw9910_priv *priv)
> +{
> + if (priv->info->platform_enable)
> + priv->info->platform_disable();
> +
> + if (priv->clk)
> + clk_disable(priv->clk);
> +
> + return 0;
> +}
> +
>  static int tw9910_s_power(struct v4l2_subdev *sd, int on)
>  {
>   struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
>   struct tw9910_priv *priv = to_tw9910(client);
> 
> - return soc_camera_set_power(>dev, ssdd, priv->clk, on);
> + return on ? tw9910_power_on(priv) :
> + tw9910_power_off(priv);
>  }
> 
>  static int tw9910_set_frame(struct v4l2_subdev *sd, u32 *width, u32 *height)
> @@ -614,7 +640,7 @@ static int tw9910_set_frame(struct v4l2_subdev *sd, u32 
> *width, u32 *height)
>* set bus width
>*/
>   val = 0x00;
> - if (SOCAM_DATAWIDTH_16 == priv->info->buswidth)
> + if (priv->info->buswidth == TW9910_DATAWIDTH_16)
>   val = LEN;
> 
>   ret = tw9910_mask_set(client, OPFORM, LEN, val);
> @@ -799,8 +825,8 @@ static int tw9910_video_probe(struct i2c_client *client)
>   /*
>* tw9910 only use 8 or 16 bit bus width
>*/
> - if (SOCAM_DATAWIDTH_16 != priv->info->buswidth &&
> - SOCAM_DATAWIDTH_8  != priv->info->buswidth) {
> + if (priv->info->buswidth != TW9910_DATAWIDTH_16 &&
> + priv->info->buswidth != TW9910_DATAWIDTH_8) {
>   dev_err(>dev, "bus width error\n");
>   return -ENODEV;
>   }
> @@ -859,15 +885,11 @@ static int tw9910_enum_mbus_code(struct v4l2_subdev *sd,
>  static int tw9910_g_mbus_config(struct v4l2_subdev *sd,
>   struct v4l2_mbus_config *cfg)
>  {
> - struct 

Re: [PATCH v1 07/10] v4l: i2c: Copy ov772x soc_camera sensor driver

[Hans Verkuil]

On 15/11/17 11:56, Jacopo Mondi wrote:
> Copy the soc_camera based driver in v4l2 sensor driver directory.
> This commit just copies the original file without modifying it.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/i2c/ov772x.c | 1124 
> 
>  1 file changed, 1124 insertions(+)
>  create mode 100644 drivers/media/i2c/ov772x.c
> 
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> new file mode 100644
> index 000..8063835
> --- /dev/null
> +++ b/drivers/media/i2c/ov772x.c
> @@ -0,0 +1,1124 @@
> +/*
> + * ov772x Camera Driver
> + *
> + * Copyright (C) 2008 Renesas Solutions Corp.
> + * Kuninori Morimoto 
> + *
> + * Based on ov7670 and soc_camera_platform driver,
> + *
> + * Copyright 2006-7 Jonathan Corbet 
> + * Copyright (C) 2008 Magnus Damm
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * register offset
> + */
> +#define GAIN0x00 /* AGC - Gain control gain setting */
> +#define BLUE0x01 /* AWB - Blue channel gain setting */
> +#define RED 0x02 /* AWB - Red   channel gain setting */
> +#define GREEN   0x03 /* AWB - Green channel gain setting */
> +#define COM10x04 /* Common control 1 */
> +#define BAVG0x05 /* U/B Average Level */
> +#define GAVG0x06 /* Y/Gb Average Level */
> +#define RAVG0x07 /* V/R Average Level */
> +#define AECH0x08 /* Exposure Value - AEC MSBs */
> +#define COM20x09 /* Common control 2 */
> +#define PID 0x0A /* Product ID Number MSB */
> +#define VER 0x0B /* Product ID Number LSB */
> +#define COM30x0C /* Common control 3 */
> +#define COM40x0D /* Common control 4 */
> +#define COM50x0E /* Common control 5 */
> +#define COM60x0F /* Common control 6 */
> +#define AEC 0x10 /* Exposure Value */
> +#define CLKRC   0x11 /* Internal clock */
> +#define COM70x12 /* Common control 7 */
> +#define COM80x13 /* Common control 8 */
> +#define COM90x14 /* Common control 9 */
> +#define COM10   0x15 /* Common control 10 */
> +#define REG16   0x16 /* Register 16 */
> +#define HSTART  0x17 /* Horizontal sensor size */
> +#define HSIZE   0x18 /* Horizontal frame (HREF column) end high 8-bit */
> +#define VSTART  0x19 /* Vertical frame (row) start high 8-bit */
> +#define VSIZE   0x1A /* Vertical sensor size */
> +#define PSHFT   0x1B /* Data format - pixel delay select */
> +#define MIDH0x1C /* Manufacturer ID byte - high */
> +#define MIDL0x1D /* Manufacturer ID byte - low  */
> +#define LAEC0x1F /* Fine AEC value */
> +#define COM11   0x20 /* Common control 11 */
> +#define BDBASE  0x22 /* Banding filter Minimum AEC value */
> +#define DBSTEP  0x23 /* Banding filter Maximum Setp */
> +#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) 
> */
> +#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) 
> */
> +#define VPT 0x26 /* AGC/AEC Fast mode operating region */
> +#define REG28   0x28 /* Register 28 */
> +#define HOUTSIZE0x29 /* Horizontal data output size MSBs */
> +#define EXHCH   0x2A /* Dummy pixel insert MSB */
> +#define EXHCL   0x2B /* Dummy pixel insert LSB */
> +#define VOUTSIZE0x2C /* Vertical data output size MSBs */
> +#define ADVFL   0x2D /* LSB of insert dummy lines in Vertical direction 
> */
> +#define ADVFH   0x2E /* MSG of insert dummy lines in Vertical direction 
> */
> +#define YAVE0x2F /* Y/G Channel Average value */
> +#define LUMHTH  0x30 /* Histogram AEC/AGC Luminance high level threshold 
> */
> +#define LUMLTH  0x31 /* Histogram AEC/AGC Luminance low  level threshold 
> */
> +#define HREF0x32 /* Image start and size control */
> +#define DM_LNL  0x33 /* Dummy line low  8 bits */
> +#define DM_LNH  0x34 /* Dummy line high 8 bits */
> +#define ADOFF_B 0x35 /* AD offset compensation value for B  channel */
> +#define ADOFF_R 0x36 /* AD offset compensation value for R  channel */
> +#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */
> +#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */
> +#define OFF_B   0x39 /* Analog process B  channel offset value */
> +#define OFF_R   0x3A /* Analog process R  channel offset value */
> +#define OFF_GB  0x3B /* Analog process Gb channel offset value */
> 

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[Hans Verkuil]

On 15/11/17 11:55, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/Kconfig   |9 +
>  drivers/media/platform/Makefile  |2 +
>  drivers/media/platform/renesas-ceu.c | 1768 
> ++
>  3 files changed, 1779 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3c4f7fa..401caea 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
> To compile this driver as a module, choose M here: the module
> will be called stm32-dcmi.
> 
> +config VIDEO_RENESAS_CEU
> + tristate "Renesas Capture Engine Unit (CEU) driver"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_FWNODE
> + ---help---
> +   This is a v4l2 driver for the Renesas CEU Interface
> +
>  source "drivers/media/platform/soc_camera/Kconfig"
>  source "drivers/media/platform/exynos4-is/Kconfig"
>  source "drivers/media/platform/am437x/Kconfig"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 327f80a..0d1f02b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)+= coda/
> 
>  obj-$(CONFIG_VIDEO_SH_VEU)   += sh_veu.o
> 
> +obj-$(CONFIG_VIDEO_RENESAS_CEU)  += renesas-ceu.o
> +
>  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)  += m2m-deinterlace.o
> 
>  obj-$(CONFIG_VIDEO_MUX)  += video-mux.o
> diff --git a/drivers/media/platform/renesas-ceu.c 
> b/drivers/media/platform/renesas-ceu.c
> new file mode 100644
> index 000..aaba3cd
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -0,0 +1,1768 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
> + *
> + * Copyright (C) 2017 Jacopo Mondi 
> + *
> + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
> + * Copyright (C) 2008 Magnus Damm
> + *
> + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
> + * Copyright (C) 2006, Sascha Hauer, Pengutronix
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define DRIVER_NAME  "renesas-ceu"
> +
> +/* 
> 
> + * CEU registers offsets and masks
> + */
> +#define CEU_CAPSR0x00 /* Capture start register  */
> +#define CEU_CAPCR0x04 /* Capture control register*/
> +#define CEU_CAMCR0x08 /* Capture interface control register  */
> +#define CEU_CAMOR0x10 /* Capture interface offset register   */
> +#define CEU_CAPWR0x14 /* Capture interface width register*/
> +#define CEU_CAIFR0x18 /* Capture interface input format register */
> +#define CEU_CRCNTR   0x28 /* CEU register control register   */
> +#define CEU_CRCMPR   0x2c /* CEU register forcible control register  */
> +#define CEU_CFLCR0x30 /* Capture filter control register */
> +#define CEU_CFSZR0x34 /* Capture filter size clip register   */
> +#define CEU_CDWDR0x38 /* Capture destination width register  */
> +#define CEU_CDAYR0x3c /* Capture data address Y register */
> +#define CEU_CDACR0x40 /* Capture data address C register */
> +#define CEU_CFWCR0x5c /* Firewall operation control register */
> +#define CEU_CDOCR0x64 /* Capture data output control register*/
> +#define CEU_CEIER0x70 /* Capture event interrupt enable register */
> +#define CEU_CETCR0x74 /* Capture event flag clear register   */
> +#define 

[PATCH 2/2] ARM: dts: r8a7743: Add thermal device to DT

[Biju Das]

This patch instantiates the thermal sensor module with thermal-zone
support.

This patch is based on the commit cac68a56e34b
("ARM: dts: r8a7791: enable to use thermal-zone") by Kuninori Morimoto.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a7743.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 0e2834a..e056bc5 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -250,6 +250,38 @@
resets = < 407>;
};
 
+   thermal: thermal@e61f {
+   compatible = "renesas,thermal-r8a7743",
+"renesas,rcar-gen2-thermal",
+"renesas,rcar-thermal";
+   reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
+   interrupts = ;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 522>;
+   #thermal-sensor-cells = <0>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+
+   thermal-sensors = <>;
+
+   trips {
+   cpu-crit {
+   temperature = <95000>;
+   hysteresis = <0>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   };
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = 

[PATCH 1/2] dt-bindings: thermal: rcar: Add device tree support for r8a7743

[Biju Das]

Add thermal sensor support for r8a7743 SoC. The Renesas RZ/G1M
(r8a7743) thermal sensor module is identical to the R-Car Gen2 family.

No driver change is needed due to the fallback compatible value
"renesas,rcar-gen2-thermal".

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index a8e52c8..349e635 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -6,6 +6,7 @@ Required properties:
   "renesas,rcar-thermal" (without thermal-zone) as 
fallback.
  Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
+   - "renesas,thermal-r8a7743" (RZ/G1M)
- "renesas,thermal-r8a7779" (R-Car H1)
- "renesas,thermal-r8a7790" (R-Car H2)
- "renesas,thermal-r8a7791" (R-Car M2-W)
-- 
1.9.1

[PATCH 0/2] Add thermal support for iWave RZ/G1M board

[Biju Das]

This series aims to add thermal support for iWave RZ/G1M board.

This patch series based on renesas tag renesas-devel-20171211-v4.15-rc3.

Biju Das (2):
  dt-bindings: thermal: rcar: Add device tree support for r8a7743
  ARM: dts: r8a7743: Add thermal device to DT

 .../devicetree/bindings/thermal/rcar-thermal.txt   |  1 +
 arch/arm/boot/dts/r8a7743.dtsi | 32 ++
 2 files changed, 33 insertions(+)

-- 
1.9.1

Re: arm64: unhandled level 0 translation fault

[Will Deacon]

Hi Geert,

Thanks for trying to bisect this.

On Tue, Dec 12, 2017 at 09:54:05PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon  wrote:
> > Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
> > reproduce this on any of our systems, unfortunately.
> 
> I've tried, but ended up on an unrelated XFS merge commit. Probably I
> marked a few commits good due to not seeing this heisenbug.
> 
> For reference, here's the bisect log.
> 
> Bad commits showed one or both of "unhandled level 0 translation fault" and
> "invalid pointer". Good commits didn't show any during 6 tries.
> 
> git bisect start
> # bad: [ae64f9bd1d3621b5e60d7363bc20afb46aede215] Linux 4.15-rc2
> git bisect bad ae64f9bd1d3621b5e60d7363bc20afb46aede215
> # good: [4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323] Linux 4.15-rc1
> git bisect good 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
> # good: [9e0600f5cf6cecfcab5046d1453a9538c054d8a7] Merge tag
> 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> git bisect good 9e0600f5cf6cecfcab5046d1453a9538c054d8a7
> # good: [503505bfea19b7d69e2572297e6defa0f9c2404e] Merge branch
> 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into
> drm-fixes
> git bisect good 503505bfea19b7d69e2572297e6defa0f9c2404e
> # good: [ae753ee2771a1bacade56411bb98037b2545c929] Merge tag
> 'afs-fixes-20171201' of
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
> git bisect good ae753ee2771a1bacade56411bb98037b2545c929
> # good: [e1ba1c99dad92c5917b22b1047cf36e4426b124a] Merge tag
> 'riscv-for-linus-4.15-rc2_cleanups' of
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux
> git bisect good e1ba1c99dad92c5917b22b1047cf36e4426b124a

^^ This one is the first "good" commit containing the arm64-fixes pull.
Maybe try stressing it a bit more and see if it also fails?

That said, I'm still suspicious that nobody else is seeing this -- I also
checked the various build/boot farms and everything looks ok.

Will

Re: [PATCH] dt-bindings: ASoC: rsnd: Add device tree support for r8a774[35]

[Geert Uytterhoeven]

On Tue, Dec 12, 2017 at 7:09 PM, Biju Das  wrote:
> Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
> (r8a774[35]) sound modules are identical to the R-Car Gen2 family.
> No driver change is needed as the fallback compatible string
> "renesas,rcar_sound-gen2" activates the right code in the driver.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support

[Fabrizio Castro]

Hello Geert,

thank you for your feedback.

> Hi Fabrizio,
>
> On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
>  wrote:
> >> On Tue, Dec 12, 2017 at 06:49:38PM +, Fabrizio Castro wrote:
> >> > Add CMT[01] support to SoC DT.
> >> > Signed-off-by: Fabrizio Castro 
> >> > Reviewed-by: Biju Das 
> >> > ---
> >> >  arch/arm/boot/dts/r8a7743.dtsi | 30 ++
> >> >  1 file changed, 30 insertions(+)
> >>
> >> I was expecting the cmt nodes to be "disabled" in the SoC file
> >> and then enabled selectively in board files. Am I missing something?
> >
> > Since this component is just a compare and match timer, I  thought there 
> > was no harm in enabling it by default in the SoC specific DT.
> > The system will park it and leave its clock disabled until actually needed 
> > for something.
> > The user can still disable it in the board specific DT if he/she doesn't 
> > mean to even have the option to use it. Do you prefer I left it
> disabled by default?
>
> It's debatable (thus up to Simon the maintainer ;-).
> For I/O devices, we disable them in the SoC .dtsi file.
> For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
> them enabled.
>
> Timers are core functionality, but who's actually using these timers?

I don't have a use case in mind unfortunately, but it's still core 
functionality and pretty harmless as far as I can tell. Let's see what Simon 
thinks about this.

Thanks,
Fab

>
> 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


[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support

[Geert Uytterhoeven]

Hi Fabrizio,

On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
 wrote:
>> On Tue, Dec 12, 2017 at 06:49:38PM +, Fabrizio Castro wrote:
>> > Add CMT[01] support to SoC DT.
>> > Signed-off-by: Fabrizio Castro 
>> > Reviewed-by: Biju Das 
>> > ---
>> >  arch/arm/boot/dts/r8a7743.dtsi | 30 ++
>> >  1 file changed, 30 insertions(+)
>>
>> I was expecting the cmt nodes to be "disabled" in the SoC file
>> and then enabled selectively in board files. Am I missing something?
>
> Since this component is just a compare and match timer, I  thought there was 
> no harm in enabling it by default in the SoC specific DT. The system will 
> park it and leave its clock disabled until actually needed for something.
> The user can still disable it in the board specific DT if he/she doesn't mean 
> to even have the option to use it. Do you prefer I left it disabled by 
> default?

It's debatable (thus up to Simon the maintainer ;-).
For I/O devices, we disable them in the SoC .dtsi file.
For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
them enabled.

Timers are core functionality, but who's actually using these timers?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Geert Uytterhoeven]

Hi Fabrizio,
On Tue, Dec 12, 2017 at 7:49 PM, Fabrizio Castro
 wrote:
> Document SoC specific compatible strings for r8a7743 and r8a7745.
> No driver change is needed as the fallback strings will activate
> the right code.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

With the issues pointed out by Simon fixed:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Fabrizio Castro]

Hello Simon,

thank you for the feedback.
I'll apply your comments to V2, but I'll wait for your reply on the CMT "enable 
by default" issue.

Thanks,
Fab

> Subject: Re: [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document 
> r8a774[35] CMT support
>
> On Tue, Dec 12, 2017 at 06:49:37PM +, Fabrizio Castro wrote:
> > Document SoC specific compatible strings for r8a7743 and r8a7745.
> > No driver change is needed as the fallback strings will activate
> > the right code.
> >
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> > ---
> >  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > index d740989..1e4fe98 100644
> > --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > @@ -22,6 +22,10 @@ Required Properties:
> >
> >  - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in 
> > r8a73a4.
> >  - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in 
> > r8a73a4.
> > +- "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in 
> > r8a7743.
> > +- "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in 
> > r8a7743.
> > +- "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in 
> > r8a7745.
> > +- "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in 
> > r8a7745.
> >  - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in 
> > r8a7790.
> >  - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in 
> > r8a7790.
> >  - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in 
> > r8a7791.
> > @@ -31,9 +35,11 @@ Required Properties:
> >  - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in 
> > r8a7794.
> >  - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in 
> > r8a7794.
> >
> > -- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car 
> > Gen2.
> > -- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car 
> > Gen2.
> > -These are fallbacks for r8a73a4 and all the R-Car Gen2
> > +- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car 
> > Gen2 or
>
> nit: or -> and ?
>
> > +RZ/G1.
> > +- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car 
> > Gen2 or
> > +RZ/G1.
> > +These are fallbacks for r8a73a4, all the R-Car Gen2 and RZ/G1
> >  entrieslisted above.
>
> nit: all the R-Car -> R-Car
>
> >- reg: base address and length of the registers block for the timer 
> > module.


[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support

[Fabrizio Castro]

Hello Simon,

thank you for your feedback.

> On Tue, Dec 12, 2017 at 06:49:38PM +, Fabrizio Castro wrote:
> > Add CMT[01] support to SoC DT.
> >
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> > ---
> >  arch/arm/boot/dts/r8a7743.dtsi | 30 ++
> >  1 file changed, 30 insertions(+)
>
> I was expecting the cmt nodes to be "disabled" in the SoC file
> and then enabled selectively in board files. Am I missing something?

Since this component is just a compare and match timer, I  thought there was no 
harm in enabling it by default in the SoC specific DT. The system will park it 
and leave its clock disabled until actually needed for something.
The user can still disable it in the board specific DT if he/she doesn't mean 
to even have the option to use it. Do you prefer I left it disabled by default?

Thanks,
Fab

>
> Otherwise this patch looks good to me.
>
> > diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> > index 59860c8..0e2834a 100644
> > --- a/arch/arm/boot/dts/r8a7743.dtsi
> > +++ b/arch/arm/boot/dts/r8a7743.dtsi
> > @@ -262,6 +262,36 @@
> >IRQ_TYPE_LEVEL_LOW)>;
> >  };
> >
> > +cmt0: timer@ffca {
> > +compatible = "renesas,r8a7743-cmt0",
> > + "renesas,rcar-gen2-cmt0";
> > +reg = <0 0xffca 0 0x1004>;
> > +interrupts = ,
> > + ;
> > +clocks = < CPG_MOD 124>;
> > +clock-names = "fck";
> > +power-domains = < R8A7743_PD_ALWAYS_ON>;
> > +resets = < 124>;
> > +};
> > +
> > +cmt1: timer@e613 {
> > +compatible = "renesas,r8a7743-cmt1",
> > + "renesas,rcar-gen2-cmt1";
> > +reg = <0 0xe613 0 0x1004>;
> > +interrupts = ,
> > + ,
> > + ,
> > + ,
> > + ,
> > + ,
> > + ,
> > + ;
> > +clocks = < CPG_MOD 329>;
> > +clock-names = "fck";
> > +power-domains = < R8A7743_PD_ALWAYS_ON>;
> > +resets = < 329>;
> > +};
> > +
> >  cpg: clock-controller@e615 {
> >  compatible = "renesas,r8a7743-cpg-mssr";
> >  reg = <0 0xe615 0 0x1000>;
> > --
> > 2.7.4
> >


[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH 0/5] Add Sound support for iWave RZ/G1M board

[Biju Das]

Hi Simon,

Thanks.

There is a typo in the documentation dependency link.
The correct one is https://patchwork.kernel.org/patch/10108015/

Regards,
Biju

> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 13 December 2017 09:03
> To: Biju Das 
> Cc: Rob Herring ; Mark Rutland
> ; Russell King ; Magnus
> Damm ; Chris Paterson
> ; devicet...@vger.kernel.org; linux-renesas-
> s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 0/5] Add Sound support for iWave RZ/G1M board
>
> On Tue, Dec 12, 2017 at 06:25:06PM +, Biju Das wrote:
> > This series aims to add sound support for iWave RZ/G1M board.
> >
> > This patch series has documentation dependency on
> > https://patchwork.kernel.org/patch/10108014/
> >
> > Biju Das (5):
> >   ARM: shmobile: defconfig: Enable SGTL5000 audio codec
> >   ARM: dts: r8a7743: Add audio clocks
> >   ARM: dts: r8a7743: Add audio DMAC support
> >   ARM: dts: r8a7743: Add sound support
> >   ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
> >
> >  arch/arm/boot/dts/iwg20d-q7-common.dtsi |  24 +++
> >  arch/arm/boot/dts/r8a7743.dtsi  | 270
> 
> >  arch/arm/configs/shmobile_defconfig |   1 +
> >  3 files changed, 295 insertions(+)
>
> These patches seem clean to me although I do not have sufficient
> documentation to properly review the last patch.
>
> I will leave these sit for a few days to allow others to review them.


[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH 2/5] phy: renesas: rcar-gen3-usb2: unify OBINTEN handling

[Sergei Shtylyov]

Hello!

On 12/13/2017 9:27 AM, Yoshihiro Shimoda wrote:


This patch unifies the OBINTEN handling to clean-up the code.

Signed-off-by: Yoshihiro Shimoda 
---
  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 23 +++
  1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index c22d65a..beeaa30 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -147,6 +147,18 @@ static void rcar_gen3_enable_vbus_ctrl(struct 
rcar_gen3_chan *ch, int vbus)
writel(val, usb2_base + USB2_ADPCTRL);
  }
  
+static void rcar_gen3_enable_otg_irq(struct rcar_gen3_chan *ch, int enable)


   If it both enables and disables, rcar_gen3_control_otg_irq() would seem a 
better name...



+{
+   void __iomem *usb2_base = ch->base;
+   u32 val = readl(usb2_base + USB2_OBINTEN);
+
+   if (enable)
+   val |= USB2_OBINT_BITS;
+   else
+   val &= ~USB2_OBINT_BITS;
+   writel(val, usb2_base + USB2_OBINTEN);
+}
+
  static void rcar_gen3_init_for_host(struct rcar_gen3_chan *ch)
  {
rcar_gen3_set_linectrl(ch, 1, 1);

[...]

MBR, Sergei

Re: [PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Laurent Pinchart]

Hello Morimoto-san,

Thank you for the patch.

On Wednesday, 6 December 2017 08:05:38 EET Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> In general, PLL has VCO (= Voltage controlled oscillator),
> one of the very important electronic feature called as "jitter"
> is related to this VCO.
> In academic generalism, VCO should be maximum to be more small jitter.
> In high frequency clock, jitter will be large impact.
> Thus, selecting Hi VCO is general theory.
> 
>fin fvcofout  fclkout
> in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out
>  +-> |  | |
>  ||
>  +-[1/N]<-+
> 
>   fclkout = fvco / P / FDPLL -- (1)
> 
> In PD, it will loop until fin/M = fvco/P/N
> 
>   fvco = fin * P *  N / M -- (2)
> 
> (1) + (2) indicates, fclkout = fin * N / M / FDPLL
> In this device, N = (n + 1), M = (m + 1), P = 2, thus
> 
>   fclkout = fin * (n + 1) / (m + 1) / FDPLL
> 
> This is the datasheet formula.
> One note here is that it should be 2000 < fvco < 4096MHz
> To be smaller jitter, fvco should be maximum,
> in other words, N as large as possible, M as small as possible driver
> should select. Here, basically M=1.
> This patch do it.
> 
> Reported-by: HIROSHI INOSE 
> Signed-off-by: Kuninori Morimoto 
> ---
> v1 -> v2
> 
>  - tidyup typo on git-log "fout" -> "fclkout"
>  - tidyup for loop terminate condition 40 -> 38 for n
> 
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 36 --
>  1 file changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index b492063..57479c9 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -125,8 +125,40 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc
> *rcrtc, unsigned int m;
>   unsigned int n;
> 
> - for (n = 39; n < 120; n++) {
> - for (m = 0; m < 4; m++) {
> + /*
> +  *   fin fvcofout   fclkout
> +  * in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> 
> out
> +  *  +-> |  | |
> +  *  ||
> +  *  +-[1/N]<-+
> +  *
> +  *  fclkout = fvco / P / FDPLL -- (1)
> +  *
> +  * fin/M = fvco/P/N
> +  *
> +  *  fvco = fin * P *  N / M -- (2)
> +  *
> +  * (1) + (2) indicates
> +  *
> +  *  fclkout = fin * N / M / FDPLL
> +  *
> +  * NOTES
> +  *  N = (n + 1), M = (m + 1), P = 2
> +  *  2000 < fvco < 4096Mhz

Are you sure that the fvco constraint is really 2kHz, and not 2GHz ? 2kHz - 
4GHz would be a surprisingly large range.

> +  *  Basically M=1

Why is this ?

> +  * To be small jitter,
> +  * N : as large as possible
> +  * M : as small as possible
> +  */
> + for (m = 0; m < 4; m++) {
> + for (n = 119; n > 38; n--) {
> + unsigned long long fvco = input * 2 * (n + 1) / (m + 1);

This code runs for Gen3 only, so unsigned long would be enough. The rest of 
the function already relies on native support for 64-bit calculation. If you 
wanted to run this on a 32-bit CPU, you would likely need to do_div() for the 
division, and convert input to u64 to avoid integer overflows, otherwise the 
calculation will be performed on 32-bit before a final conversion to 64-bit.

> + if ((fvco < 2000) ||
> + (fvco > 409600ll))

No need for the inner parentheses, and you can write both conditions on a 
single line. Furthemore 4096 MHz will fit in a 32-bit number, so there's no 
need for the ll.

> + continue;
> +

I think you can then drop the output >= 40 check inside the inner 
fdpll loop, as the output frequency can't be higher than 4GHz if the VCO 
frequency isn't.

>   for (fdpll = 1; fdpll < 32; fdpll++) {
>   unsigned long output;

The output frequency on the line below can be calculated with

output = fvco / 2 / (fdpll + 1)

to avoid the multiplication by (n + 1) and division by (m + 1).

If we wanted to optimize even more we could compute and operatate on fout 
instead of fvco, that would remove the * 2 and / 2.

This patch seems to be a good first step in case of multiple possible exact 
frequency matches. However, when the PLL can't achieve an exact match, we 
might still end up with a high M value when a lower value could produce an 
output frequency close enough to the desired value. I wonder if this function 
should also take 

Re: [PATCH 0/5] Add Sound support for iWave RZ/G1M board

[Simon Horman]

On Tue, Dec 12, 2017 at 06:25:06PM +, Biju Das wrote:
> This series aims to add sound support for iWave RZ/G1M board.
> 
> This patch series has documentation dependency on 
> https://patchwork.kernel.org/patch/10108014/
> 
> Biju Das (5):
>   ARM: shmobile: defconfig: Enable SGTL5000 audio codec
>   ARM: dts: r8a7743: Add audio clocks
>   ARM: dts: r8a7743: Add audio DMAC support
>   ARM: dts: r8a7743: Add sound support
>   ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
> 
>  arch/arm/boot/dts/iwg20d-q7-common.dtsi |  24 +++
>  arch/arm/boot/dts/r8a7743.dtsi  | 270 
> 
>  arch/arm/configs/shmobile_defconfig |   1 +
>  3 files changed, 295 insertions(+)

These patches seem clean to me although I do not have sufficient
documentation to properly review the last patch.

I will leave these sit for a few days to allow others to review them.

Re: [PATCH 5/5] phy: renesas: rcar-gen3-usb2: add gpio handling

[Geert Uytterhoeven]

Hi Shimoda-san,

On Wed, Dec 13, 2017 at 7:27 AM, Yoshihiro Shimoda
 wrote:
> Some R-Car SoCs (e.g. R-Car D3) doesn't have dedicated pins of VBUS
> and ID. So, they may be connected to gpio pins. To handle the gpio
> pins, this patch adds the handling of VBUS and ID pins instead of
> dedicated pins.
>
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  2 +
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c   | 77 
> --
>  2 files changed, 72 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> index 99b651b..851582f 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> @@ -27,6 +27,8 @@ channel as USB OTG:
>  - interrupts: interrupt specifier for the PHY.
>  - vbus-supply: Phandle to a regulator that provides power to the VBUS. This
>regulator will be managed during the PHY power on/off sequence.
> +- renesas,vbus-gpios: use gpio to control vbus instead of dedicated pin.
> +- renesas,id-gpios: use gpio to detect id instead of dedicated pin.

Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt already uses
"vbus-gpios" and "id-gpios" without vendor-specific prefixes, so perhaps
the "renesas," can be dropped?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/3] ARM: dts: r8a7745: Add CMT SoC specific support

[Simon Horman]

On Tue, Dec 12, 2017 at 06:49:39PM +, Fabrizio Castro wrote:
> Add CMT[01] support to SoC DT.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
>  arch/arm/boot/dts/r8a7745.dtsi | 30 ++
>  1 file changed, 30 insertions(+)

Please see my review of the r8a7743 patch in this series.

Re: [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Simon Horman]

On Tue, Dec 12, 2017 at 06:49:37PM +, Fabrizio Castro wrote:
> Document SoC specific compatible strings for r8a7743 and r8a7745.
> No driver change is needed as the fallback strings will activate
> the right code.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
> b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> index d740989..1e4fe98 100644
> --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> @@ -22,6 +22,10 @@ Required Properties:
>  
>  - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
>  - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
> +- "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743.
> +- "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743.
> +- "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745.
> +- "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745.
>  - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790.
>  - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790.
>  - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791.
> @@ -31,9 +35,11 @@ Required Properties:
>  - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794.
>  - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794.
>  
> -- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car 
> Gen2.
> -- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car 
> Gen2.
> - These are fallbacks for r8a73a4 and all the R-Car Gen2
> +- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car 
> Gen2 or

nit: or -> and ?

> + RZ/G1.
> +- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car 
> Gen2 or
> + RZ/G1.
> + These are fallbacks for r8a73a4, all the R-Car Gen2 and RZ/G1
>   entries listed above.

nit: all the R-Car -> R-Car

>- reg: base address and length of the registers block for the timer module.

Re: [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support

[Simon Horman]

On Tue, Dec 12, 2017 at 06:49:38PM +, Fabrizio Castro wrote:
> Add CMT[01] support to SoC DT.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
>  arch/arm/boot/dts/r8a7743.dtsi | 30 ++
>  1 file changed, 30 insertions(+)

I was expecting the cmt nodes to be "disabled" in the SoC file
and then enabled selectively in board files. Am I missing something?

Otherwise this patch looks good to me.

> diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> index 59860c8..0e2834a 100644
> --- a/arch/arm/boot/dts/r8a7743.dtsi
> +++ b/arch/arm/boot/dts/r8a7743.dtsi
> @@ -262,6 +262,36 @@
> IRQ_TYPE_LEVEL_LOW)>;
>   };
>  
> + cmt0: timer@ffca {
> + compatible = "renesas,r8a7743-cmt0",
> +  "renesas,rcar-gen2-cmt0";
> + reg = <0 0xffca 0 0x1004>;
> + interrupts = ,
> +  ;
> + clocks = < CPG_MOD 124>;
> + clock-names = "fck";
> + power-domains = < R8A7743_PD_ALWAYS_ON>;
> + resets = < 124>;
> + };
> +
> + cmt1: timer@e613 {
> + compatible = "renesas,r8a7743-cmt1",
> +  "renesas,rcar-gen2-cmt1";
> + reg = <0 0xe613 0 0x1004>;
> + interrupts = ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ;
> + clocks = < CPG_MOD 329>;
> + clock-names = "fck";
> + power-domains = < R8A7743_PD_ALWAYS_ON>;
> + resets = < 329>;
> + };
> +
>   cpg: clock-controller@e615 {
>   compatible = "renesas,r8a7743-cpg-mssr";
>   reg = <0 0xe615 0 0x1000>;
> -- 
> 2.7.4
> 

Re: [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus

[Geert Uytterhoeven]

Hi Simon,

On Wed, Dec 13, 2017 at 9:25 AM, Simon Horman  wrote:
> For now I've applied the following:
>
> From: Simon Horman 
> Date: Tue, 12 Dec 2017 09:24:35 +0100
> Subject: [PATCH] arm64: dts: renesas: r8a7796: move nodes which have no reg
>  property out of bus
>
> Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.

> index c1b0d0344329..e82b4db1ad1a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -154,6 +154,23 @@
> clock-frequency = <0>;
> };
>
> +   pmu_a57 {
> +   compatible = "arm,cortex-a57-pmu";
> +   interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> +   interrupt-affinity = <_0>,
> +<_1>;

Merge?

> +   };
> +
> +   pmu_a53 {
> +   compatible = "arm,cortex-a53-pmu";
> +   interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> +   interrupt-affinity = <_0>, <_1>, <_2>, <_3>;

Thanks!

> +   };

> @@ -2027,4 +1968,56 @@
> resets = < 822>;
> };
> };
> +
> +   timer {
> +   compatible = "arm,armv8-timer";
> +   interrupts-extended = < GIC_PPI 13 
> (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 14 
> (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 11 
> (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 10 
> (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;

Much better!

Or even

> +   interrupts-extended =
> +   < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | 
> IRQ_TYPE_LEVEL_LOW)>,
> +   < GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | 
> IRQ_TYPE_LEVEL_LOW)>,
> +   < GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | 
> IRQ_TYPE_LEVEL_LOW)>,
> +   < GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | 
> IRQ_TYPE_LEVEL_LOW)>;

I don't care that much, it extends beyond 80 characters anyway.

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] mmc: renesas_sdhi: Add MODULE_LICENSE

[Simon Horman]

On Wed, Dec 13, 2017 at 11:33:00AM +0900, Yoshihiro Shimoda wrote:
> From: Masaharu Hayakawa 
> 
> The following error occurs when loading renesas_sdhi_core.c module,
> so add MODULE_LICENSE("GPL v2").
> 
>  renesas_sdhi_core: module license 'unspecified' taints kernel.
> 
> Signed-off-by: Masaharu Hayakawa 
> Fixes: 9d08428afb72 ("mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main 
> module file")
> Cc:  # v4.13+
> [Shimoda: Added Fixes tag and Cc to the stable ML]
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

Re: [PATCH 1/2] PCI: rcar: Fix use-after-free in probe error path

[Simon Horman]

On Tue, Dec 12, 2017 at 01:29:42PM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 07, 2017 at 11:15:19AM +0100, Geert Uytterhoeven wrote:
> > If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes
> > during probe on r8a7791/koelsch:
> > 
> > rcar-pcie fe00.pcie: PCIe link down
> > Unable to handle kernel paging request at virtual address 6b6b6b6b
> > 
> > (seeing this message requires earlycon and keep_bootcon).
> > 
> > Indeed, pci_free_host_bridge() frees the PCI host bridge, including the
> > embedded rcar_pcie object, so pci_free_resource_list() must not be
> > called afterwards.
> > 
> > To fix this, move the call to pci_free_resource_list() up, and update the
> > label name accordingly.
> > 
> > Fixes: ddd535f1ea3eb27e ("PCI: rcar: Fix memory leak when no PCIe card is 
> > inserted")
> > Signed-off-by: Geert Uytterhoeven 
> 
> Applied with Simon's and Lorenzo's acks to for-linus for v4.15, thanks!
> 
> I'll leave the second patch up to Lorenzo for v4.16, since it doesn't seem
> as critical.

Thanks Bjorn, that's fine by me.

Re: [PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes

[Simon Horman]

On Tue, Dec 12, 2017 at 10:50:33AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
>  wrote:
> > Add reg properties to pciec[01] placeholder nodes
> >
> > This is to stop the compiler complaining as follows:
> > $ make
> > ...
> >   DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
> > (simple_bus_reg): Node /soc/pcie@fe00 missing or empty reg/ranges 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
> > (simple_bus_reg): Node /soc/pcie@ee80 missing or empty reg/ranges 
> > property
> >   DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): 
> > Node /soc/pcie@fe00 missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): 
> > Node /soc/pcie@ee80 missing or empty reg/ranges property
> >   DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
> > (simple_bus_reg): Node /soc/pcie@fe00 missing or empty reg/ranges 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
> > (simple_bus_reg): Node /soc/pcie@ee80 missing or empty reg/ranges 
> > property
> >   DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> > (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> > (simple_bus_reg): Node /soc/pcie@fe00 missing or empty reg/ranges 
> > property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> > (simple_bus_reg): Node /soc/pcie@ee80 missing or empty reg/ranges 
> > property
> >
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus

[Simon Horman]

On Tue, Dec 12, 2017 at 10:44:53AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
>  wrote:
> > Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> > The nodes that have been moved do not have any register properties and thus
> > shouldn't be placed on the bus.
> 
> [...]
> 
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 
> but a few minor comments below...
> 
> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > @@ -154,6 +154,26 @@
> > clock-frequency = <0>;
> > };
> >
> > +   pmu_a57 {
> > +   compatible = "arm,cortex-a57-pmu";
> > +   interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> > + < GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> > +   interrupt-affinity = <_0>,
> > +<_1>;
> > +   };
> > +
> > +   pmu_a53 {
> > +   compatible = "arm,cortex-a53-pmu";
> > +   interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> > + < GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> > + < GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> > + < GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> > +   interrupt-affinity = <_0>,
> > +<_1>,
> > +<_2>,
> > +<_3>;
> 
> Merge these 4 into a single line?
> 
> > @@ -2027,4 +1971,64 @@
> > resets = < 822>;
> > };
> > };
> > +
> > +   timer {
> > +   compatible = "arm,armv8-timer";
> > +   interrupts-extended = < GIC_PPI 13
> > +  (GIC_CPU_MASK_SIMPLE(6) |
> > +   IRQ_TYPE_LEVEL_LOW)>,
> > + < GIC_PPI 14
> > +  (GIC_CPU_MASK_SIMPLE(6) |
> > +   IRQ_TYPE_LEVEL_LOW)>,
> > + < GIC_PPI 11
> > +  (GIC_CPU_MASK_SIMPLE(6) |
> > +   IRQ_TYPE_LEVEL_LOW)>,
> > + < GIC_PPI 10
> > +  (GIC_CPU_MASK_SIMPLE(6) |
> > +   IRQ_TYPE_LEVEL_LOW)>;
> 
> I think you can do a better job here, by trying not to break entries across
> multiple lines ;-)
> 
> (Oops, we already have it this way in r8a7795.dtsi)

That can be fixed.

For now I've applied the following:

From: Simon Horman 
Date: Tue, 12 Dec 2017 09:24:35 +0100
Subject: [PATCH] arm64: dts: renesas: r8a7796: move nodes which have no reg
 property out of bus

Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
The nodes that have been moved do not have any register properties and thus
shouldn't be placed on the bus.

This problem is flagged by the compiler as follows:
$ make
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/thermal-zones missing or empty reg/ranges property
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/thermal-zones missing or empty reg/ranges property
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: 

Re: [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically

[Simon Horman]

On Tue, Dec 12, 2017 at 10:30:34AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
>  wrote:
> > Sort root sub-nodes alphabetically for allow for easier maintenance
> > of this file.
> >
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically

[Simon Horman]

On Tue, Dec 12, 2017 at 10:30:34AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
>  wrote:
> > Sort root sub-nodes alphabetically for allow for easier maintenance
> > of this file.
> >
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically

[Simon Horman]

On Tue, Dec 12, 2017 at 10:45:58AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:27 AM, Simon Horman
>  wrote:
> > Sort root sub-nodes alphabetically for allow for easier maintenance
> > of this file.
> >
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.