Re: [PATCH v2 1/3] power: reset: Add Renesas reset driver

On 02/16/2017 06:00 PM, Chris Brandt wrote: On Thursday, February 16, 2017, Guenter Roeck wrote: Hmm, ok. Guess I don't have to understand that you can not use the watchdog driver because of the above, but implementing exactly the same functionality in a separate driver is ok. [ I am sure I am

RE: [PATCH v2 1/3] power: reset: Add Renesas reset driver

On Thursday, February 16, 2017, Guenter Roeck wrote: > Hmm, ok. Guess I don't have to understand that you can not use the > watchdog driver because of the above, but implementing exactly the same > functionality in a separate driver is ok. > > [ I am sure I am missing something here, so just

Re: [PATCH v2 1/3] power: reset: Add Renesas reset driver

On Thu, Feb 16, 2017 at 06:40:05PM +, Chris Brandt wrote: > On Thursday, February 16, 2017, Guenter Roeck wrote: > > On Thu, Feb 16, 2017 at 12:23:18PM -0500, Chris Brandt wrote: > > > Some Renesas SoCs do not have a reset register and the only way to do a SW > > > controlled reset is to use

Applied "spi: rspi: Fixes bogus received byte in qspi_transfer_in()" to the spi tree

The patch spi: rspi: Fixes bogus received byte in qspi_transfer_in() has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "spi: rspi: Replaces "n" by "len" in qspi_transfer_*()" to the spi tree

The patch spi: rspi: Replaces "n" by "len" in qspi_transfer_*() has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

RE: [PATCH v2 1/3] power: reset: Add Renesas reset driver

On Thursday, February 16, 2017, Guenter Roeck wrote: > On Thu, Feb 16, 2017 at 12:23:18PM -0500, Chris Brandt wrote: > > Some Renesas SoCs do not have a reset register and the only way to do > > a SW controlled reset is to use the watchdog timer. Additionally, > > since all the WDT timeout options

Re: [PATCH v2 1/3] power: reset: Add Renesas reset driver

On Thu, Feb 16, 2017 at 12:23:18PM -0500, Chris Brandt wrote: > Some Renesas SoCs do not have a reset register and the only way to do a SW > controlled reset is to use the watchdog timer. Additionally, since all the > WDT timeout options are so quick, a system reset is about the only thing > it's

RE: [PATCH v4 0/3] ARM: l2c: add l2c support for RZ/A1

On Thursday, February 16, 2017, Russell King wrote: > Chris, can you put all three in the patch system, preferably with Arnd's > ack for the last two please? Yes, I will do that now. Thank you. Chris

[PATCH v2 1/3] power: reset: Add Renesas reset driver

Some Renesas SoCs do not have a reset register and the only way to do a SW controlled reset is to use the watchdog timer. Additionally, since all the WDT timeout options are so quick, a system reset is about the only thing it's good for. Signed-off-by: Chris Brandt

[PATCH v2 2/3] watchdog: renesas-wdt: add support for rza

Describe the WDT hardware in the RZ/A series. Signed-off-by: Chris Brandt --- v2: * added to renesas-wdt.txt instead of creating a new file * changed commit title * added "renesas,rza-wdt" as a fallback * added interrupts property ---

[PATCH v2 3/3] ARM: dts: r7s72100: Add reset handler

For the RZ/A1, the only way to do a reset is to overflow the WDT. Signed-off-by: Chris Brandt --- v2: * changed "renesas,r7s72100-reset" to "renesas,r7s72100-wdt" * changed "renesas,wdt-reset" to "renesas,rza-wdt" * added interupt property (even though it is not used) *

[PATCH v2 0/3] power: reset: add reset for renesas r7s72100

Some Renesas SoCs do not have a reset register and the only way to do a SW controlled reset is to use the watchdog timer. Additionally, since all the WDT timeout options are so quick, a system reset is about the only thing it's good for. For example, the longest WDT overflow you can get with a

