On Tue, Jul 12, 2016 at 11:40 PM, Sergei Shtylyov
wrote:
> Add SDHI0 pin groups to the R8A7792 PFC driver.
>
> Signed-off-by: Sergei Shtylyov
Acked-by: Linus Walleij
I expect Geert to queue this and send it with the first pull request
for the v4.9 development cycle.
Yours,
Linus Walleij
On Tue, Jul 19, 2016 at 9:29 AM, Geert Uytterhoeven
wrote:
> This source file handles r8a7795 only, which is not the sole member of
> the R-Car Gen3 family.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> To be queued up in sh-pfc-for-v4.9.
OK! Acked-by.
Yours,
Linus Walleij
On Fri, Jul 22, 2016 at 3:51 PM, Sergei Shtylyov
wrote:
> The patch I've based my R8A7792 PFC work on had some VIN pinmux data missing
> and I just noticed that while adding the VIN pin groups...
>
> Signed-off-by: Sergei Shtylyov
This looks like a fix that should go in ASAP?
Geert, do you w
On 08/04/2016 04:38 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
>> I think moving forward we should get rid of the whole CPU/CODEC/platform
>> concept. This is an outdated view of how the hardware looks like. When ASoC
>> was initially introduce all hardware basically had a CPU side DAI, a CODEC
>
On Tue, 12 Jul 2016, Daniel Vetter wrote:
> On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
>> Backlights controlled by i915.ko and only associated with its connectors
>> and also only associated with the intel_drmfb fbcon, controlled by
>> i915.ko. In this situation, we already hand
On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote:
> On Tue, 12 Jul 2016, Daniel Vetter wrote:
> > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
> >> Backlights controlled by i915.ko and only associated with its connectors
> >> and also only associated with the intel_drmf
On Thu, Aug 04, 2016 at 10:57:29AM +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 11:50:27AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote:
> > > On Tue, 12 Jul 2016, Daniel Vetter wrote:
> > > > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wi
On Thu, Aug 04, 2016 at 11:50:27AM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote:
> > On Tue, 12 Jul 2016, Daniel Vetter wrote:
> > > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
> > >> Backlights controlled by i915.ko and only associate
On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
> On Jul 30 2016 07:08, Mark Brown wrote:
> > The card should be deinstantiated and reinstantiated whenever a
> > component driver unbinds and rebinds (respectively). You'd need to
> > completely deregister the card to change the l
The USB-DMAC's interruption happens even if the CHCR.DE is not set to 1
because CHCR.NULLE is set to 1. So, this driver should call
usb_dmac_isr_transfer_end() if the DE bit is set to 1 only. Otherwise,
the desc is possible to be NULL in the usb_dmac_isr_transfer_end().
Fixes: 0c1c8ff32fa2 ("dmaen
Hi Kieran,
Thank you for the patch.
On Thursday 09 Jun 2016 18:06:43 Kieran Bingham wrote:
> The FCP must be powered up for the FDP1 to function, even when the FDP1
> does not make use of the FCNL features. Extend the compatible list
> to allow us to use the power domain and runtime-pm support.
>
On Aug 4 2016 19:28, Mark Brown wrote:
> On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
>> On Jul 30 2016 07:08, Mark Brown wrote:
>
>>> The card should be deinstantiated and reinstantiated whenever a
>>> component driver unbinds and rebinds (respectively). You'd need to
>>> co
On Thu, 04 Aug 2016 14:12:09 +0200,
Takashi Sakamoto wrote:
>
> On Aug 4 2016 19:28, Mark Brown wrote:
> > On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
> >> On Jul 30 2016 07:08, Mark Brown wrote:
> >
> >>> The card should be deinstantiated and reinstantiated whenever a
> >>>
Hi Hans,
Thank you for the review.
I'll temporarily take over work on the FDP driver until the end of this month
as Kieran is away.
On Tuesday 19 Jul 2016 14:28:28 Hans Verkuil wrote:
> Hi Kieran,
>
> Hmm, I don't think I ever reviewed this one.
>
> So here is my quick review:
>
> General no
On 08/04/2016 03:01 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the review.
>
> I'll temporarily take over work on the FDP driver until the end of this month
> as Kieran is away.
>
> On Tuesday 19 Jul 2016 14:28:28 Hans Verkuil wrote:
>> Hi Kieran,
>>
>> Hmm, I don't think I ever
On Wed, Aug 3, 2016 at 3:56 PM, Niklas Söderlund
wrote:
> Use macro to define the runtime PM operations.
>
> Signed-off-by: Niklas Söderlund
Duplicate of commit 524c6f691b99065577b245b250efe93fb0cda5c4
Author: Kazuya Mizuguchi
Date: Mon May 30 05:25:43 2016 +0900
ravb: Add SET_RUNTIME_P
On Aug 4 2016 21:27, Takashi Iwai wrote:
> On Thu, 04 Aug 2016 14:12:09 +0200,
> Takashi Sakamoto wrote:
>>
>> On Aug 4 2016 19:28, Mark Brown wrote:
>>> On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
On Jul 30 2016 07:08, Mark Brown wrote:
>>>
> The card should be deins
On 08/04/2016 11:04 AM, Linus Walleij wrote:
The patch I've based my R8A7792 PFC work on had some VIN pinmux data missing
and I just noticed that while adding the VIN pin groups...
Signed-off-by: Sergei Shtylyov
This looks like a fix that should go in ASAP?
It would be enough if it ge
On Thu, 04 Aug 2016 15:39:40 +0200,
Takashi Sakamoto wrote:
>
> On Aug 4 2016 21:27, Takashi Iwai wrote:
> > On Thu, 04 Aug 2016 14:12:09 +0200,
> > Takashi Sakamoto wrote:
> >>
> >> On Aug 4 2016 19:28, Mark Brown wrote:
> >>> On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote:
> >>
On 2016-08-04 15:33:18 +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 3, 2016 at 3:56 PM, Niklas Söderlund
> wrote:
> > Use macro to define the runtime PM operations.
> >
> > Signed-off-by: Niklas Söderlund
>
> Duplicate of commit 524c6f691b99065577b245b250efe93fb0cda5c4
> Author: Kazuya Mizugu
Well, it's a 16 byte FIFO, so if you can just fill it up and leave that's the
easiest from a SW/HW standpoint.
However, if you just used DMA every time, it would still finish just as fast
without any CPU involvement so that's the same.
So, maybe using the FIFO instead of DMA was a fun idea, but
Thanks for the response.
I think I have actually worked this one out. I was blaming the SPI
driver incorrectly.
The DMA driver (Hacked up version from the BSP with DT support) was
never resetting the register (DMARS) that causes the SPI interrupts to
be routed there instead.
So after a DMA transfe
Hi Daniel,
On Thu, Aug 4, 2016 at 8:16 PM, Daniel Palmer wrote:
> On 5 August 2016 at 02:56, Chris Brandt wrote:
>> From: linux-renesas-soc-ow...@vger.kernel.org
>> [mailto:linux-renesas-soc-ow...@vger.kernel.org] On Behalf Of Daniel Palmer
>> I got DMA working on the RZ/A1H and started to notic
On 5 August 2016 at 03:46, Geert Uytterhoeven wrote:
> Performance figures for reading from a QSPI FLASH driven at 24.375 MHz
> on r8a7791/koelsch:
> - Single: 1.1 Mbps PIO, 23 Mbps DMA
> - Dual : 12.7 Mbps PIO, 48 Mbps DMA
> - Quad : 13 Mbps PIO, 70 Mbps DMA
Thank
Is your source buffer in external SDRAM?
The one issue with DMA is that after each byte transfer, the DMA must first
acquire a new value over SDRAM (no cache) and then write it to the RSPI IP
block sitting on the peripheral bus. I figured that would make some latency
between bytes, but maybe it
On 5 August 2016 at 04:13, Chris Brandt wrote:
> Is your source buffer in external SDRAM?
The gr peach board only has the internal 10MB SRAM so everything
should be coming from there.
The kernel is running from the memory mapped SPI flash however. I'm
not sure if that would make a difference.
> The gr peach board only has the internal 10MB SRAM so everything should be
> coming from there.
Damn. There goes that easy excuse of why it's slow.
> The kernel is running from the memory mapped SPI flash however. I'm not sure
> if that would make a difference.
No, that should not be the issu
On Thu, Aug 04, 2016 at 02:38:33AM +, Kuninori Morimoto wrote:
> I agree to your opinion.
> OTOH, we would like to use/keep existing current all drivers.
> Thus, I think we need super many small and slow steps.
> Or, we need new ASoC2 ?
Small steps is how we do things in the kernel.
> OTOH
On Thu, Aug 04, 2016 at 10:21:10AM +0200, Lars-Peter Clausen wrote:
> To be honest I'd also get rid of DAIs has a top level concept. This image
> (http://metafoo.de/the_new_asoc.svg) is something I've put together awhile
> ago how I think we should lay things out if we do a major refactoring of th
Add support for the R8A7792 DU; it has 2 DPAD (RGB) outputs.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'drm/next/du' branch of Laurent Pinchart's 'media.git'
repo...
Documentation/devicetree/bindings/display/renesas,du.txt |4 ++
drivers/gpu/drm/rcar-du/rcar_du_drv.c
30 matches
Mail list logo
