Hi Sebastian,
On 2016년 12월 07일 12:05, Sebastian Reichel wrote:
> Hi Chanwoo,
>
> On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
>> Could you please review and pick the patch3/4 for power-supply driver?
>
> Patches look fine. As I expect the merge window to open next week I
> would
Hi Chanwoo,
On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
> Could you please review and pick the patch3/4 for power-supply driver?
Patches look fine. As I expect the merge window to open next week I
would rather not queue this for 4.10 and instead do it once 4.10-rc1
has been tagg
Hello Wolfram,
On Thu, Dec 01, 2016 at 11:04:40PM +0100, Wolfram Sang wrote:
> Add support for R-Car Gen3 thermal sensors. Polling only for now,
> interrupts will be added incrementally. Same goes for reading fuses.
> This is documented already, but no hardware available for now.
>
> Signed-off-b
On Thu, Dec 01, 2016 at 11:04:40PM +0100, Wolfram Sang wrote:
> Add support for R-Car Gen3 thermal sensors. Polling only for now,
> interrupts will be added incrementally. Same goes for reading fuses.
> This is documented already, but no hardware available for now.
>
> Signed-off-by: Hien Dang
>
On Fri, Dec 02, 2016 at 09:44:22PM +0100, Wolfram Sang wrote:
> COMPILE_TEST triggers problems on 32 bit machines, so limit this driver
> to 64BIT for now. This is no loss because the hardware is only available
> on 64 bit SoCs anyhow. After we obtained more data from the hardware
> engineers, we w
On Fri, Dec 02, 2016 at 01:43:30AM +0200, Laurent Pinchart wrote:
> The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
> corresponding device tree bindings based on the DWC HDMI TX bindings
> model.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/renes
On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> tree binding by itself but is meant to be referenced by platform device
> tree bindings, and update the Rockchip and Freescale DWC HDMI TX
> bindings to refer
On Tue, 6 Dec 2016, Jacopo Mondi wrote:
> Add IIO driver for Maxim MAX11100 single-channel ADC.
> Support raw_read mode only.
comments below; very minimal driver, but several easy issues...
the read_raw() is supposed to return millivolts (after application of
offset and scale); maybe need _SCAL
Hi Rob,
> >> On Monday 05 Dec 2016 09:57:32 Rob Herring wrote:
> >> > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote:
> >> > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote:
> >> > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote:
> >> > >>> Hello DT maintainers,
> >>
Add node to test MAX11100 ADC with LED28 connected to the chip input
line.
The ADC sits on a gpio-spi master.
Signed-off-by: Jacopo Mondi
---
Sending as RFC only, not for inclusion.
Used to test MAX11100 ADC driver currently connected to Koelsch GPIO
expander.
Adding LED28 as ADC input line.
--
Add IIO driver for Maxim MAX11100 single-channel ADC.
Support raw_read mode only.
Signed-off-by: Jacopo Mondi
---
drivers/iio/adc/Kconfig| 9 +++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/max11100.c | 165 +
3 files changed, 175 inserti
Hi Ramesh,
On Tuesday 06 Dec 2016 15:41:06 Ramesh Shanmugasundaram wrote:
> > On Monday 05 Dec 2016 09:57:32 Rob Herring wrote:
> >> On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote:
> >>> On Monday 05 Dec 2016 08:18:34 Rob Herring wrote:
> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanm
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant o
On Tue, Dec 6, 2016 at 9:41 AM, Ramesh Shanmugasundaram
wrote:
> Hi Rob, Laurent,
>
> Thanks for the response.
>
>> On Monday 05 Dec 2016 09:57:32 Rob Herring wrote:
>> > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote:
>> > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote:
>> > >> On Fri
Add fallback compatibility string for the R-Car Gen 3 family. This is in
keeping with the both the existing fallback compatibility string for the
R-Car Gen 2 family and the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: Simon Horman
---
v3
* s/rc
Improve readability by listing fallback compatibility strings
after the more-specific compatibility strings they provide a fallback for.
This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.
Signed-off-by: Simon Horman
---
v3
*
Improve readability by listing fallback compatibility strings
after the more-specific compatibility strings they provide a fallback for.
This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.
Signed-off-by: Simon Horman
---
v3
*
Hi,
this short series makes some bindings cleanups to the Renesas PCI drivers.
Changes v2->v3:
* Reworded changelogs to indicate that re-ordering struct of_device_id
entries does not effect run-time behaviour
* Corrected compile error due to typo in symbol name
Changes v1->v2:
* re-order struct
Hi Rob, Laurent,
Thanks for the response.
> On Monday 05 Dec 2016 09:57:32 Rob Herring wrote:
> > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote:
> > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote:
> > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote:
> > >>> Hello D
I have pushed renesas-drivers-2016-12-06-v4.9-rc8 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging branches with driver code
submitted or planned for submi
Hello,
On Wednesday 26 Oct 2016 18:13:23 Magnus Damm wrote:
> On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote:
> > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> >> From: Magnus Damm
> >>
> >> For the DU to operate on R-Car Gen3 hardware a combination of DU
> >> and VSP devices
On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman wrote:
> Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
>
> Signed-off-by: Simon Horman
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman wrote:
> Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
>
> Signed-off-by: Simon Horman
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
Signed-off-by: Simon Horman
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 11f37ed1dbff..770e96d61a64
Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
Signed-off-by: Simon Horman
---
arch/arm/configs/shmobile_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/shmobile_defconfig
b/arch/arm/configs/shmobile_defconfig
index b66e17aec058..760688aa5c79
Hi,
this short series enables recently added r8a7743 (RZ/G1M) and r8a7745
(RZ/G1E) SoCs in relevant defconfigs.
Based on renesas-devel-20161206-v4.9-rc8
Simon Horman (2):
ARM: shmobile: defconfig: Enable r8a774[35] SoCs
ARM: multi_v7_defconfig: Enable r8a774[35] SoCs
arch/arm/configs
Hi Simon,
On Tue, Dec 6, 2016 at 1:39 PM, Simon Horman wrote:
> On Mon, Dec 05, 2016 at 11:39:36AM +0100, Geert Uytterhoeven wrote:
>> This patch series allows booting secondary CPU cores on R-Car Gen2 when
>> hardware debug mode is enabled. In this mode, reset requests derived
> Thanks, I have
On Mon, Dec 05, 2016 at 11:39:36AM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This patch series allows booting secondary CPU cores on R-Car Gen2 when
> hardware debug mode is enabled. In this mode, reset requests derived
> from power-shutoff to the AP-system CPU cores must be e
With multiple inputs through the BRU it is feasible for the streams to
race each other at stream-on. In the case of the video pipelines, this
can present two serious issues.
1) A null-dereference if the pipe->dl is committed at the same time as
the vsp1_video_setup_pipeline() is processing
The usage of pipe->dl is susceptible to races, and it is redundant to
keep this pointer in a larger scoped context.
Now that the calling order of vsp1_video_setup_pipeline() has been
adapted, it is possible to remove the pipe->dl and pass the variable as
required.
Currently the pipe->dl is set du
media_entity_pipeline_stop() can be called through error paths with a
NULL entity pipe object. In this instance, stopping is a no-op, so
simply return without any action
Signed-off-by: Kieran Bingham
---
I've marked this patch as RFC, although if deemed suitable, by all means
integrate it as is.
Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.
This commit is just a code move for clarity performing no functional
change.
Signed-off-by: Kieran Bingha
This small patchset helps rework the VSP1 driver to repair an issue on
suspend/resume operations whereby the pipeline does not get reconfigured after
it has been re-initialised following a resume operation.
Along side this, there was an intrinsic race in the vsp1_video_start_streaming()
function w
33 matches
Mail list logo