Re: [PATCH v4 0/3] ARM: l2c: add l2c support for RZ/A1

On Thu, Feb 16, 2017 at 05:57:53PM +0100, Arnd Bergmann wrote: > On Thu, Feb 16, 2017 at 5:44 PM, Russell King - ARM Linux > wrote: > > On Thu, Feb 16, 2017 at 11:17:39AM -0500, Chris Brandt wrote: > >> The PL310 in the Renesas RZ/A1 SoC (R7S72100) does not have the

Re: [PATCH v4 0/3] ARM: l2c: add l2c support for RZ/A1

On Thu, Feb 16, 2017 at 5:44 PM, Russell King - ARM Linux wrote: > On Thu, Feb 16, 2017 at 11:17:39AM -0500, Chris Brandt wrote: >> The PL310 in the Renesas RZ/A1 SoC (R7S72100) does not have the sideband >> signals connected between the CPU and L2C. According the PL310

Re: [PATCH v4 0/3] ARM: l2c: add l2c support for RZ/A1

On Thu, Feb 16, 2017 at 11:17:39AM -0500, Chris Brandt wrote: > The PL310 in the Renesas RZ/A1 SoC (R7S72100) does not have the sideband > signals connected between the CPU and L2C. According the PL310 TRM, > sideband signals are optional. > > If a PL310 is added to a system, but the sideband

[PATCH v4 3/3] ARM: dts: r7s72100: add l2 cache

Note that early-bresp-disable and full-line-zero-disable are required because the sideband signals between the CPU and L2C were not connected in this SoC. Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven --- v3: * split

[PATCH v4 0/3] ARM: l2c: add l2c support for RZ/A1

The PL310 in the Renesas RZ/A1 SoC (R7S72100) does not have the sideband signals connected between the CPU and L2C. According the PL310 TRM, sideband signals are optional. If a PL310 is added to a system, but the sideband signals are not connected, some Cortex A9 optimizations cannot be used. In

[PATCH v4 1/3] ARM: l2c: allow CA9 optimizations to be disabled

If a PL310 is added to a system, but the sideband signals are not connected, some Cortex A9 optimizations cannot be used. In particular, enabling Full Line of Zeros in the CA9 without sidebands connected will crash the system since the CA9 will expect the L2C to perform operations, yet the L2C

[PATCH v4 2/3] ARM: shmobile: r7s72100: Enable L2 cache

