RE: [PATCH] irqchip: Enable compile-testing for Renesas drivers

e up > + to 8 external interrupts with configurable sense select. Appreciated−by: Chris Brandt :)

RE: [PATCH 0/5] ARM: rskrza1: Add RZ/A1 IRQC and input switches

Hi Geert, Thanks for this patch! I've been hacking this support into the standard GIC driver in our BSPs for years now. :o On Mon, Apr 29, 2019, Geert Uytterhoeven wrote: > I expect this driver to be reusable for RZ/A2, after adding a match > entry with .gic_spi_base = 4. Yes, the same IP

RE: [PATCH v5 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver

On Wednesday, January 09, 2019, Sergei Shtylyov wrote: > > IIRC, this hardware block is also used on RZ/A, which is 32-bit. > > I'm not seeing it in the "RZ/A1H Group, RZ/A1M Group User’s Manual: > Hardware" > Rev 3.00. What SoC did you have in mind? For the RZ/A series (and RZ/T series), it

RE: [PATCH 0/2] serial: sh-sci: Fix earlycon on Renesas ARM platforms

Hi Geert, On Thursday, August 30, 2018, Geert Uytterhoeven wrote: > Earlycon for RZ/A2 (which is a new platform) will be fixed later in a > separate patch. I assume something like this: (which works for me) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index

RE: [PATCH 0/2] serial: sh-sci: Fix earlycon on Renesas ARM platforms

Hi Geert, On Thursday, August 30, 2018, Geert Uytterhoeven wrote: > Earlycon for RZ/A2 (which is a new platform) will be fixed later in a > separate patch. I assume something like this: (which works for me) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index

RE: [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"

On Friday, June 22, 2018, Russell King - ARM Linux wrote: > We've worked around the issues with "multi-platform" XIP/NOMMU by > using things such as "ARM_SINGLE_V7M" to cover all V7M platforms > (which must, by definition) have compatible physical layouts. > Exactly the same approach should be

RE: [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"

On Friday, June 22, 2018, Russell King - ARM Linux wrote: > We've worked around the issues with "multi-platform" XIP/NOMMU by > using things such as "ARM_SINGLE_V7M" to cover all V7M platforms > (which must, by definition) have compatible physical layouts. > Exactly the same approach should be

RE: [PATCH v6 1/4] cramfs: direct memory access support

-1000 r-xp 00:00 0 [vectors] So far, so good. Thank you! Tested-by: Chris Brandt <chris.bra...@renesas.com>

RE: [PATCH v6 1/4] cramfs: direct memory access support

00:00 0 [vectors] So far, so good. Thank you! Tested-by: Chris Brandt

RE: [PATCH v5 0/5] cramfs refresh for embedded usage

On Friday, October 06, 2017, Christoph Hellwig wrote: > This is still missing a proper API for accessing the file system, > as said before specifying a physical address in the mount command > line is a an absolute non-no. > > Either work with the mtd folks to get the mtd core down to an absolute

RE: [PATCH v5 0/5] cramfs refresh for embedded usage

On Friday, October 06, 2017, Christoph Hellwig wrote: > This is still missing a proper API for accessing the file system, > as said before specifying a physical address in the mount command > line is a an absolute non-no. > > Either work with the mtd folks to get the mtd core down to an absolute

RE: [PATCH v4 4/5] cramfs: add mmap support

On Thursday, October 05, 2017, Nicolas Pitre wrote: > Do you have the same amount of free memory once booted in both cases? Yes, almost exactly the same, so obvious it must be working the same for both cases. That's enough evidence for me. Thanks. Chris

RE: [PATCH v4 4/5] cramfs: add mmap support

On Thursday, October 05, 2017, Nicolas Pitre wrote: > Do you have the same amount of free memory once booted in both cases? Yes, almost exactly the same, so obvious it must be working the same for both cases. That's enough evidence for me. Thanks. Chris

RE: [PATCH v4 4/5] cramfs: add mmap support

013.10.so bec93000-becb4000 rw-p 00:00 0 [stack] befad000-befae000 r-xp 00:00 0 [sigpage] -1000 r-xp 00:00 0 [vectors] Regardless, from a functional standpoint: Tested-by: Chris Brandt <chris.bra...@renesas.com> Jus

RE: [PATCH v4 4/5] cramfs: add mmap support

013.10.so bec93000-becb4000 rw-p 00:00 0 [stack] befad000-befae000 r-xp 00:00 0 [sigpage] -1000 r-xp 00:00 0 [vectors] Regardless, from a functional standpoint: Tested-by: Chris Brandt Just FYI, the previous [PATCH v4 4/5

RE: [PATCH v4 1/5] cramfs: direct memory access support

On Tuesday, October 03, 2017 1, Rob Herring wrote: > On Sun, Oct 1, 2017 at 3:29 AM, Christoph Hellwig > wrote: > > On Wed, Sep 27, 2017 at 07:32:20PM -0400, Nicolas Pitre wrote: > >> To distinguish between both access types, the cramfs_physmem filesystem > >> type must be

RE: [PATCH v4 1/5] cramfs: direct memory access support

On Tuesday, October 03, 2017 1, Rob Herring wrote: > On Sun, Oct 1, 2017 at 3:29 AM, Christoph Hellwig > wrote: > > On Wed, Sep 27, 2017 at 07:32:20PM -0400, Nicolas Pitre wrote: > >> To distinguish between both access types, the cramfs_physmem filesystem > >> type must be specified when using a

RE: [PATCH v2 0/5] cramfs refresh for embedded usage

lso willing to step up as cramfs maintainer given > that no sign of any maintenance activities appeared for years. > > This series is also available based on v4.13-rc4 via git here: > > http://git.linaro.org/people/nicolas.pitre/linux xipcramfs > > > Changes from v1: > > -

RE: [PATCH v2 0/5] cramfs refresh for embedded usage

lso willing to step up as cramfs maintainer given > that no sign of any maintenance activities appeared for years. > > This series is also available based on v4.13-rc4 via git here: > > http://git.linaro.org/people/nicolas.pitre/linux xipcramfs > > > Changes from v1: > > -

RE: [PATCH v2 4/5] cramfs: add mmap support

On Tuesday, August 29, 2017, Chris Brandt wrote: > On Tuesday, August 29, 2017, Nicolas Pitre wrote: > > On Tue, 29 Aug 2017, Chris Brandt wrote: > > > > > On Monday, August 28, 2017, Nicolas Pitre wrote: > > > > OK I moved the lock promotion right at t

RE: [PATCH v2 4/5] cramfs: add mmap support

On Tuesday, August 29, 2017, Chris Brandt wrote: > On Tuesday, August 29, 2017, Nicolas Pitre wrote: > > On Tue, 29 Aug 2017, Chris Brandt wrote: > > > > > On Monday, August 28, 2017, Nicolas Pitre wrote: > > > > OK I moved the lock promotion right at t

RE: [PATCH v2 4/5] cramfs: add mmap support

On Tuesday, August 29, 2017, Nicolas Pitre wrote: > On Tue, 29 Aug 2017, Chris Brandt wrote: > > > On Monday, August 28, 2017, Nicolas Pitre wrote: > > > OK I moved the lock promotion right at the beginning _before_ > validating > > > the split point. Also got a r

RE: [PATCH v2 4/5] cramfs: add mmap support

On Tuesday, August 29, 2017, Nicolas Pitre wrote: > On Tue, 29 Aug 2017, Chris Brandt wrote: > > > On Monday, August 28, 2017, Nicolas Pitre wrote: > > > OK I moved the lock promotion right at the beginning _before_ > validating > > > the split point. Also got a r

RE: [PATCH v2 4/5] cramfs: add mmap support

On Monday, August 28, 2017, Nicolas Pitre wrote: > OK I moved the lock promotion right at the beginning _before_ validating > the split point. Also got a reference on the file to make sure that > hasn't changed too. > > > While we are at it, what happens if you mmap 120Kb, then munmap() the >

RE: [PATCH v2 4/5] cramfs: add mmap support

On Monday, August 28, 2017, Nicolas Pitre wrote: > OK I moved the lock promotion right at the beginning _before_ validating > the split point. Also got a reference on the file to make sure that > hasn't changed too. > > > While we are at it, what happens if you mmap 120Kb, then munmap() the >

RE: [PATCH v2 4/5] cramfs: add mmap support

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > When cramfs_physmem is used then we have the opportunity to map files > directly from ROM, directly into user space, saving on RAM usage. > This gives us Execute-In-Place (XIP) support. > > For a file to be mmap()-able, the map area has to

RE: [PATCH v2 4/5] cramfs: add mmap support

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > When cramfs_physmem is used then we have the opportunity to map files > directly from ROM, directly into user space, saving on RAM usage. > This gives us Execute-In-Place (XIP) support. > > For a file to be mmap()-able, the map area has to

RE: [PATCH v2 3/5] cramfs: implement uncompressed and arbitrary data block positioning

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > Two new capabilities are introduced here: > > - The ability to store some blocks uncompressed. > > - The ability to locate blocks anywhere. > > Those capabilities can be used independently, but the combination > opens the possibility for

RE: [PATCH v2 3/5] cramfs: implement uncompressed and arbitrary data block positioning

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > Two new capabilities are introduced here: > > - The ability to store some blocks uncompressed. > > - The ability to locate blocks anywhere. > > Those capabilities can be used independently, but the combination > opens the possibility for

RE: [PATCH v2 1/5] cramfs: direct memory access support

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > Small embedded systems typically execute the kernel code in place (XIP) > directly from flash to save on precious RAM usage. This adds the ability > to consume filesystem data directly from flash to the cramfs filesystem > as well. Cramfs is

RE: [PATCH v2 1/5] cramfs: direct memory access support

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > Small embedded systems typically execute the kernel code in place (XIP) > directly from flash to save on precious RAM usage. This adds the ability > to consume filesystem data directly from flash to the cramfs filesystem > as well. Cramfs is

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Wednesday, August 16, 2017 1, Nicolas Pitre wrote: > > Just FYI, > > I'm running an xipImage with all the RZ/A1 upstream drivers enabled and > > only using about 4.5MB of total system RAM. > > That's pretty good. Of course for a real application, you would trim off > > the drivers and

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Wednesday, August 16, 2017 1, Nicolas Pitre wrote: > > Just FYI, > > I'm running an xipImage with all the RZ/A1 upstream drivers enabled and > > only using about 4.5MB of total system RAM. > > That's pretty good. Of course for a real application, you would trim off > > the drivers and

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > > Yes, now I can boot with my rootfs being a XIP cramfs. > > > > However, like you said, libc is not XIP. > > I think I have it working now. Probably learned more about the memory > management internals than I ever wanted to know. Please try

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Wednesday, August 16, 2017, Nicolas Pitre wrote: > > Yes, now I can boot with my rootfs being a XIP cramfs. > > > > However, like you said, libc is not XIP. > > I think I have it working now. Probably learned more about the memory > management internals than I ever wanted to know. Please try

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Tuesday, August 15, 2017 1, Nicolas Pitre wrote: > I was able to reproduce. The following patch on top should partially fix > it. I'm trying to figure out how to split a vma and link it properly in > the case the vma cannot be mapped entirely. In the mean time shared libs > won't be XIP. > >

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Tuesday, August 15, 2017 1, Nicolas Pitre wrote: > I was able to reproduce. The following patch on top should partially fix > it. I'm trying to figure out how to split a vma and link it properly in > the case the vma cannot be mapped entirely. In the mean time shared libs > won't be XIP. > >

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Monday, August 14, 2017, Nicolas Pitre wrote: > > However, now with your mkcramfs tool, I can no longer mount my cramfs > > image as the rootfs on boot. I was able to do that before (ie, 30 > minutes > > ago) when using the community mkcramfs (ie, 30 minutes ago). > > > > I get this: > > > > [

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Monday, August 14, 2017, Nicolas Pitre wrote: > > However, now with your mkcramfs tool, I can no longer mount my cramfs > > image as the rootfs on boot. I was able to do that before (ie, 30 > minutes > > ago) when using the community mkcramfs (ie, 30 minutes ago). > > > > I get this: > > > > [

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Monday, August 14, 2017, Nicolas Pitre wrote: > > I just applied the patches tried this simple test: > > - tested with a Renesas RZ/A1 (Cortex-A9...so it has an MMU). > > - I set the sticky bit for busybox before using mkcramfs > > You need the newer mkcramfs I linked to in the

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Monday, August 14, 2017, Nicolas Pitre wrote: > > I just applied the patches tried this simple test: > > - tested with a Renesas RZ/A1 (Cortex-A9...so it has an MMU). > > - I set the sticky bit for busybox before using mkcramfs > > You need the newer mkcramfs I linked to in the

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Friday, August 11, 2017, Nicolas Pitre wrote: > This series brings a nice refresh to the cramfs filesystem, adding the > following capabilities: > > - Direct memory access, bypassing the block and/or MTD layers entirely. > > - Ability to store individual data blocks uncompressed. > > -

RE: [PATCH 0/5] cramfs refresh for embedded usage

On Friday, August 11, 2017, Nicolas Pitre wrote: > This series brings a nice refresh to the cramfs filesystem, adding the > following capabilities: > > - Direct memory access, bypassing the block and/or MTD layers entirely. > > - Ability to store individual data blocks uncompressed. > > -

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

Hello Jacopo and Linus, On Monday, May 29, 2017, jmondi wrote: > > > We can handle 'bi-directional' pins with static tables in our pin > > > controller driver and not have it anywhere in DT. > > > > This sounds like a viable approach. > > > > I just want to know if "output-enable" is the right

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

Hello Jacopo and Linus, On Monday, May 29, 2017, jmondi wrote: > > > We can handle 'bi-directional' pins with static tables in our pin > > > controller driver and not have it anywhere in DT. > > > > This sounds like a viable approach. > > > > I just want to know if "output-enable" is the right

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

Hi Geert, On Friday, May 12, 2017, Geert Uytterhoeven wrote: > 12 x 16 = 192, not 384. Opps, my math was off! (I think I need another cup of coffee this morning) > Do you need all possible combinations of input, output, and bi-dir? > I assumed they're mutually exclusive. If not, you need 3

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

Hi Geert, On Friday, May 12, 2017, Geert Uytterhoeven wrote: > 12 x 16 = 192, not 384. Opps, my math was off! (I think I need another cup of coffee this morning) > Do you need all possible combinations of input, output, and bi-dir? > I assumed they're mutually exclusive. If not, you need 3

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

Hi Geert and Linus, On Friday, May 12, 2017, Geert Uytterhoeven wrote: > Jacopo, Chris: Would two bits per pin/function (none, input, output, > bidir) > be sufficient? > That makes one u16 per pin. So roughtly 12 ports x 16 pins => 384 bytes. > Plus code to handle it. After all not that bad...

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

Hi Geert and Linus, On Friday, May 12, 2017, Geert Uytterhoeven wrote: > Jacopo, Chris: Would two bits per pin/function (none, input, output, > bidir) > be sufficient? > That makes one u16 per pin. So roughtly 12 ports x 16 pins => 384 bytes. > Plus code to handle it. After all not that bad...

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

On Friday, May 12, 2017, linux-renesas-soc-ow...@vger.kernel.org wrote: > As you say this is actually fixing hardware bugs, we can expect these > quirky tables to be gone in the next hardware generation, right? I see this particular pin controller as a one shot deal. For the next part in this

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

On Friday, May 12, 2017, linux-renesas-soc-ow...@vger.kernel.org wrote: > As you say this is actually fixing hardware bugs, we can expect these > quirky tables to be gone in the next hardware generation, right? I see this particular pin controller as a one shot deal. For the next part in this

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

Hello Andy, On Monday, May 08, 2017, Andy Shevchenko wrote: > > Bi-Directional: > > > > For any pin that needs to drive (send) or sense (receive) signals, the > pin > > mux controller can only enable 1 direction of buffers (in this case, it > > only the output buffers). Therefore the appropriate

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

Hello Andy, On Monday, May 08, 2017, Andy Shevchenko wrote: > > Bi-Directional: > > > > For any pin that needs to drive (send) or sense (receive) signals, the > pin > > mux controller can only enable 1 direction of buffers (in this case, it > > only the output buffers). Therefore the appropriate

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

On Monday, May 08, 2017, Andy Shevchenko wrote: > On Mon, May 8, 2017 at 7:01 PM, jmondi wrote: > > On Sun, May 07, 2017 at 09:52:49AM +0200, Linus Walleij wrote: > >> On Fri, Apr 28, 2017 at 4:53 PM, Andy Shevchenko > >> wrote: > >> > >> > Linus,

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

On Monday, May 08, 2017, Andy Shevchenko wrote: > On Mon, May 8, 2017 at 7:01 PM, jmondi wrote: > > On Sun, May 07, 2017 at 09:52:49AM +0200, Linus Walleij wrote: > >> On Fri, Apr 28, 2017 at 4:53 PM, Andy Shevchenko > >> wrote: > >> > >> > Linus, for me it looks like better to revert that

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

On Friday, May 05, 2017, Linus Walleij wrote: > > This is the part of the whole "DT is for hardware description only" that > doesn't really make sense to me. > > OK yeah we do hardware description AND configuration. > > And we never do interpreted languages. > > And then there is a bunch of

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

On Friday, May 05, 2017, Linus Walleij wrote: > > This is the part of the whole "DT is for hardware description only" that > doesn't really make sense to me. > > OK yeah we do hardware description AND configuration. > > And we never do interpreted languages. > > And then there is a bunch of

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

On Friday, April 28, 2017, Andy Shevchenko wrote: > > We were using "input-enable" to signal when the pin function that we set > also needs to be forcible set to input by the software (once again, > because the HW is not smart enough to do it on its own), but is different > than the bi-directional

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

On Friday, April 28, 2017, Andy Shevchenko wrote: > > We were using "input-enable" to signal when the pin function that we set > also needs to be forcible set to input by the software (once again, > because the HW is not smart enough to do it on its own), but is different > than the bi-directional

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

On Friday, April 28, 2017, Andy Shevchenko wrote: > Had you read the following, esp. Note there? > > * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does > not > * affect the pin's ability to drive output. 1 enables input, 0 > disables > * input. > > For me manual

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

On Friday, April 28, 2017, Andy Shevchenko wrote: > Had you read the following, esp. Note there? > > * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does > not > * affect the pin's ability to drive output. 1 enables input, 0 > disables > * input. > > For me manual

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

Hi Geert, On Friday, April 28, 2017, Geert Uytterhoeven wrote: > >> Shouldn't the interrupt (connected to P1_15) be described? > > > > That interrupt pin from the PHY is not used. It did not need to be > connected. > > But it is connected, according to the schematics. P1_15 can be configured

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

Hi Geert, On Friday, April 28, 2017, Geert Uytterhoeven wrote: > >> Shouldn't the interrupt (connected to P1_15) be described? > > > > That interrupt pin from the PHY is not used. It did not need to be > connected. > > But it is connected, according to the schematics. P1_15 can be configured

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

On Friday, April 28, 2017, Linus Walleij wrote: > > Add pin configuration subnode for ETHER ethernet controller. > > > > Signed-off-by: Jacopo Mondi > (...) > > + pins_bidir { > > + pinmux = ;/* P3_3 = > ET_MDIO

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

On Friday, April 28, 2017, Linus Walleij wrote: > > Add pin configuration subnode for ETHER ethernet controller. > > > > Signed-off-by: Jacopo Mondi > (...) > > + pins_bidir { > > + pinmux = ;/* P3_3 = > ET_MDIO */ > > + bi-directional; >

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

On Friday, April 28, 2017, Andy Shevchenko wrote: > > In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control > Logical Diagram (but that wasn't obvious to me at first). > > Please, post a link to it or copy essential parts. This board the RZ/A1 GENMAI board.

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

On Friday, April 28, 2017, Andy Shevchenko wrote: > > In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control > Logical Diagram (but that wasn't obvious to me at first). > > Please, post a link to it or copy essential parts. This board the RZ/A1 GENMAI board.

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

On Friday, April 28, 2017, Linus Walleij wrote: > > For me it looks like you are trying to alias open-drain + bias or > > alike. Don't actually see the benefit of it. > > Andy is bringing up a valid point. And I remember asking about this before. > > What does "bi-directional" really mean,

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

On Friday, April 28, 2017, Linus Walleij wrote: > > For me it looks like you are trying to alias open-drain + bias or > > alike. Don't actually see the benefit of it. > > Andy is bringing up a valid point. And I remember asking about this before. > > What does "bi-directional" really mean,

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

Hi Geert, On Thursday, April 27, 2017, Geert Uytterhoeven wrote: > > + { > > + pinctrl-names = "default"; > > + pinctrl-0 = <_pins>; > > + > > + status = "okay"; > > + > > + renesas,no-ether-link; > > + phy-handle = <>; > > + phy0: ethernet-phy@0 { > > +

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

Hi Geert, On Thursday, April 27, 2017, Geert Uytterhoeven wrote: > > + { > > + pinctrl-names = "default"; > > + pinctrl-0 = <_pins>; > > + > > + status = "okay"; > > + > > + renesas,no-ether-link; > > + phy-handle = <>; > > + phy0: ethernet-phy@0 { > > +

RE: [PATCH v4 0/9] Renesas RZ/A1 pin and gpio controller

Hi Jacopo, On Wednesday, April 05, 2017, Jacopo Mondi wrote: > v3 -> v4: > - use "pinmux" property in pmx sub-nodes in place of "renesas,pins" > - use pinconf standard properties to set pin mux additional flags > - add "bi-directional" and "output-enable" to pinconf generic properties > - perform

RE: [PATCH v4 0/9] Renesas RZ/A1 pin and gpio controller

Hi Jacopo, On Wednesday, April 05, 2017, Jacopo Mondi wrote: > v3 -> v4: > - use "pinmux" property in pmx sub-nodes in place of "renesas,pins" > - use pinconf standard properties to set pin mux additional flags > - add "bi-directional" and "output-enable" to pinconf generic properties > - perform

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

On Thursday, March 30, 2017, Linus Walleij wrote: > >> > +/* > >> > + * Pin is bi-directional. > >> > + * An alternate function that needs both input/output > >> > +functionalities shall > >> > + * be configured as bidirectional. > >> > + * Eg. SDA/SCL pins of an I2c interface. > >> > + */ > >> >

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

On Thursday, March 30, 2017, Linus Walleij wrote: > >> > +/* > >> > + * Pin is bi-directional. > >> > + * An alternate function that needs both input/output > >> > +functionalities shall > >> > + * be configured as bidirectional. > >> > + * Eg. SDA/SCL pins of an I2c interface. > >> > + */ > >> >

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

On Wednesday, March 29, 2017, Chris Brandt wrote: > On Wednesday, March 29, 2017, Geert Uytterhoeven wrote: > > > But, what do we do for Ethernet? All the pins are "normal" except > > > just the MDIO pin needs to be bidirectional. > > > That's the pa

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

On Wednesday, March 29, 2017, Chris Brandt wrote: > On Wednesday, March 29, 2017, Geert Uytterhoeven wrote: > > > But, what do we do for Ethernet? All the pins are "normal" except > > > just the MDIO pin needs to be bidirectional. > > > That's the pa

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

Hi Geert, On Wednesday, March 29, 2017, Geert Uytterhoeven wrote: > > But, what do we do for Ethernet? All the pins are "normal" except just > > the MDIO pin needs to be bidirectional. > > That's the part I'm confused by. > > How do we flag that just the ET_MDIO needs "bidirectional"? > > You

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

Hi Geert, On Wednesday, March 29, 2017, Geert Uytterhoeven wrote: > > But, what do we do for Ethernet? All the pins are "normal" except just > > the MDIO pin needs to be bidirectional. > > That's the part I'm confused by. > > How do we flag that just the ET_MDIO needs "bidirectional"? > > You

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

On Wednesday, March 29, 2017, Linus Walleij wrote: > On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi > wrote: > > > Add dt-bindings for Renesas r7s72100 pin controller header file. > > > > Signed-off-by: Jacopo Mondi > > > +/* > > + * Pin is

RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

On Wednesday, March 29, 2017, Linus Walleij wrote: > On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi > wrote: > > > Add dt-bindings for Renesas r7s72100 pin controller header file. > > > > Signed-off-by: Jacopo Mondi > > > +/* > > + * Pin is bi-directional. > > + * An alternate function that

RE: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

On Wednesday, March 29, 2017, Linus Walleij: > If you prefer to use preprocessor macros or whatever to make the bitmasks > or how you want to organize the constants in your include files is not my > concern, do whatever you seem fit, just pack it into a 32bit thing somehow > which makes sense from

RE: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

On Wednesday, March 29, 2017, Linus Walleij: > If you prefer to use preprocessor macros or whatever to make the bitmasks > or how you want to organize the constants in your include files is not my > concern, do whatever you seem fit, just pack it into a 32bit thing somehow > which makes sense from

RE: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

Adding my 2 cents here: On Wednesday, March 29, 2017, jacopo wrote: > > > If you really do we may need to go for u64 but ... really? Is there > > > a rational reason for that other than "we did it like this first"? > > > > > > I do not understand the notion of "flags" here. I hope that is not > >

RE: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

Adding my 2 cents here: On Wednesday, March 29, 2017, jacopo wrote: > > > If you really do we may need to go for u64 but ... really? Is there > > > a rational reason for that other than "we did it like this first"? > > > > > > I do not understand the notion of "flags" here. I hope that is not > >

RE: [PATCH v3 4/7] arm: dts: r7s72100: Add pin controller node

Hi Jacopo, On Friday, March 24, 2017, Jacopo Mondi > + pinctrl: pinctrl@fcfe3000 { > + compatible = "renesas,r7s72100-ports"; > + > + #pinctrl-cells = <1>; > + > + reg = <0xfcfe3000 0x42C0>; Out of curiosity, why did you change this from 0x4248 to 0x42C0?

RE: [PATCH v3 4/7] arm: dts: r7s72100: Add pin controller node

Hi Jacopo, On Friday, March 24, 2017, Jacopo Mondi > + pinctrl: pinctrl@fcfe3000 { > + compatible = "renesas,r7s72100-ports"; > + > + #pinctrl-cells = <1>; > + > + reg = <0xfcfe3000 0x42C0>; Out of curiosity, why did you change this from 0x4248 to 0x42C0?

RE: [PATCH v2 0/7] Renesas RZ/A1 pin and gpio controller

Hi Jacopo, On Monday, March 20, 2017, Jacopo Mondi wrote: > Chris: it would be great if you could give this another spin on RSK board. I tested these patches on an RZ/A1H RSK board after modifying the DT for the RSK vs the GENMAI board. The following worked fine: * SCIF * I2C * SDHI *

RE: [PATCH v2 0/7] Renesas RZ/A1 pin and gpio controller

Hi Jacopo, On Monday, March 20, 2017, Jacopo Mondi wrote: > Chris: it would be great if you could give this another spin on RSK board. I tested these patches on an RZ/A1H RSK board after modifying the DT for the RSK vs the GENMAI board. The following worked fine: * SCIF * I2C * SDHI *

RE: [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END

On 12/6/2016, Florian Fainelli wrote: > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > index 4001dd15818d..18ef688a796e 100644 > --- a/arch/arm/mm/mmu.c > +++ b/arch/arm/mm/mmu.c > @@ -1437,12 +1437,8 @@ static void __init kmap_init(void) > static void __init map_lowmem(void) > { >

RE: [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END

On 12/6/2016, Florian Fainelli wrote: > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > index 4001dd15818d..18ef688a796e 100644 > --- a/arch/arm/mm/mmu.c > +++ b/arch/arm/mm/mmu.c > @@ -1437,12 +1437,8 @@ static void __init kmap_init(void) > static void __init map_lowmem(void) > { >

RE: [PATCH] spi: rspi: avoid uninitialized variable access

Since I was CC-ed, I'll add in my opinion: While Geert already pointed out the spelling mistake (_in_or_our >> _in_or_out), since that function is only just for qspi versions, a better function name should have been "qspi_pio_transfer_in_or_out" However On 11/8/2016, Arnd Bergmann

RE: [PATCH] spi: rspi: avoid uninitialized variable access

Since I was CC-ed, I'll add in my opinion: While Geert already pointed out the spelling mistake (_in_or_our >> _in_or_out), since that function is only just for qspi versions, a better function name should have been "qspi_pio_transfer_in_or_out" However On 11/8/2016, Arnd Bergmann

RE: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On 19 Feb 2016, Russell King wrote: > Using the DTB location on XIP platforms is a no-goer - the flattened > DTB information can be fixed, so on an XIP platform it makes sense > for this to also be in flash, not in RAM (the whole point of XIP is > to remove constant data from RAM after all, so

RE: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On 19 Feb 2016, Russell King wrote: > Using the DTB location on XIP platforms is a no-goer - the flattened > DTB information can be fixed, so on an XIP platform it makes sense > for this to also be in flash, not in RAM (the whole point of XIP is > to remove constant data from RAM after all, so

RE: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On 19 Feb 2016, Arnd Bergmann wrote: > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote: > > > > Acked-by: Nicolas Pitre > > > > Is there a way to provide a default for defaults? > > We could have something like > > config PHYS_OFFSET_0 > bool > > config

RE: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On 19 Feb 2016, Arnd Bergmann wrote: > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote: > > > > Acked-by: Nicolas Pitre > > > > Is there a way to provide a default for defaults? > > We could have something like > > config PHYS_OFFSET_0 > bool > > config PHYS_OFFSET_1 >

RE: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation

; Carsten Otte ; Chris Brandt Subject: RE: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation Hi Jared, The old filemap_xip code was living in a state of sin ;-) It was writing to the kernel's mapping of an address, and then not flushing the cache before telling userspace

RE: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation

lt;linux-kernel@vger.kernel.org>; Linux Memory Management List <linux...@kvack.org>; Matthew Wilcox <wi...@linux.intel.com>; Andrew Morton <a...@linux-foundation.org>; Carsten Otte <co...@de.ibm.com>; Chris Brandt <chris.bra...@renesas.com> Subject: RE: [PATCH v1

RE: [PATCH] ARM: xip: Use correct symbol for end of ROM marker

> I think below is required as well. > > --- a/arch/arm/kernel/module.c > +++ b/arch/arm/kernel/module.c > @@ -34,7 +36,7 @@ > * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off. > */ > #undef MODULES_VADDR > -#define MODULES_VADDR(((unsigned long)_etext +

  1   2   >