[PATCH] thermal: rcar_thermal: fix duplicate IRQ request
The driver on R8A77995 requests the same IRQ twice since
platform_get_resource() is always called for the 1st IRQ resource.
Fixes: 1969d9dc2079 ("thermal: rcar_thermal: add r8a77995 support")
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'master' branch of Zhang Rui's linux.git' repo.
drivers/thermal/rcar_thermal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/thermal/rcar_thermal.c
===
--- linux.orig/drivers/thermal/rcar_thermal.c
+++ linux/drivers/thermal/rcar_thermal.c
@@ -504,7 +504,7 @@ static int rcar_thermal_probe(struct pla
pm_runtime_get_sync(dev);
for (i = 0; i < chip->nirqs; i++) {
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, i);
if (!irq)
continue;
if (!common->base) {
Re: [PATCH] mmc: renesas_sdhi: rename DTRAN_MODE_BUS_WID_TH to DTRAN_MODE_BUS_WIDTH
On 10/03/2018 02:39 PM, Masahiro Yamada wrote: > Socionext UniPhier SoCs use the almost the same internal DMAC. > My datasheet says 'BUS_WIDTH' instead of 'BUS_WID_TH'. I suspect > this is a typo. > > Signed-off-by: Masahiro Yamada Already fixed, see: https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=devel&id=652c517c6828a830b71db4b1439a0229c98d9b9e MBR, Sergei
[PATCH QEMU POC] Add a GPIO backend
This is a Proof-of-Concept for a GPIO backend, which allows to connect
virtual GPIOs on the guest to physical GPIOs on the host. This allows
the guest to control any external device connected to the physical
GPIOs.
Features and limitations:
- The backend uses libgpiod on Linux,
- For now only GPIO outputs are supported,
- The frontend is currently hardcoded to be the PL061 GPIO controller
on the arm virtual machine. As the generic qdev_connect_gpio_out()
API call is used, any virtual GPIO controller could do, though.
Future work:
- Adding a user-instantiable GPIO frontend (or is any of the existing
virtualized GPIO controllers already user-instantiable?),
- Proper frontend/backend interface using IDs,
- Adding a QEMU internal API for controlling multiple GPIOs at once,
- Defining an API for GPIO paravirtualization,
- ...
Example:
To connect the first three GPIOs of the virtual PL061 GPIO controller
to the GPIOs controlling the three LEDs on the Renesas Salvator-X(S)
board, add the following to your qemu command invocation:
-gpiodev e6055400.gpio,vgpios=0:1:2,gpios=11:12:13
After that, the guest can cycle through the three LEDs using:
for i in $(seq 504 506); do echo $i > /sys/class/gpio/export; done
while /bin/true; do
for i in $(seq 504 506); do
echo high > /sys/class/gpio/gpio$i/direction
sleep 1
echo low > /sys/class/gpio/gpio$i/direction
done
done
Signed-off-by: Geert Uytterhoeven
---
Thanks for your comments!
---
backends/Makefile.objs | 2 +
backends/gpiodev.c | 183 +++
configure| 29 +++
hw/arm/virt.c| 6 ++
include/sysemu/gpiodev.h | 11 +++
qemu-options.hx | 20 +
vl.c | 27 ++
7 files changed, 278 insertions(+)
create mode 100644 backends/gpiodev.c
create mode 100644 include/sysemu/gpiodev.h
diff --git a/backends/Makefile.objs b/backends/Makefile.objs
index 717fcbdae4715db1..2b5f68fedd40bea0 100644
--- a/backends/Makefile.objs
+++ b/backends/Makefile.objs
@@ -16,3 +16,5 @@ common-obj-$(call land,$(CONFIG_VHOST_USER),$(CONFIG_LINUX))
+= \
endif
common-obj-$(CONFIG_LINUX) += hostmem-memfd.o
+
+common-obj-$(CONFIG_GPIO) += gpiodev.o
diff --git a/backends/gpiodev.c b/backends/gpiodev.c
new file mode 100644
index ..8d90e150f5472463
--- /dev/null
+++ b/backends/gpiodev.c
@@ -0,0 +1,183 @@
+/*
+ * QEMU GPIO Backend
+ *
+ * Copyright (C) 2018 Glider bvba
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include
+#include
+
+#include "qemu/osdep.h"
+#include "qemu/config-file.h"
+#include "qemu/cutils.h"
+#include "qemu/error-report.h"
+#include "qemu/module.h"
+#include "qemu/option.h"
+
+#include "sysemu/gpiodev.h"
+
+#include "hw/irq.h"
+#include "hw/qdev-core.h"
+
+DeviceState *the_pl061_dev;
+
+static void gpio_irq_handler(void *opaque, int n, int level)
+{
+struct gpiod_line *line = opaque;
+int status;
+
+status = gpiod_line_set_value(line, level);
+if (status < 0) {
+struct gpiod_chip *chip = gpiod_line_get_chip(line);
+
+error_report("%s/%s: Cannot set GPIO line %u: %s",
+ gpiod_chip_name(chip), gpiod_chip_label(chip),
+ gpiod_line_offset(line), strerror(errno));
+}
+}
+
+static int gpio_connect_line(unsigned int vgpio, struct gpiod_chip *chip,
+ unsigned int gpio)
+{
+const char *name = gpiod_chip_name(chip);
+const char *label = gpiod_chip_label(chip);
+struct gpiod_line *line;
+qemu_irq irq;
+int status;
+
+if (!the_pl061_dev) {
+error_report("PL061 GPIO controller not available");
+return -1;
+}
+
+line = gpiod_chip_get_line(chip, gpio);
+if (!line) {
+error_report("%s/%s: Cannot obtain GPIO line %u: %s", name, label,
+ gpio, strerror(errno));
+return -1;
+}
+
+status = gpiod_line_request_output(line, "qemu", 0);
+if (status < 0) {
+error_report("%s/%s: Cannot request GPIO line %u for output: %s", name,
+ label, gpio, strerror(errno));
+return -1;
+}
+
+irq = qemu_allocate_irq(gpio_irq_handler, line, 0);
+qdev_connect_gpio_out(the_pl061_dev, vgpio, irq);
+
+info_report("%s/%s: Connected PL061 GPIO %u to GPIO line %u", name, label,
+vgpio, gpio);
+return 0;
+}
+
+static int gpio_count_gpios(const char *opt)
+{
+unsigned int len = 0;
+unsigned int n = 0;
+
+do {
+switch (*opt) {
+case '0' ... '9':
+len++;
+break;
+
+case ':':
+case '\0':
+if (!len) {
+return -1;
+}
+
+n++;
+len = 0;
+break;
+
+default:
+return -1;
+}
+} while (*opt++);
+
+return n;
+}
+
+int qemu_gpiodev_add(QemuO
[PATCH] mfd: bd9571mwv: add volatile register to make DVFS work
From: Dien Pham
Because BD9571MWV_DVFS_MONIVDAC is not defined in the volatile table,
the physical register value is not updated by regmap and DVFS doesn't
work as expected. Fix it!
Signed-off-by: Dien Pham
[wsa: rebase, add 'Fixes', reword commit message]
Signed-off-by: Wolfram Sang
Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
---
Grabbed from the BSP and confirmed by the datasheet. The register is RO
and reflecting states depending on other registers.
drivers/mfd/bd9571mwv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 503979c81dae..fab3cdc27ed6 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -59,6 +59,7 @@ static const struct regmap_access_table
bd9571mwv_writable_table = {
};
static const struct regmap_range bd9571mwv_volatile_yes_ranges[] = {
+ regmap_reg_range(BD9571MWV_DVFS_MONIVDAC, BD9571MWV_DVFS_MONIVDAC),
regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN),
regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV_GPIO_INT),
regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTREQ),
--
2.19.0
Re: [PATCH 0/2] serial: sh-sci: Use pm_runtime_get_sync()/put()
Hey guys, I stumbled over this one again and want to make sure we have a conclusion here. > The way I understand it, the problem this intends to fix is not the > state the device ends up in, but that it needs to be powered while > registers are read or written. I agree. > It seems to me that that the current "resume" code should work in that > respect, because it changes the PM state to "on" in uart_resume_port() > before any access to hardware registers takes place, so there is > nothing that needs to be fixed. Ack. > That may be different for the "suspend" part, though, because it > assumes that the PM state is "on", and I think that is what the patch > asserts to not be a valid assumption anymore. It's hard to tell if > that is true, though, because I cannot reproduce the issue here; it > just works either way... So, do we agree then that *if* there needs to be a fix for that, it should be in uart_suspend_port() by adding some 'uart_change_pm' shortly before accessing the ops-callbacks? I am not super-fit with the uart layer, but can't we assume because of the "Nothing to do if the console is not suspending"-if-block that (for SCIF at least) it means the port is on because it _is_ the console? (I wonder, though, if the OMAPs won't need such a fix because they seem to use runtime_autosuspend, so their state might be off actually?) Regards, Wolfram signature.asc Description: PGP signature
[PATCH] mmc: renesas_sdhi: rename DTRAN_MODE_BUS_WID_TH to DTRAN_MODE_BUS_WIDTH
Socionext UniPhier SoCs use the almost the same internal DMAC.
My datasheet says 'BUS_WIDTH' instead of 'BUS_WID_TH'. I suspect
this is a typo.
Signed-off-by: Masahiro Yamada
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index ca0b439..8d04eea 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -36,7 +36,7 @@
/* DM_CM_DTRAN_MODE */
#define DTRAN_MODE_CH_NUM_CH0 0 /* "downstream" = for write commands */
#define DTRAN_MODE_CH_NUM_CH1 BIT(16) /* "uptream" = for read commands */
-#define DTRAN_MODE_BUS_WID_TH (BIT(5) | BIT(4))
+#define DTRAN_MODE_BUS_WIDTH (BIT(5) | BIT(4))
#define DTRAN_MODE_ADDR_MODE BIT(0) /* 1 = Increment address */
/* DM_CM_DTRAN_CTRL */
@@ -174,7 +174,7 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host
*host,
struct mmc_data *data)
{
struct scatterlist *sg = host->sg_ptr;
- u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
+ u32 dtran_mode = DTRAN_MODE_BUS_WIDTH | DTRAN_MODE_ADDR_MODE;
if (!dma_map_sg(&host->pdev->dev, sg, host->sg_len,
mmc_get_dma_dir(data)))
--
2.7.4
[PATCH v2 2/2] mmc: tmio: remove TMIO_MMC_HAVE_HIGH_REG flag
TMIO_MMC_HAVE_HIGH_REG is confusing due to its counter-intuitive name.
All the TMIO MMC variants (TMIO MMC, Renesas SDHI, UniPhier SD) actually
have high registers. It is just that each of them implements its own
registers there. The original IP from Panasonic only defines registers
0x00-0xff in the bus_shift=1 review. The register area above them is
platform-dependent.
In fact, TMIO_MMC_HAVE_HIGH_REG is set only by tmio-mmc.c and used to
test the accessibility of CTL_SDIO_REGS. Because it is specific to
the TMIO MFD variant, the right thing to do is to move such registers
to tmio_mmc.c and delete the TMIO_MMC_HAVE_HIGH_REG flag.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/host/tmio_mmc.c | 7 +--
drivers/mmc/host/tmio_mmc.h | 3 ---
include/linux/mfd/tmio.h| 7 ---
3 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 00d291c..4e91020 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -24,6 +24,11 @@
#include "tmio_mmc.h"
+/* Registers specific to this variant */
+#define CTL_SDIO_REGS 0x100
+#define CTL_CLK_AND_WAIT_CTL 0x138
+#define CTL_RESET_SDIO 0x1e0
+
static void tmio_mmc_clk_start(struct tmio_mmc_host *host)
{
sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
@@ -161,8 +166,6 @@ static int tmio_mmc_probe(struct platform_device *pdev)
goto cell_disable;
}
- pdata->flags |= TMIO_MMC_HAVE_HIGH_REG;
-
host = tmio_mmc_host_alloc(pdev, pdata);
if (IS_ERR(host)) {
ret = PTR_ERR(host);
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index a1a661b..18b4308 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -47,9 +47,6 @@
#define CTL_RESET_SD 0xe0
#define CTL_VERSION 0xe2
#define CTL_SDIF_MODE 0xe6
-#define CTL_SDIO_REGS 0x100
-#define CTL_CLK_AND_WAIT_CTL 0x138
-#define CTL_RESET_SDIO 0x1e0
/* Definitions for values the CTL_STOP_INTERNAL_ACTION register can take */
#define TMIO_STOP_STP BIT(0)
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 7786621..1e70060 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -62,13 +62,6 @@
#define TMIO_MMC_USE_GPIO_CD BIT(5)
/*
- * Some controllers doesn't have over 0x100 register.
- * it is used to checking accessibility of
- * CTL_SD_CARD_CLK_CTL / CTL_CLK_AND_WAIT_CTL
- */
-#define TMIO_MMC_HAVE_HIGH_REG BIT(6)
-
-/*
* Some controllers have CMD12 automatically
* issue/non-issue register
*/
--
2.7.4
[PATCH v2 0/2] mmc: tmio: remove confusing TMIO_MMC_HAVE_HIGH_REG flag
CTL_SDIO_REGS is a register specific to tmio_mmc.c Currently, we handle it in tmio_mmc_core.c, hence need TMIO_MMC_HAVE_HIGH_REG flag to prevent the other platforms from accessing to it. We can just move CTL_SDIO_REGS to tmio_mmc.c and delete the confusing TMIO_MMC_HAVE_HIGH_REG flag. Masahiro Yamada (2): mmc: tmio: move MFD variant reset to a platform hook mmc: tmio: remove TMIO_MMC_HAVE_HIGH_REG flag drivers/mmc/host/tmio_mmc.c | 24 ++-- drivers/mmc/host/tmio_mmc.h | 4 +--- drivers/mmc/host/tmio_mmc_core.c | 8 +++- include/linux/mfd/tmio.h | 7 --- 4 files changed, 26 insertions(+), 17 deletions(-) -- 2.7.4
[PATCH v2 1/2] mmc: tmio: move MFD variant reset to a platform hook
CTL_RESET_SDIO register is specific to the TMIO MFD (tmio_mmc.c).
Add a new hook host->reset for performing a platform-specific reset
sequence, and move CTL_RESET_SDIO over there.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Preserve the current sequence for tmio_mmc.c
drivers/mmc/host/tmio_mmc.c | 17 +
drivers/mmc/host/tmio_mmc.h | 1 +
drivers/mmc/host/tmio_mmc_core.c | 8 +++-
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index e04c322..00d291c 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -78,6 +78,22 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
tmio_mmc_clk_start(host);
}
+static void tmio_mmc_reset(struct tmio_mmc_host *host)
+{
+ /* FIXME - should we set stop clock reg here */
+ sd_ctrl_write16(host, CTL_RESET_SD, 0x);
+ sd_ctrl_write16(host, CTL_RESET_SDIO, 0x);
+ usleep_range(1, 11000);
+ sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
+ sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
+ usleep_range(1, 11000);
+
+ if (host->pdata->flags & TMIO_MMC_SDIO_IRQ) {
+ sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
+ sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x0001);
+ }
+}
+
#ifdef CONFIG_PM_SLEEP
static int tmio_mmc_suspend(struct device *dev)
{
@@ -156,6 +172,7 @@ static int tmio_mmc_probe(struct platform_device *pdev)
/* SD control register space size is 0x200, 0x400 for bus_shift=1 */
host->bus_shift = resource_size(res) >> 10;
host->set_clock = tmio_mmc_set_clock;
+ host->reset = tmio_mmc_reset;
host->mmc->f_max = pdata->hclk;
host->mmc->f_min = pdata->hclk / 512;
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index e6aa13a..a1a661b 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -176,6 +176,7 @@ struct tmio_mmc_host {
int (*multi_io_quirk)(struct mmc_card *card,
unsigned int direction, int blk_size);
int (*write16_hook)(struct tmio_mmc_host *host, int addr);
+ void (*reset)(struct tmio_mmc_host *host);
void (*hw_reset)(struct tmio_mmc_host *host);
void (*prepare_tuning)(struct tmio_mmc_host *host, unsigned long tap);
bool (*check_scc_error)(struct tmio_mmc_host *host);
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 0611824..9bcc760 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -164,19 +164,14 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
{
/* FIXME - should we set stop clock reg here */
sd_ctrl_write16(host, CTL_RESET_SD, 0x);
- if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
- sd_ctrl_write16(host, CTL_RESET_SDIO, 0x);
usleep_range(1, 11000);
sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
- if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
- sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
usleep_range(1, 11000);
if (host->pdata->flags & TMIO_MMC_SDIO_IRQ) {
sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x0001);
}
-
}
static void tmio_mmc_reset_work(struct work_struct *work)
@@ -1212,6 +1207,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
mmc->caps & MMC_CAP_NEEDS_POLL ||
!mmc_card_is_removable(mmc));
+ if (!_host->reset)
+ _host->reset = tmio_mmc_reset;
+
/*
* On Gen2+, eMMC with NONREMOVABLE currently fails because native
* hotplug gets disabled. It seems RuntimePM related yet we need further
--
2.7.4
Re: [PATCH 1/2] mmc: tmio: move MFD variant reset to a platform hook
Hi Wolfram,
On Wed, Oct 3, 2018 at 8:02 AM Wolfram Sang wrote:
>
> Hi Yamada-san,
>
> On Mon, Oct 01, 2018 at 09:31:01PM +0900, Masahiro Yamada wrote:
> > CTL_RESET_SDIO register is specific to the TMIO MFD (tmio_mmc.c).
> >
> > Add a new hook host->reset for performing a platform-specific reset
> > sequence, and move CTL_RESET_SDIO over there.
> >
> > Signed-off-by: Masahiro Yamada
>
> I like it in general.
>
> > +static void tmio_mmc_reset(struct tmio_mmc_host *host)
> > +{
> > + sd_ctrl_write16(host, CTL_RESET_SDIO, 0x);
> > + usleep_range(1, 11000);
> > + sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
> > + usleep_range(1, 11000);
> > +}
> > +
>
> Are you sure resetting SDIO works independently of resetting SD? Maybe
> we should add resetting SD here, too, to keep the pattern...
I am not 100% sure
since I do not have this hardware.
> > --- a/drivers/mmc/host/tmio_mmc_core.c
> > +++ b/drivers/mmc/host/tmio_mmc_core.c
> > @@ -164,14 +164,13 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
> > {
> > /* FIXME - should we set stop clock reg here */
> > sd_ctrl_write16(host, CTL_RESET_SD, 0x);
> > - if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
> > - sd_ctrl_write16(host, CTL_RESET_SDIO, 0x);
> > usleep_range(1, 11000);
> > sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
> > - if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
> > - sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
> > usleep_range(1, 11000);
>
> ... and have this simplified reset pattern either also in a seperate
> function, or doing...
>
> >
> > + if (host->reset)
> > + host->reset(host);
> else
> simplified_reset_pattern
>
> ?
>
> What's your opinion?
OK, I will send v2.
> Regards,
>
>Wolfram
>
--
Best Regards
Masahiro Yamada
[PATCH] serial: sh-sci: Add r8a77990 support
From: Hiromitsu Yamasaki This patch adds the R-Car E3 serial documentation. Signed-off-by: Hiromitsu Yamasaki Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index eaca9da79d83..0873dc043d4d 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -50,6 +50,8 @@ Required properties: - "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART. - "renesas,scif-r8a77980" for R8A77980 (R-Car V3H) SCIF compatible UART. - "renesas,hscif-r8a77980" for R8A77980 (R-Car V3H) HSCIF compatible UART. +- "renesas,scif-r8a77990" for R8A77990 (R-Car E3) SCIF compatible UART. +- "renesas,hscif-r8a77990" for R8A77990 (R-Car E3) HSCIF compatible UART. - "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART. - "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART. - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. -- 2.19.0
[PATCH 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI pins
capable of switching voltage, also add pin groups and functions
for SDHI0 and SDHI1. Please note that with the RZ/G1C only 1
bit of the POC Control Register is used to control each interface.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v1->v2:
* Reworked implementation of r8a77470_pin_to_pocctrl as per Wolfram's
and Geert's comments
* Added SDHI0 and SDHI1 pins and IO voltage control
* Added SDHI0 and SDHI1 pin groups and functions
* Reworked changelog and title
* Please note that there is some overlapping between mmc pin groups
and sdhi1 pin groups
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 +-
1 file changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 3d36e5f..fa0d42b 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -10,14 +10,45 @@
#include "sh_pfc.h"
#define CPU_ALL_PORT(fn, sfx) \
- PORT_GP_23(0, fn, sfx), \
+ PORT_GP_4(0, fn, sfx), \
+ PORT_GP_1(0, 4, fn, sfx), \
+ PORT_GP_CFG_1(0, 5, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 6, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 7, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 8, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 9, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 10, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 11, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 12, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 13, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 20, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 21, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(0, 22, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
PORT_GP_23(1, fn, sfx), \
PORT_GP_32(2, fn, sfx), \
PORT_GP_17(3, fn, sfx), \
PORT_GP_1(3, 27, fn, sfx), \
PORT_GP_1(3, 28, fn, sfx), \
PORT_GP_1(3, 29, fn, sfx), \
- PORT_GP_26(4, fn, sfx), \
+ PORT_GP_14(4, fn, sfx), \
+ PORT_GP_CFG_1(4, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(4, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_1(4, 20, fn, sfx), \
+ PORT_GP_1(4, 21, fn, sfx), \
+ PORT_GP_1(4, 22, fn, sfx), \
+ PORT_GP_1(4, 23, fn, sfx), \
+ PORT_GP_1(4, 24, fn, sfx), \
+ PORT_GP_1(4, 25, fn, sfx), \
PORT_GP_32(5, fn, sfx)
enum {
@@ -1619,6 +1650,81 @@ static const unsigned int scif_clk_b_pins[] = {
static const unsigned int scif_clk_b_mux[] = {
SCIF_CLK_B_MARK,
};
+/* - SDHI0 --
*/
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(0, 7),
+};
+static const unsigned int sdhi0_data1_mux[] = {
+ SD0_DAT0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 8),
+ RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 10),
+};
+static const unsigned int sdhi0_data4_mux[] = {
+ SD0_DAT0_MARK, SD0_DAT1_MARK, SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+static const unsigned int sdhi0_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+};
+static c
[PATCH 4/6] ARM: dts: r8a77470: Add SDHI0 support
RZ/G1C comes with two different types of IP for the SDHI
interfaces, SDHI0 and SDHI2 share the same IP type, and
such an IP is also compatible with the one found in R-Car
Gen2. SDHI1 IP on the other hand is compatible with R-Car
Gen3 with internal DMA.
This patch completes the SDHI support of the R-Car Gen2
compatible IPs, including fixing the max-frequency
definition of SDHI2, as it turns out there is a bug in
Section 1.3.9 of the RZ/G1C Hardware User's Manual (Rev.
1.00 Oct. 2017).
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2:
* New patch
---
arch/arm/boot/dts/r8a77470.dtsi | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 9e7f86d..e01df9c 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -412,6 +412,21 @@
status = "disabled";
};
+ sdhi0: sd@ee10 {
+ compatible = "renesas,sdhi-r8a77470",
+"renesas,rcar-gen2-sdhi";
+ reg = <0 0xee10 0 0x328>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 314>;
+ dmas = <&dmac0 0xcd>, <&dmac0 0xce>,
+ <&dmac1 0xcd>, <&dmac1 0xce>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <15600>;
+ power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
+ resets = <&cpg 314>;
+ status = "disabled";
+ };
+
sdhi2: sd@ee16 {
compatible = "renesas,sdhi-r8a77470",
"renesas,rcar-gen2-sdhi";
@@ -421,7 +436,7 @@
dmas = <&dmac0 0xd3>, <&dmac0 0xd4>,
<&dmac1 0xd3>, <&dmac1 0xd4>;
dma-names = "tx", "rx", "tx", "rx";
- max-frequency = <9750>;
+ max-frequency = <7800>;
power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
resets = <&cpg 312>;
status = "disabled";
--
2.7.4
[PATCH 5/6] ARM: dts: r8a77470: Add SDHI1 support
Althought interface SDHI1 found on the RZ/G1C SoC (a.k.a.
r8a77470) is compatible with the R-Car Gen3 ones, its OF
compatibility is restricted to the SoC specific compatible
string to avoid confusion, as from a more generic perspective
the RZ/G1C is sharing the most similarities with the R-Car
Gen2 family of SoCs, and there is a combination of R-Car
Gen2 compatible SDHI IPs and R-Car Gen3 compatible SDHI IP
on this specific chip.
This patch adds the SoC specific part of SDHI1 support, and
since SDHI1 comes with internal DMA, its DT node looks fairly
different from SDHI0 and SDHI2.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2:
* New patch
---
arch/arm/boot/dts/r8a77470.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index e01df9c..3e39777 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -427,6 +427,17 @@
status = "disabled";
};
+ sdhi1: sd@ee30 {
+ compatible = "renesas,sdhi-mmc-r8a77470";
+ reg = <0 0xee30 0 0x2000>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 313>;
+ max-frequency = <15600>;
+ power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
+ resets = <&cpg 313>;
+ status = "disabled";
+ };
+
sdhi2: sd@ee16 {
compatible = "renesas,sdhi-r8a77470",
"renesas,rcar-gen2-sdhi";
--
2.7.4
[PATCH 6/6] ARM: dts: iwg23s-sbc: Add uSD and eMMC support
Add uSD card and eMMC support to the iwg23s single board
computer powered by the RZ/G1C SoC (a.k.a. r8a77470).
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v1->v2:
* Added eMMC support as well
* Reworked title and changelog
* Reworked voltage regulators for uSD card on sdhi2
---
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 76 +++
1 file changed, 76 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 22da819..e5cfb50 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -6,6 +6,7 @@
*/
/dts-v1/;
+#include
#include "r8a77470.dtsi"
/ {
model = "iWave iW-RainboW-G23S single board computer based on RZ/G1C";
@@ -25,6 +26,37 @@
device_type = "memory";
reg = <0 0x4000 0 0x2000>;
};
+
+ reg_1p8v: reg-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: reg-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vccq_sdhi2: regulator-vccq-sdhi2 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI2 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
&avb {
@@ -46,10 +78,28 @@
};
&pfc {
+ mmc_pins_uhs: mmc_uhs {
+ groups = "mmc_data8", "mmc_ctrl";
+ function = "mmc";
+ power-source = <1800>;
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_b";
function = "scif1";
};
+
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
};
&scif1 {
@@ -58,3 +108,29 @@
status = "okay";
};
+
+&sdhi1 {
+ pinctrl-0 = <&mmc_pins_uhs>;
+ pinctrl-names = "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ mmc-hs200-1_8v;
+ non-removable;
+ fixed-emmc-driver-type = <1>;
+ status = "okay";
+};
+
+&sdhi2 {
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <&vccq_sdhi2>;
+ bus-width = <4>;
+ cd-gpios = <&gpio4 20 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
+ status = "okay";
+};
--
2.7.4
[PATCH 3/6] mmc: renesas_sdhi: Add r8a77470 SDHI1 support
The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces,
SDHI0 and SDHI2 are compatible with the R-Car Gen2 SDHIs, SDHI1
is compatible with R-Car Gen3 SDHIs and it can be used as
eMMC as well. This patch adds driver compatibility, and makes
sure both drivers get compiled for the R8A77470.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
v2:
* New patch
---
drivers/mmc/host/Kconfig | 4 ++--
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 694d082..fb654cd 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -622,9 +622,9 @@ config MMC_SDHI_SYS_DMAC
config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
- depends on ARM64 || COMPILE_TEST
+ depends on ARM64 || ARCH_R8A77470 || COMPILE_TEST
depends on MMC_SDHI
- default MMC_SDHI if ARM64
+ default MMC_SDHI if (ARM64 || ARCH_R8A77470)
help
This provides DMA support for SDHI SD/SDIO controllers
using on-chip bus mastering. This supports the controllers
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index e5e5015..e729c39 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -113,6 +113,7 @@ static const struct renesas_sdhi_of_data
of_rcar_gen3_compatible = {
};
static const struct of_device_id renesas_sdhi_internal_dmac_of_match[] = {
+ { .compatible = "renesas,sdhi-mmc-r8a77470", .data =
&of_rcar_gen3_compatible, },
{ .compatible = "renesas,sdhi-r8a7795", .data =
&of_rcar_r8a7795_compatible, },
{ .compatible = "renesas,sdhi-r8a7796", .data =
&of_rcar_r8a7795_compatible, },
{ .compatible = "renesas,rcar-gen3-sdhi", .data =
&of_rcar_gen3_compatible, },
@@ -288,7 +289,7 @@ static const struct tmio_mmc_dma_ops
renesas_sdhi_internal_dmac_dma_ops = {
* Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
* implementation as others may use a different implementation.
*/
-static const struct soc_device_attribute gen3_soc_whitelist[] = {
+static const struct soc_device_attribute soc_whitelist[] = {
/* specific ones */
{ .soc_id = "r8a7795", .revision = "ES1.*",
.data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
@@ -296,6 +297,7 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
.data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
/* generic ones */
{ .soc_id = "r8a774a1" },
+ { .soc_id = "r8a77470" },
{ .soc_id = "r8a7795" },
{ .soc_id = "r8a7796" },
{ .soc_id = "r8a77965" },
@@ -307,7 +309,7 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
{
- const struct soc_device_attribute *soc =
soc_device_match(gen3_soc_whitelist);
+ const struct soc_device_attribute *soc =
soc_device_match(soc_whitelist);
struct device *dev = &pdev->dev;
if (!soc)
--
2.7.4
[PATCH 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support
The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces, SDHI0 and SDHI2 are compatible with R-Car Gen2 SDHIs, and SDHI1 is compatible with R-Car Gen3 SDHIs, as it comes with an internal DMAC, therefore SDHI1 is fully compatible with driver renesas_sdhi_internal_dmac driver. As a result, the compatible strings for the R8A77470 SDHI interfaces are a little bit special. Document SDHI support for the RZ/G1C SoC. Signed-off-by: Fabrizio Castro Reviewed-by: Biju Das --- v1->v2: * Added "renesas,sdhi-mmc-r8a77470" * Using generic/fallback compatibilty only for SDHI[02] * Reworked changelog --- Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index d39d5e4..247abee 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -19,6 +19,8 @@ Required properties: "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC + "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC (SDHI[02]) + "renesas,sdhi-mmc-r8a77470" - SDHI IP on R8A77470 SoC (SDHI1) "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC @@ -35,8 +37,8 @@ Required properties: "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller - "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 or RZ/G1 - SDHI controller + "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 (but + not RZ/G1C SDHI1) SDHI controller "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2 SDHI controller -- 2.7.4
[PATCH 0/6] Add uSD and eMMC to iwg23s
Dear All, this series includes all that is necessary for uSD and eMMC to work on the iwg23s board, powered by the RZ/G1C (a.k.a. r8a77470). This work applies on top of next-20181002 Thanks, Fab Fabrizio Castro (6): dt-bindings: mmc: renesas_sdhi: Add r8a77470 support pinctrl: sh-pfc: r8a77470: Add SDHI support mmc: renesas_sdhi: Add r8a77470 SDHI1 support ARM: dts: r8a77470: Add SDHI0 support ARM: dts: r8a77470: Add SDHI1 support ARM: dts: iwg23s-sbc: Add uSD and eMMC support Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 +- arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 76 ++ arch/arm/boot/dts/r8a77470.dtsi| 28 +++- drivers/mmc/host/Kconfig | 4 +- drivers/mmc/host/renesas_sdhi_internal_dmac.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162 - 6 files changed, 273 insertions(+), 9 deletions(-) -- 2.7.4
[PATCH RESEND] ARM: dts: iwg23s-sbc: Add pinctl support for EtherAVB
Adding pinctrl support for EtherAVB interface.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
---
Hi Simon,
As per the below discussion,I need to resend this patch for V.21
https://patchwork.kernel.org/patch/10558315/
Are you happy to take this patch?
This patch is tested against renesas-dev branch
---
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 22da819..4ceff9c 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -28,6 +28,9 @@
};
&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+
phy-handle = <&phy3>;
phy-mode = "gmii";
renesas,no-ether-link;
@@ -46,6 +49,11 @@
};
&pfc {
+ avb_pins: avb {
+ groups = "avb_mdio", "avb_gmii_tx_rx";
+ function = "avb";
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_b";
function = "scif1";
--
2.7.4
Re: [PATCH v2] thermal_hwmon: Fix the 'No sensors found' error after replacing the parameter NULL by the actual device
On 03/10/18 08:25, Cao Van Dong wrote:
Formerly, when registering the hwmon device, we pass NULL as the device. It's
not a problem.
Recently, the developer has replaced the parameter NULL as the device by the
actual device.
This causes the "No sensors found" error. Therefore, instead of using the
device we will use pass
What does report this error? Is it a userspace application?
the parent of that device as parameter. This will sync with the processor on
the hwmon core.
This patch is to fix this error.
This patch is based on the v4.19-rc3 tag.
---
This patch has no SoB.
drivers/thermal/thermal_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 40c69a5..a918ba9 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -143,7 +143,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
INIT_LIST_HEAD(&hwmon->tz_list);
strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
strreplace(hwmon->type, '-', '_');
- hwmon->device = hwmon_device_register_with_info(&tz->device,
hwmon->type,
+ hwmon->device = hwmon_device_register_with_info(tz->device.parent,
hwmon->type,
hwmon, NULL, NULL);
if (IS_ERR(hwmon->device)) {
result = PTR_ERR(hwmon->device);
It is not clear to me that this is any better. What is the parent device
in this case? Can you give an example of what breaks in the hierarchy?
Given how close we are to to 4.19, I'd rather we revert f6b6b52ef7a54160
if there are userspace visible regressions.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v2] thermal_hwmon: Fix the 'No sensors found' error after replacing the parameter NULL by the actual device
CC Eduardo, Enric, Günter,
On Wed, Oct 3, 2018 at 9:27 AM Cao Van Dong wrote:
> Formerly, when registering the hwmon device, we pass NULL as the device. It's
> not a problem.
> Recently, the developer has replaced the parameter NULL as the device by the
> actual device.
> This causes the "No sensors found" error. Therefore, instead of using the
> device we will use pass
> the parent of that device as parameter. This will sync with the processor on
> the hwmon core.
> This patch is to fix this error.
>
> This patch is based on the v4.19-rc3 tag.
Fixes: f6b6b52ef7a54160 ("thermal_hwmon: Pass the originating device
down to hwmon_device_register_with_info")
> --- a/drivers/thermal/thermal_hwmon.c
> +++ b/drivers/thermal/thermal_hwmon.c
> @@ -143,7 +143,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device
> *tz)
> INIT_LIST_HEAD(&hwmon->tz_list);
> strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
> strreplace(hwmon->type, '-', '_');
> - hwmon->device = hwmon_device_register_with_info(&tz->device,
> hwmon->type,
> + hwmon->device = hwmon_device_register_with_info(tz->device.parent,
> hwmon->type,
> hwmon, NULL, NULL);
> if (IS_ERR(hwmon->device)) {
> result = PTR_ERR(hwmon->device);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2] thermal_hwmon: Fix the 'No sensors found' error after replacing the parameter NULL by the actual device
Formerly, when registering the hwmon device, we pass NULL as the device. It's
not a problem.
Recently, the developer has replaced the parameter NULL as the device by the
actual device.
This causes the "No sensors found" error. Therefore, instead of using the
device we will use pass
the parent of that device as parameter. This will sync with the processor on
the hwmon core.
This patch is to fix this error.
This patch is based on the v4.19-rc3 tag.
---
drivers/thermal/thermal_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 40c69a5..a918ba9 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -143,7 +143,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
INIT_LIST_HEAD(&hwmon->tz_list);
strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
strreplace(hwmon->type, '-', '_');
- hwmon->device = hwmon_device_register_with_info(&tz->device,
hwmon->type,
+ hwmon->device = hwmon_device_register_with_info(tz->device.parent,
hwmon->type,
hwmon, NULL, NULL);
if (IS_ERR(hwmon->device)) {
result = PTR_ERR(hwmon->device);
--
2.7.4