Even though L2C is specified in the DT, you still need to add the aux settings in the machine_desc. Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven --- v2: * removed dummy l2c_write_sec function ---

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Thursday, December 29, 2016 11:45:03 PM CET Nikita Yushchenko wrote: > > static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) > { > +#ifdef CONFIG_PCI > + if (dev_is_pci(hwdev)) { > + struct pci_dev *pdev = to_pci_dev(hwdev); > + struct

Re: [PATCH v3 1/3] ARM: l2c: allow CA9 optimizations to be disabled

On Thu, Feb 16, 2017 at 10:37:24AM -0500, Chris Brandt wrote: > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c > index 2290be3..486cc6d 100644 > --- a/arch/arm/mm/cache-l2x0.c > +++ b/arch/arm/mm/cache-l2x0.c > @@ -57,6 +57,9 @@ static unsigned long sync_reg_offset =

[PATCH v3 3/3] ARM: dts: r7s72100: add l2 cache

Note that early-bresp-disable and full-line-zero-disable are required because the sideband signals between the CPU and L2C were not connected in this SoC. Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven --- v3: * split

[PATCH v3 1/3] ARM: l2c: allow CA9 optimizations to be disabled

If a PL310 is added to a system, but the sideband signals are not connected, some Cortex A9 optimizations cannot be used. In particular, enabling Full Line of Zeros in the CA9 without sidebands connected will crash the system since the CA9 will expect the L2C to perform operations, yet the L2C

[PATCH v3 0/3] ARM: l2c: add l2c support for RZ/A1

The PL310 in the Renesas RZ/A1 SoC (R7S72100) does not have the sideband signals connected between the CPU and L2C. According the PL310 TRM, sideband signals are optional. If a PL310 is added to a system, but the sideband signals are not connected, some Cortex A9 optimizations cannot be used. In

[PATCH v3 2/3] ARM: shmobile: r7s72100: Enable L2 cache

Even though L2C is specified in the DT, you still need to add the aux settings in the machine_desc. Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven --- v2: * removed dummy l2c_write_sec function ---

Re: [PATCH v2 2/4] mmc: host: tmio: fix minor typos in comments

On Mon, Feb 13, 2017 at 07:03:40PM +0100, Wolfram Sang wrote: > Making sure we match the actual register names. > > Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman

RE: [PATCH 2/3] dt-bindings: power: reset: add document for renesas-reset driver

Hi Geert, On Thursday, February 16, 2017, Geert Uytterhoeven wrote: > On Wed, Feb 15, 2017 at 6:33 PM, Chris Brandt > wrote: > > On Tuesday, February 14, 2017, Geert Uytterhoeven wrote: > >> > +Required properties: > >> > + - compatible: must be one or more of the

Re: [PATCH 2/3] dt-bindings: power: reset: add document for renesas-reset driver

Hi Chris, On Wed, Feb 15, 2017 at 6:33 PM, Chris Brandt wrote: > On Tuesday, February 14, 2017, Geert Uytterhoeven wrote: >> > +Required properties: >> > + - compatible: must be one or more of the following: >> > +- "renesas,r7s72100-reset" for the r7s72100 SoC >>

RE: [PATCH v3 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

Hi Rob, Thank you for the review comments. > Subject: Re: [PATCH v3 6/7] dt-bindings: media: Add Renesas R-Car DRIF > binding > > On Tue, Feb 07, 2017 at 03:02:36PM +, Ramesh Shanmugasundaram wrote: > > Add binding documentation for Renesas R-Car Digital Radio Interface > > (DRIF)

RE: How to get related device pointer via DT?

Hi Peter, > From: Peter Chen > Sent: Wednesday, February 15, 2017 7:02 PM > > On Wed, Feb 15, 2017 at 02:21:55AM +, Yoshihiro Shimoda wrote: < snip > > > If my idea A), ehci0 will have companion = <>; > > If my idea B), no need to add any property. > > > > What do you think? > > Anyway, I

Re: [PATCH v2 4/4] mmc: host: tmio: fill in response from auto cmd12

On 16 February 2017 at 09:37, Wolfram Sang wrote: > Hi Ulf, > > On Thu, Feb 16, 2017 at 08:57:36AM +0100, Ulf Hansson wrote: >> On 15 February 2017 at 16:02, Wolfram Sang wrote: >> > >> >> > I see. Ulf, do you think it makes sense to extend the condition

Re: [RFC] mmc: host: tmio: ensure end of DMA and SD access are in sync

On Thu, Feb 16, 2017 at 09:28:24AM +0100, Ulf Hansson wrote: > On 15 February 2017 at 19:05, Wolfram Sang > wrote: > > The current code assumes that DMA is finished before SD access end is > > flagged. Thus, it schedules the 'dma_complete' tasklet in the SD card

Re: [PATCH v2 4/4] mmc: host: tmio: fill in response from auto cmd12

Hi Ulf, On Thu, Feb 16, 2017 at 08:57:36AM +0100, Ulf Hansson wrote: > On 15 February 2017 at 16:02, Wolfram Sang wrote: > > > >> > I see. Ulf, do you think it makes sense to extend the condition when to > >> > call mmc_blk_cmd_recovery() with checking if stop.resp[0] has one

Re: [RFC] mmc: host: tmio: ensure end of DMA and SD access are in sync

On 15 February 2017 at 19:05, Wolfram Sang wrote: > The current code assumes that DMA is finished before SD access end is > flagged. Thus, it schedules the 'dma_complete' tasklet in the SD card > interrupt routine when DATAEND is set. The assumption is not safe,