Hi Jones,
> Subject
>
> Re: [PATCH v13 3/3] dt-bindings: mfd: Document Renesas R-Car Gen3 RPC-IF
> controller bindings
>
> Hello!
>
> On 06/03/2019 04:04 PM, Lee Jones wrote:
>
> >>> Document the bindings used by the Renesas R-Car Gen3 RPC-IF
controller.
> >>>
> >>> Signed-off-by: Mason Yang <masonccyang@xxxxxxxxxxx>
> >>> ---
> >>> .../devicetree/bindings/mfd/renesas-rpc-if.txt | 65
++++++++++++++++++++++
> >>> 1 file changed, 65 insertions(+)
> >>> create mode 100644
Documentation/devicetree/bindings/mfd/renesas-rpc-if.txt
> >>>
> >>> diff --git
a/Documentation/devicetree/bindings/mfd/renesas-rpc-if.txt b/
> Documentation/devicetree/bindings/mfd/renesas-rpc-if.txt
> >>> new file mode 100644
> >>> index 0000000..20ec85b
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/mfd/renesas-rpc-if.txt
> >>> @@ -0,0 +1,65 @@
> >>> +Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
> >>> +---------------------------------------------------------
> >>> +
> >>> +RPC-IF supports both SPI NOR and HyperFlash (CFI-compliant flash)
> >>> +
> >>> +Required properties:
> >>> +- compatible: should be an SoC-specific compatible value, followed
by
> >>> + "renesas,rcar-gen3-rpc" as a fallback.
> >>> + supported SoC-specific values are:
> >>> + "renesas,r8a77995-rpc" (R-Car D3)
> >>> +- reg: should contain three register areas:
> >>> + first for RPC-IF registers,
> >>> + second for the direct mapping read mode and
> >>> + third for the write buffer area.
> >>> +- reg-names: should contain "regs", "dirmap" and "wbuf"
> >>> +- clocks: should contain 1 entries for the module's clock
> >>> +- clock-names: should contain "rpc"
> >>> +- power-domains: should contain system-controller(sysc) for
power-domain-cell
> >>> +- resets: should contain clock pulse generator(cpg) for reset-cell,
> >>> + power-domain-cell and clock-cell
> >>
> >> That's just some nonsense, sorry...
> >> I suggest that you stop reposting your patches as I'm going to
post
> >> my version of this patchset RSN (based on your patches, of course)
and I'm
> >> going to take care of fixing this file as well.
> >
> > Why is this necessary?
>
> Because Mason doesn't want to develop the HyperFlash driver (or even
move his code
> in preparation to this driver being developed). I must develop this
driver, and I'd
> like to avoid the extra churn of mving the code between the MFD and SPI
drivers.
>
There might be some misunderstandings.
I had been requested to boot R-CAR from the OctaFlash and finally I have
achieved it
by patching SPI framework for OctaFlash operation and RPC-IF SPI driver.
We were aware of the lacking support of RPC-IF in the Linux kernel at that
time and
I though I could contribute what I had developed.
At that time for my first submission of RPC-IF SPI on 15 NOv 2018, there
was no any
HyperFlash (or Hyper Bus) patches. And we did not consider it because the
resource
of HyperFlash was shortage to us.
RPC-IF SPI was applied by Mark on 12,Feb 2019 but Marek comment to add
supporting
MFD for RPC-IF and then I patched RPC-IF to MFD and SPI till this v13.
I always think about:
Is RPC-IF really good/suitable for MFD ?
RPC-IF works either in SPI or HyperFlash is decided by external hardware
pins
configuration and it can NOT switch it's operation mode in the run time.
This is not like my understanding of MFD.
As your comments:
------------------------------------------------------------------------>
> + flash = of_get_next_child(pdev->dev.of_node, NULL);
> + if (!flash) {
> + dev_warn(&pdev->dev, "no flash node
found\n");
> + return -ENODEV;
> + }
> +
> + if (of_device_is_compatible(flash, "jedec,spi-nor")) {
> + cell = &rpc_spi_ctlr;
> + } else if (of_device_is_compatible(flash, "cfi-flash")) {
> + cell = &rpc_hf_ctlr;
> + } else {
> + dev_warn(&pdev->dev, "unknown flash
type\n");
> + return -ENODEV;
> + }
Are there going to be more children coming?
If not, I'd argue that this is not an MFD.
<-------------------------------------------------------------------
I agreed with your opinion and I will resubmit RPC-IF in SPI only
if you also agree with it.
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
