Hi Simon-san,
> From: Simon Horman, Sent: Thursday, May 9, 2019 9:52 PM
>
> SUDMAC driver was introduced in v3.10 but was never integrated for use
> by any platform. As it unused remove it.
>
> Signed-off-by: Simon Horman
Thank you for the patch!
Acked-by: Yoshihiro Shimoda
Best regards,
Yo
Hi Shimoda-san,
thank you for this update!
> +static void renesas_sdhi_init_card(struct mmc_host *mmc, struct mmc_card
> *card)
> +{
> + struct tmio_mmc_host *host = mmc_priv(mmc);
> +
> + if (host->pdev->dev.iommu_group &&
I wonder if I am too cautious, but maybe we should have another
Hi Wolfram-san,
> From: Wolfram Sang, Sent: Monday, May 13, 2019 6:01 PM
>
> Hi Shimoda-san,
>
> thank you for this update!
>
> > +static void renesas_sdhi_init_card(struct mmc_host *mmc, struct mmc_card
> > *card)
> > +{
> > + struct tmio_mmc_host *host = mmc_priv(mmc);
> > +
> > + if (ho
Hi Wolfram-san,
> From: Yoshihiro Shimoda, Sent: Monday, May 13, 2019 6:46 PM
> > That also means, for the sys-dmac and Gen2, we then use 512 for the
> > IOMMU case and 32 (default TMIO value) for the non IOMMU case. My
> > understanding is that SYS DMAC can handle 512 in both cases. Maybe it
> >
SUDMAC driver was introduced in v3.10 but was never integrated for use
by any platform. As it is unused remove it.
Signed-off-by: Simon Horman
Acked-by: Yoshihiro Shimoda
---
v2
* Update changelog
* Add Shimoda-san's Ack
---
drivers/dma/sh/Kconfig | 6 -
drivers/dma/sh/Makefile | 1 -
driv
On Fri, May 10, 2019 at 11:03:48AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
>
> > From: Simon Horman, Sent: Thursday, May 9, 2019 9:55 PM
> >
>
> > Shimoda-san, can we go further and also:
> >
> > 1. Remove the r8a66597-udc driver, which also seems unused
> > 2. Remove (minimal) sudmac i
On Fri, May 10, 2019 at 02:10:23PM +0200, Geert Uytterhoeven wrote:
> Get rid of the custom PORT_GP_PUP_27() macro by using the common
> PORT_GP_CFG_27() macro instead.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
On Fri, May 10, 2019 at 02:10:22PM +0200, Geert Uytterhoeven wrote:
> This follows the style of the existing PORT_GP_X macros, and will be
> used by a follow-up patch for the r8a7778 SoC.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
On Thu, May 09, 2019 at 03:11:29PM -0500, Chris Brandt wrote:
> The RZ/A2M EVB has a 48MHz clock attached to USB_X1.
>
> Signed-off-by: Chris Brandt
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman
On Thu, May 09, 2019 at 03:11:28PM -0500, Chris Brandt wrote:
> Add USB clock node. If present, this clock input must be 48MHz.
>
> Signed-off-by: Chris Brandt
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman
Hi Shimoda-san,
> > > That also means, for the sys-dmac and Gen2, we then use 512 for the
> > > IOMMU case and 32 (default TMIO value) for the non IOMMU case. My
> > > understanding is that SYS DMAC can handle 512 in both cases. Maybe it
> > > makes sense then to make an incremental patch setting
Update the R-Car M3-W pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the R-Car M3-W SiP (in 39x39 BGA package) by
symbolic enum values, referring to signal names.
Signed-off-by: Geert Uytterhoeven
---
dri
Now all Renesas pin control drivers have been converted to use the new
non-GPIO helper macros, SH_PFC_PIN_NAMED() and SH_PFC_PIN_NAMED_CFG()
are no longer used. Remove them.
Signed-off-by: Geert Uytterhoeven
---
drivers/pinctrl/sh-pfc/sh_pfc.h | 16
1 file changed, 16 deletions
Update the R-Car M1A pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the R-Car M1A SoC (in 25x25 FCBGA package) by
symbolic enum values, referring to signal names.
Note that the user-visible names of these p
Update the R-Car M3-N pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the R-Car M3-N SiP (in 39x39 BGA package) by
symbolic enum values, referring to signal names.
Signed-off-by: Geert Uytterhoeven
---
dri
Update the R-Car H2 pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the R-Car H2 SoC (in 31x31 FCBGA package) by
symbolic enum values, referring to signal names.
Note that the user-visible names of these pin
Hi all,
On many Renesas ARM SoCs, there exist pins that are not associated with
a GPIO port, but still need configuration (e.g. drive strength or
pull-up). While pins with GPIO functionality are indexed by their
GPIO number, no such number exists for non-GPIO pins. Hence for the
latter,
Add new macros for describing pins without GPIO functionality:
- NOGP_ALL() expands to a list of PIN_id values, to be used for
generating symbolic enum values,
- PINMUX_NOGP_ALL() expands to a list of sh_pfc_pin entries, to
list all pins and their capabilities.
Both macros depend on an
Update the R-Car H3 ES2.0 and later pin control driver to use the new
macros for describing pins without GPIO functionality. This replaces
the use of physical pin numbers on the R-Car H3 ES2.0 SiP (in 39x39
BGA package) by symbolic enum values, referring to signal names.
Signed-off-by: Geert Uytt
Update the R-Car E3 pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the R-Car E3 SoC (in 25x25 FCBGA package) by
symbolic enum values, referring to signal names.
Signed-off-by: Geert Uytterhoeven
---
drive
Update the EMMA Mobile EV2 pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the EMMA Mobile EV2 SoC (in 23x23 BGA package)
by symbolic enum values, referring to signal names.
Note that the user-visible names
Update the SH-Mobile AG5 pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the SH-Mobile AG5 SoC (in 34x34 BGA package) by
symbolic enum values, referring to signal names.
Note that the user-visible names of t
Update the R-Car H3 ES1.x pin control driver to use the new macros for
describing pins without GPIO functionality. This replaces the use of
physical pin numbers on the R-Car H3 ES1.x SiP (in 39x39 BGA package) by
symbolic enum values, referring to signal names.
Signed-off-by: Geert Uytterhoeven
As evaluation of hardware team, temperature calculation formula
of M3-W is difference from all other SoCs as below:
- M3-W: Tj_1: 116 (so Tj_1 - Tj_3 = 157)
- Others: Tj_1: 126 (so Tj_1 - Tj_3 = 167)
Signed-off-by: Yoshihiro Kaneko
---
drivers/thermal/rcar_gen3_thermal.c | 41 +++
This series was inspired by a patch in the BSP by Dien Pham
.
This series is based on the master branch of Linus Torvalds's linux tree.
v3 [Yoshihiro Kaneko]
* As suggested by Simon Horman
- Patch 1/3: change the types of ths_tj_1 to int
* As suggested by Niklas Söderlund
- Patch 2/3: rename tj_
Update the formula to calculate CTEMP:
Currently, the CTEMP is average of val1 (is calculated by
formula 1) and val2 (is calculated by formula 2). But,
as description in HWM (chapter 10A.3.1.1 Setting of Normal Mode)
If (STEMP < Tj_T) CTEMP value should be val1.
If (STEMP > Tj_T) CTEMP value shoul
Update the formula to calculate temperature:
Currently, current TEMP is calculated as
average of val1 (is calculated by formula 1)
and val2 (is calculated by formula 2). But,
as description in HWM (chapter 10A.3.1.2 Normal Mode.)
If (TEMP_CODE < THCODE2[11:0]) CTEMP value should be val1.
If (TEMP_
Hi Wolfram-san again,
> From: Yoshihiro Shimoda, Sent: Monday, May 13, 2019 6:46 PM
>
> Hi Wolfram-san,
>
> > From: Wolfram Sang, Sent: Monday, May 13, 2019 6:01 PM
> >
> > Hi Shimoda-san,
> >
> > thank you for this update!
> >
> > > +static void renesas_sdhi_init_card(struct mmc_host *mmc, stru
28 matches
Mail list logo
