* Re: [RFC PATCH 5/6] watchdog: ROHM BD96801 PMIC WDG driver
From: Matti Vaittinen @ 2024-04-03 6:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: Matti Vaittinen, Lee Jones, Wim Van Sebroeck, devicetree,
linux-kernel, linux-watchdog
In-Reply-To: <4fa3a64b-60fb-4e5e-8785-0f14da37eea2@roeck-us.net>
Hi Guenter,
First of all, thanks for the review. It was quick! Especially when we
speak of a RFC series. Very much appreciated.
On 4/2/24 20:11, Guenter Roeck wrote:
> On Tue, Apr 02, 2024 at 04:11:41PM +0300, Matti Vaittinen wrote >> +static int init_wdg_hw(struct wdtbd96801 *w)
>> +{
>> + u32 hw_margin[2];
>> + int count, ret;
>> + u32 hw_margin_max = BD96801_WDT_DEFAULT_MARGIN, hw_margin_min = 0;
>> +
>> + count = device_property_count_u32(w->dev->parent, "rohm,hw-timeout-ms");
>> + if (count < 0 && count != -EINVAL)
>> + return count;
>> +
>> + if (count > 0) {
>> + if (count > ARRAY_SIZE(hw_margin))
>> + return -EINVAL;
>> +
>> + ret = device_property_read_u32_array(w->dev->parent,
>> + "rohm,hw-timeout-ms",
>> + &hw_margin[0], count);
>> + if (ret < 0)
>> + return ret;
>> +
>> + if (count == 1)
>> + hw_margin_max = hw_margin[0];
>> +
>> + if (count == 2) {
>> + hw_margin_max = hw_margin[1];
>> + hw_margin_min = hw_margin[0];
>> + }
>> + }
>> +
>> + ret = bd96801_set_wdt_mode(w, hw_margin_max, hw_margin_min);
>> + if (ret)
>> + return ret;
>> +
>> + ret = device_property_match_string(w->dev->parent, "rohm,wdg-action",
>> + "prstb");
>> + if (ret >= 0) {
>> + ret = regmap_update_bits(w->regmap, BD96801_REG_WD_CONF,
>> + BD96801_WD_ASSERT_MASK,
>> + BD96801_WD_ASSERT_RST);
>> + return ret;
>> + }
>> +
>> + ret = device_property_match_string(w->dev->parent, "rohm,wdg-action",
>> + "intb-only");
>> + if (ret >= 0) {
>> + ret = regmap_update_bits(w->regmap, BD96801_REG_WD_CONF,
>> + BD96801_WD_ASSERT_MASK,
>> + BD96801_WD_ASSERT_IRQ);
>> + return ret;
>> + }
>
> I don't see the devicetree bindings documented in the series.
Seems like I have missed this WDG binding. But after reading your
comment below, I am wondering if I should just drop the binding and
default to "prstb" (shutdown should the feeding be skipped) - and leave
the "intb-only" case for one who actually needs such.
> I am also a bit surprised that the interrupt isn't handled in the driver.
> Please explain.
Basically, I just had no idea what the IRQ should do in the generic
case. If we get an interrupt, it means the WDG feeding has failed. My
thinking is that, what should happen is forced reset. I don't see how
that can be done in reliably manner from an IRQ handler.
When the "prstb WDG action" is set (please, see the above DT binding
handling), the PMIC shall shut down power outputs. This should get the
watchdog's job done.
With the "intb-only"-option, PMIC will not turn off the power. I'd
expect there to be some external HW connection which handles the reset
by HW.
After all this being said, I wonder if I should just unconditionally
configure the PMIC to always turn off the power (prstb option) should
the feeding fail? Or do someone have some suggestion what the IRQ
handler should do (except maybe print an error msg)?
>
>> +
>> + return 0;
>> +}
>> +
>> +static int bd96801_wdt_probe(struct platform_device *pdev)
>> +{
>> + struct wdtbd96801 *w;
>> + int ret;
>> + unsigned int val;
>> +
>> + w = devm_kzalloc(&pdev->dev, sizeof(*w), GFP_KERNEL);
>> + if (!w)
>> + return -ENOMEM;
>> +
>> + w->regmap = dev_get_regmap(pdev->dev.parent, NULL);
>
> dev_get_regmap() can return NULL.
>
>> + w->dev = &pdev->dev;
>> +
>> + w->wdt.info = &bd96801_wdt_info;
>> + w->wdt.ops = &bd96801_wdt_ops;
>> + w->wdt.parent = pdev->dev.parent;
>> + w->wdt.timeout = DEFAULT_TIMEOUT;
>> + watchdog_set_drvdata(&w->wdt, w);
>> +
>> + w->always_running = device_property_read_bool(pdev->dev.parent,
>> + "always-running");
>> +
> Without documentation, it looks like the always-running (from
> linux,wdt-gpio.yaml) may be abused. Its defined meaning is
> "the watchdog is always running and can not be stopped". Its
> use here seems to be "start watchdog when loading the module and
> prevent it from being stopped".
Yes. You're right.
> Oh well, looks like the abuse was introduced with bd9576_wdt. That
> doesn't make it better. At the very least it needs to be documented
> that the property does not have the intended (documented) meaning.
I can raise my hand for a sign of an error here. I've been misreading
the intended meaning of the always-running. Not sure if I've picked it
from another driver (maybe GPIO watchdog), or if I've just
misinterpreted the binding docs.
Do you suggest me to add a note in the BD9576 binding doc (there is no
BD9576 specific binding doc for watchdog. I wonder whether this warrants
adding one under watchdog or if the note can be added under
Documentation/devicetree/bindings/mfd/rohm,bd9576...).
>> + ret = regmap_read(w->regmap, BD96801_REG_WD_CONF, &val);
>> + if (ret)
>> + return dev_err_probe(&pdev->dev, ret,
>> + "Failed to get the watchdog state\n");
>> +
>> + /*
>> + * If the WDG is already enabled we assume it is configured by boot.
>> + * In this case we just update the hw-timeout based on values set to
>> + * the timeout / mode registers and leave the hardware configs
>> + * untouched.
>> + */
>> + if ((val & BD96801_WD_EN_MASK) != BD96801_WD_DISABLE) {
>> + dev_dbg(&pdev->dev, "watchdog was running during probe\n");
>> + ret = bd96801_set_heartbeat_from_hw(w, val);
>> + if (ret)
>> + return ret;
>> +
>> + set_bit(WDOG_HW_RUNNING, &w->wdt.status);
>> + } else {
>> + /* If WDG is not running so we will initializate it */
>> + ret = init_wdg_hw(w);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + watchdog_init_timeout(&w->wdt, 0, pdev->dev.parent);
>> + watchdog_set_nowayout(&w->wdt, nowayout);
>> + watchdog_stop_on_reboot(&w->wdt);
>> +
>> + if (w->always_running)
>> + bd96801_wdt_start(&w->wdt);
>
> I think this needs to set WDOG_HW_RUNNING or the watchdog will trigger
> a reboot if the watchdog device is not opened and the watchdog wasn't
> already running when the module was loaded.
I believe you're right. Seems I haven't properly tested this path.
> That makes me wonder what happens if the property is set and the
> watchdog daemon isn't started in the bd9576_wdt driver.
My assumption is the dog starts barking. I'll see if I find the BD9576
break-out board from one of my boxes to wire it up and test this. If the
always-running is not working it might be justified to just drop it from
both drivers. I believe it'd be indication that no-one is really using
the always-running with the upstream driver.
Thanks a ton!
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH 1/2] drm/bridge: lt8912b: add support for P/N pin swap
From: Alexandru Ardelean @ 2024-04-03 6:32 UTC (permalink / raw)
To: Francesco Dolcini
Cc: linux-kernel, dri-devel, devicetree, adrien.grassein,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, airlied, daniel, maarten.lankhorst, mripard,
tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt,
stefan.eichenberger, francesco.dolcini, marius.muresan,
irina.muresan
In-Reply-To: <20240402165307.GA31874@francesco-nb>
On Tue, Apr 2, 2024 at 7:53 PM Francesco Dolcini <francesco@dolcini.it> wrote:
>
> Hello Alexandru, thanks for your patch.
>
> On Tue, Apr 02, 2024 at 01:59:24PM +0300, Alexandru Ardelean wrote:
> > On some HW designs, it's easier for the layout if the P/N pins are swapped.
> > In those cases, we need to adjust (for this) by configuring the MIPI analog
> > registers differently. Specifically, register 0x3e needs to be 0xf6
> > (instead of 0xd6).
> >
> > This change adds a 'lontium,pn-swap' device-tree property to configure the
> > MIPI analog registers for P/N swap.
> >
> > Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
> > ---
> > drivers/gpu/drm/bridge/lontium-lt8912b.c | 25 +++++++++++++++++++++---
> > 1 file changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> > index 4b2ae27f0a57f..154126bb922b4 100644
> > --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> > +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> > @@ -47,6 +47,7 @@ struct lt8912 {
> >
> > u8 data_lanes;
> > bool is_power_on;
> > + bool do_pn_swap;
> > };
> >
> > static int lt8912_write_init_config(struct lt8912 *lt)
> > @@ -78,15 +79,31 @@ static int lt8912_write_init_config(struct lt8912 *lt)
> > {0x55, 0x44},
> > {0x57, 0x01},
> > {0x5a, 0x02},
> > -
> > - /*MIPI Analog*/
> > + };
> > + const struct reg_sequence mipi_analog_seq[] = {
> > {0x3e, 0xd6},
> > {0x3f, 0xd4},
> > {0x41, 0x3c},
> > {0xB2, 0x00},
> > };
> > + const struct reg_sequence mipi_analog_pn_swap_seq[] = {
> > + {0x3e, 0xf6},
> > + {0x3f, 0xd4},
> > + {0x41, 0x3c},
> > + {0xB2, 0x00},
> > + };
> > + int ret;
> >
> > - return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq, ARRAY_SIZE(seq));
> > + ret = regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq, ARRAY_SIZE(seq));
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (!lt->do_pn_swap)
> > + return regmap_multi_reg_write(lt->regmap[I2C_MAIN], mipi_analog_seq,
> > + ARRAY_SIZE(mipi_analog_seq));
> > +
> > + return regmap_multi_reg_write(lt->regmap[I2C_MAIN], mipi_analog_pn_swap_seq,
> > + ARRAY_SIZE(mipi_analog_pn_swap_seq));
>
> Can you just remove {0x3e, 0xd6} from the register/value array and write
> it afterward depending on `do_pn_swap` value? Or keep it with the
> current value and only overwrite it when do_pn_swap is true?
>
> If you do it this way is a 4 line change.
Hmm, good point.
I did it like this, because I don't have a board with the P/N in the
0xd6 configuration, to test.
But, if I leave it like this, and just overwrite 0x3e when
`do_pn_swap` is true, I can test that; and I don't need to test the
original case.
I'm actually not 100% sure here if the order of registers (being
written) matters for the initialization.
>
>
> > static int lt8912_write_mipi_basic_config(struct lt8912 *lt)
> > @@ -702,6 +719,8 @@ static int lt8912_parse_dt(struct lt8912 *lt)
> > }
> > lt->gp_reset = gp_reset;
> >
> > + lt->do_pn_swap = device_property_read_bool(dev, "lontium,pn-swap");
>
> I would call this variable the same that is called in the lontium
> documentation, mipirx_diff_swap
Oh.
I actually based this change on a reference software for the LT8912B.
I didn't get a chance to see/find a documentation for the registers.
I compared with the Linux driver, to see what was missing to get
output on the HDMI display (for our setup).
>
> Francesco
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 6:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <eb7a0d5c-c197-44b9-baea-e9b54792b447@kernel.org>
On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> > On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> >>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>>>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>>>> registers within the System Controller device-tree node. The default MAC
> >>>>> Address for the interface corresponding to the first MAC port will be set
> >>>>> to the value programmed in the eFuse.
> >>>>>
> >>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>>>> ---
> >>>>>
> >>>>> This patch is based on linux-next tagged next-20240402.
> >>>>
> >>>> Where is the DTS using it?
> >>>
> >>> The current implementation in the device-tree for older TI K3 SoCs is as
> >>> follows:
> >>>
> >>> cpsw_port1: port@1 {
> >>> reg = <1>;
> >>> ti,mac-only;
> >>> label = "port1";
> >>> phys = <&phy_gmii_sel 1>;
> >>> mac-address = [00 00 00 00 00 00];
> >>> ti,syscon-efuse = <&wkup_conf 0x200>;
> >>> };
> >>>
> >>> The "ti,syscon-efuse" property passes the reference to the System
> >>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> >>> within the CTRL_MMR space.
> >>
> >> Please reference upstream DTS or lore link to patch under review.
> >
> > An example of the existing implementation in the device-tree for AM64x
> > is:
> > https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> > It uses:
> > ti,syscon-efuse = <&main_conf 0x200>;
> >
> > and "main_conf" node is defined at:
> > https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
>
> It is quite different than your bindings, so your bindings are incorrect.
Sorry I didn't understand what you mean. The references I have provided
are for existing DTS where "main_conf"/"wkup_conf" (System Controller
nodes) have the compatible "syscon", unlike in AM62p at:
https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
which has the "simple-bus" compatible for the "wkup_conf" node.
Also, shouldn't the device-tree bindings patches be posted first and get
merged before I post the device-tree patches that utilize the
compatible/properties that have been added in the bindings? That is the
reason why I had shared the "DIFF" for the DTS changes that I will be
posting once this patch for the new compatible is accepted.
Regards,
Siddharth.
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-03 6:27 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <aabea385-16e0-4116-a12b-3ce1e06574e3@ti.com>
On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>>>> registers within the System Controller device-tree node. The default MAC
>>>>> Address for the interface corresponding to the first MAC port will be set
>>>>> to the value programmed in the eFuse.
>>>>>
>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>>> ---
>>>>>
>>>>> This patch is based on linux-next tagged next-20240402.
>>>>
>>>> Where is the DTS using it?
>>>
>>> The current implementation in the device-tree for older TI K3 SoCs is as
>>> follows:
>>>
>>> cpsw_port1: port@1 {
>>> reg = <1>;
>>> ti,mac-only;
>>> label = "port1";
>>> phys = <&phy_gmii_sel 1>;
>>> mac-address = [00 00 00 00 00 00];
>>> ti,syscon-efuse = <&wkup_conf 0x200>;
>>> };
>>>
>>> The "ti,syscon-efuse" property passes the reference to the System
>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
>>> within the CTRL_MMR space.
>>
>> Please reference upstream DTS or lore link to patch under review.
>
> An example of the existing implementation in the device-tree for AM64x
> is:
> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> It uses:
> ti,syscon-efuse = <&main_conf 0x200>;
>
> and "main_conf" node is defined at:
> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
It is quite different than your bindings, so your bindings are incorrect.
Please fix them and send when your DTS is ready.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium,pn-swap' property
From: Alexandru Ardelean @ 2024-04-03 6:16 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-kernel, dri-devel, devicetree, adrien.grassein,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, airlied, daniel, maarten.lankhorst, mripard,
tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt,
stefan.eichenberger, francesco.dolcini, marius.muresan,
irina.muresan
In-Reply-To: <20240402-sheet-retread-025759b22faf@spud>
On Tue, Apr 2, 2024 at 9:06 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Tue, Apr 02, 2024 at 01:59:25PM +0300, Alexandru Ardelean wrote:
> > On some HW designs, it's easier for the layout if the P/N pins are swapped.
> > The driver currently has a DT property to do that.
>
> "currently", because 1/2 adds it. bindings patches should precede the
> driver patches in the series, so please swap the patches and remove this
> portion of the description.
ack;
i'll invert the order and remove this;
>
> >
> > This change documents the 'lontium,pn-swap' property.
> >
> > Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
> > ---
> > .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > index 2cef252157985..3a804926b288a 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > @@ -24,6 +24,12 @@ properties:
> > maxItems: 1
> > description: GPIO connected to active high RESET pin.
> >
> > + lontium,pn-swap:
> > + description: Swap the polarities of the P/N pins in software.
> > + On some HW designs, the layout is simplified if the P/N pins
> > + are inverted.
>
> Please explain what configuration of a board would cause these to be
> swapped, rather than why someone might want to configure the board this
> way. I've got no idea what this hardware is actually doing, so this is
> being pulled out of a hat, but I'd expect something like "Some boards
> swap the polarity of the P/N pins, use this property to indicate this to
> software".
ack
if it's fine with you, i'll use your suggested description;
for a broader context, we were using a DSI-HDMI converter [1] from
SomLabs on a different (than SomLabs) board;
and we were not seeing anything on the HDMI-connected display;
as I understand it, some DSI-HDMI bridges support P/N auto-inversion;
this one doesn't AFAICT;
on this DSI-HDMI converter [1], we've noticed that the P/N pins were
inverted from the DSI to the chip (vs what we expected to see)
after changing the register value (for the P/N swap), it worked;
our conclusion was that, the design of the converter (board) was done
as-such, because it made the layout easier
[1] https://wiki.somlabs.com/index.php/SL-MIPI-LVDS-HDMI-CNV-11_Datasheet_and_Pinout
>
> > + type: boolean
>
> The type here should be flag.
ack; i'll change the type
>
> Cheers,
> Conor.
>
> > +
> > ports:
> > $ref: /schemas/graph.yaml#/properties/ports
> >
> > --
> > 2.44.0
> >
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 5:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <4b1380a8-0136-4395-ba42-9bcff2e1bdb0@kernel.org>
On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> > On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>> registers within the System Controller device-tree node. The default MAC
> >>> Address for the interface corresponding to the first MAC port will be set
> >>> to the value programmed in the eFuse.
> >>>
> >>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>> ---
> >>>
> >>> This patch is based on linux-next tagged next-20240402.
> >>
> >> Where is the DTS using it?
> >
> > The current implementation in the device-tree for older TI K3 SoCs is as
> > follows:
> >
> > cpsw_port1: port@1 {
> > reg = <1>;
> > ti,mac-only;
> > label = "port1";
> > phys = <&phy_gmii_sel 1>;
> > mac-address = [00 00 00 00 00 00];
> > ti,syscon-efuse = <&wkup_conf 0x200>;
> > };
> >
> > The "ti,syscon-efuse" property passes the reference to the System
> > Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> > within the CTRL_MMR space.
>
> Please reference upstream DTS or lore link to patch under review.
An example of the existing implementation in the device-tree for AM64x
is:
https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
It uses:
ti,syscon-efuse = <&main_conf 0x200>;
and "main_conf" node is defined at:
https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
Regards,
Siddharth.
^ permalink raw reply
* [PATCH v4 5/7] PCI: dwc: rcar-gen4: Add .ltssm_enable() for other SoC support
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
This driver can reuse other R-Car Gen4 SoCs support like r8a779g0 and
r8a779h0. However, r8a779g0 and r8a779h0 require other initializing
settings that differ than r8a779f0. So, add a new function pointer
.ltssm_enable() for it. No behavior changes.
After applied this patch, probing SoCs by rcar_gen4_pcie_of_match[]
will be changed like below:
- r8a779f0 as "renesas,r8a779f0-pcie" and "renesas,r8a779f0-pcie-ep"
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 41 ++++++++++++++++++---
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index da2821d6efce..e760bcd30c4e 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -48,7 +48,9 @@
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+struct rcar_gen4_pcie;
struct rcar_gen4_pcie_platdata {
+ int (*ltssm_enable)(struct rcar_gen4_pcie *rcar);
enum dw_pcie_device_mode mode;
};
@@ -61,8 +63,8 @@ struct rcar_gen4_pcie {
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
/* Common */
-static void rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar,
- bool enable)
+static void rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar,
+ bool enable)
{
u32 val;
@@ -127,9 +129,13 @@ static int rcar_gen4_pcie_speed_change(struct dw_pcie *dw)
static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
{
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
- int i, changes;
+ int i, changes, ret;
- rcar_gen4_pcie_ltssm_enable(rcar, true);
+ if (rcar->platdata->ltssm_enable) {
+ ret = rcar->platdata->ltssm_enable(rcar);
+ if (ret)
+ return ret;
+ }
/*
* Require direct speed change with retrying here if the link_gen is
@@ -157,7 +163,7 @@ static void rcar_gen4_pcie_stop_link(struct dw_pcie *dw)
{
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
- rcar_gen4_pcie_ltssm_enable(rcar, false);
+ rcar_gen4_pcie_ltssm_control(rcar, false);
}
static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
@@ -504,6 +510,23 @@ static void rcar_gen4_pcie_remove(struct platform_device *pdev)
rcar_gen4_pcie_unprepare(rcar);
}
+static int r8a779f0_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
+{
+ rcar_gen4_pcie_ltssm_control(rcar, true);
+
+ return 0;
+}
+
+static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
+ .ltssm_enable = r8a779f0_pcie_ltssm_enable,
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
+ .ltssm_enable = r8a779f0_pcie_ltssm_enable,
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
.mode = DW_PCIE_RC_TYPE,
};
@@ -513,6 +536,14 @@ static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
};
static const struct of_device_id rcar_gen4_pcie_of_match[] = {
+ {
+ .compatible = "renesas,r8a779f0-pcie",
+ .data = &platdata_r8a779f0_pcie,
+ },
+ {
+ .compatible = "renesas,r8a779f04-pcie-ep",
+ .data = &platdata_r8a779f0_pcie_ep,
+ },
{
.compatible = "renesas,rcar-gen4-pcie",
.data = &platdata_rcar_gen4_pcie,
--
2.25.1
^ permalink raw reply related
* [PATCH v4 7/7] misc: pci_endpoint_test: Document a policy about adding pci_device_id
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Frank Li
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
To avoid becoming struct pci_device_id pci_endpoint_test_tbl longer
and longer, document a policy. For example, if PCIe endpoint controller
can configure vendor id and/or product id, you can reuse one of
existing entries to test.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
Cc: Frank Li <Frank.li@nxp.com>
---
drivers/misc/pci_endpoint_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index c38a6083f0a7..3c8a0afad91d 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -980,6 +980,7 @@ static const struct pci_endpoint_test_data j721e_data = {
.irq_type = IRQ_TYPE_MSI,
};
+/* Don't need to add a new entry if you can use existing entry to test */
static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x),
.driver_data = (kernel_ulong_t)&default_data,
--
2.25.1
^ permalink raw reply related
* [PATCH v4 3/7] PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
R-Car Gen4 PCIe controller needs to use the Synopsys-specific PCIe
configuration registers. So, add the macros.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-designware.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 26dae4837462..aa4db6eaf02a 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -71,6 +71,9 @@
#define LINK_WAIT_IATU 9
/* Synopsys-specific PCIe configuration registers */
+#define PCIE_PORT_FORCE 0x708
+#define PORT_FORCE_DO_DESKEW_FOR_SRIS BIT(23)
+
#define PCIE_PORT_AFR 0x70C
#define PORT_AFR_N_FTS_MASK GENMASK(15, 8)
#define PORT_AFR_N_FTS(n) FIELD_PREP(PORT_AFR_N_FTS_MASK, n)
@@ -92,6 +95,9 @@
#define PORT_LINK_MODE_4_LANES PORT_LINK_MODE(0x7)
#define PORT_LINK_MODE_8_LANES PORT_LINK_MODE(0xf)
+#define PCIE_PORT_LANE_SKEW 0x714
+#define PORT_LANE_SKEW_INSERT_MASK GENMASK(23, 0)
+
#define PCIE_PORT_DEBUG0 0x728
#define PORT_LOGIC_LTSSM_STATE_MASK 0x1f
#define PORT_LOGIC_LTSSM_STATE_L0 0x11
--
2.25.1
^ permalink raw reply related
* [PATCH v4 6/7] PCI: dwc: rcar-gen4: Add support for r8a779g0
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
This driver previously supported r8a779f0 (R-Car S4-8). Add support
for r8a779g0 (R-Car V4H).
To support r8a779g0, it requires specific firmware.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 201 +++++++++++++++++++-
1 file changed, 200 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index e760bcd30c4e..5d5a088bd2c1 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -5,8 +5,10 @@
*/
#include <linux/delay.h>
+#include <linux/firmware.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/pci.h>
@@ -20,9 +22,10 @@
/* Renesas-specific */
/* PCIe Mode Setting Register 0 */
#define PCIEMSR0 0x0000
-#define BIFUR_MOD_SET_ON BIT(0)
+#define APP_SRIS_MODE BIT(6)
#define DEVICE_TYPE_EP 0
#define DEVICE_TYPE_RC BIT(4)
+#define BIFUR_MOD_SET_ON BIT(0)
/* PCIe Interrupt Status 0 */
#define PCIEINTSTS0 0x0084
@@ -37,19 +40,47 @@
#define PCIEDMAINTSTSEN 0x0314
#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
+/* Port Logic Registers 89 */
+#define PRTLGC89 0x0b70
+
+/* Port Logic Registers 90 */
+#define PRTLGC90 0x0b74
+
/* PCIe Reset Control Register 1 */
#define PCIERSTCTRL1 0x0014
#define APP_HOLD_PHY_RST BIT(16)
#define APP_LTSSM_ENABLE BIT(0)
+/* PCIe Power Management Control */
+#define PCIEPWRMNGCTRL 0x0070
+#define APP_CLK_REQ_N BIT(11)
+#define APP_CLK_PM_EN BIT(10)
+
+/*
+ * The R-Car Gen4 documents don't describe the PHY registers' name.
+ * But, the initialization procedure describes these offsets. So,
+ * this driver makes up own #defines for the offsets.
+ */
+#define RCAR_GEN4_PCIE_PHY_0f8 0x0f8
+#define RCAR_GEN4_PCIE_PHY_148 0x148
+#define RCAR_GEN4_PCIE_PHY_1d4 0x1d4
+#define RCAR_GEN4_PCIE_PHY_514 0x514
+#define RCAR_GEN4_PCIE_PHY_700 0x700
+
#define RCAR_NUM_SPEED_CHANGE_RETRIES 10
#define RCAR_MAX_LINK_SPEED 4
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+#define RCAR_GEN4_PCIE_FIRMWARE_NAME "rcar_gen4_pcie.bin"
+#define RCAR_GEN4_PCIE_FIRMWARE_BASE_ADDR 0xc000
+
+MODULE_FIRMWARE(RCAR_GEN4_PCIE_FIRMWARE_NAME);
+
struct rcar_gen4_pcie;
struct rcar_gen4_pcie_platdata {
+ void (*additional_common_init)(struct rcar_gen4_pcie *rcar);
int (*ltssm_enable)(struct rcar_gen4_pcie *rcar);
enum dw_pcie_device_mode mode;
};
@@ -57,12 +88,144 @@ struct rcar_gen4_pcie_platdata {
struct rcar_gen4_pcie {
struct dw_pcie dw;
void __iomem *base;
+ void __iomem *phy_base;
struct platform_device *pdev;
const struct rcar_gen4_pcie_platdata *platdata;
};
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
/* Common */
+static void rcar_gen4_pcie_phy_reg_update_bits(struct rcar_gen4_pcie *rcar,
+ u32 offset, u32 mask, u32 val)
+{
+ u32 tmp;
+
+ tmp = readl(rcar->phy_base + offset);
+ tmp &= ~mask;
+ tmp |= val;
+ writel(tmp, rcar->phy_base + offset);
+}
+
+static int rcar_gen4_pcie_reg_check_bit(struct rcar_gen4_pcie *rcar,
+ u32 offset, u32 mask)
+{
+ struct dw_pcie *dw = &rcar->dw;
+
+ if (dw_pcie_readl_dbi(dw, offset) & mask)
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int rcar_gen4_pcie_update_phy_firmware(struct rcar_gen4_pcie *rcar)
+{
+ const u32 check_addr[] = { 0x00101018, 0x00101118, 0x00101021, 0x00101121};
+ struct dw_pcie *dw = &rcar->dw;
+ const struct firmware *fw;
+ unsigned int i, timeout;
+ u32 data;
+ int ret;
+
+ ret = request_firmware(&fw, RCAR_GEN4_PCIE_FIRMWARE_NAME, dw->dev);
+ if (ret) {
+ dev_err(dw->dev, "%s: Requesting firmware failed\n", __func__);
+ return ret;
+ }
+
+ for (i = 0; i < (fw->size / 2); i++) {
+ data = fw->data[i * 2] | fw->data[(i * 2) + 1] << 8;
+ timeout = 100;
+ do {
+ dw_pcie_writel_dbi(dw, PRTLGC89, RCAR_GEN4_PCIE_FIRMWARE_BASE_ADDR + i);
+ dw_pcie_writel_dbi(dw, PRTLGC90, data);
+ if (rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30)) >= 0)
+ break;
+ if (!(--timeout)) {
+ ret = -ETIMEDOUT;
+ goto exit;
+ }
+ usleep_range(100, 200);
+ } while (1);
+ }
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(17), BIT(17));
+
+ for (i = 0; i < ARRAY_SIZE(check_addr); i++) {
+ timeout = 100;
+ do {
+ dw_pcie_writel_dbi(dw, PRTLGC89, check_addr[i]);
+ ret = rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30));
+ ret |= rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC90, BIT(0));
+ if (ret >= 0)
+ break;
+ if (!(--timeout)) {
+ ret = -ETIMEDOUT;
+ goto exit;
+ }
+ usleep_range(100, 200);
+ } while (1);
+ }
+
+ ret = 0;
+exit:
+ release_firmware(fw);
+
+ return ret;
+}
+
+static int rcar_gen4_pcie_enable_phy(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+ u32 val;
+ int ret;
+
+ val = dw_pcie_readl_dbi(dw, PCIE_PORT_FORCE);
+ val |= PORT_FORCE_DO_DESKEW_FOR_SRIS;
+ dw_pcie_writel_dbi(dw, PCIE_PORT_FORCE, val);
+
+ val = readl(rcar->base + PCIEMSR0);
+ val |= APP_SRIS_MODE;
+ writel(val, rcar->base + PCIEMSR0);
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(28), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(20), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(12), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(4), 0);
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(23, 22), BIT(22));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(18, 16), GENMASK(17, 16));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(7, 6), BIT(6));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(2, 0), GENMASK(11, 0));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_1d4,
+ GENMASK(16, 15), GENMASK(16, 15));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_514, BIT(26), BIT(26));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(16), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(19), BIT(19));
+
+ val = readl(rcar->base + PCIERSTCTRL1);
+ val &= ~APP_HOLD_PHY_RST;
+ writel(val, rcar->base + PCIERSTCTRL1);
+
+ ret = readl_poll_timeout(rcar->phy_base + RCAR_GEN4_PCIE_PHY_0f8, val,
+ !(val & BIT(18)), 100, 10000);
+ if (ret < 0)
+ return ret;
+
+ ret = rcar_gen4_pcie_update_phy_firmware(rcar);
+ if (ret)
+ return ret;
+
+ val = readl(rcar->base + PCIERSTCTRL1);
+ val |= APP_LTSSM_ENABLE;
+ writel(val, rcar->base + PCIERSTCTRL1);
+
+ return 0;
+}
+
static void rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar,
bool enable)
{
@@ -200,6 +363,9 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
if (ret)
goto err_unprepare;
+ if (rcar->platdata->additional_common_init)
+ rcar->platdata->additional_common_init(rcar);
+
return 0;
err_unprepare:
@@ -241,6 +407,10 @@ static void rcar_gen4_pcie_unprepare(struct rcar_gen4_pcie *rcar)
static int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
{
+ rcar->phy_base = devm_platform_ioremap_resource_byname(rcar->pdev, "phy");
+ if (IS_ERR(rcar->phy_base))
+ return PTR_ERR(rcar->base);
+
/* Renesas-specific registers */
rcar->base = devm_platform_ioremap_resource_byname(rcar->pdev, "app");
@@ -517,6 +687,31 @@ static int r8a779f0_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
return 0;
}
+static void rcar_gen4_pcie_additional_common_init(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+ u32 val;
+
+ /*
+ * The SoC manual said the register setting is required. Otherwise,
+ * linkup failed.
+ */
+ val = dw_pcie_readl_dbi(dw, PCIE_PORT_LANE_SKEW);
+ val &= ~PORT_LANE_SKEW_INSERT_MASK;
+ if (dw->num_lanes < 4)
+ val |= BIT(6);
+ dw_pcie_writel_dbi(dw, PCIE_PORT_LANE_SKEW, val);
+
+ val = readl(rcar->base + PCIEPWRMNGCTRL);
+ val |= APP_CLK_REQ_N | APP_CLK_PM_EN;
+ writel(val, rcar->base + PCIEPWRMNGCTRL);
+}
+
+static int rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
+{
+ return rcar_gen4_pcie_enable_phy(rcar);
+}
+
static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
.ltssm_enable = r8a779f0_pcie_ltssm_enable,
.mode = DW_PCIE_RC_TYPE,
@@ -528,10 +723,14 @@ static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
};
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
+ .additional_common_init = rcar_gen4_pcie_additional_common_init,
+ .ltssm_enable = rcar_gen4_pcie_ltssm_enable,
.mode = DW_PCIE_RC_TYPE,
};
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
+ .additional_common_init = rcar_gen4_pcie_additional_common_init,
+ .ltssm_enable = rcar_gen4_pcie_ltssm_enable,
.mode = DW_PCIE_EP_TYPE,
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 2/7] dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
From: Yoshihiro Shimoda @ 2024-04-03 5:32 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Conor Dooley, Geert Uytterhoeven
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
Document bindings for R-Car V4H (R8A779G0) PCIe endpoint module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
index fe38f62da066..91b81ac75592 100644
--- a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
@@ -16,7 +16,9 @@ allOf:
properties:
compatible:
items:
- - const: renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - enum:
+ - renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - renesas,r8a779g0-pcie-ep # R-Car V4H
- const: renesas,rcar-gen4-pcie-ep # R-Car Gen4
reg:
--
2.25.1
^ permalink raw reply related
* [PATCH v4 4/7] PCI: dwc: rcar-gen4: Add rcar_gen4_pcie_platdata
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
This driver supports r8a779f0 now. In the future, add support for
r8a779g0 and r8a779h0. To support these new SoCs, need other
initializing settings. So, at first, add rcar_gen4_pcie_platdata
and have a member with mode. No behavior changes.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 30 ++++++++++++++-------
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 0be760ed420b..da2821d6efce 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -48,11 +48,15 @@
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+struct rcar_gen4_pcie_platdata {
+ enum dw_pcie_device_mode mode;
+};
+
struct rcar_gen4_pcie {
struct dw_pcie dw;
void __iomem *base;
struct platform_device *pdev;
- enum dw_pcie_device_mode mode;
+ const struct rcar_gen4_pcie_platdata *platdata;
};
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
@@ -137,7 +141,7 @@ static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
* Since dw_pcie_setup_rc() sets it once, PCIe Gen2 will be trained.
* So, this needs remaining times for up to PCIe Gen4 if RC mode.
*/
- if (changes && rcar->mode == DW_PCIE_RC_TYPE)
+ if (changes && rcar->platdata->mode == DW_PCIE_RC_TYPE)
changes--;
for (i = 0; i < changes; i++) {
@@ -172,9 +176,9 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
reset_control_assert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
val = readl(rcar->base + PCIEMSR0);
- if (rcar->mode == DW_PCIE_RC_TYPE) {
+ if (rcar->platdata->mode == DW_PCIE_RC_TYPE) {
val |= DEVICE_TYPE_RC;
- } else if (rcar->mode == DW_PCIE_EP_TYPE) {
+ } else if (rcar->platdata->mode == DW_PCIE_EP_TYPE) {
val |= DEVICE_TYPE_EP;
} else {
ret = -EINVAL;
@@ -437,9 +441,9 @@ static void rcar_gen4_remove_dw_pcie_ep(struct rcar_gen4_pcie *rcar)
/* Common */
static int rcar_gen4_add_dw_pcie(struct rcar_gen4_pcie *rcar)
{
- rcar->mode = (uintptr_t)of_device_get_match_data(&rcar->pdev->dev);
+ rcar->platdata = of_device_get_match_data(&rcar->pdev->dev);
- switch (rcar->mode) {
+ switch (rcar->platdata->mode) {
case DW_PCIE_RC_TYPE:
return rcar_gen4_add_dw_pcie_rp(rcar);
case DW_PCIE_EP_TYPE:
@@ -480,7 +484,7 @@ static int rcar_gen4_pcie_probe(struct platform_device *pdev)
static void rcar_gen4_remove_dw_pcie(struct rcar_gen4_pcie *rcar)
{
- switch (rcar->mode) {
+ switch (rcar->platdata->mode) {
case DW_PCIE_RC_TYPE:
rcar_gen4_remove_dw_pcie_rp(rcar);
break;
@@ -500,14 +504,22 @@ static void rcar_gen4_pcie_remove(struct platform_device *pdev)
rcar_gen4_pcie_unprepare(rcar);
}
+static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static const struct of_device_id rcar_gen4_pcie_of_match[] = {
{
.compatible = "renesas,rcar-gen4-pcie",
- .data = (void *)DW_PCIE_RC_TYPE,
+ .data = &platdata_rcar_gen4_pcie,
},
{
.compatible = "renesas,rcar-gen4-pcie-ep",
- .data = (void *)DW_PCIE_EP_TYPE,
+ .data = &platdata_rcar_gen4_pcie_ep,
},
{},
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 1/7] dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
From: Yoshihiro Shimoda @ 2024-04-03 5:32 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Conor Dooley, Geert Uytterhoeven
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
Document bindings for R-Car V4H (R8A779G0) PCIe host module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
index ffb34339b637..955c664f1fbb 100644
--- a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
@@ -16,7 +16,9 @@ allOf:
properties:
compatible:
items:
- - const: renesas,r8a779f0-pcie # R-Car S4-8
+ - enum:
+ - renesas,r8a779f0-pcie # R-Car S4-8
+ - renesas,r8a779g0-pcie # R-Car V4H
- const: renesas,rcar-gen4-pcie # R-Car Gen4
reg:
--
2.25.1
^ permalink raw reply related
* [PATCH v4 0/7] PCI: dwc: rcar-gen4: Add R-Car V4H support
From: Yoshihiro Shimoda @ 2024-04-03 5:32 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
The pcie-rcar-gen4 driver can reuse other R-Car Gen4 support like
r8a779g0 (R-Car V4H) and r8a779h0 (R-Car V4M). However, some
initializing settings differ between R-Car S4-8 (r8a779f0) and
others. The R-Car S4-8 will be minority about the setting way. So,
R-Car V4H will be majority and this is generic initialization way
as "renesas,rcar-gen4-pcie{-ep}" compatible. For now, I tested
both R-Car S4-8 and R-Car V4H on this driver. I'll support one more
other SoC (R-Car V4M) in the future.
Changes from v3:
https://lore.kernel.org/linux-pci/20240401023942.134704-1-yoshihiro.shimoda.uh@renesas.com/
- Modify the code to use "do .. while" instead of goto in patch 6/7.
Changes from v2:
https://lore.kernel.org/linux-pci/20240326024540.2336155-1-yoshihiro.shimoda.uh@renesas.com/
- Add a new patch which just add a platdata in patch 4/7.
- Modify the subjects in patch [56]/7.
- Modify the description and code about Bjorn's comment in patch [56]/7.
- Add missing MODULE_FIRMWARE(9 in patch 6/7.
- Document a policy aboud adding pci_device_id instead of adding r8a779g0's id
in patch 7/7.
Changes from v1:
https://lore.kernel.org/linux-pci/20240229120719.2553638-1-yoshihiro.shimoda.uh@renesas.com/
- Based on v6.9-rc1.
- Add Acked-by and/or Reviewed-by in patch [126/6].
Yoshihiro Shimoda (7):
dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
PCI: dwc: rcar-gen4: Add rcar_gen4_pcie_platdata
PCI: dwc: rcar-gen4: Add .ltssm_enable() for other SoC support
PCI: dwc: rcar-gen4: Add support for r8a779g0
misc: pci_endpoint_test: Document a policy about adding pci_device_id
.../bindings/pci/rcar-gen4-pci-ep.yaml | 4 +-
.../bindings/pci/rcar-gen4-pci-host.yaml | 4 +-
drivers/misc/pci_endpoint_test.c | 1 +
drivers/pci/controller/dwc/pcie-designware.h | 6 +
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 272 +++++++++++++++++-
5 files changed, 270 insertions(+), 17 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v8 1/3] input: pm8xxx-vibrator: refactor to support new SPMI vibrator
From: Fenglin Wu @ 2024-04-03 5:29 UTC (permalink / raw)
To: Konrad Dybcio, kernel, Andy Gross, Bjorn Andersson,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree
In-Reply-To: <21641459-d7c0-412d-8244-6f2f2c458551@linaro.org>
On 4/2/2024 11:21 PM, Konrad Dybcio wrote:
> On 1.04.2024 10:38 AM, Fenglin Wu via B4 Relay wrote:
>> From: Fenglin Wu <quic_fenglinw@quicinc.com>
>>
>> Currently, vibrator control register addresses are hard coded,
>> including the base address and offsets, it's not flexible to
>> support new SPMI vibrator module which is usually included in
>> different PMICs with different base address. Refactor it by using
>> the base address defined in devicetree.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>
> [...]
>
>> if (regs->enable_mask)
>> - rc = regmap_update_bits(vib->regmap, regs->enable_addr,
>> + rc = regmap_update_bits(vib->regmap, vib->enable_addr,
>> regs->enable_mask, on ? ~0 : 0);
>
> The idiomatic way across the kernel seems to be writing the mask value
> instead of ~0 (which also saves like 2 cpu instructions)
>
>
> Not sure about how ssbi addressing works, but except for that lgtm
>
Agree.
SSBI driver doesn't provide reg_update_bits function call so similar
mathematics is done on the value before writing to the register, I can
update it to use enable_mask directly in next version.
> Konrad
^ permalink raw reply
* Re: [PATCH v18 2/9] usb: dwc3: core: Access XHCI address space temporarily to read port info
From: Krishna Kurapati PSSNV @ 2024-04-03 5:24 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Felipe Balbi,
Johan Hovold, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_ppratap@quicinc.com,
quic_jackp@quicinc.com, Johan Hovold
In-Reply-To: <20240402233218.5kngtj56qellnrmo@synopsys.com>
On 4/3/2024 5:02 AM, Thinh Nguyen wrote:
> On Tue, Mar 26, 2024, Krishna Kurapati wrote:
>> All DWC3 Multi Port controllers that exist today only support host mode.
>> Temporarily map XHCI address space for host-only controllers and parse
>> XHCI Extended Capabilities registers to read number of usb2 ports and
>> usb3 ports present on multiport controller. Each USB Port is at least HS
>> capable.
>>
>> The port info for usb2 and usb3 phy are identified as num_usb2_ports
>> and num_usb3_ports. The intention is as follows:
>>
>> Wherever we need to perform phy operations like:
>>
>> LOOP_OVER_NUMBER_OF_AVAILABLE_PORTS()
>> {
>> phy_set_mode(dwc->usb2_generic_phy[i], PHY_MODE_USB_HOST);
>> phy_set_mode(dwc->usb3_generic_phy[i], PHY_MODE_USB_HOST);
>> }
>>
>> If number of usb2 ports is 3, loop can go from index 0-2 for
>> usb2_generic_phy. If number of usb3-ports is 2, we don't know for sure,
>> if the first 2 ports are SS capable or some other ports like (2 and 3)
>> are SS capable. So instead, num_usb2_ports is used to loop around all
>> phy's (both hs and ss) for performing phy operations. If any
>> usb3_generic_phy turns out to be NULL, phy operation just bails out.
>> num_usb3_ports is used to modify GUSB3PIPECTL registers while setting up
>> phy's as we need to know how many SS capable ports are there for this.
>>
>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
>> ---
>> drivers/usb/dwc3/core.c | 61 +++++++++++++++++++++++++++++++++++++++++
>> drivers/usb/dwc3/core.h | 5 ++++
>> 2 files changed, 66 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 3e55838c0001..fab7664c12c0 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -39,6 +39,7 @@
>> #include "io.h"
>>
>> #include "debug.h"
>> +#include "../host/xhci-ext-caps.h"
>>
>> #define DWC3_DEFAULT_AUTOSUSPEND_DELAY 5000 /* ms */
>>
>> @@ -1879,10 +1880,56 @@ static int dwc3_get_clocks(struct dwc3 *dwc)
>> return 0;
>> }
>>
>> +static int dwc3_read_port_info(struct dwc3 *dwc)
>> +{
>> + void __iomem *base;
>> + u8 major_revision;
>> + u32 offset;
>> + u32 val;
>> +
>> + /*
>> + * Remap xHCI address space to access XHCI ext cap regs since it is
>> + * needed to get information on number of ports present.
>> + */
>> + base = ioremap(dwc->xhci_resources[0].start,
>> + resource_size(&dwc->xhci_resources[0]));
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>
> Looks like you forgot to address some of the comments you said you'd
> update previously if you submit a new version to the series.
>
> [*] https://lore.kernel.org/linux-usb/af73110d-e13e-4183-af11-aed869ac0a31@quicinc.com/
>
Apologies. I agree. I was too much focused on acpi removal and interrupt
cleanup, I forgot the last comment you gave.
Can I send in a separate patch for this ?
Regards,
Krishna,
^ permalink raw reply
* RE: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY binding
From: Hongxing Zhu @ 2024-04-03 5:16 UTC (permalink / raw)
To: Conor Dooley, Frank Li
Cc: vkoul@kernel.org, kishon@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
imx@lists.linux.dev
In-Reply-To: <20240402-anemic-aerospace-bc428fff280c@spud>
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: 2024年4月3日 2:17
> To: Frank Li <frank.li@nxp.com>
> Cc: Hongxing Zhu <hongxing.zhu@nxp.com>; vkoul@kernel.org;
> kishon@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> conor+dt@kernel.org; linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; imx@lists.linux.dev
> Subject: Re: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY
> binding
>
> On Tue, Apr 02, 2024 at 10:23:45AM -0400, Frank Li wrote:
> > On Tue, Apr 02, 2024 at 01:45:03PM +0800, Richard Zhu wrote:
> > > Add i.MX8QM and i.MX8QXP HSIO SerDes PHY binding.
> > > - Use the controller ID to specify which controller is binded to the
> > > PHY.
> > > - Introduce one HSIO configuration, mandatory required to set
> > > "PCIE_AB_SELECT" and "PHY_X1_EPCS_SEL" during the initialization.
> > >
> > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> >
> > You missed all conor's comments.
> > Please double check v1's comments.
>
Hi Frank:
Thanks a lot for your reminder.
It's my fault that I missed this email.
> > > + fsl,refclk-pad-mode:
> > > + description: |
> > > + Specifies the mode of the refclk pad used. It can be UNUSED(PHY
> > > + refclock is derived from SoC internal source), INPUT(PHY refclock
> > > + is provided externally via the refclk pad) or OUTPUT(PHY refclock
> > > + is derived from SoC internal source and provided on the refclk pad).
> > > + Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
> > > + to be used.
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + enum: [ 0, 1, 2 ]
> >
> > I remember needn't enum because there are header file.
>
> Yah, specifically my comments about this property were missed and were
> probably the most meaningful comments I left.
Hi Conor:
I'm so sorry about it.
I made the mistake missing your last review email.
Would follow your comments in next review cycle.
Best Regards
Richard Zhu
>
> Thanks for the reminder Frank.
^ permalink raw reply
* Re: [PATCH 1/7] arm64: dts: imx8-ss-lsio: fix pwm lpcg indices
From: Shawn Guo @ 2024-04-03 4:44 UTC (permalink / raw)
To: Frank Li
Cc: Fabio Estevam, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, NXP Linux Team,
Marcel Ziswiler, Philippe Schenker, Max Krummenacher,
Alexander Stein, Joakim Zhang, devicetree, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <ZgzIjziArPh8wnHA@lizhi-Precision-Tower-5810>
On Tue, Apr 02, 2024 at 11:10:07PM -0400, Frank Li wrote:
> On Wed, Apr 03, 2024 at 09:41:26AM +0800, Shawn Guo wrote:
> > On Tue, Apr 02, 2024 at 11:09:17AM -0400, Frank Li wrote:
> > > On Mon, Apr 01, 2024 at 08:04:56PM -0300, Fabio Estevam wrote:
> > > > On Mon, Apr 1, 2024 at 7:25 PM Frank Li <Frank.Li@nxp.com> wrote:
> > > > >
> > > > > lpcg's arg0 should use clock indices instead of index.
> > > > >
> > > > > pwm0_lpcg: clock-controller@5d400000 {
> > > > > ... // Col1 Col2
> > > > > clocks = <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>, // 0 0
> > > > > <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>, // 1 1
> > > > > <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>, // 2 4
> > > > > <&lsio_bus_clk>, // 3 5
> > > > > <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>; // 4 6
> > > > > clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
> > > > > <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
> > > > > <IMX_LPCG_CLK_6>;
> > > > > };
> > > > >
> > > > > Col1: index, which exited dts try to get.
> > > >
> > > > I cannot understand this sentence, sorry.
> > >
> > > This base on downstream dts code. Downstream code use index in 'Col1' to
> > > get clock.
> >
> > So s/exited/existing you meant?
>
> Yes, sorry for typo.
I fixed the typo and applied the series, thanks!
Shawn
^ permalink raw reply
* [PATCH v5 3/3] arm64: dts: qcom: apq8016: Add Schneider HMIBSC board DTS
From: Sumit Garg @ 2024-04-03 4:34 UTC (permalink / raw)
To: linux-arm-msm, devicetree
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, stephan, caleb.connolly, neil.armstrong,
dmitry.baryshkov, laetitia.mariottini, pascal.eberhard,
abdou.saker, jimmy.lalande, benjamin.missey, daniel.thompson,
linux-kernel, Sumit Garg, Jagdish Gediya
In-Reply-To: <20240403043416.3800259-1-sumit.garg@linaro.org>
Add Schneider Electric HMIBSC board DTS. The HMIBSC board is an IIoT Edge
Box Core board based on the Qualcomm APQ8016E SoC.
Support for Schneider Electric HMIBSC. Features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 1GiB RAM
- 8GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI
- USB ethernet adaptors (soldered)
Co-developed-by: Jagdish Gediya <jagdish.gediya@linaro.org>
Signed-off-by: Jagdish Gediya <jagdish.gediya@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/apq8016-schneider-hmibsc.dts | 491 ++++++++++++++++++
2 files changed, 492 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 39889d5f8e12..ad55e52e950b 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -5,6 +5,7 @@ apq8016-sbc-usb-host-dtbs := apq8016-sbc.dtb apq8016-sbc-usb-host.dtbo
dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-usb-host.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3-camera-mezzanine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += apq8016-schneider-hmibsc.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8039-t2.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8094-sony-xperia-kitakami-karin_windy.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
diff --git a/arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts b/arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
new file mode 100644
index 000000000000..75c6137e5a11
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include "msm8916-pm8916.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/pinctrl/qcom,pmic-mpp.h>
+#include <dt-bindings/sound/apq8016-lpass.h>
+
+/ {
+ model = "Schneider Electric HMIBSC Board";
+ compatible = "schneider,apq8016-hmibsc", "qcom,apq8016";
+
+ aliases {
+ i2c1 = &blsp_i2c6;
+ i2c3 = &blsp_i2c4;
+ i2c4 = &blsp_i2c3;
+ mmc0 = &sdhc_1; /* eMMC */
+ mmc1 = &sdhc_2; /* SD card */
+ serial0 = &blsp_uart1;
+ serial1 = &blsp_uart2;
+ spi0 = &blsp_spi5;
+ usid0 = &pm8916_0;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7533_out>;
+ };
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-0 = <&msm_key_volp_n_default>;
+ pinctrl-names = "default";
+
+ button {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ gpios = <&tlmm 107 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pm8916_mpps_leds>;
+ pinctrl-names = "default";
+
+ led-1 {
+ function = LED_FUNCTION_WLAN;
+ color = <LED_COLOR_ID_YELLOW>;
+ gpios = <&pm8916_mpps 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "phy0tx";
+ default-state = "off";
+ };
+
+ led-2 {
+ function = LED_FUNCTION_BLUETOOTH;
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pm8916_mpps 3 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "bluetooth-power";
+ default-state = "off";
+ };
+ };
+
+ memory@80000000 {
+ reg = <0 0x80000000 0 0x40000000>;
+ };
+
+ reserved-memory {
+ ramoops@bff00000 {
+ compatible = "ramoops";
+ reg = <0x0 0xbff00000 0x0 0x100000>;
+ record-size = <0x20000>;
+ console-size = <0x20000>;
+ ftrace-size = <0x20000>;
+ ecc-size = <16>;
+ };
+ };
+
+ usb-hub {
+ compatible = "smsc,usb3503";
+ reset-gpios = <&pm8916_gpios 1 GPIO_ACTIVE_LOW>;
+ initial-mode = <1>;
+ };
+
+ usb_id: usb-id {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&usb_id_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&blsp_i2c3 {
+ status = "okay";
+
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+};
+
+&blsp_i2c4 {
+ status = "okay";
+
+ adv_bridge: bridge@39 {
+ compatible = "adi,adv7533";
+ reg = <0x39>;
+ interrupts-extended = <&tlmm 31 IRQ_TYPE_EDGE_FALLING>;
+
+ adi,dsi-lanes = <4>;
+ clocks = <&rpmcc RPM_SMD_BB_CLK2>;
+ clock-names = "cec";
+ pd-gpios = <&tlmm 32 GPIO_ACTIVE_HIGH>;
+
+ avdd-supply = <&pm8916_l6>;
+ a2vdd-supply = <&pm8916_l6>;
+ dvdd-supply = <&pm8916_l6>;
+ pvdd-supply = <&pm8916_l6>;
+ v1p2-supply = <&pm8916_l6>;
+ v3p3-supply = <&pm8916_l17>;
+
+ pinctrl-0 = <&adv7533_int_active &adv7533_switch_active>;
+ pinctrl-1 = <&adv7533_int_suspend &adv7533_switch_suspend>;
+ pinctrl-names = "default","sleep";
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7533_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7533_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&blsp_i2c6 {
+ status = "okay";
+
+ rtc@30 {
+ compatible = "sii,s35390a";
+ reg = <0x30>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ };
+};
+
+&blsp_spi5 {
+ cs-gpios = <&tlmm 18 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ tpm@0 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <0>;
+ spi-max-frequency = <500000>;
+ };
+};
+
+&blsp_uart1 {
+ label = "UART0";
+ status = "okay";
+};
+
+&blsp_uart2 {
+ label = "UART1";
+ status = "okay";
+};
+
+&lpass {
+ status = "okay";
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&adv7533_in>;
+};
+
+&pm8916_codec {
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+ status = "okay";
+};
+
+&pm8916_gpios {
+ gpio-line-names =
+ "USB_HUB_RESET_N_PM",
+ "USB_SW_SEL_PM",
+ "NC",
+ "NC";
+
+ usb_hub_reset_pm: usb-hub-reset-pm-state {
+ pins = "gpio1";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ input-disable;
+ output-high;
+ };
+
+ usb_hub_reset_pm_device: usb-hub-reset-pm-device-state {
+ pins = "gpio1";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ input-disable;
+ output-low;
+ };
+
+ usb_sw_sel_pm: usb-sw-sel-pm-state {
+ pins = "gpio2";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ power-source = <PM8916_GPIO_VPH>;
+ input-disable;
+ output-high;
+ };
+
+ usb_sw_sel_pm_device: usb-sw-sel-pm-device-state {
+ pins = "gpio2";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ power-source = <PM8916_GPIO_VPH>;
+ input-disable;
+ output-low;
+ };
+};
+
+&pm8916_mpps {
+ gpio-line-names =
+ "NC",
+ "WLAN_LED_CTRL",
+ "BT_LED_CTRL",
+ "NC";
+
+ pm8916_mpps_leds: pm8916-mpps-state {
+ pins = "mpp2", "mpp3";
+ function = "digital";
+ output-low;
+ };
+};
+
+&pm8916_resin {
+ linux,code = <KEY_POWER>;
+ status = "okay";
+};
+
+&pm8916_rpm_regulators {
+ pm8916_l17: l17 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&sdhc_1 {
+ status = "okay";
+};
+
+&sdhc_2 {
+ pinctrl-0 = <&sdc2_default &sdc2_cd_default>;
+ pinctrl-1 = <&sdc2_sleep &sdc2_cd_default>;
+ pinctrl-names = "default", "sleep";
+ cd-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&sound {
+ pinctrl-0 = <&cdc_pdm_default &sec_mi2s_default>;
+ pinctrl-1 = <&cdc_pdm_sleep &sec_mi2s_sleep>;
+ pinctrl-names = "default", "sleep";
+ model = "HMIBSC";
+ audio-routing =
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+ status = "okay";
+
+ quaternary-dai-link {
+ link-name = "ADV7533";
+ cpu {
+ sound-dai = <&lpass MI2S_QUATERNARY>;
+ };
+ codec {
+ sound-dai = <&adv_bridge 0>;
+ };
+ };
+
+ primary-dai-link {
+ link-name = "WCD";
+ cpu {
+ sound-dai = <&lpass MI2S_PRIMARY>;
+ };
+ codec {
+ sound-dai = <&lpass_codec 0>, <&pm8916_codec 0>;
+ };
+ };
+
+ tertiary-dai-link {
+ link-name = "WCD-Capture";
+ cpu {
+ sound-dai = <&lpass MI2S_TERTIARY>;
+ };
+ codec {
+ sound-dai = <&lpass_codec 1>, <&pm8916_codec 1>;
+ };
+ };
+};
+
+&tlmm {
+ pinctrl-0 = <&uart1_mux0_rs232_high &uart1_mux1_rs232_low>;
+ pinctrl-names = "default";
+
+ adv7533_int_active: adv533-int-active-state {
+ pins = "gpio31";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ adv7533_int_suspend: adv7533-int-suspend-state {
+ pins = "gpio31";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ adv7533_switch_active: adv7533-switch-active-state {
+ pins = "gpio32";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ adv7533_switch_suspend: adv7533-switch-suspend-state {
+ pins = "gpio32";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ msm_key_volp_n_default: msm-key-volp-n-default-state {
+ pins = "gpio107";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ sdc2_cd_default: sdc2-cd-default-state {
+ pins = "gpio38";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ /*
+ * UART1 being the debug console supports various modes of
+ * operation (RS-232/485/422) controlled via GPIOs configured
+ * mux as follows:
+ *
+ * gpio100 gpio99 UART mode
+ * 0 0 loopback
+ * 0 1 RS-232
+ * 1 0 RS-485
+ * 1 1 RS-422
+ *
+ * The default mode configured here is RS-232 mode.
+ */
+ uart1_mux0_rs232_high: uart1-mux0-rs232-state {
+ bootph-all;
+ pins = "gpio99";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+
+ uart1_mux1_rs232_low: uart1-mux1-rs232-state {
+ bootph-all;
+ pins = "gpio100";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ output-low;
+ };
+
+ usb_id_default: usb-id-default-state {
+ pins = "gpio110";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+};
+
+&usb {
+ extcon = <&usb_id>, <&usb_id>;
+ pinctrl-0 = <&usb_sw_sel_pm &usb_hub_reset_pm>;
+ pinctrl-1 = <&usb_sw_sel_pm_device &usb_hub_reset_pm_device>;
+ pinctrl-names = "default", "device";
+ status = "okay";
+};
+
+&usb_hs_phy {
+ extcon = <&usb_id>;
+};
+
+&wcnss {
+ firmware-name = "qcom/apq8016/wcnss.mbn";
+ status = "okay";
+};
+
+&wcnss_ctrl {
+ firmware-name = "qcom/apq8016/WCNSS_qcom_wlan_nv_sbc.bin";
+};
+
+&wcnss_iris {
+ compatible = "qcom,wcn3620";
+};
+
+&wcnss_mem {
+ status = "okay";
+};
+
+/* PINCTRL - additions to nodes defined in msm8916.dtsi */
+
+/*
+ * 2mA drive strength is not enough when connecting multiple
+ * I2C devices with different pull up resistors.
+ */
+&blsp_i2c4_default {
+ drive-strength = <16>;
+};
+
+&blsp_i2c6_default {
+ drive-strength = <16>;
+};
+
+&blsp_uart1_default {
+ bootph-all;
+};
+
+/* Enable CoreSight */
+&cti0 { status = "okay"; };
+&cti1 { status = "okay"; };
+&cti12 { status = "okay"; };
+&cti13 { status = "okay"; };
+&cti14 { status = "okay"; };
+&cti15 { status = "okay"; };
+&debug0 { status = "okay"; };
+&debug1 { status = "okay"; };
+&debug2 { status = "okay"; };
+&debug3 { status = "okay"; };
+&etf { status = "okay"; };
+&etm0 { status = "okay"; };
+&etm1 { status = "okay"; };
+&etm2 { status = "okay"; };
+&etm3 { status = "okay"; };
+&etr { status = "okay"; };
+&funnel0 { status = "okay"; };
+&funnel1 { status = "okay"; };
+&replicator { status = "okay"; };
+&stm { status = "okay"; };
+&tpiu { status = "okay"; };
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/3] dt-bindings: arm: qcom: Add Schneider Electric HMIBSC board
From: Sumit Garg @ 2024-04-03 4:34 UTC (permalink / raw)
To: linux-arm-msm, devicetree
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, stephan, caleb.connolly, neil.armstrong,
dmitry.baryshkov, laetitia.mariottini, pascal.eberhard,
abdou.saker, jimmy.lalande, benjamin.missey, daniel.thompson,
linux-kernel, Sumit Garg, Krzysztof Kozlowski
In-Reply-To: <20240403043416.3800259-1-sumit.garg@linaro.org>
Document the compatible for the Schneider Electric HMIBSC IIoT edge box
core board based on the Qualcomm APQ8016E SoC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 1a5fb889a444..c8c91754fe04 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -137,6 +137,7 @@ properties:
- items:
- enum:
- qcom,apq8016-sbc
+ - schneider,apq8016-hmibsc
- const: qcom,apq8016
- items:
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: vendor-prefixes: Add Schneider Electric
From: Sumit Garg @ 2024-04-03 4:34 UTC (permalink / raw)
To: linux-arm-msm, devicetree
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, stephan, caleb.connolly, neil.armstrong,
dmitry.baryshkov, laetitia.mariottini, pascal.eberhard,
abdou.saker, jimmy.lalande, benjamin.missey, daniel.thompson,
linux-kernel, Sumit Garg, Krzysztof Kozlowski
In-Reply-To: <20240403043416.3800259-1-sumit.garg@linaro.org>
Add vendor prefix for Schneider Electric (https://www.se.com/).
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 1a0dc04f1db4..4ef38573e411 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1211,6 +1211,8 @@ patternProperties:
description: Smart Battery System
"^schindler,.*":
description: Schindler
+ "^schneider,.*":
+ description: Schneider Electric
"^seagate,.*":
description: Seagate Technology PLC
"^seeed,.*":
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/3] arm64: dts: qcom: apq8016: Add Schneider HMIBSC board DTS
From: Sumit Garg @ 2024-04-03 4:34 UTC (permalink / raw)
To: linux-arm-msm, devicetree
Cc: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, stephan, caleb.connolly, neil.armstrong,
dmitry.baryshkov, laetitia.mariottini, pascal.eberhard,
abdou.saker, jimmy.lalande, benjamin.missey, daniel.thompson,
linux-kernel, Sumit Garg
Add Schneider Electric HMIBSC board DTS. The HMIBSC board is an IIoT Edge
Box Core board based on the Qualcomm APQ8016E SoC. For more information
refer to the product page [1].
One of the major difference from db410c is serial port where HMIBSC board
uses UART1 as the debug console with a default RS232 mode (UART1 mode mux
configured via gpio99 and gpio100).
Support for Schneider Electric HMIBSC. Features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 1GiB RAM
- 8GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI
- USB ethernet adaptors (soldered)
This series is a v2 since v1 of this DTS file has been reviewed on the
U-Boot mailing list [2].
Changes in v5:
- Addressed another nitpick from Stephen.
- Collected Stephen's review tag.
- Warnings reported by Rob's DT check bot aren't related to HMIBSC
board DTS but rather they are due to msm8916.dtsi or extcon-usb-gpio.txt
still not converted to YAML format.
Changes in v4:
- Dropped IRQ_TYPE_EDGE_FALLING for pm8916_resin given the expectations
of Linux kernel driver. Instead depend on systemd workaround suggested
by Caleb to get expected HMIBSC reset behaviour.
- Incorporated further DT coding style comments from Stephen.
- Warnings reported by Rob's DT check bot aren't related to HMIBSC
board DTS but rather they are due to msm8916.dtsi or extcon-usb-gpio.txt
still not converted to YAML format.
Changes in v3:
- Picked up tags.
- Fixed further DT schema warnings.
- Configure resin/power button interrupt as falling edge.
- Incorporate DTS coding style comments from Krzysztof and Konrad.
Changes in v2:
- Fix DT schema warnings.
- Incorporate suggestions from Stephan.
- Document UART1 mode GPIOs based mux.
[1] https://www.se.com/us/en/product/HMIBSCEA53D1L0T/iiot-edge-box-core-harmony-ipc-emmc-dc-linux-tpm/
[2] https://patchwork.ozlabs.org/project/uboot/patch/20240311111027.44577-6-sumit.garg@linaro.org/
Sumit Garg (3):
dt-bindings: vendor-prefixes: Add Schneider Electric
dt-bindings: arm: qcom: Add Schneider Electric HMIBSC board
arm64: dts: qcom: apq8016: Add Schneider HMIBSC board DTS
.../devicetree/bindings/arm/qcom.yaml | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/apq8016-schneider-hmibsc.dts | 491 ++++++++++++++++++
4 files changed, 495 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
--
2.34.1
^ permalink raw reply
* Re: [PATCH v1 2/2] media: i2c: Add GC05A2 image sensor driver
From: Zhi Mao (毛智) @ 2024-04-03 4:24 UTC (permalink / raw)
To: sakari.ailus@linux.intel.com
Cc: heiko@sntech.de, gerald.loacker@wolfvision.net,
robh+dt@kernel.org, yunkec@chromium.org,
linux-kernel@vger.kernel.org, dan.scally@ideasonboard.com,
linux-media@vger.kernel.org,
Shengnan Wang (王圣男), hdegoede@redhat.com,
linus.walleij@linaro.org, andy.shevchenko@gmail.com,
Yaya Chang (張雅清), mchehab@kernel.org,
jacopo.mondi@ideasonboard.com, jernej.skrabec@gmail.com,
linux-mediatek@lists.infradead.org, bingbu.cao@intel.com,
Project_Global_Chrome_Upstream_Group, conor+dt@kernel.org,
10572168@qq.com, hverkuil-cisco@xs4all.nl,
tomi.valkeinen@ideasonboard.com,
krzysztof.kozlowski+dt@linaro.org,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com,
laurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,
angelogioacchino.delregno@collabora.com, macromorgan@hotmail.com
In-Reply-To: <8a6bbbdde57283b5bf8cab0ea7ecb0f201d437e7.camel@mediatek.com>
Hi Sakari,
Update gc05a2 driver patch.
On Sat, 2024-03-23 at 10:59 +0800, zhi.mao@mediatek.com wrote:
> Hi Sakari,
>
> Thanks for your review.
>
> On Wed, 2024-03-20 at 07:29 +0000, Sakari Ailus wrote:
> >
> > External email : Please do not click links or open attachments
> > until
> > you have verified the sender or the content.
> > Hi Zhi,
> >
> > Thanks for the set.
> >
> > On Sat, Mar 16, 2024 at 10:52:53AM +0800, Zhi Mao wrote:
> > > +static int gc05a2_set_ctrl(struct v4l2_ctrl *ctrl)
> > > +{
> > > +struct gc05a2 *gc05a2 =
> > > +container_of(ctrl->handler, struct gc05a2, ctrls);
> > > +int ret = 0;
> > > +s64 exposure_max;
> > > +struct v4l2_subdev_state *state;
> > > +const struct v4l2_mbus_framefmt *format;
> > > +
> > > +state = v4l2_subdev_get_locked_active_state(&gc05a2->sd);
> > > +format = v4l2_subdev_state_get_format(state, 0);
> > > +
> > > +if (ctrl->id == V4L2_CID_VBLANK) {
> > > +/* Update max exposure while meeting expected vblanking */
> > > +exposure_max = format->height + ctrl->val - GC05A2_EXP_MARGIN;
> > > +__v4l2_ctrl_modify_range(gc05a2->exposure,
> > > + gc05a2->exposure->minimum,
> > > + exposure_max, gc05a2->exposure->step,
> > > + exposure_max);
> > > +}
> > > +
> > > +/*
> > > + * Applying V4L2 control value only happens
> > > + * when power is on for streaming.
> > > + */
> > > +if (!pm_runtime_get_if_in_use(gc05a2->dev))
> >
> > This should be pm_runtime_get_if_active(). Please assume it takes a
> > single
> > argument (the device)---see commit
> > c0ef3df8dbaef51ee4cfd58a471adf2eaee6f6b3.
> >
> > The same comment applies to the GC08A3 if it uses autosuspend,
> > please
> > post
> > a new patch for that.
> >
>
> fixed, patch as below:
> gc05a patch:v2
>
>
https://lore.kernel.org/linux-media/20240323014751.4989-1-zhi.mao@mediatek.com/
>
gc05a driver was updated to patch:v3
https://lore.kernel.org/linux-media/20240403033825.9072-1-zhi.mao@mediatek.com/
> gc08a patch:v8
>
>
https://lore.kernel.org/linux-media/20240323023851.5503-1-zhi.mao@mediatek.com/
>
> > --
> > Kind regards,
> >
> > Sakari Ailus
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: qcm6490-idp: Add change to name the regulators
From: Bjorn Andersson @ 2024-04-03 3:52 UTC (permalink / raw)
To: Umang Chheda, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
quic_kamalw
In-Reply-To: <20240329140534820-0700.eberman@hu-eberman-lv.qualcomm.com>
On Fri, Mar 29, 2024 at 02:09:55PM -0700, Elliot Berman wrote:
> Nit: the subject line should be:
>
> arm64: dts: qcom: qcm6490: Name the regulators
>
Much cleaner subject, but no longer matches file prefix.
> I don't know if it merits a resend, though.
Yes, please.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 1/3] media: mediatek: vcodec: fix h264 multi statless decoder smatch warning
From: Yunfei Dong (董云飞) @ 2024-04-03 3:45 UTC (permalink / raw)
To: nhebert@chromium.org, benjamin.gaignard@collabora.com,
nfraprado@collabora.com, angelogioacchino.delregno@collabora.com,
nicolas.dufresne@collabora.com, hverkuil-cisco@xs4all.nl
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
frkoenig@chromium.org, stevecho@chromium.org,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
daniel@ffwll.ch, Project_Global_Chrome_Upstream_Group,
hsinyi@chromium.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <4949bd54-8c32-4490-ab19-d38796d29ac1@collabora.com>
Hi AngeloGioacchino,
Thanks for your reviewing.
On Tue, 2024-04-02 at 11:50 +0200, AngeloGioacchino Del Regno wrote:
> Il 29/02/24 10:56, Yunfei Dong ha scritto:
> > Fix smatch static checker warning for vdec_h264_req_multi_if.c.
> > Leading to kernel crash when fb is NULL.
> >
> > Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 decoder")
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > ---
> > .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9
> > +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _multi_if.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _multi_if.c
> > index 0e741e0dc8ba..ab8e708e0df1 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _multi_if.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req
> > _multi_if.c
> > @@ -724,11 +724,16 @@ static int vdec_h264_slice_single_decode(void
> > *h_vdec, struct mtk_vcodec_mem *bs
> > return vpu_dec_reset(vpu);
> >
> > fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx);
> > + if (!fb) {
> > + mtk_vdec_err(inst->ctx, "fb buffer is NULL");
> > + return -EBUSY;
> > + }
> > +
> > src_buf_info = container_of(bs, struct mtk_video_dec_buf,
> > bs_buffer);
> > dst_buf_info = container_of(fb, struct mtk_video_dec_buf,
> > frame_buffer);
> >
> > - y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0;
> > - c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0;
>
> You're changing the behavior here, can you please explain why this
> change is valid
> into the commit description?
>
The driver already add the condition to check whether fb is NULL at the
front, no need these two lines again.
> Thanks,
> Angelo
>
Best Regards,
Yunfei Dong
> > + y_fb_dma = (u64)fb->base_y.dma_addr;
> > + c_fb_dma = (u64)fb->base_c.dma_addr;
> > mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx
> > c_dma=%llx",
> > inst->ctx->decoded_frame_cnt, y_fb_dma,
> > c_fb_dma);
> >
>
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox