On 4/19/21 11:38 AM, gabriel.fernan...@foss.st.com wrote:
From: Gabriel Fernandez
Introduce new compatible string "st,stm32mp1-rcc-secure" for
stm32mp1 clock driver when the device is configured with RCC
security support hardened.
Signed-off-by: Etienne Carriere
Signed-off-by: Gabriel
On 4/15/21 4:35 PM, Alexandre TORGUE wrote:
On 4/15/21 4:30 PM, Marek Vasut wrote:
On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
Hi Marek
Hello Alexandre,
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 2bc92ef3aeb9..19ef475a48fc 100644
On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
Hi Marek
Hello Alexandre,
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts
b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 2bc92ef3aeb9..19ef475a48fc 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@
On 4/15/21 12:10 PM, Alexandre Torgue wrote:
Running "make dtbs_check W=1", some warnings are reported concerning
LTDC port subnode:
/soc/display-controller@5a001000/port:
unnecessary #address-cells/#size-cells without "ranges" or child "reg"
property
/soc/display-controller@5a001000/port:
gpio@5000*000.
To achieve the same behaviour, read property from the firmware node.
Fixes: 7cba1a4d5e162 ("gpiolib: generalize devprop_gpiochip_set_names() for device
properties")
Cc: sta...@vger.kernel.org
Reported-by: Marek Vasut
Reported-by: Roman Guskov
Signed-off-by: Andy Shevchenko
On 4/10/21 11:06 AM, Bartosz Golaszewski wrote:
On Sat, Apr 10, 2021 at 2:46 AM Marek Vasut wrote:
On 3/15/21 6:04 PM, Andy Shevchenko wrote:
On Mon, Mar 15, 2021 at 6:49 PM Bartosz Golaszewski
wrote:
On Mon, Mar 15, 2021 at 3:34 PM Andy Shevchenko
wrote:
On Mon, Mar 15, 2021 at 03:04
On 3/15/21 6:04 PM, Andy Shevchenko wrote:
On Mon, Mar 15, 2021 at 6:49 PM Bartosz Golaszewski
wrote:
On Mon, Mar 15, 2021 at 3:34 PM Andy Shevchenko
wrote:
On Mon, Mar 15, 2021 at 03:04:37PM +0100, Bartosz Golaszewski wrote:
On Mon, Mar 15, 2021 at 1:50 PM Andy Shevchenko
wrote:
On
On 3/19/21 1:36 PM, Greg Kroah-Hartman wrote:
On Fri, Mar 19, 2021 at 01:27:23PM +0100, Marek Vasut wrote:
On 3/19/21 1:19 PM, Greg Kroah-Hartman wrote:
From: Andy Shevchenko
[ Upstream commit b41ba2ec54a70908067034f139aa23d0dd2985ce ]
On STM32MP1, the GPIO banks are subnodes of pin
On 3/19/21 1:19 PM, Greg Kroah-Hartman wrote:
From: Andy Shevchenko
[ Upstream commit b41ba2ec54a70908067034f139aa23d0dd2985ce ]
On STM32MP1, the GPIO banks are subnodes of pin-controller@50002000,
see arch/arm/boot/dts/stm32mp151.dtsi. The driver for
pin-controller@50002000 is in
On 3/15/21 2:52 PM, gre...@linuxfoundation.org wrote:
From: Greg Kroah-Hartman
From: Andy Shevchenko
commit b41ba2ec54a70908067034f139aa23d0dd2985ce upstream.
On STM32MP1, the GPIO banks are subnodes of pin-controller@50002000,
see arch/arm/boot/dts/stm32mp151.dtsi. The driver for
On 3/11/21 7:10 PM, Alexandre TORGUE wrote:
Hi Guys
On 3/11/21 5:11 PM, Marek Vasut wrote:
On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
Hello,
Hi,
On 11.03.21 15:02, Alexandre TORGUE wrote:
On 3/11/21 12:43 PM, Marek Vasut wrote:
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
1- Break
On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
Hello,
Hi,
On 11.03.21 15:02, Alexandre TORGUE wrote:
On 3/11/21 12:43 PM, Marek Vasut wrote:
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
1- Break the current ABI: as soon as those patches are merged,
stm32mp157c-dk2.dtb will impose to use
A tf
On 3/11/21 2:15 PM, Alexandre TORGUE wrote:
Hi Marek
Hello Alexandre,
On 3/11/21 12:43 PM, Marek Vasut wrote:
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
Hi ALex
Hello everyone,
[...]
Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode
On 1/26/21 3:01 AM
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
Hi ALex
Hello everyone,
[...]
Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode
On 1/26/21 3:01 AM, gabriel.fernan...@foss.st.com wrote:
From: Gabriel Fernandez
Platform STM32MP1 can be used in configuration where some
On 2/14/21 6:44 PM, Jagan Teki wrote:
[...]
+static const struct regmap_config sn65dsi_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = SN65DSI_CHA_ERR,
+ .name = "sn65dsi",
+ .cache_type = REGCACHE_RBTREE,
+};
You might want to look at the
On 2/14/21 6:44 PM, Jagan Teki wrote:
SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge
controller IC's from Texas Instruments.
SN65DSI83 - Single Channel DSI to Single-link LVDS bridge
SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge
SN65DSI85 - Dual Channel DSI to Dual-link
On 3/5/21 1:24 PM, Andy Shevchenko wrote:
On Fri, Mar 05, 2021 at 01:11:39PM +0100, Marek Vasut wrote:
On 3/5/21 1:02 PM, Andy Shevchenko wrote:
On STM32MP1, the GPIO banks are subnodes of pin-controller@50002000,
see arch/arm/boot/dts/stm32mp151.dtsi. The driver for
pin-controller@50002000
162 ("gpiolib: generalize devprop_gpiochip_set_names() for device
properties")
Reported-by: Marek Vasut
Reported-by: Roman Guskov
Signed-off-by: Andy Shevchenko
Tested-by: Marek Vasut
Reviewed-by: Marek Vasut
Thanks
static int devprop_gpiochip_set_names(struct gpio_chip *c
On 3/4/21 9:47 PM, Sasha Levin wrote:
On Tue, Mar 02, 2021 at 08:25:49PM +0100, Marek Vasut wrote:
On 12/23/20 3:13 AM, Sasha Levin wrote:
Hello Sasha,
From: Marek Vasut
[ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ]
In case RSI9116 SDIO WiFi operates in STA mode against
On 3/3/21 11:47 AM, Abel Vesa wrote:
On 20-11-03 13:18:12, Abel Vesa wrote:
The BLK_CTL according to HW design is basically the wrapper of the entire
function specific group of IPs and holds GPRs that usually cannot be placed
into one specific IP from that group. Some of these GPRs are used to
On 12/23/20 3:13 AM, Sasha Levin wrote:
Hello Sasha,
From: Marek Vasut
[ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ]
In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in AP mode,
the association fails. The former is using wpa_supplicant during association
and IWLwifi 6235 card,
Tested-by: Marek Vasut
Thanks.
On 2/24/21 9:38 AM, Arnd Bergmann wrote:
On Wed, Feb 24, 2021 at 3:38 AM Randy Dunlap wrote:
On 2/21/21 10:12 PM, kernel test robot wrote:
Hi Marek,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head:
On 2/11/21 11:17 AM, Frieder Schrempf wrote:
On 11.02.21 10:54, Claudius Heine wrote:
There is a 0 missing in the pad register offset. This patch adds it.
Signed-off-by: Claudius Heine
I think this should rather be prefixed by "arm64: dts: imx8mm:" as this
is no change in the pinctrl
controllers.
Right now the bridge driver is supporting a single link, dual-link
support requires to initiate I2C Channel B registers.
MArek Vasut (on CC) has very recently posted a driver for the SN65DSI86.
Should the two drivers be merged together ?
Since Jagan's V1 was out first, I will let Jagan
On 2/4/21 1:54 PM, Yann GAUTIER wrote:
On 2/4/21 1:26 PM, Marek Vasut wrote:
On 2/4/21 1:05 PM, yann.gaut...@foss.st.com wrote:
From: Yann Gautier
To properly manage commands awaiting R1B responses, the capability
MMC_CAP_NEED_RSP_BUSY is enabled in mmci driver, for variants that
manage busy
On 2/4/21 1:05 PM, yann.gaut...@foss.st.com wrote:
From: Yann Gautier
To properly manage commands awaiting R1B responses, the capability
MMC_CAP_NEED_RSP_BUSY is enabled in mmci driver, for variants that
manage busy detection.
This R1B management needs both the flags MMC_CAP_NEED_RSP_BUSY and
On 10/24/20 6:20 PM, Adam Ford wrote:
This driver is intended to work with the multimedia block which
contains display and camera subsystems:
LCDIF
ISI
MIPI CSI
MIPI DSI
Signed-off-by: Adam Ford
---
drivers/clk/imx/clk-blk-ctl-imx8mn.c | 80
You seem
On 1/25/21 1:19 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
An object file cannot be built for both loadable module and built-in
use at the same time:
arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function
`ks8851_probe_common':
ks8851_common.c:(.text+0xf80):
On 1/15/21 4:31 PM, t...@redhat.com wrote:
From: Tom Rix
Defining DEBUG should only be done in development.
So remove DEBUG.
Signed-off-by: Tom Rix
Reviewed-by: Marek Vasut
Thanks
On 10/25/20 1:05 PM, Abel Vesa wrote:
[...]
>> Together, both the GPC and the clk-blk driver should be able to pull
>> the multimedia block out of reset. Currently, the GPC can handle the
>> USB OTG and the GPU, but the LCDIF and MIPI DSI appear to be gated by
>> the clock block
>>
>> My
On 10/22/20 7:16 PM, Adam Ford wrote:
> According to the documentation from NXP, the i.MX8M Nano has a
> Vivante GC7000 Ultra Lite as its GPU core.
>
> With this patch, the Etnaviv driver presents the GPU as:
>etnaviv-gpu 3800.gpu: model: GC7000, revision: 6203
>
> It uses the GPCV2
On 10/12/20 7:48 AM, Oleksij Rempel wrote:
> Hi all,
>
> thank you for the feedback!
>
> On Fri, Oct 09, 2020 at 04:25:49PM +0200, Bruno Thomsen wrote:
>> Hi Fabio and Oleksij
>>
>> Den ons. 7. okt. 2020 kl. 11.50 skrev Fabio Estevam :
>>>
>>> Hi Oleksij,
>>>
>>> On Tue, Oct 6, 2020 at 5:05 AM
On 10/7/20 11:06 AM, Marco Felsch wrote:
> On 20-10-07 10:23, Marek Vasut wrote:
>> On 10/7/20 10:14 AM, Marco Felsch wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>> [...]
>>
>>> On 20-10-06 14:11, Florian Fainelli wrote:
>>>> On 10/6/2
On 10/7/20 10:14 AM, Marco Felsch wrote:
> Hi Marek,
Hi,
[...]
> On 20-10-06 14:11, Florian Fainelli wrote:
>> On 10/6/2020 1:24 PM, Marek Vasut wrote:
>
> ...
>
>>> If this happens on MX6 with FEC, can you please try these two patches?
>>>
>>
On 10/6/20 11:11 PM, Florian Fainelli wrote:
>
>
> On 10/6/2020 1:24 PM, Marek Vasut wrote:
>> On 10/6/20 9:36 PM, Florian Fainelli wrote:
>> [...]
>>>> - Use compatible ("compatible = "ethernet-phy-id0022.1560") in the
>>>>
On 10/6/20 9:36 PM, Florian Fainelli wrote:
[...]
>> - Use compatible ("compatible = "ethernet-phy-id0022.1560") in the
>> devicetree,
>> so that reading the PHYID is not needed
>> - easy to solve.
>> Disadvantage:
>> - losing PHY auto-detection capability
>> - need a new devicetree
On 6/12/20 6:46 PM, Nicolas Saenz Julienne wrote:
> Some atypical users of xhci-pci might need to manually reset their xHCI
> controller before starting the HCD setup. Check if a reset controller
> device is available to the PCI bus and trigger a reset.
>
> Signed-off-by: Nicolas Saenz Julienne
On 6/5/20 5:23 AM, Navid Emamdoost wrote:
> Calling pm_runtime_get_sync increments the counter even in case of
> failure, causing incorrect ref count. Call pm_runtime_put if
> pm_runtime_get_sync fails.
>
> Signed-off-by: Navid Emamdoost
This looks like a V2 of
[PATCH] PCI: rcar: fix runtime pm
On 5/20/20 10:22 AM, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
Sorry for the late reply.
> Signed-off-by: Dinghao Liu
> ---
>
On 6/4/20 1:18 PM, Nicolas Saenz Julienne wrote:
> On Mon, 2020-06-01 at 17:27 +0200, Marek Vasut wrote:
>> On 6/1/20 4:41 PM, Nicolas Saenz Julienne wrote:
>>> On Mon, 2020-06-01 at 13:12 +0200, Marek Vasut wrote:
>>>> On 6/1/20 1:09 PM, Nicolas Saenz Julienne w
On 6/1/20 4:41 PM, Nicolas Saenz Julienne wrote:
> On Mon, 2020-06-01 at 13:12 +0200, Marek Vasut wrote:
>> On 6/1/20 1:09 PM, Nicolas Saenz Julienne wrote:
>>> On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote:
>>>> On 6/1/20 12:47 PM, Nicolas Saenz Julienne w
On 6/1/20 1:09 PM, Nicolas Saenz Julienne wrote:
> On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote:
>> On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote:
>>> On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote:
>>>> Newer revisions of the RPi4 need th
On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote:
> On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote:
>> Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
>> loaded explicitly. Earlier versions didn't need that as they where using
>> an EEPROM for that purpose.
Hi,
since commit
0ada120c883d ("perf: Make perf able to build with latest libbfd")
is in master, can it be backported to stable as well? I keep hitting
this with too new binutils on Linux 5.4.y and I have to keep
cherry-picking this commit to fix it.
Thanks
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 1d0326f352bb094771df17f045bdbadff89a43e6
Gitweb:
https://git.kernel.org/tip/1d0326f352bb094771df17f045bdbadff89a43e6
Author:Marek Vasut
AuthorDate:Thu, 14 May 2020 02:25:55 +02:00
Committer
On 10/16/19 2:02 PM, Simon Horman wrote:
> At the end of the v5.3 upstream development cycle I stepped down
> from my role at Renesas.
>
> Pass maintainership of the R-Car PCIE to Marek and Shimoda-san.
>
> Signed-off-by: Simon Horman
Co-maintainer model is great:
Ack
On 9/30/19 2:52 PM, Robin Murphy wrote:
> On 30/09/2019 13:40, Marek Vasut wrote:
>> On 9/27/19 2:24 AM, Rob Herring wrote:
>>> This series fixes several issues related to 'dma-ranges'. Primarily,
>>> 'dma-ranges' in a PCI bridge node does correctly set dma masks for PC
s resolves the
> issues on Rpi4 and NXP Layerscape platforms.
With the following patches applied:
https://patchwork.ozlabs.org/patch/1144870/
https://patchwork.ozlabs.org/patch/1144871/
on R8A7795 Salvator-XS
Tested-by: Marek Vasut
--
Best regards,
Marek Vasut
iewed-by: Marek Vasut
--
Best regards,
Marek Vasut
s/net/dsa/microchip/ksz9477_spi.c
> +++ b/drivers/net/dsa/microchip/ksz9477_spi.c
> @@ -81,6 +81,7 @@ static const struct of_device_id ksz9477_dt_ids[] = {
> { .compatible = "microchip,ksz9893" },
> { .compatible = "microchip,ksz9563" },
> { .compatible = "microchip,ksz8563" },
> + { .compatible = "microchip,ksz9567" },
> {},
> };
> MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
>
Reviewed-by: Marek Vasut
--
Best regards,
Marek Vasut
019 Microchip Technology Inc.
Doesn't the copyright need update ?
> + */
> +
> +#include
> +#include
> +#include
> +#include
Please keep the headers sorted.
> +#include "ksz_common.h"
> +
> +KSZ_REGMAP_TABLE(ksz9477, not_used, 16, 0, 0);
> +
The rest looks good.
[...]
--
Best regards,
Marek Vasut
> Signed-off-by: George McCollister
Reviewed-by: Marek Vasut
ILI2117
Tested-by: Marek Vasut
n enough eyeballs, ...
I don't think ret is initialized, reg is, not ret .
>> And maybe we can use something else than -EINVAL for this case? I am on
>> the go right now, I will look for a suggestion later.
>
> -EINVAL is correct here (and in the above case, too), IMHO.
Yep, -EINVAL is fine.
--
Best regards,
Marek Vasut
On 6/26/19 1:15 PM, Mark Brown wrote:
> On Wed, Jun 26, 2019 at 01:31:16AM +0200, Marek Vasut wrote:
>> Drop the CONFIG_64BIT checks from core regmap code, as it is well
>> possible to access e.g. an SPI device with 64bit registers from a
>> 32bit CPU. The CONFIG_64BIT
Drop the CONFIG_64BIT checks from core regmap code, as it is well
possible to access e.g. an SPI device with 64bit registers from a
32bit CPU. The CONFIG_64BIT checks are still left in place in the
regmap mmio code however.
Signed-off-by: Marek Vasut
Cc: Rafael J. Wysocki
Cc: Mark Brown
g something obvious, but isn't DT something you want to
use on your ARM device to describe the hardware , instead of hard-coding
it into the kernel configuration ?
I recently worked with MT6797 (the Gemini PDA SoC), and the vendorkernel
does exactly this, it's a spectacular display of ifdeffery and Kconfig
chaos, so I suspect this is where the idea of putting stuff into Kconfig
comes from.
--
Best regards,
Marek Vasut
pins decide the RPC configuration ?
It seems to me like PHYCNT register, PHYMEM bitfield, selects what
device is connected, and then a couple of other bits control the
communication, but I see nothing which would be tied to any external
configuration pins.
[...]
--
Best regards,
Marek Vasut
PI_MEM_OP_DUMMY(ndummy, 4), \
> +SPI_MEM_OP_DATA_IN(len, buf, 4))
> +
> #define SPINAND_PROG_EXEC_OP(addr) \
> SPI_MEM_OP(SPI_MEM_OP_CMD(0x10, 1), \
> SPI_MEM_OP_ADDR(3, addr, 1), \
>
--
Best regards,
Marek Vasut
On 5/3/19 12:37 PM, Simon Goldschmidt wrote:
> On Fri, May 3, 2019 at 12:00 PM Marek Vasut wrote:
>>
>> On 5/3/19 10:53 AM, Simon Goldschmidt wrote:
>>> Tested on socfpga cyclone5 where this is required to ensure that the
>>> boot rom can access this flash afte
INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
> SPI_NOR_QUAD_READ) },
> { "n25q512ax3", INFO(0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
> SPI_NOR_QUAD_READ) },
>
--
Best regards,
Marek Vasut
On 3/17/19 4:43 PM, Russell King - ARM Linux admin wrote:
> On Sun, Mar 17, 2019 at 04:05:14PM +0100, Stefan Agner wrote:
>> On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
>>> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
>>>> If yo
On 3/16/19 1:22 PM, Måns Rullgård wrote:
> Marek Vasut writes:
>
>> On 3/15/19 10:52 PM, Tim Harvey wrote:
>>> Tim Harvey - Principal Software EngineerGateworks Corporation -
>>> http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
>>> 93401805-7
ays the first sdhc (sometimes the first
> one is an SDIO radio for example). It seems ridiculous that I can't
> handle this with:
>
> aliases {
> mmc0 = /* MMC boot device */
> mmc1 = /* SDIO radio */
> };
>
> I see the imx6q-dhcom-som added in
> 52c7a088badd665a09ca9307ffa91e88d5686a7d re-defines the default
> imx6qdl.dtsi mmc0-mmc3 aiases but I don't see any handling of this in
> code anywhere - am I missing something?
>
> Marek, why did you change the alias ordering for imx6q-dhcom-som.dtsi?
> (maybe your carrying around a patch to make this useful?)
Nope, likely a cleanup remnant which can be dropped.
> + aliases {
> + mmc0 =
> + mmc1 =
> + mmc2 =
> + mmc3 =
> + };
>
> Regards,
>
> Tim
>
--
Best regards,
Marek Vasut
e(np, "regulator-fixed") ||
>of_device_is_compatible(np, "reg-fixed-voltage") ||
> - of_device_is_compatible(np, "regulator-gpio"))) {
> + (of_device_is_compatible(np, "regulator-gpio") &&
> + strcmp(propna
On 2/14/19 10:12 AM, masonccy...@mxic.com.tw wrote:
> Hi,
Hi,
>> "Marek Vasut"
>> 2019/02/13 下午 08:37
>>
>> On 2/13/19 1:16 PM, Mark Brown wrote:
>> > On Wed, Feb 13, 2019 at 04:25:32PM +0800, masonccy...@mxic.com.tw wrote:
>> >
>>
mode or CFI mode.
>
> For MMIO devices MFD just passes through the parent resources.
>
--
Best regards,
Marek Vasut
cremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
How did that happen when there were still comments and open topics ?
--
Best regards,
Marek Vasut
sysfs_remove_group(>dev.kobj, _attr_group);
> -
> - return 0;
> }
>
> static int __maybe_unused ili210x_i2c_suspend(struct device *dev)
> @@ -454,7 +443,6 @@ static struct i2c_driver ili210x_ts_driver = {
> },
> .id_table = ili210x_i2c_id,
>
ch
git send-email --annotate --to=... --cc=... --cc=... 000*patch
This will likely make your life easier, rather than having to paste
various email addresses to git send-email queries.
[...]
--
Best regards,
Marek Vasut
+#define RV3028_EEBUSY_TIMEOUT10
> +
> +#define RV3028_BACKUP_TCEBIT(5)
> +#define RV3028_BACKUP_TCR_MASK GENMASK(1,0)
> +
> +#define OFFSET_STEP_PPT 953674
> +
> +enum rv3028_type {
> + rv_3028,
> +};
> +
> +struct rv3028_data {
> + struct regmap *regmap;
> + struct rtc_device *rtc;
> + enum rv3028_type type;
> +};
> +
> +static u32 rv3028_trickle_resistors[] = {1000, 3000, 6000, 11000};
u16 ?
The rest looks good to me.
--
Best regards,
Marek Vasut
On 1/30/19 3:22 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
>> "Marek Vasut"
>> 2019/01/29 下午 12:45
>>
>> To
>>
>> masonccy...@mxic.com.tw,
>>
>> cc
>>
>> bbrezil...@kernel.org, broo...@kernel.org, "G
On 1/29/19 3:26 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
>> >> "Marek Vasut"
>> >> >> >> > +module_platform_driver(rpc_spi_driver);
>> >> >> >>
>> >> >> >> RPC is not a SPI controller
On 1/28/19 2:38 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
>> "Marek Vasut"
>> >> >> > +module_platform_driver(rpc_spi_driver);
>> >> >>
>> >> >> RPC is not a SPI controller, it's a SPI and HF contro
On 1/24/19 7:28 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
>> "Marek Vasut"
>> 2019/01/24 上午 11:14
>> >>
>> >> > +module_platform_driver(rpc_spi_driver);
>> >>
>> >> RPC is not a SPI controller, it's a SPI
On 1/24/19 3:23 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
>> "Marek Vasut"
>> 2019/01/24 上午 09:54
>>
>>
>> > +#define RPC_CMNCR 0x // R/W
>>
>> Is there any reason for using those horrible C++ comments ?
>
&
resets = < 917>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <4000>;
> + spi-tx-bus-width = <1>;
> + spi-rx-bus-width = <1>;
Is the bus width really 1 or is it 4 on the D3 ?
> + };
> + };
>
--
Best regards,
Marek Vasut
;
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Marek Vasut
On 1/18/19 9:10 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Fri, Jan 18, 2019 at 9:08 AM Marek Vasut wrote:
>> On 1/18/19 9:03 AM, Geert Uytterhoeven wrote:
>>> On Fri, Jan 18, 2019 at 6:55 AM Mason Yang wrote:
>>>> --- /dev/null
>>>> +++ b/D
>> +- clocks: should contain 1 entries for the module's clock
>> +
>> +Example:
>> +
>> + rpc: rpc@ee20 {
>> + compatible = "renesas,rcar-gen3-rpc";
>
> compatible = "renesas,r8a7795-rpc," renesas,rcar-gen3-rpc";
Without the extra comma after r8a7795-rpc, of course ;-)
--
Best regards,
Marek Vasut
On 1/18/19 8:41 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
>> "Marek Vasut"
>> 2019/01/18 下午 03:10
>>
>> > +Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
>> > +--
>
<1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <4000>;
> + spi-tx-bus-width = <1>;
> + spi-rx-bus-width = <1>;
> + };
> + };
>
--
Best regards,
Marek Vasut
>
> Signed-off-by: Tudor Ambarus
Acked-by: Marek Vasut
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6682420421c1..7deb0e91e3ed 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14081,6 +1408
On 1/10/19 10:31 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,
Hi,
>> "Marek Vasut"
>> 2019/01/08 下午 08:06
>> > diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-
>> rpc.txt b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
>
RPC-IF SPI controller"
>>>> + depends on ARCH_RENESAS || COMPILE_TEST
>>>
>>>Judging on the compilation error reported by the 0-day bot about readq(),
>>> we now need to depend on 64BIT or something...
>>
>> 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?
At least the GR Peach boots from this block, so that one :)
--
Best regards,
Marek Vasut
))
> + return 0;
Shouldn't this return ret on failure ?
> div_int = (fb[0] << 4) | (fb[1] >> 4);
> div_frc = (fb[2] << 16) | (fb[3] << 8) | fb[4];
>
--
Best regards,
Marek Vasut
le to detect the
configuration based on the type of child of the RPC node. If the driver
was properly designed, it could well behave as either CFI NOR driver or
SPI flash driver and all would be good, but it seems this is written
with it being SPI flash driver only and once the HF mode would need to
be added, it'd mean a tremendous undertaking to rework the entire driver.
--
Best regards,
Marek Vasut
n "rpc"
> +- clocks: should contain 1 entries for the module's clock
> +- renesas,rpc-mode: should contain "spi" for rpc spi mode or
> +"hyperflash" for rpc hyerflash mode.
We do not need special property to identify that the controller is in HF
mode, just attach CFI NOR node or JEDEC SPI NOR underneath it.
--
Best regards,
Marek Vasut
On 12/24/18 7:52 AM, Mason Yang wrote:
> Hi Mark,
>
> This Renesas R-Car Gen3 RPC SPI driver is based on Boris's new
> spi-mem direct mapping read/write mode [1][2].
Again, the RPC is NOT a SPI controller, it is dual SPI/HF controller.
[...]
--
Best regards,
Marek Vasut
On 12/21/2018 10:08 PM, Paul Burton wrote:
> Hi Marek,
>
> On Fri, Dec 21, 2018 at 09:08:28PM +0100, Marek Vasut wrote:
>> On 12/16/2018 11:28 PM, Paul Burton wrote:
>>> On Sun, Dec 16, 2018 at 11:01:18PM +0100, Marek Vasut wrote:
>>>>>>> I did sugge
On 12/16/2018 11:28 PM, Paul Burton wrote:
> Hi Marek,
>
> On Sun, Dec 16, 2018 at 11:01:18PM +0100, Marek Vasut wrote:
>>>>> I did suggest an alternative approach which would rename
>>>>> serial8250_clear_fifos() and split it into 2 variants - one th
On 12/17/2018 06:20 PM, Marek Vasut wrote:
> On 12/17/2018 05:30 PM, Ezequiel Garcia wrote:
>> On Sun, 16 Dec 2018 at 19:35, Paul Burton wrote:
>>>
>>> Hi Ezequiel,
>>>
>>> On Sun, Dec 16, 2018 at 07:28:22PM -0300, Ezequiel Garcia wrote:
>>
s transmission in the FIFO.
Those two UARTs are connected together by two wires, without any real
RS485 hardware to minimize the hardware complexity (it's easy to
implement that on the pocketbeagle, which is the cheap option here).
--
Best regards,
Marek Vasut
n the FCR register (like the UME bit, which disables the whole
UART block), so the revert IMO would break that core too, it just
hides the breakage. I'm still trying to understand the implications
of that in detail, but the discussion wasn't quite constructive.
I'd much rather see Ezequiel's patch applied, since that's far less
destructive approach to fixing the problem than the revert.
--
Best regards,
Marek Vasut
o(rx_buf + pos, (void *), nbytes);
>> > + pos += nbytes;
>>
>> ... and it skips byte 4 unless I copy the code from the end of the
> writing
>> branch, clearing CDE/ADE. But even then the byte 4 reads as 0x03
> instead of 0.
>
> yup, I think this is some kind of RPC HW limitation,
> in RPC manual I/O mode, it only could read 4 bytes data w/ one command.
>
> That is, one command + read 4 bytes data + read 4 bytes data + read 4
> bytes data + ...
> will get the incorrect data.
>
> That's why RPC in manual I/O mode, driver only could do,
> one command + read 4 bytes data; one command + read 4 bytes data and so on.
>
> But RPC in external address space read mode(here we call it direct
> mapping read mode)
> is ok for one command + read 4 bytes data + read 4 bytes data +
I think the U-Boot driver solves those problems, since it works in both
RPC and HF mode on all of Gen3 boards , not just D3 in non-standard SPI
boot configuration. Please take a look.
--
Best regards,
Marek Vasut
On 12/16/2018 10:52 PM, Ezequiel Garcia wrote:
> On Sun, 16 Dec 2018 at 18:45, Marek Vasut wrote:
> [skips discussion]
>>
>>> Ultimately it's Greg's decision but it sounds like you're asking me to
>>> say it's OK to break the JZ4780 in a stable kernel with a patch t
On 12/16/2018 10:39 PM, Paul Burton wrote:
> Hi Marek,
Hi,
> On Sun, Dec 16, 2018 at 10:08:48PM +0100, Marek Vasut wrote:
>>> I did suggest an alternative approach which would rename
>>> serial8250_clear_fifos() and split it into 2 variants - one that
>>&g
On 12/16/2018 10:31 PM, Paul Burton wrote:
> Hi Marek,
Hi,
> On Sun, Dec 16, 2018 at 09:32:19PM +0100, Marek Vasut wrote:
>> I am unable to test it on such a short notice as I'm currently ill, so I
>> cannot tell if your change breaks the OMAP3/AM335x boards or not. Given
>
of that patch
> that disabling the FIFOs is incorrect therefore seems wrong.
>
> For these reasons, this reverts commit f6aa5beb45be ("serial: 8250: Fix
> clearing FIFOs in RS485 mode again").
>
> Signed-off-by: Paul Burton
> Fixes: f6aa5beb45be ("serial
1 - 100 of 1712 matches
Mail list logo
