* Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
From: gregkh @ 2019-08-06 18:40 UTC (permalink / raw)
To: Stefan-gabriel Mirea
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, corbet@lwn.net,
catalin.marinas@arm.com, linux-doc@vger.kernel.org,
Larisa Ileana Grigore, linux-kernel@vger.kernel.org, Leo Li,
Cosmin Stefan Stoica, robh+dt@kernel.org,
linux-serial@vger.kernel.org, jslaby@suse.com,
shawnguo@kernel.org, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <HE1PR0402MB28579034C09EB49A76A4F8E7DFD50@HE1PR0402MB2857.eurprd04.prod.outlook.com>
On Tue, Aug 06, 2019 at 05:11:17PM +0000, Stefan-gabriel Mirea wrote:
> On 8/5/2019 6:31 PM, gregkh@linuxfoundation.org wrote:
> > On Fri, Aug 02, 2019 at 07:47:23PM +0000, Stefan-gabriel Mirea wrote:
> >>
> >> +/* Freescale Linflex UART */
> >> +#define PORT_LINFLEXUART 121
> >
> > Do you really need this modified?
>
> Hello Greg,
>
> This macro is meant to be assigned to port->type in the config_port
> method from uart_ops, in order for verify_port to know if the received
> serial_struct structure was really targeted for a LINFlex port. It
> needs to be defined outside, to avoid "collisions" with other drivers.
Yes, I know what it goes to, but does anyone in userspace actually use
it?
> As far as I see, uart_set_info() will actually fail at the
> "baud_base < 9600" check[1], right after calling verify_port(), when
> performing an ioctl() on "/dev/console" with TIOCSSERIAL using a
> serial_struct obtained with TIOCGSERIAL. This happens because this
> reduced version of the LINFlex UART driver will not touch the uartclk
> field of the uart_port (as there is currently no clock support).
> Therefore, the linflex_config/verify_port() functions, along with the
> PORT_LINFLEXUART macro, may be indeed unnecessary at this point (and
> should be added later). Is this what you mean?
No, see below.
> Other than that, I do not see anything wrong with the addition of a
> define in serial_core.h for this purpose (which is also what most of the
> serial drivers do, including amba-pl011.c, mentioned in
> Documentation/driver-api/serial/driver.rst as providing the reference
> implementation), so please be more specific.
I am getting tired of dealing with merge issues with that list, and no
one seems to be able to find where they are really needed for userspace,
especially for new devices. What happens if you do not have use it?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Ondřej Jirman @ 2019-08-06 18:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
linux-arm-kernel, linux-rtc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAGb2v66cbpsoHJoiFJkBwhZ5SbO+uO+Kf6gtnA3kPFQZq0329Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 15, 2019 at 04:18:12PM +0800, Chen-Yu Tsai wrote:
> On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> wrote:
> >
> > From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
> >
> > I went through the datasheets for H6 and H5, and compared the differences.
> > RTCs are largely similar, but not entirely compatible. Incompatibilities
> > are in details not yet implemented by the rtc driver though.
> >
> > I also corrected the clock tree in H6 DTSI.
>
> Please also add DCXO clock input/output and XO clock input to the bindings
> and DT, and also fix up the clock tree. You can skip them in the driver for
> now, but please add a TODO. As long as you don't change the clock-output-name
> of osc24M, everything should work as before.
>
> We just want the DT to describe what is actually there. For the XO input,
> you could just directly reference the external crystal node. The gate for
> it is likely somewhere in the PRCM block, which we don't have docs for.
So I was thinking about this for a while, and came up with this:
----------------- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi -----------------
index 64c39f663d22..ac99ddbebe5c 100644
@@ -627,14 +635,15 @@
rtc: rtc@7000000 {
compatible = "allwinner,sun50i-h6-rtc";
reg = <0x07000000 0x400>;
interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
- clock-output-names = "osc32k", "osc32k-out", "iosc";
- clocks = <&ext_osc32k>;
+ clock-output-names = "osc32k", "osc32k-out", "iosc", "hosc";
+ clock-names = "losc", "dcxo";
+ clocks = <&ext_osc32k>, <&osc24M>;
#clock-cells = <1>;
};
r_ccu: clock@7010000 {
compatible = "allwinner,sun50i-h6-r-ccu";
reg = <0x07010000 0x400>;
I'm not completely sure how (or why?) to describe in DTSI which oscillator the
designer used (XO vs DCXO). This information is signalled by the pad voltage and
can be determined at runtime from DCXO_CTRL_REG's OSC_CLK_SRC_SEL (bit 3). It's
not possible to change at runtime.
HOSC source selection is only material to the CPUS (ARISC) firmware when it
wants to turn off all PLLs and the main crystal oscillator so that it knows
which one to turn off. I don't see any other use for it. It's just
informational. I don't think (future) crust firmware has space to be reading
DTBs, so the detection will be using OSC_CLK_SRC_SEL anyway.
Maybe whether XO or DCXO is used also matters if you want to do some fine
tunning of DCXO (control register has pletny of options), but that's probably
better done in u-boot. And there's still no need to read HOSC source from DT.
The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
be using this info to gate/disable the osciallator.
If we really want this in DT, maybe we can model it by having just two input
clocks to RTC described in DTSI, and the DTSI for H6 would have this by default:
clock-names = "losc", "dcxo";
clocks = <&ext_osc32k>, <&osc24M>;
And the board designer could change it from a board file, like this:
&rtc {
clock-names = "losc", "xo";
clocks = <&ext_osc32k>, <&osc24M>;
};
The driver could decide which oscillator is used by the presence of either
dcxo or xo input clock.
But in any case, the driver can also get this info from DCXO_CTRL_REG's
OSC_CLK_SRC_SEL, so it doesn't need to read this from DT at all. So it's a bit
pointless.
So I see two options:
1) skip adding dcxo/xo to input clocks of RTC completely
2) the above
What do you think?
regards,
o.
> > There's a small detail here, that's not described absolutely correctly in
> > DTSI, but the difference is not really that material. ext_osc32k is
> > originally modelled as a fixed clock that feeds into RTC module, but in
> > reality it's the RTC module that implements via its registers enabling and
> > disabling of this oscillator/clock.
> >
> > Though:
> > - there's no other possible user of ext_osc32k than RTC module
> > - there's no other possible external configuration for the crystal
> > circuit that would need to be handled in the dts per board
> >
> > So I guess, while the description is not perfect, this patch series still
> > improves the current situation. Or maybe I'm misunderstanding something,
> > and &ext_osc32k node just describes a fact that there's a crystal on
> > the board. Then, everything is perhaps fine. :)
>
> Correct. The external clock nodes are modeling the crystal, not the internal
> clock gate / distributor.
>
> Were the vendor to not include the crystal (for whatever reasons), the DT
> should be able to describe it via the absence of the clock input, and the
> driver should correctly use the internal (inaccurate) oscillator. I realize
> the clocks property is required, and the driver doesn't handle this case
> either, so we might have to fix that if it were to appear in the wild.
>
> > For now, the enable bit for this oscillator is toggled by the re-parenting
> > code automatically, as needed.
>
> That's fine. No need to increase the clock tree depth.
>
> ChenYu
>
> > This patchset is necessary for implementing the WiFi/Bluetooth support
> > on boards using H6 SoC.
> >
> > Please take a look.
> >
> > Thank you and regards,
> > Ondrej Jirman
> >
> > Ondrej Jirman (3):
> > dt-bindings: Add compatible for H6 RTC
> > rtc: sun6i: Add support for H6 RTC
> > arm64: dts: sun50i-h6: Add support for RTC and fix the clock tree
> >
> > .../devicetree/bindings/rtc/sun6i-rtc.txt | 1 +
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 30 +++++++-------
> > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++-
> > 3 files changed, 55 insertions(+), 16 deletions(-)
> >
> > --
> > 2.21.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > For more options, visit https://groups.google.com/d/optout.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
From: Bjorn Andersson @ 2019-08-06 18:21 UTC (permalink / raw)
To: Suman Anna
Cc: Fabien DESSENNE, Ohad Ben-Cohen, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre TORGUE, Jonathan Corbet,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
Benjamin GAIGNARD
In-Reply-To: <dcd1aeea-cffe-d5fb-af5a-e52efcc2e046@ti.com>
On Tue 06 Aug 10:38 PDT 2019, Suman Anna wrote:
> Hi Fabien,
>
> On 8/5/19 12:46 PM, Bjorn Andersson wrote:
> > On Mon 05 Aug 01:48 PDT 2019, Fabien DESSENNE wrote:
> >
> >>
> >> On 01/08/2019 9:14 PM, Bjorn Andersson wrote:
> >>> On Wed 13 Mar 08:50 PDT 2019, Fabien Dessenne wrote:
[..]
> >> B/ This would introduce some inconsistency between the two 'request' API
> >> which are hwspin_lock_request() and hwspin_lock_request_specific().
> >> hwspin_lock_request() looks for an unused lock, so requests for an exclusive
> >> usage. On the other side, request_specific() would request shared locks.
> >> Worst the following sequence can transform an exclusive usage into a shared
> >>
> >
> > There is already an inconsistency in between these; as with above any
> > system that uses both request() and request_specific() will be suffering
> > from intermittent failures due to probe ordering.
> >
> >> one:
> >> -hwspin_lock_request() -> returns Id#0 (exclusive)
> >> -hwspin_lock_request() -> returns Id#1 (exclusive)
> >> -hwspin_lock_request_specific(0) -> returns Id#0 and makes Id#0 shared
> >> Honestly I am not sure that this is a real issue, but it's better to have it
> >> in mind before we take ay decision
>
> Wouldn't it be actually simpler to just introduce a new specific API
> variant for this, similar to the reset core for example (it uses a
> separate exclusive API), without having to modify the bindings at all.
> It is just a case of your driver using the right API, and the core can
> be modified to use the additional tag semantics based on the API. It
> should avoid any confusion with say using a different second cell value
> for the same lock in two different nodes.
>
But this implies that there is an actual need to hold these locks
exclusively. Given that they are (except for the raw case) all wrapped
by Linux locking primitives there shouldn't be a problem sharing a lock
(except possibly for the raw case).
I agree that we shouldn't specify this property in DT - if anything it
should be a variant of the API.
> If you are sharing a hwlock on the Linux side, surely your driver should
> be aware that it is a shared lock. The tag can be set during the first
> request API, and you look through both tags when giving out a handle.
>
Why would the driver need to know about it?
> Obviously, the hwspin_lock_request() API usage semantics always had the
> implied additional need for communicating the lock id to the other peer
> entity, so a realistic usage is most always the specific API variant. I
> doubt this API would be of much use for the shared driver usage. This
> also implies that the client user does not care about specifying a lock
> in DT.
>
Afaict if the lock are shared then there shouldn't be a problem with
some clients using the request API and others request_specific(). As any
collisions would simply mean that there are more contention on the lock.
With the current exclusive model that is not possible and the success of
the request_specific will depend on probe order.
But perhaps it should be explicitly prohibited to use both APIs on the
same hwspinlock instance?
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size
From: Nicolas Saenz Julienne @ 2019-08-06 18:12 UTC (permalink / raw)
To: Rob Herring
Cc: Catalin Marinas, Will Deacon, Christoph Hellwig, wahrenst,
Marc Zyngier, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, Linux IOMMU, linux-mm, Frank Rowand, phill,
Florian Fainelli, linux-kernel@vger.kernel.org, Eric Anholt,
Matthias Brugger, Andrew Morton, Marek Szyprowski,
"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" <linux-rp>
In-Reply-To: <CAL_Jsq+LjsRmFg-xaLgpVx3miXN3hid3aD+mgTW__j0SbEFYjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]
Hi Rob,
On Mon, 2019-08-05 at 13:23 -0600, Rob Herring wrote:
> On Mon, Aug 5, 2019 at 10:03 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > Hi Rob,
> > Thanks for the review!
> >
> > On Fri, 2019-08-02 at 11:17 -0600, Rob Herring wrote:
> > > On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne
> > > <nsaenzjulienne@suse.de> wrote:
> > > > Some SoCs might have multiple interconnects each with their own DMA
> > > > addressing limitations. This function parses the 'dma-ranges' on each of
> > > > them and tries to guess the maximum SoC wide DMA addressable memory
> > > > size.
> > > >
> > > > This is specially useful for arch code in order to properly setup CMA
> > > > and memory zones.
> > >
> > > We already have a way to setup CMA in reserved-memory, so why is this
> > > needed for that?
> >
> > Correct me if I'm wrong but I got the feeling you got the point of the patch
> > later on.
>
> No, for CMA I don't. Can't we already pass a size and location for CMA
> region under /reserved-memory. The only advantage here is perhaps the
> CMA range could be anywhere in the DMA zone vs. a fixed location.
Now I get it, sorry I wasn't aware of that interface.
Still, I'm not convinced it matches RPi's use case as this would hard-code
CMA's size. Most people won't care, but for the ones that do, it's nicer to
change the value from the kernel command line than editing the dtb. I get that
if you need to, for example, reserve some memory for the video to work, it's
silly not to hard-code it. Yet due to the board's nature and users base I say
it's important to favor flexibility. It would also break compatibility with
earlier versions of the board and diverge from the downstream kernel behaviour.
Which is a bigger issue than it seems as most users don't always understand
which kernel they are running and unknowingly copy configuration options from
forums.
As I also need to know the DMA addressing limitations to properly configure
memory zones and dma-direct. Setting up the proper CMA constraints during the
arch's init will be trivial anyway.
> > > IMO, I'd just do:
> > >
> > > if (of_fdt_machine_is_compatible(blob, "brcm,bcm2711"))
> > > dma_zone_size = XX;
> > >
> > > 2 lines of code is much easier to maintain than 10s of incomplete code
> > > and is clearer who needs this. Maybe if we have dozens of SoCs with
> > > this problem we should start parsing dma-ranges.
> >
> > FYI that's what arm32 is doing at the moment and was my first instinct. But
> > it
> > seems that arm64 has been able to survive so far without any machine
> > specific
> > code and I have the feeling Catalin and Will will not be happy about this
> > solution. Am I wrong?
>
> No doubt. I'm fine if the 2 lines live in drivers/of/.
>
> Note that I'm trying to reduce the number of early_init_dt_scan_*
> calls from arch code into the DT code so there's more commonality
> across architectures in the early DT scans. So ideally, this can all
> be handled under early_init_dt_scan() call.
How does this look? (I'll split it in two patches and add a comment explaining
why dt_dma_zone_size is needed)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index f2444c61a136..1395be40b722 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -30,6 +30,8 @@
#include "of_private.h"
+u64 dt_dma_zone_size __ro_after_init;
+
/*
* of_fdt_limit_memory - limit the number of regions in the /memory node
* @limit: maximum entries
@@ -802,6 +805,11 @@ const char * __init of_flat_dt_get_machine_name(void)
return name;
}
+static const int __init of_fdt_machine_is_compatible(char *name)
+{
+ return of_compat_cmp(of_flat_dt_get_machine_name(), name, strlen(name));
+}
+
/**
* of_flat_dt_match_machine - Iterate match tables to find matching machine.
*
@@ -1260,6 +1268,14 @@ void __init early_init_dt_scan_nodes(void)
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
}
+void __init early_init_dt_get_dma_zone_size(void)
+{
+ dt_dma_zone_size = 0;
+
+ if (of_fdt_machine_is_compatible("brcm,bcm2711"))
+ dt_dma_zone_size = 0x3c000000;
+}
+
bool __init early_init_dt_scan(void *params)
{
bool status;
@@ -1269,6 +1285,7 @@ bool __init early_init_dt_scan(void *params)
return false;
early_init_dt_scan_nodes();
+ early_init_dt_get_dma_zone_size();
return true;
}
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 2ad36b7bd4fa..b5a9f685de14 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -27,6 +27,8 @@ extern void *of_fdt_unflatten_tree(const unsigned long *blob,
struct device_node *dad,
struct device_node **mynodes);
+extern u64 dt_dma_zone_size __ro_after_init;
+
/* TBD: Temporary export of fdt globals - remove when code fully merged */
extern int __initdata dt_root_addr_cells;
extern int __initdata dt_root_size_cells;
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH v7 01/20] pinctrl: tegra: Add suspend and resume support
From: Dmitry Osipenko @ 2019-08-06 17:59 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree, rjw, viresh.kumar, linux-pm
In-Reply-To: <b45ca99a-188a-c695-3f3d-48d273808f9c@nvidia.com>
05.08.2019 21:06, Sowjanya Komatineni пишет:
>
> On 8/5/19 3:50 AM, Dmitry Osipenko wrote:
>> 01.08.2019 0:10, Sowjanya Komatineni пишет:
>>> This patch adds support for Tegra pinctrl driver suspend and resume.
>>>
>>> During suspend, context of all pinctrl registers are stored and
>>> on resume they are all restored to have all the pinmux and pad
>>> configuration for normal operation.
>>>
>>> Acked-by: Thierry Reding <treding@nvidia.com>
>>> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>> ---
>>> drivers/pinctrl/tegra/pinctrl-tegra.c | 59
>>> +++++++++++++++++++++++++++++++++++
>>> drivers/pinctrl/tegra/pinctrl-tegra.h | 3 ++
>>> 2 files changed, 62 insertions(+)
>>>
>>> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> b/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> index 186ef98e7b2b..e3a237534281 100644
>>> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
>>> @@ -631,6 +631,58 @@ static void
>>> tegra_pinctrl_clear_parked_bits(struct tegra_pmx *pmx)
>>> }
>>> }
>>> +static size_t tegra_pinctrl_get_bank_size(struct device *dev,
>>> + unsigned int bank_id)
>>> +{
>>> + struct platform_device *pdev = to_platform_device(dev);
>>> + struct resource *res;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, bank_id);
>>> +
>>> + return resource_size(res) / 4;
>>> +}
>>> +
>>> +static int tegra_pinctrl_suspend(struct device *dev)
>>> +{
>>> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
>>> + u32 *backup_regs = pmx->backup_regs;
>>> + u32 *regs;
>>> + size_t bank_size;
>>> + unsigned int i, k;
>>> +
>>> + for (i = 0; i < pmx->nbanks; i++) {
>>> + bank_size = tegra_pinctrl_get_bank_size(dev, i);
>>> + regs = pmx->regs[i];
>>> + for (k = 0; k < bank_size; k++)
>>> + *backup_regs++ = readl_relaxed(regs++);
>>> + }
>>> +
>>> + return pinctrl_force_sleep(pmx->pctl);
>>> +}
>>> +
>>> +static int tegra_pinctrl_resume(struct device *dev)
>>> +{
>>> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
>>> + u32 *backup_regs = pmx->backup_regs;
>>> + u32 *regs;
>>> + size_t bank_size;
>>> + unsigned int i, k;
>>> +
>>> + for (i = 0; i < pmx->nbanks; i++) {
>>> + bank_size = tegra_pinctrl_get_bank_size(dev, i);
>>> + regs = pmx->regs[i];
>>> + for (k = 0; k < bank_size; k++)
>>> + writel_relaxed(*backup_regs++, regs++);
>>> + }
>> I'm now curious whether any kind of barrier is needed after the
>> writings. The pmx_writel() doesn't insert a barrier after the write and
>> seems it just misuses writel, which actually should be writel_relaxed()
>> + barrier, IIUC.
>
> pmx_writel uses writel and it has wmb before raw_write which complete
> all writes initiated prior to this.
>
> By misusing writel, you mean to have barrier after register write?
Yes, at least to me it doesn't make much sense for this driver to stall
before the write. It's the pinctrl user which should be taking care
about everything to be ready before making a change to the pinctrl's
configuration.
>> It's also not obvious whether PINCTRL HW has any kind of write-FIFO and
>> thus maybe read-back + rmb() is needed in order ensure that writes are
>> actually completed.
> I believe adding write barrier wmb after writel_relaxed should be good
> rather than doing readback + rmb
>>
>> The last thing which is not obvious is when the new configuration
>> actually takes into effect, does it happen immediately or maybe some
>> delay is needed?
>>
>> [snip]
>
> Based on internal design there is no internal delay and it all depends
> on APB rate that it takes to write to register.
>
> Pinmux value change to reflect internally might take couple of clock
> cycles which is much faster than SW can read.
Still not quite obvious if it's possible to have a case where some
hardware is touched before necessary pinctrl change is fully completed
and then to get into trouble because of it.
^ permalink raw reply
* Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
From: Suman Anna @ 2019-08-06 17:38 UTC (permalink / raw)
To: Bjorn Andersson, Fabien DESSENNE
Cc: Ohad Ben-Cohen, Mark Rutland, Alexandre TORGUE, Jonathan Corbet,
linux-doc@vger.kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Rob Herring, Maxime Coquelin,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Benjamin GAIGNARD
In-Reply-To: <20190805174659.GA23928@tuxbook-pro>
Hi Fabien,
On 8/5/19 12:46 PM, Bjorn Andersson wrote:
> On Mon 05 Aug 01:48 PDT 2019, Fabien DESSENNE wrote:
>
>>
>> On 01/08/2019 9:14 PM, Bjorn Andersson wrote:
>>> On Wed 13 Mar 08:50 PDT 2019, Fabien Dessenne wrote:
>>>
>>>> The current implementation does not allow two different devices to use
>>>> a common hwspinlock. This patch set proposes to have, as an option, some
>>>> hwspinlocks shared between several users.
>>>>
>>>> Below is an example that explain the need for this:
>>>> exti: interrupt-controller@5000d000 {
>>>> compatible = "st,stm32mp1-exti", "syscon";
>>>> interrupt-controller;
>>>> #interrupt-cells = <2>;
>>>> reg = <0x5000d000 0x400>;
>>>> hwlocks = <&hsem 1>;
>>>> };
>>>> The two drivers (stm32mp1-exti and syscon) refer to the same hwlock.
>>>> With the current hwspinlock implementation, only the first driver succeeds
>>>> in requesting (hwspin_lock_request_specific) the hwlock. The second request
>>>> fails.
Help me understand the problem that you are trying to solve here. Is
this a case of you having two clients on Linux-side needing to use the
same lock but still requiring the arbitration with software running on
some other remote processor? Are they talking to the same entity on the
remote-side or different peers.
I see the series is all about getting a handle so that they can use the
API, and is the expected usage that the same entity will lock and unlock
before the other driver can lock it.
>>>>
>>>>
>>>> The proposed approach does not modify the API, but extends the DT 'hwlocks'
>>>> property with a second optional parameter (the first one identifies an
>>>> hwlock) that specifies whether an hwlock is requested for exclusive usage
>>>> (current behavior) or can be shared between several users.
>>>> Examples:
>>>> hwlocks = <&hsem 8>; Ref to hwlock #8 for exclusive usage
>>>> hwlocks = <&hsem 8 0>; Ref to hwlock #8 for exclusive (0) usage
>>>> hwlocks = <&hsem 8 1>; Ref to hwlock #8 for shared (1) usage
>>>>
>>>> As a constraint, the #hwlock-cells value must be 1 or 2.
>>>> In the current implementation, this can have theorically any value but:
>>>> - all of the exisiting drivers use the same value : 1.
>>>> - the framework supports only one value : 1 (see implementation of
>>>> of_hwspin_lock_simple_xlate())
>>>> Hence, it shall not be a problem to restrict this value to 1 or 2 since
>>>> it won't break any driver.
>>>>
>>> Hi Fabien,
>>>
>>> Your series looks good, but it makes me wonder why the hardware locks
>>> should be an exclusive resource.
>>>
>>> How about just making all (specific) locks shared?
>>
>> Hi Bjorn,
>>
>> Making all locks shared is a possible implementation (my first
>> implementation
>> was going this way) but there are some drawbacks we must be aware of:
>>
>> A/ This theoretically break the legacy behavior (the legacy works with
>> exclusive (UNUSED radix tag) usage). As a consequence, an existing driver
>> that is currently failing to request a lock (already claimed by another
>> user) would now work fine. Not sure that there are such drivers, so this
>> point is probably not a real issue.
>>
>
> Right, it's possible that a previously misconfigured system now
> successfully probes more than one device that uses a particular
> spinlock. But such system would be suffering from issues related to e.g.
> probe ordering.
>
> So I think we should ignore this issue.
>
>> B/ This would introduce some inconsistency between the two 'request' API
>> which are hwspin_lock_request() and hwspin_lock_request_specific().
>> hwspin_lock_request() looks for an unused lock, so requests for an exclusive
>> usage. On the other side, request_specific() would request shared locks.
>> Worst the following sequence can transform an exclusive usage into a shared
>>
>
> There is already an inconsistency in between these; as with above any
> system that uses both request() and request_specific() will be suffering
> from intermittent failures due to probe ordering.
>
>> one:
>> -hwspin_lock_request() -> returns Id#0 (exclusive)
>> -hwspin_lock_request() -> returns Id#1 (exclusive)
>> -hwspin_lock_request_specific(0) -> returns Id#0 and makes Id#0 shared
>> Honestly I am not sure that this is a real issue, but it's better to have it
>> in mind before we take ay decision
Wouldn't it be actually simpler to just introduce a new specific API
variant for this, similar to the reset core for example (it uses a
separate exclusive API), without having to modify the bindings at all.
It is just a case of your driver using the right API, and the core can
be modified to use the additional tag semantics based on the API. It
should avoid any confusion with say using a different second cell value
for the same lock in two different nodes.
If you are sharing a hwlock on the Linux side, surely your driver should
be aware that it is a shared lock. The tag can be set during the first
request API, and you look through both tags when giving out a handle.
Obviously, the hwspin_lock_request() API usage semantics always had the
implied additional need for communicating the lock id to the other peer
entity, so a realistic usage is most always the specific API variant. I
doubt this API would be of much use for the shared driver usage. This
also implies that the client user does not care about specifying a lock
in DT.
regards
Suman
>
> The case where I can see a
> problem with this would be if the two clients somehow would nest their
> locking regions.
>
> But generally I think this could consider this an improvement, because
> the request_specific() would now be able to acquire its hwlock, with
> some additional contention due to the multiple use.
>
>> I could not find any driver using the hwspin_lock_request() API, we
>> may decide to remove (or to make deprecated) this API, having
>> everything 'shared without any conditions'.
>>
>
> It would be nice to have an upstream user of this API.
>
>>
>> I can see three options:
>> 1- Keep my initial proposition
>> 2- Have hwspin_lock_request_specific() using shared locks and
>> hwspin_lock_request() using unused (so 'initially' exclusive) locks.
>> 3- Have hwspin_lock_request_specific() using shared locks and
>> remove/make deprecated hwspin_lock_request().
>>
>> Just let me know what is your preference.
>>
>
> I think we should start with #2 and would like input from e.g. Suman
> regarding #3.
>
> Regards,
> Bjorn
>
>> BR
>>
>> Fabien
>>
>>>
>>> Regards,
>>> Bjorn
>>>
>>>> Fabien Dessenne (6):
>>>> dt-bindings: hwlock: add support of shared locks
>>>> hwspinlock: allow sharing of hwspinlocks
>>>> dt-bindings: hwlock: update STM32 #hwlock-cells value
>>>> ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
>>>> ARM: dts: stm32: Add hwlock for irqchip on stm32mp157
>>>> ARM: dts: stm32: hwlocks for GPIO for stm32mp157
>>>>
>>>> .../devicetree/bindings/hwlock/hwlock.txt | 27 +++++--
>>>> .../bindings/hwlock/st,stm32-hwspinlock.txt | 6 +-
>>>> Documentation/hwspinlock.txt | 10 ++-
>>>> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 2 +
>>>> arch/arm/boot/dts/stm32mp157c.dtsi | 10 +++
>>>> drivers/hwspinlock/hwspinlock_core.c | 82 +++++++++++++++++-----
>>>> drivers/hwspinlock/hwspinlock_internal.h | 2 +
>>>> 7 files changed, 108 insertions(+), 31 deletions(-)
>>>>
>>>> --
>>>> 2.7.4
>>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
From: Stefan-gabriel Mirea @ 2019-08-06 17:11 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
catalin.marinas@arm.com, will@kernel.org, shawnguo@kernel.org,
Leo Li, jslaby@suse.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Cosmin Stefan Stoica,
Larisa Ileana Grigore
In-Reply-To: <20190805153114.GA16836@kroah.com>
On 8/5/2019 6:31 PM, gregkh@linuxfoundation.org wrote:
> On Fri, Aug 02, 2019 at 07:47:23PM +0000, Stefan-gabriel Mirea wrote:
>>
>> +/* Freescale Linflex UART */
>> +#define PORT_LINFLEXUART 121
>
> Do you really need this modified?
Hello Greg,
This macro is meant to be assigned to port->type in the config_port
method from uart_ops, in order for verify_port to know if the received
serial_struct structure was really targeted for a LINFlex port. It
needs to be defined outside, to avoid "collisions" with other drivers.
As far as I see, uart_set_info() will actually fail at the
"baud_base < 9600" check[1], right after calling verify_port(), when
performing an ioctl() on "/dev/console" with TIOCSSERIAL using a
serial_struct obtained with TIOCGSERIAL. This happens because this
reduced version of the LINFlex UART driver will not touch the uartclk
field of the uart_port (as there is currently no clock support).
Therefore, the linflex_config/verify_port() functions, along with the
PORT_LINFLEXUART macro, may be indeed unnecessary at this point (and
should be added later). Is this what you mean?
Other than that, I do not see anything wrong with the addition of a
define in serial_core.h for this purpose (which is also what most of the
serial drivers do, including amba-pl011.c, mentioned in
Documentation/driver-api/serial/driver.rst as providing the reference
implementation), so please be more specific.
Regards,
Stefan
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/serial_core.c?h=v5.3-rc1#n872
^ permalink raw reply
* [PATCH v2 3/5] dt-bindings: arm: Extend SCMI to support new reset protocol
From: Sudeep Holla @ 2019-08-06 17:02 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Peng Fan, linux-kernel, Bo Zhang, Jim Quinlan,
Volodymyr Babchuk, Gaku Inami, aidapala, pajay, Etienne Carriere,
Souvik Chakravarty, wesleys, Felix Burton, Saeed Nowshadi,
Philipp Zabel, Rob Herring, Mark Rutland, devicetree
In-Reply-To: <20190806170208.6787-1-sudeep.holla@arm.com>
SCMIv2.0 adds a new Reset Management Protocol to manage various reset
states a given device or domain can enter. Extend the existing SCMI
bindings to add reset protocol support by re-using the reset bindings
for bothe reset providers and consumers.
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scmi.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
index 317a2fc3667a..083dbf96ee00 100644
--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
@@ -73,6 +73,16 @@ SCMI provides an API to access the various sensors on the SoC.
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
+Reset signal bindings for the reset domains based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding for the SCMI reset domain providers uses the generic reset
+signal binding[5].
+
+Required properties:
+ - #reset-cells : Should be 1. Contains the reset domain ID value used
+ by SCMI commands.
+
SRAM and Shared Memory for SCMI
-------------------------------
@@ -93,6 +103,7 @@ Each sub-node represents the reserved area for SCMI.
[2] Documentation/devicetree/bindings/power/power_domain.txt
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.txt
+[5] Documentation/devicetree/bindings/reset/reset.txt
Example:
@@ -152,6 +163,11 @@ firmware {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
+
+ scmi_reset: protocol@16 {
+ reg = <0x16>;
+ #reset-cells = <1>;
+ };
};
};
@@ -166,6 +182,7 @@ hdlcd@7ff60000 {
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scmi_clk 4>;
power-domains = <&scmi_devpd 1>;
+ resets = <&scmi_reset 10>;
};
thermal-zones {
--
2.17.1
^ permalink raw reply related
* Re: [v2,2/2] PCI: mediatek: Add controller support for MT7629
From: Andrew Murray @ 2019-08-06 16:33 UTC (permalink / raw)
To: Jianjun Wang
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Ryder Lee, Mark Rutland,
devicetree, linux-pci, youlin.pei, linux-kernel, Rob Herring,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1564385918.17211.6.camel@mhfsdcap03>
On Mon, Jul 29, 2019 at 03:38:38PM +0800, Jianjun Wang wrote:
> On Fri, 2019-06-28 at 15:34 +0800, Jianjun Wang wrote:
> > MT7629 is an ARM platform SoC which has the same PCIe IP with MT7622.
> >
> > The HW default value of its Device ID is invalid, fix its Device ID to
> > match the hardware implementation.
> >
> > Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> > Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> > ---
> > drivers/pci/controller/pcie-mediatek.c | 18 ++++++++++++++++++
> > include/linux/pci_ids.h | 1 +
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > index 80601e1b939e..e5e6740b635d 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -73,6 +73,7 @@
> > #define PCIE_MSI_VECTOR 0x0c0
> >
> > #define PCIE_CONF_VEND_ID 0x100
> > +#define PCIE_CONF_DEVICE_ID 0x102
> > #define PCIE_CONF_CLASS_ID 0x106
> >
> > #define PCIE_INT_MASK 0x420
> > @@ -141,12 +142,16 @@ struct mtk_pcie_port;
> > /**
> > * struct mtk_pcie_soc - differentiate between host generations
> > * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> > + * @need_fix_device_id: whether this host's Device ID needed to be fixed or not
> > + * @device_id: Device ID which this host need to be fixed
Really trivial nit: s/Device ID/device ID/ to be consistent with class ID above it.
Either way:
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
> > * @ops: pointer to configuration access functions
> > * @startup: pointer to controller setting functions
> > * @setup_irq: pointer to initialize IRQ functions
> > */
> > struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > + bool need_fix_device_id;
> > + unsigned int device_id;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -696,6 +701,9 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> > writew(val, port->base + PCIE_CONF_CLASS_ID);
> > }
> >
> > + if (soc->need_fix_device_id)
> > + writew(soc->device_id, port->base + PCIE_CONF_DEVICE_ID);
> > +
> > /* 100ms timeout value should be enough for Gen1/2 training */
> > err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > !!(val & PCIE_PORT_LINKUP_V2), 20,
> > @@ -1216,11 +1224,21 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 = {
> > .setup_irq = mtk_pcie_setup_irq,
> > };
> >
> > +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> > + .need_fix_class_id = true,
> > + .need_fix_device_id = true,
> > + .device_id = PCI_DEVICE_ID_MEDIATEK_7629,
> > + .ops = &mtk_pcie_ops_v2,
> > + .startup = mtk_pcie_startup_port_v2,
> > + .setup_irq = mtk_pcie_setup_irq,
> > +};
> > +
> > static const struct of_device_id mtk_pcie_ids[] = {
> > { .compatible = "mediatek,mt2701-pcie", .data = &mtk_pcie_soc_v1 },
> > { .compatible = "mediatek,mt7623-pcie", .data = &mtk_pcie_soc_v1 },
> > { .compatible = "mediatek,mt2712-pcie", .data = &mtk_pcie_soc_mt2712 },
> > { .compatible = "mediatek,mt7622-pcie", .data = &mtk_pcie_soc_mt7622 },
> > + { .compatible = "mediatek,mt7629-pcie", .data = &mtk_pcie_soc_mt7629 },
> > {},
> > };
> >
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 70e86148cb1e..aa32962759b2 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2131,6 +2131,7 @@
> > #define PCI_VENDOR_ID_MYRICOM 0x14c1
> >
> > #define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > +#define PCI_DEVICE_ID_MEDIATEK_7629 0x7629
> >
> > #define PCI_VENDOR_ID_TITAN 0x14D2
> > #define PCI_DEVICE_ID_TITAN_010L 0x8001
>
> Hi Bjorn & Lorenzo,
>
> Is this patch ok or is there anything I need to fixed?
>
> Thanks.
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 10/10] arm: dts: mt6323: add keys, power-controller, rtc and codec
From: Frank Wunderlich @ 2019-08-06 16:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana, Rob Herring, Sean Wang,
Sebastian Reichel <sre>
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806163026.8530-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
support poweroff and power-related keys on bpi-r2
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: none
changes since v2: none (=v2 part 7)
arch/arm/boot/dts/mt6323.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
index ba397407c1dd..7fda40ab5fe8 100644
--- a/arch/arm/boot/dts/mt6323.dtsi
+++ b/arch/arm/boot/dts/mt6323.dtsi
@@ -238,5 +238,32 @@
regulator-enable-ramp-delay = <216>;
};
};
+
+ mt6323keys: mt6323keys {
+ compatible = "mediatek,mt6323-keys";
+ mediatek,long-press-mode = <1>;
+ power-off-time-sec = <0>;
+
+ power {
+ linux,keycodes = <116>;
+ wakeup-source;
+ };
+
+ home {
+ linux,keycodes = <114>;
+ };
+ };
+
+ codec: mt6397codec {
+ compatible = "mediatek,mt6397-codec";
+ };
+
+ power-controller {
+ compatible = "mediatek,mt6323-pwrc";
+ };
+
+ rtc {
+ compatible = "mediatek,mt6323-rtc";
+ };
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH v4 09/10] MAINTAINERS: add Mediatek shutdown drivers
From: Frank Wunderlich @ 2019-08-06 16:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana, Rob Herring, Sean Wang,
Sebastian Reichel <sre>
Cc: Josef Friedl, Frank Wunderlich
From: Josef Friedl <josef.friedl@speed.at>
add Section in MAINTAINERS file for poweroff driver
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: moved SOB
changes since v2: none (=v2 part 6)
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6426db5198f0..4172a3177633 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10128,6 +10128,13 @@ S: Maintained
F: drivers/net/dsa/mt7530.*
F: net/dsa/tag_mtk.c
+MEDIATEK BOARD LEVEL SHUTDOWN DRIVERS
+M: Sean Wang <sean.wang@mediatek.com>
+L: linux-pm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
+F: drivers/power/reset/mt6323-poweroff.c
+
MEDIATEK JPEG DRIVER
M: Rick Chang <rick.chang@mediatek.com>
M: Bin Liu <bin.liu@mediatek.com>
--
2.17.1
^ permalink raw reply related
* [PATCH v4 08/10] power: reset: add driver for mt6323 poweroff
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add poweroff driver for mt6323 and make Makefile and Kconfig-Entries
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: none
changes since v2: none (=v2 part 5)
drivers/power/reset/Kconfig | 10 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/mt6323-poweroff.c | 97 +++++++++++++++++++++++++++
include/linux/mfd/mt6397/core.h | 2 +
4 files changed, 110 insertions(+)
create mode 100644 drivers/power/reset/mt6323-poweroff.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index a564237278ff..c721939767eb 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -140,6 +140,16 @@ config POWER_RESET_LTC2952
This driver supports an external powerdown trigger and board power
down via the LTC2952. Bindings are made in the device tree.
+config POWER_RESET_MT6323
+ bool "MediaTek MT6323 power-off driver"
+ depends on MFD_MT6397
+ help
+ The power-off driver is responsible for externally shutdown down
+ the power of a remote MediaTek SoC MT6323 is connected to through
+ controlling a tiny circuit BBPU inside MT6323 RTC.
+
+ Say Y if you have a board where MT6323 could be found.
+
config POWER_RESET_QNAP
bool "QNAP power-off driver"
depends on OF_GPIO && PLAT_ORION
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 85da3198e4e0..da37f8b851dc 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
+obj-$(CONFIG_POWER_RESET_MT6323) += mt6323-poweroff.o
obj-$(CONFIG_POWER_RESET_QCOM_PON) += qcom-pon.o
obj-$(CONFIG_POWER_RESET_OCELOT_RESET) += ocelot-reset.o
obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
diff --git a/drivers/power/reset/mt6323-poweroff.c b/drivers/power/reset/mt6323-poweroff.c
new file mode 100644
index 000000000000..1caf43d9e46d
--- /dev/null
+++ b/drivers/power/reset/mt6323-poweroff.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Power off through MediaTek PMIC
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author: Sean Wang <sean.wang@mediatek.com>
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6397/rtc.h>
+
+struct mt6323_pwrc {
+ struct device *dev;
+ struct regmap *regmap;
+ u32 base;
+};
+
+static struct mt6323_pwrc *mt_pwrc;
+
+static void mt6323_do_pwroff(void)
+{
+ struct mt6323_pwrc *pwrc = mt_pwrc;
+ unsigned int val;
+ int ret;
+
+ regmap_write(pwrc->regmap, pwrc->base + RTC_BBPU, RTC_BBPU_KEY);
+ regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR, 1);
+
+ ret = regmap_read_poll_timeout(pwrc->regmap,
+ pwrc->base + RTC_BBPU, val,
+ !(val & RTC_BBPU_CBUSY),
+ MTK_RTC_POLL_DELAY_US,
+ MTK_RTC_POLL_TIMEOUT);
+ if (ret)
+ dev_err(pwrc->dev, "failed to write BBPU: %d\n", ret);
+
+ /* Wait some time until system down, otherwise, notice with a warn */
+ mdelay(1000);
+
+ WARN_ONCE(1, "Unable to power off system\n");
+}
+
+static int mt6323_pwrc_probe(struct platform_device *pdev)
+{
+ struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
+ struct mt6323_pwrc *pwrc;
+ struct resource *res;
+
+ pwrc = devm_kzalloc(&pdev->dev, sizeof(*pwrc), GFP_KERNEL);
+ if (!pwrc)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pwrc->base = res->start;
+ pwrc->regmap = mt6397_chip->regmap;
+ pwrc->dev = &pdev->dev;
+ mt_pwrc = pwrc;
+
+ pm_power_off = &mt6323_do_pwroff;
+
+ return 0;
+}
+
+static int mt6323_pwrc_remove(struct platform_device *pdev)
+{
+ if (pm_power_off == &mt6323_do_pwroff)
+ pm_power_off = NULL;
+
+ return 0;
+}
+
+static const struct of_device_id mt6323_pwrc_dt_match[] = {
+ { .compatible = "mediatek,mt6323-pwrc" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mt6323_pwrc_dt_match);
+
+static struct platform_driver mt6323_pwrc_driver = {
+ .probe = mt6323_pwrc_probe,
+ .remove = mt6323_pwrc_remove,
+ .driver = {
+ .name = "mt6323-pwrc",
+ .of_match_table = mt6323_pwrc_dt_match,
+ },
+};
+
+module_platform_driver(mt6323_pwrc_driver);
+
+MODULE_DESCRIPTION("Poweroff driver for MT6323 PMIC");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/mt6397/core.h b/include/linux/mfd/mt6397/core.h
index 25a95e72179b..652da61e3711 100644
--- a/include/linux/mfd/mt6397/core.h
+++ b/include/linux/mfd/mt6397/core.h
@@ -7,6 +7,8 @@
#ifndef __MFD_MT6397_CORE_H__
#define __MFD_MT6397_CORE_H__
+#include <linux/mutex.h>
+
enum mt6397_irq_numbers {
MT6397_IRQ_SPKL_AB = 0,
MT6397_IRQ_SPKR_AB,
--
2.17.1
^ permalink raw reply related
* [PATCH v4 07/10] mfd: mt6323: add mt6323 rtc+pwrc
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana, Rob Herring, Sean Wang,
Sebastian Reichel <sre>
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add entry for rtc and power-controller to mt6323
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: none
changes since v2: only splitting, second part of v2 part 4
drivers/mfd/mt6397-core.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 5f7070267c9a..a4abce00f156 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -16,13 +16,24 @@
#include <linux/mfd/mt6397/registers.h>
#include <linux/mfd/mt6323/registers.h>
+#define MT6323_RTC_BASE 0x8000
+#define MT6323_RTC_SIZE 0x40
+
#define MT6397_RTC_BASE 0xe000
#define MT6397_RTC_SIZE 0x3e
+#define MT6323_PWRC_BASE 0x8000
+#define MT6323_PWRC_SIZE 0x40
+
#define MT6323_CID_CODE 0x23
#define MT6391_CID_CODE 0x91
#define MT6397_CID_CODE 0x97
+static const struct resource mt6323_rtc_resources[] = {
+ DEFINE_RES_MEM(MT6323_RTC_BASE, MT6323_RTC_SIZE),
+ DEFINE_RES_IRQ(MT6323_IRQ_STATUS_RTC),
+};
+
static const struct resource mt6397_rtc_resources[] = {
DEFINE_RES_MEM(MT6397_RTC_BASE, MT6397_RTC_SIZE),
DEFINE_RES_IRQ(MT6397_IRQ_RTC),
@@ -38,8 +49,17 @@ static const struct resource mt6397_keys_resources[] = {
DEFINE_RES_IRQ(MT6397_IRQ_HOMEKEY),
};
+static const struct resource mt6323_pwrc_resources[] = {
+ DEFINE_RES_MEM(MT6323_PWRC_BASE, MT6323_PWRC_SIZE),
+};
+
static const struct mfd_cell mt6323_devs[] = {
{
+ .name = "mt6323-rtc",
+ .num_resources = ARRAY_SIZE(mt6323_rtc_resources),
+ .resources = mt6323_rtc_resources,
+ .of_compatible = "mediatek,mt6323-rtc",
+ }, {
.name = "mt6323-regulator",
.of_compatible = "mediatek,mt6323-regulator"
}, {
@@ -50,6 +70,11 @@ static const struct mfd_cell mt6323_devs[] = {
.num_resources = ARRAY_SIZE(mt6323_keys_resources),
.resources = mt6323_keys_resources,
.of_compatible = "mediatek,mt6323-keys"
+ }, {
+ .name = "mt6323-pwrc",
+ .num_resources = ARRAY_SIZE(mt6323_pwrc_resources),
+ .resources = mt6323_pwrc_resources,
+ .of_compatible = "mediatek,mt6323-pwrc"
},
};
--
2.17.1
^ permalink raw reply related
* [PATCH v4 06/10] rtc: mt6397: add compatible for mt6323
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
use mt6397 rtc driver also for mt6323 but with different
base/size see "mfd: mt6323: add mt6323 rtc+pwrc"
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: moved (was part 5)
changes since v2: splitted this from v2.3 suggested-by Alexandre Belloni
drivers/rtc/rtc-mt6397.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 9370b7fc9f81..21cd9cc8b4c7 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -325,6 +325,7 @@ static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
mt6397_rtc_resume);
static const struct of_device_id mt6397_rtc_of_match[] = {
+ { .compatible = "mediatek,mt6323-rtc", },
{ .compatible = "mediatek,mt6397-rtc", },
{ }
};
--
2.17.1
^ permalink raw reply related
* [PATCH v4 05/10] mfd: mt6323: some improvements of mt6397-core
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
simplyfications (resource definitions my DEFINE_RES_* macros)
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: moved part 6 forward to let compatible and driver be together
changes since v2: splitted v2 part 4 into 6+7
drivers/mfd/mt6397-core.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 337bcccdb914..5f7070267c9a 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -1,10 +1,11 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2014 MediaTek Inc.
+ * Copyright (c) 2014-2018 MediaTek Inc.
* Author: Flora Fu, MediaTek
*/
#include <linux/interrupt.h>
+#include <linux/ioport.h>
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
@@ -23,16 +24,8 @@
#define MT6397_CID_CODE 0x97
static const struct resource mt6397_rtc_resources[] = {
- {
- .start = MT6397_RTC_BASE,
- .end = MT6397_RTC_BASE + MT6397_RTC_SIZE,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = MT6397_IRQ_RTC,
- .end = MT6397_IRQ_RTC,
- .flags = IORESOURCE_IRQ,
- },
+ DEFINE_RES_MEM(MT6397_RTC_BASE, MT6397_RTC_SIZE),
+ DEFINE_RES_IRQ(MT6397_IRQ_RTC),
};
static const struct resource mt6323_keys_resources[] = {
--
2.17.1
^ permalink raw reply related
* [PATCH v4 04/10] rtc: mt6397: improvements of rtc driver
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
- use regmap_read_poll_timeout to drop while-loop
- use devm-api to drop remove-callback
Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: none
changes since v2:
- fix allocation after irq-request
- compatible for mt6323 in separate commit => part 5
drivers/rtc/rtc-mt6397.c | 51 +++++++++++++++-------------------------
1 file changed, 19 insertions(+), 32 deletions(-)
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index c08ee5edf865..9370b7fc9f81 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -4,16 +4,19 @@
* Author: Tianping.Fang <tianping.fang@mediatek.com>
*/
-#include <linux/delay.h>
-#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/mt6397/core.h>
#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/rtc.h>
#include <linux/mfd/mt6397/rtc.h>
+#include <linux/mod_devicetable.h>
static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
{
- unsigned long timeout = jiffies + HZ;
int ret;
u32 data;
@@ -21,19 +24,13 @@ static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
if (ret < 0)
return ret;
- while (1) {
- ret = regmap_read(rtc->regmap, rtc->addr_base + RTC_BBPU,
- &data);
- if (ret < 0)
- break;
- if (!(data & RTC_BBPU_CBUSY))
- break;
- if (time_after(jiffies, timeout)) {
- ret = -ETIMEDOUT;
- break;
- }
- cpu_relax();
- }
+ ret = regmap_read_poll_timeout(rtc->regmap,
+ rtc->addr_base + RTC_BBPU, data,
+ !(data & RTC_BBPU_CBUSY),
+ MTK_RTC_POLL_DELAY_US,
+ MTK_RTC_POLL_TIMEOUT);
+ if (ret < 0)
+ dev_err(rtc->dev, "failed to write WRTGE: %d\n", ret);
return ret;
}
@@ -266,19 +263,19 @@ static int mtk_rtc_probe(struct platform_device *pdev)
return rtc->irq;
rtc->regmap = mt6397_chip->regmap;
- rtc->dev = &pdev->dev;
mutex_init(&rtc->lock);
platform_set_drvdata(pdev, rtc);
- rtc->rtc_dev = devm_rtc_allocate_device(rtc->dev);
+ rtc->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc->rtc_dev))
return PTR_ERR(rtc->rtc_dev);
- ret = request_threaded_irq(rtc->irq, NULL,
- mtk_rtc_irq_handler_thread,
- IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
- "mt6397-rtc", rtc);
+ ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
+ mtk_rtc_irq_handler_thread,
+ IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
+ "mt6397-rtc", rtc);
+
if (ret) {
dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
rtc->irq, ret);
@@ -302,15 +299,6 @@ static int mtk_rtc_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_rtc_remove(struct platform_device *pdev)
-{
- struct mt6397_rtc *rtc = platform_get_drvdata(pdev);
-
- free_irq(rtc->irq, rtc);
-
- return 0;
-}
-
#ifdef CONFIG_PM_SLEEP
static int mt6397_rtc_suspend(struct device *dev)
{
@@ -349,7 +337,6 @@ static struct platform_driver mtk_rtc_driver = {
.pm = &mt6397_pm_ops,
},
.probe = mtk_rtc_probe,
- .remove = mtk_rtc_remove,
};
module_platform_driver(mtk_rtc_driver);
--
2.17.1
^ permalink raw reply related
* [PATCH v4 03/10] rtc: mt6397: move some common definitions into rtc.h
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree-u79uwXL29TY76Z2rM5mHXA, Eddie Huang,
Greg Kroah-Hartman, Jonathan Cameron, Kate Stewart, Lee Jones,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-rtc-u79uwXL29TY76Z2rM5mHXA,
Mark Rutland, Matthias Brugger, Mauro Carvalho Chehab,
Nicolas Ferre, Richard Fontana, Rob Herring, Sean Wang,
Sebastian Reichel <sre>
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w-SipyoOjXbOMoAHOVJHB0wA@public.gmane.org>
From: Josef Friedl <josef.friedl-D4IDLmZPRBc@public.gmane.org>
move code to separate header-file to reuse definitions later
in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)
Suggested-by: Frank Wunderlich <frank-w-SipyoOjXbOMoAHOVJHB0wA@public.gmane.org>
Signed-off-by: Josef Friedl <josef.friedl-D4IDLmZPRBc@public.gmane.org>
Signed-off-by: Frank Wunderlich <frank-w-SipyoOjXbOMoAHOVJHB0wA@public.gmane.org>
---
changes since v3: none
changes since v2: add missing commit-message
drivers/rtc/rtc-mt6397.c | 55 +-------------------------
include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 54 deletions(-)
create mode 100644 include/linux/mfd/mt6397/rtc.h
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index b46ed4dc7015..c08ee5edf865 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -9,60 +9,7 @@
#include <linux/module.h>
#include <linux/regmap.h>
#include <linux/rtc.h>
-#include <linux/irqdomain.h>
-#include <linux/platform_device.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/io.h>
-#include <linux/mfd/mt6397/core.h>
-
-#define RTC_BBPU 0x0000
-#define RTC_BBPU_CBUSY BIT(6)
-
-#define RTC_WRTGR 0x003c
-
-#define RTC_IRQ_STA 0x0002
-#define RTC_IRQ_STA_AL BIT(0)
-#define RTC_IRQ_STA_LP BIT(3)
-
-#define RTC_IRQ_EN 0x0004
-#define RTC_IRQ_EN_AL BIT(0)
-#define RTC_IRQ_EN_ONESHOT BIT(2)
-#define RTC_IRQ_EN_LP BIT(3)
-#define RTC_IRQ_EN_ONESHOT_AL (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
-
-#define RTC_AL_MASK 0x0008
-#define RTC_AL_MASK_DOW BIT(4)
-
-#define RTC_TC_SEC 0x000a
-/* Min, Hour, Dom... register offset to RTC_TC_SEC */
-#define RTC_OFFSET_SEC 0
-#define RTC_OFFSET_MIN 1
-#define RTC_OFFSET_HOUR 2
-#define RTC_OFFSET_DOM 3
-#define RTC_OFFSET_DOW 4
-#define RTC_OFFSET_MTH 5
-#define RTC_OFFSET_YEAR 6
-#define RTC_OFFSET_COUNT 7
-
-#define RTC_AL_SEC 0x0018
-
-#define RTC_PDN2 0x002e
-#define RTC_PDN2_PWRON_ALARM BIT(4)
-
-#define RTC_MIN_YEAR 1968
-#define RTC_BASE_YEAR 1900
-#define RTC_NUM_YEARS 128
-#define RTC_MIN_YEAR_OFFSET (RTC_MIN_YEAR - RTC_BASE_YEAR)
-
-struct mt6397_rtc {
- struct device *dev;
- struct rtc_device *rtc_dev;
- struct mutex lock;
- struct regmap *regmap;
- int irq;
- u32 addr_base;
-};
+#include <linux/mfd/mt6397/rtc.h>
static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
{
diff --git a/include/linux/mfd/mt6397/rtc.h b/include/linux/mfd/mt6397/rtc.h
new file mode 100644
index 000000000000..b702c29e8c74
--- /dev/null
+++ b/include/linux/mfd/mt6397/rtc.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2014-2018 MediaTek Inc.
+ *
+ * Author: Tianping.Fang <tianping.fang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
+ * Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
+ */
+
+#ifndef _LINUX_MFD_MT6397_RTC_H_
+#define _LINUX_MFD_MT6397_RTC_H_
+
+#include <linux/jiffies.h>
+#include <linux/mutex.h>
+#include <linux/regmap.h>
+#include <linux/rtc.h>
+
+#define RTC_BBPU 0x0000
+#define RTC_BBPU_CBUSY BIT(6)
+#define RTC_BBPU_KEY (0x43 << 8)
+
+#define RTC_WRTGR 0x003c
+
+#define RTC_IRQ_STA 0x0002
+#define RTC_IRQ_STA_AL BIT(0)
+#define RTC_IRQ_STA_LP BIT(3)
+
+#define RTC_IRQ_EN 0x0004
+#define RTC_IRQ_EN_AL BIT(0)
+#define RTC_IRQ_EN_ONESHOT BIT(2)
+#define RTC_IRQ_EN_LP BIT(3)
+#define RTC_IRQ_EN_ONESHOT_AL (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
+
+#define RTC_AL_MASK 0x0008
+#define RTC_AL_MASK_DOW BIT(4)
+
+#define RTC_TC_SEC 0x000a
+/* Min, Hour, Dom... register offset to RTC_TC_SEC */
+#define RTC_OFFSET_SEC 0
+#define RTC_OFFSET_MIN 1
+#define RTC_OFFSET_HOUR 2
+#define RTC_OFFSET_DOM 3
+#define RTC_OFFSET_DOW 4
+#define RTC_OFFSET_MTH 5
+#define RTC_OFFSET_YEAR 6
+#define RTC_OFFSET_COUNT 7
+
+#define RTC_AL_SEC 0x0018
+
+#define RTC_PDN2 0x002e
+#define RTC_PDN2_PWRON_ALARM BIT(4)
+
+#define RTC_MIN_YEAR 1968
+#define RTC_BASE_YEAR 1900
+#define RTC_NUM_YEARS 128
+#define RTC_MIN_YEAR_OFFSET (RTC_MIN_YEAR - RTC_BASE_YEAR)
+
+#define MTK_RTC_POLL_DELAY_US 10
+#define MTK_RTC_POLL_TIMEOUT (jiffies_to_usecs(HZ))
+
+struct mt6397_rtc {
+ struct device *dev;
+ struct rtc_device *rtc_dev;
+
+ /* Protect register access from multiple tasks */
+ struct mutex lock;
+ struct regmap *regmap;
+ int irq;
+ u32 addr_base;
+};
+
+#endif /* _LINUX_MFD_MT6397_RTC_H_ */
--
2.17.1
^ permalink raw reply related
* [PATCH v4 02/10] dt-bindings: add missing mt6397 rtc
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana, Rob Herring, Sean Wang,
Sebastian Reichel <sre>
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add missing devicetree-binding document for mt6397 rtc
in later patch driver is extended with mt6323 chip
Suggested-By: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: moved SOB
changes since v2: splitted rtc-mt6397.txt from first patch
.../devicetree/bindings/rtc/rtc-mt6397.txt | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
new file mode 100644
index 000000000000..ebd1cf80dcc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
@@ -0,0 +1,29 @@
+Device-Tree bindings for MediaTek PMIC based RTC
+
+MediaTek PMIC based RTC is an independent function of MediaTek PMIC that works
+as a type of multi-function device (MFD). The RTC can be configured and set up
+with PMIC wrapper bus which is a common resource shared with the other
+functions found on the same PMIC.
+
+For MediaTek PMIC MFD bindings, see:
+Documentation/devicetree/bindings/mfd/mt6397.txt
+
+For MediaTek PMIC wrapper bus bindings, see:
+Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+
+Required properties:
+- compatible: Should be one of follows
+ "mediatek,mt6323-rtc": for MT6323 PMIC
+ "mediatek,mt6397-rtc": for MT6397 PMIC
+
+Example:
+
+ pmic {
+ compatible = "mediatek,mt6323";
+
+ ...
+
+ rtc {
+ compatible = "mediatek,mt6323-rtc";
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v4 01/10] dt-bindings: add powercontroller
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190806162745.8414-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add mt6323-rtc and mt6323-pwrc to mt6397 mfd DT bindings
an example is shown in mt6323-poweroff.txt
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes since v3: none
changes since v2: separated rtc-mt6397.txt to part 2
.../devicetree/bindings/mfd/mt6397.txt | 10 +++++++++-
.../bindings/power/reset/mt6323-poweroff.txt | 20 +++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
index 0ebd08af777d..44acb9827716 100644
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -8,6 +8,7 @@ MT6397/MT6323 is a multifunction device with the following sub modules:
- Clock
- LED
- Keys
+- Power controller
It is interfaced to host controller using SPI interface by a proprietary hardware
called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
@@ -22,8 +23,10 @@ compatible: "mediatek,mt6397" or "mediatek,mt6323"
Optional subnodes:
- rtc
- Required properties:
+ Required properties: Should be one of follows
+ - compatible: "mediatek,mt6323-rtc"
- compatible: "mediatek,mt6397-rtc"
+ For details, see Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
- regulators
Required properties:
- compatible: "mediatek,mt6397-regulator"
@@ -46,6 +49,11 @@ Optional subnodes:
- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
see Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
+- power-controller
+ Required properties:
+ - compatible: "mediatek,mt6323-pwrc"
+ For details, see Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
+
Example:
pwrap: pwrap@1000f000 {
compatible = "mediatek,mt8135-pwrap";
diff --git a/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
new file mode 100644
index 000000000000..933f0c48e887
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
@@ -0,0 +1,20 @@
+Device Tree Bindings for Power Controller on MediaTek PMIC
+
+The power controller which could be found on PMIC is responsible for externally
+powering off or on the remote MediaTek SoC through the circuit BBPU.
+
+Required properties:
+- compatible: Should be one of follows
+ "mediatek,mt6323-pwrc": for MT6323 PMIC
+
+Example:
+
+ pmic {
+ compatible = "mediatek,mt6323";
+
+ ...
+
+ power-controller {
+ compatible = "mediatek,mt6323-pwrc";
+ };
+ }
--
2.17.1
^ permalink raw reply related
* [PATCH v4 00/10] implement poweroff for mt6323 / bpi-r2
From: Frank Wunderlich @ 2019-08-06 16:27 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana
Cc: Frank Wunderlich
mainline-driver does not support mt6323
this series makes some cleanup to mt6397-rtc-driver, adds mt6323 and
implement power-controller on it.
tested on bananapi-r2
Original Patch from Josef Friedl
changes since v3:
- moved SOB in 2/10 and 9/10
- moved part 5 to 6 to be near driver-change
- changehistory of patches below ---
changes since v2:
- Splitted some parts and rebased on 5.3-rc2:
v2.1 dt-bindings: add powercontroller – try to make better subject
v2.2 separate rtc-mt6397.txt (suggested by Alexandre Belloni)
add missing commit-message (suggested by Matthias Brugger)
v2.3 fix alloc after IRQ (suggested by Alexandre Belloni)
new compatible (splitting suggested by Alexandre Belloni)
needed due to different rtc-base/size see #7
v2.4 simplifications (Define-res-macros)
add mt6323 rtc+pwrc
v2.5 add poweroff-driver (no change)
v2.6 MAINTAINERS (no change)
v2.7 DTS-Changes (no change)
Josef Friedl (10):
dt-bindings: add powercontroller
dt-bindings: add missing mt6397 rtc
rtc: mt6397: move some common definitions into rtc.h
rtc: mt6397: improvements of rtc driver
mfd: mt6323: some improvements of mt6397-core
rtc: mt6397: add compatible for mt6323
mfd: mt6323: add mt6323 rtc+pwrc
power: reset: add driver for mt6323 poweroff
MAINTAINERS: add Mediatek shutdown drivers
arm: dts: mt6323: add keys, power-controller, rtc and codec
.../devicetree/bindings/mfd/mt6397.txt | 10 +-
.../bindings/power/reset/mt6323-poweroff.txt | 20 ++++
.../devicetree/bindings/rtc/rtc-mt6397.txt | 29 +++++
MAINTAINERS | 7 ++
arch/arm/boot/dts/mt6323.dtsi | 27 +++++
drivers/mfd/mt6397-core.c | 40 +++++--
drivers/power/reset/Kconfig | 10 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/mt6323-poweroff.c | 97 ++++++++++++++++
drivers/rtc/rtc-mt6397.c | 107 ++++--------------
include/linux/mfd/mt6397/core.h | 2 +
include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++
12 files changed, 323 insertions(+), 98 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
create mode 100644 drivers/power/reset/mt6323-poweroff.c
create mode 100644 include/linux/mfd/mt6397/rtc.h
--
2.17.1
^ permalink raw reply
* Re: [v2,2/2] PCI: mediatek: Add controller support for MT7629
From: Lorenzo Pieralisi @ 2019-08-06 16:24 UTC (permalink / raw)
To: Jianjun Wang, Bjorn Helgaas
Cc: Ryder Lee, Rob Herring, Mark Rutland, Matthias Brugger, linux-pci,
linux-mediatek, devicetree, linux-kernel, linux-arm-kernel,
youlin.pei
In-Reply-To: <1564385918.17211.6.camel@mhfsdcap03>
[trim the CC list please to keep only required maintainers]
On Mon, Jul 29, 2019 at 03:38:38PM +0800, Jianjun Wang wrote:
> On Fri, 2019-06-28 at 15:34 +0800, Jianjun Wang wrote:
> > MT7629 is an ARM platform SoC which has the same PCIe IP with MT7622.
> >
> > The HW default value of its Device ID is invalid, fix its Device ID to
> > match the hardware implementation.
> >
> > Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> > Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> > ---
> > drivers/pci/controller/pcie-mediatek.c | 18 ++++++++++++++++++
> > include/linux/pci_ids.h | 1 +
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > index 80601e1b939e..e5e6740b635d 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -73,6 +73,7 @@
> > #define PCIE_MSI_VECTOR 0x0c0
> >
> > #define PCIE_CONF_VEND_ID 0x100
> > +#define PCIE_CONF_DEVICE_ID 0x102
> > #define PCIE_CONF_CLASS_ID 0x106
> >
> > #define PCIE_INT_MASK 0x420
> > @@ -141,12 +142,16 @@ struct mtk_pcie_port;
> > /**
> > * struct mtk_pcie_soc - differentiate between host generations
> > * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> > + * @need_fix_device_id: whether this host's Device ID needed to be fixed or not
> > + * @device_id: Device ID which this host need to be fixed
> > * @ops: pointer to configuration access functions
> > * @startup: pointer to controller setting functions
> > * @setup_irq: pointer to initialize IRQ functions
> > */
> > struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > + bool need_fix_device_id;
> > + unsigned int device_id;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -696,6 +701,9 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> > writew(val, port->base + PCIE_CONF_CLASS_ID);
> > }
> >
> > + if (soc->need_fix_device_id)
> > + writew(soc->device_id, port->base + PCIE_CONF_DEVICE_ID);
> > +
> > /* 100ms timeout value should be enough for Gen1/2 training */
> > err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > !!(val & PCIE_PORT_LINKUP_V2), 20,
> > @@ -1216,11 +1224,21 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 = {
> > .setup_irq = mtk_pcie_setup_irq,
> > };
> >
> > +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> > + .need_fix_class_id = true,
> > + .need_fix_device_id = true,
> > + .device_id = PCI_DEVICE_ID_MEDIATEK_7629,
> > + .ops = &mtk_pcie_ops_v2,
> > + .startup = mtk_pcie_startup_port_v2,
> > + .setup_irq = mtk_pcie_setup_irq,
> > +};
> > +
> > static const struct of_device_id mtk_pcie_ids[] = {
> > { .compatible = "mediatek,mt2701-pcie", .data = &mtk_pcie_soc_v1 },
> > { .compatible = "mediatek,mt7623-pcie", .data = &mtk_pcie_soc_v1 },
> > { .compatible = "mediatek,mt2712-pcie", .data = &mtk_pcie_soc_mt2712 },
> > { .compatible = "mediatek,mt7622-pcie", .data = &mtk_pcie_soc_mt7622 },
> > + { .compatible = "mediatek,mt7629-pcie", .data = &mtk_pcie_soc_mt7629 },
> > {},
> > };
> >
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 70e86148cb1e..aa32962759b2 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2131,6 +2131,7 @@
> > #define PCI_VENDOR_ID_MYRICOM 0x14c1
> >
> > #define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > +#define PCI_DEVICE_ID_MEDIATEK_7629 0x7629
> >
> > #define PCI_VENDOR_ID_TITAN 0x14D2
> > #define PCI_DEVICE_ID_TITAN_010L 0x8001
>
> Hi Bjorn & Lorenzo,
>
> Is this patch ok or is there anything I need to fixed?
The commit log need to be fixed and I will do it, the code if
Bjorn is OK with it I can merge it.
Lorenzo
^ permalink raw reply
* Re: [PATCH RFC 5/7] pwm: rcar: remove a redundant condition in rcar_pwm_apply()
From: Uwe Kleine-König @ 2019-08-06 16:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Linus Walleij, Geert Uytterhoeven,
Thierry Reding, Rob Herring, Mark Rutland,
open list:GPIO SUBSYSTEM, Linux PWM List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas
In-Reply-To: <CAMuHMdWw1Gh_CxgiO5gd+MY0vUvWX_ACDj+L3_Wcomkaf5Oo4Q@mail.gmail.com>
Hello,
On Tue, Aug 06, 2019 at 11:05:30AM +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 8, 2019 at 11:08 AM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > Since the rcar_pwm_apply() has already check whehter state->enabled
> > is not set or not, this patch removes a redundant condition.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> This is completely independent from the rest of the series, and can be applied
> immediately, right?
The original patch didn't make it into my mailbox. I only see a few
replies. Is it only me?
https://patchwork.ozlabs.org/project/linux-pwm/list/ doesn't seem to
have it either.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v8 4/4] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: megous-5qf/QAjKc83QT0dZR+AlfA @ 2019-08-06 15:57 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Maxime Ripard, Chen-Yu Tsai,
Rob Herring, Jernej Škrabec
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20190806155744.10263-1-megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
This is realized by the ddc-en-gpios property.
Signed-off-by: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 2c6807b74ff6..01bb1bafe284 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -22,6 +22,18 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -72,6 +84,10 @@
cpu-supply = <®_dcdca>;
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -91,6 +107,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.22.0
^ permalink raw reply related
* [PATCH v8 3/4] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
From: megous @ 2019-08-06 15:57 UTC (permalink / raw)
To: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Jernej Škrabec
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel,
Jernej Skrabec
In-Reply-To: <20190806155744.10263-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
for the DDC bus to be usable.
Add support for hdmi-connector node's optional ddc-en-gpios property to
support this use case.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 +++++++++++++++++++++++++--
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 8ca5af0c912f..a44dca4b0219 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -97,10 +97,34 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct drm_device *drm,
return crtcs;
}
+static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
+ struct platform_device **pdev_out)
+{
+ struct platform_device *pdev;
+ struct device_node *remote;
+
+ remote = of_graph_get_remote_node(dev->of_node, 1, -1);
+ if (!remote)
+ return -ENODEV;
+
+ if (!of_device_is_compatible(remote, "hdmi-connector")) {
+ of_node_put(remote);
+ return -ENODEV;
+ }
+
+ pdev = of_find_device_by_node(remote);
+ of_node_put(remote);
+ if (!pdev)
+ return -ENODEV;
+
+ *pdev_out = pdev;
+ return 0;
+}
+
static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
+ struct platform_device *pdev = to_platform_device(dev), *connector_pdev;
struct dw_hdmi_plat_data *plat_data;
struct drm_device *drm = data;
struct device_node *phy_node;
@@ -150,16 +174,30 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
return PTR_ERR(hdmi->regulator);
}
+ ret = sun8i_dw_hdmi_find_connector_pdev(dev, &connector_pdev);
+ if (!ret) {
+ hdmi->ddc_en = gpiod_get_optional(&connector_pdev->dev,
+ "ddc-en", GPIOD_OUT_HIGH);
+ platform_device_put(connector_pdev);
+
+ if (IS_ERR(hdmi->ddc_en)) {
+ dev_err(dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(hdmi->ddc_en);
+ }
+ }
+
ret = regulator_enable(hdmi->regulator);
if (ret) {
dev_err(dev, "Failed to enable regulator\n");
- return ret;
+ goto err_unref_ddc_en;
}
+ gpiod_set_value(hdmi->ddc_en, 1);
+
ret = reset_control_deassert(hdmi->rst_ctrl);
if (ret) {
dev_err(dev, "Could not deassert ctrl reset control\n");
- goto err_disable_regulator;
+ goto err_disable_ddc_en;
}
ret = clk_prepare_enable(hdmi->clk_tmds);
@@ -212,8 +250,12 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
clk_disable_unprepare(hdmi->clk_tmds);
err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
-err_disable_regulator:
+err_disable_ddc_en:
+ gpiod_set_value(hdmi->ddc_en, 0);
regulator_disable(hdmi->regulator);
+err_unref_ddc_en:
+ if (hdmi->ddc_en)
+ gpiod_put(hdmi->ddc_en);
return ret;
}
@@ -227,7 +269,11 @@ static void sun8i_dw_hdmi_unbind(struct device *dev, struct device *master,
sun8i_hdmi_phy_remove(hdmi);
clk_disable_unprepare(hdmi->clk_tmds);
reset_control_assert(hdmi->rst_ctrl);
+ gpiod_set_value(hdmi->ddc_en, 0);
regulator_disable(hdmi->regulator);
+
+ if (hdmi->ddc_en)
+ gpiod_put(hdmi->ddc_en);
}
static const struct component_ops sun8i_dw_hdmi_ops = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 720c5aa8adc1..d707c9171824 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -9,6 +9,7 @@
#include <drm/bridge/dw_hdmi.h>
#include <drm/drm_encoder.h>
#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/reset.h>
@@ -190,6 +191,7 @@ struct sun8i_dw_hdmi {
struct regulator *regulator;
const struct sun8i_dw_hdmi_quirks *quirks;
struct reset_control *rst_ctrl;
+ struct gpio_desc *ddc_en;
};
static inline struct sun8i_dw_hdmi *
--
2.22.0
^ permalink raw reply related
* [PATCH v8 2/4] dt-bindings: display: hdmi-connector: Support DDC bus enable
From: megous-5qf/QAjKc83QT0dZR+AlfA @ 2019-08-06 15:57 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Maxime Ripard, Chen-Yu Tsai,
Rob Herring, Jernej Škrabec
Cc: Ondrej Jirman, David Airlie, Daniel Vetter, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <20190806155744.10263-1-megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
on-board voltage shifting logic for the DDC bus using a gpio to be able
to access DDC bus. Use ddc-en-gpios property on the hdmi-connector to
model this.
Add binding documentation for optional ddc-en-gpios property.
Signed-off-by: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/display/connector/hdmi-connector.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
index 508aee461e0d..aeb07c4bd703 100644
--- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
+++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
@@ -9,6 +9,7 @@ Optional properties:
- label: a symbolic name for the connector
- hpd-gpios: HPD GPIO number
- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
+- ddc-en-gpios: signal to enable DDC bus
Required nodes:
- Video port for HDMI input
--
2.22.0
^ permalink raw reply related
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