Re: [PATCH v2 3/3] [media] mt9v032: Add V4L2 controls for AEC and AGC
Hi Markus,
Thank you for the patch.
On Monday 14 December 2015 15:41:53 Markus Pargmann wrote:
> This patch adds V4L2 controls for Auto Exposure Control and Auto Gain
> Control settings. These settings include low pass filter, update
> frequency of these settings and the update interval for those units.
>
> Signed-off-by: Markus Pargmann
Please see below for a few comments. If you agree about them there's no need
to resubmit, I'll fix the patch when applying.
> ---
> drivers/media/i2c/mt9v032.c | 153 -
> 1 file changed, 152 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> index cc16acf001de..6cbc3b87eda9 100644
> --- a/drivers/media/i2c/mt9v032.c
> +++ b/drivers/media/i2c/mt9v032.c
[snip]
> enum mt9v032_model {
> @@ -162,6 +169,8 @@ struct mt9v032_model_data {
> unsigned int min_shutter;
> unsigned int max_shutter;
> unsigned int pclk_reg;
> + unsigned int aec_max_shutter_reg;
> + const struct v4l2_ctrl_config * const aec_max_shutter_v4l2_ctrl;
> };
>
> struct mt9v032_model_info {
> @@ -175,6 +184,9 @@ static const struct mt9v032_model_version
> mt9v032_versions[] = { { MT9V034_CHIP_ID_REV1, "MT9V024/MT9V034 rev1" },
> };
>
> +static const struct v4l2_ctrl_config mt9v032_aec_max_shutter_width;
> +static const struct v4l2_ctrl_config mt9v034_aec_max_shutter_width;
We can avoid forward declarations by moving the mt9v032_model_data array
further down in the driver.
> static const struct mt9v032_model_data mt9v032_model_data[] = {
> {
> /* MT9V022, MT9V032 revisions 1/2/3 */
[snip]
> @@ 647,6 +663,33 @@ static int mt9v032_set_selection(struct v4l2_subdev
> *subdev, */
>
> #define V4L2_CID_TEST_PATTERN_COLOR (V4L2_CID_USER_BASE | 0x1001)
> +/*
> + * Value between 1 and 64 to set the desired bin. This is effectively a
> measure + * of how bright the image is supposed to be. Both AGC and AEC try
> to reach + * this.
> + */
> +#define V4L2_CID_AEGC_DESIRED_BIN(V4L2_CID_USER_BASE | 0x1002)
> +/*
> + * LPF is the low pass filter capability of the chip. Both AEC and AGC have
> + * this setting. This limits the speed in which AGC/AEC adjust their
> settings.
> + * Possible values are 0-2. 0 means no LPF. For 1 and 2 this equation is
> used:
> + * if |(Calculated new exp - current exp)| > (current exp / 4)
> + * next exp = Calculated new exp
> + * else
> + * next exp = Current exp + ((Calculated new exp - current exp) /
2^LPF)
Over 80 columns, you can fix it by just reducing the indentation by one tab.
> + */
> +#define V4L2_CID_AEC_LPF (V4L2_CID_USER_BASE | 0x1003)
> +#define V4L2_CID_AGC_LPF (V4L2_CID_USER_BASE | 0x1004)
> +/*
> + * Value between 0 and 15. This is the number of frames being skipped
> before
> + * updating the auto exposure/gain.
> + */
> +#define V4L2_CID_AEC_UPDATE_INTERVAL (V4L2_CID_USER_BASE | 0x1005)
> +#define V4L2_CID_AGC_UPDATE_INTERVAL (V4L2_CID_USER_BASE | 0x1006)
> +/*
> + * Maximum shutter width used for AEC.
> + */
> +#define V4L2_CID_AEC_MAX_SHUTTER_WIDTH (V4L2_CID_USER_BASE | 0x1007)
[snip]
> @@ -745,6 +810,84 @@ static const struct v4l2_ctrl_config
> mt9v032_test_pattern_color = { .flags = 0,
> };
>
> +static const struct v4l2_ctrl_config mt9v032_aegc_controls[] = {
> + {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AEGC_DESIRED_BIN,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "aec_agc_desired_bin",
I forgot to reply to your e-mail asking what proper controls names would be,
sorry.
V4L2 control names contain spaces and use uppercase as needed. This one could
be "AEC/AGC Desired Bin" for instance.
> + .min= 1,
> + .max= 64,
> + .step = 1,
> + .def= 58,
> + .flags = 0,
> + }, {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AEC_LPF,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "aec_lpf",
> + .min= 0,
> + .max= 2,
> + .step = 1,
> + .def= 0,
> + .flags = 0,
> + }, {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AGC_LPF,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "agc_lpf",
> + .min= 0,
> + .max= 2,
> + .step = 1,
> + .def= 2,
> + .flags = 0,
> + }, {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AEC_UPDATE_INTERVAL,
> + .type
Re: [PATCH v4 3/5] dt/bindings: qcom_nandc: Add DT bindings
Hi Archit,
Sorry for the late review, but there are a few things I think should be
addressed.
On Wed, 19 Aug 2015 10:19:04 +0530
Archit Taneja wrote:
> Add DT bindings document for the Qualcomm NAND controller driver.
>
> Cc: devicetree@vger.kernel.org
>
> v4:
> - No changes
>
> v3:
> - Don't use '0x' when specifying nand controller address space
> - Add optional property for on-flash bbt usage
>
> Acked-by: Andy Gross
> Signed-off-by: Archit Taneja
> ---
> .../devicetree/bindings/mtd/qcom_nandc.txt | 49
> ++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> new file mode 100644
> index 000..1de4643
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> @@ -0,0 +1,49 @@
> +* Qualcomm NAND controller
> +
> +Required properties:
> +- compatible:should be "qcom,ebi2-nand" for IPQ806x
> +- reg: MMIO address range
> +- clocks:must contain core clock and always on clock
> +- clock-names: must contain "core" for the core clock and
> "aon" for the
> + always on clock
> +- dmas: DMA specifier, consisting of a phandle to the
> ADM DMA
> + controller node and the channel number to be used for
> + NAND. Refer to dma.txt and qcom_adm.txt for more details
> +- dma-names: must be "rxtx"
> +- qcom,cmd-crci: must contain the ADM command type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +- qcom,data-crci:must contain the ADM data type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +
> +Optional properties:
> +- nand-bus-width:bus width. Must be 8 or 16. If not present, 8 is chosen
> + as default
> +
> +- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8
> + bits. If not present, 4 is chosen as default
> +- nand-on-flash-bbt: Create/use on-flash bad block table
> +
> +The device tree may optionally contain sub-nodes describing partitions of the
> +address space. See partition.txt for more detail.
> +
> +Example:
> +
> +nand@1ac0 {
> + compatible = "qcom,ebi2-nandc";
> + reg = <0x1ac0 0x800>;
> +
> + clocks = <&gcc EBI2_CLK>,
> + <&gcc EBI2_AON_CLK>;
> + clock-names = "core", "aon";
> +
> + dmas = <&adm_dma 3>;
> + dma-names = "rxtx";
> + qcom,cmd-crci = <15>;
> + qcom,data-crci = <3>;
> +
> + partition@0 {
> + ...
> + };
> +};
According to the registers layout defined in your driver, your NAND
controller can address multiple chips (NAND_DEV_SEL register). Since DT
bindings are supposed to be as stable as possible, I would recommend
separating the NAND controller and NAND chip declaration (as done here
[1] and here [2]).
Best Regards,
Boris
[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/5] memory: mediatek: Add SMI driver
On Tue, 2015-12-15 at 13:45 +0800, Daniel Kurtz wrote:
> Hi Yong,
>
> On Tue, Dec 15, 2015 at 10:38 AM, Yong Wu wrote:
> > On Mon, 2015-12-14 at 19:18 +0100, Matthias Brugger wrote:
> >> On Tuesday 08 Dec 2015 17:49:11 Yong Wu wrote:
> >> > This patch add SMI(Smart Multimedia Interface) driver. This driver
> >> > is responsible to enable/disable iommu and control the power domain
> >> > and clocks of each local arbiter.
> >> >
> >> > Signed-off-by: Yong Wu
> >> > ---
> >> > Currently SMI offer mtk_smi_larb_get/put to enable the power-domain
> >> > ,clocks and initialize the iommu configuration register for each a local
> >> > arbiter, The reason is:
> >> > a) If a device would like to disable iommu, it also need call
> >> > mtk_smi_larb_get/put to enable its power and clocks.
> >> > b) The iommu core don't support attach/detach a device within a
> >> > iommu-group. So we cann't use iommu_attach_device(iommu_detach_device)
> >> > instead
> >> > of mtk_smi_larb_get/put.
> >> >
> > [..]
> >> > +static int
> >> > +mtk_smi_enable(struct device *dev, struct clk *apb, struct clk *smi)
> >> > +{
> >> > + int ret;
> >> > +
> >> > + ret = pm_runtime_get_sync(dev);
> >> > + if (ret < 0)
> >> > + return ret;
> >> > +
> >> > + ret = clk_prepare_enable(apb);
> >> > + if (ret)
> >> > + goto err_put_pm;
> >> > +
> >> > + ret = clk_prepare_enable(smi);
> >> > + if (ret)
> >> > + goto err_disable_apb;
> >> > +
> >> > + return 0;
> >> > +
> >> > +err_disable_apb:
> >> > + clk_disable_unprepare(apb);
> >> > +err_put_pm:
> >> > + pm_runtime_put_sync(dev);
> >> > + return ret;
> >> > +}
> >> > +
> >> > +static void
> >> > +mtk_smi_disable(struct device *dev, struct clk *apb, struct clk *smi)
> >> > +{
> >> > + clk_disable_unprepare(smi);
> >> > + clk_disable_unprepare(apb);
> >> > + pm_runtime_put_sync(dev);
> >> > +}
> >> > +
> >> > +static int mtk_smi_common_enable(struct mtk_smi_common *common)
> >> > +{
> >> > + return mtk_smi_enable(common->dev, common->clk_apb, common->clk_smi);
> >> > +}
> >> > +
> >> > +static void mtk_smi_common_disable(struct mtk_smi_common *common)
> >> > +{
> >> > + mtk_smi_disable(common->dev, common->clk_apb, common->clk_smi);
> >> > +}
> >> > +
> >> > +static int mtk_smi_larb_enable(struct mtk_smi_larb *larb)
> >> > +{
> >> > + return mtk_smi_enable(larb->dev, larb->clk_apb, larb->clk_smi);
> >> > +}
> >> > +
> >> > +static void mtk_smi_larb_disable(struct mtk_smi_larb *larb)
> >> > +{
> >> > + mtk_smi_disable(larb->dev, larb->clk_apb, larb->clk_smi);
> >> > +}
> >> > +
> >>
> >> This is somehow over-engineered. Just use mtk_smi_enable and
> >> mtk_smi_disable
> >> instead of adding an extra indirection.
> >
> > I added this only for readable...then the code in mtk_smi_larb_get below
> > may looks simple and readable.
> >
> > If I use mtk_smi_enable/disable directly, the code will be like our
> > v5[1], is it OK?
> > Maybe I don't need these help function here, and only add more comment
> > based on v5.
> >
> > [1]
> > http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014590.html
>
> bike-shedding...
>
> I like the fact that Yong is trying to make his helpers more type-safe.
> But, perhaps we can rename "struct mtk_smi_common" as "struct
> mtk_smi", and then make "struct mtk_smi_larb" contain a "struct
> mtk_smi":
>
> struct mtk_smi {
> struct device *dev;
> struct clk *clk_apb, *clk_smi;
> }
>
> struct mtk_smi_larb {
> struct mtk_smi;
> ...
> }
>
>
> Then, have:
>
> int mtk_smi_enable(struct mtk_smi *smi)
> {
> clk_enable(smi->clk_apb);
> ...
> }
>
> int mtk_smi_disable(struct mtk_smi *smi)
> {
> }
>
> int mtk_smi_larb_get(struct device *larbdev)
> {
> struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
>
> mtk_smi_enable(common);
> mtk_smi_enable(&larb->smi);
> ...
> }
Thanks. I will change like this in next time.
>
> >>
> >> > +int mtk_smi_larb_get(struct device *larbdev)
> >> > +{
> >> > + struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> >> > + struct mtk_smi_common *common =
> >> > dev_get_drvdata(larb->smi_common_dev);
> >> > + int ret;
> >> > +
> >> > + ret = mtk_smi_common_enable(common);
> >> > + if (ret)
> >> > + return ret;
> >> > +
> >> > + ret = mtk_smi_larb_enable(larb);
> >> > + if (ret)
> >> > + goto err_put_smi;
> >> > +
> >> > + /* Configure the iommu info */
> >> > + writel_relaxed(larb->mmu, larb->base + SMI_LARB_MMU_EN);
>
> I think this should probably be writel() not writel_relaxed, since you
> really do want the barrier to ensure all other register accesses have
> completed before enabling the MMU.
Yes. I will fix this.
>
> >> > +
> >> > + return 0;
> >> > +
> >> > +err_put_smi:
> >> > + mtk_smi_common_disable(common);
> >> > + return ret;
> >> > +}
> >> > +
> >> > +void mtk_smi_larb_put(struct device *larbdev)
> >> > +{
> >> > +
Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver
On Tue, 2015-12-15 at 12:37 +, Robin Murphy wrote:
> On 15/12/15 03:28, Yong Wu wrote:
> > On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote:
> >> On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote:
> >>> +static int mtk_iommu_attach_device(struct iommu_domain *domain,
> >>> +struct device *dev)
> >>> +{
> >>> + struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> >>> + struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
> >>> + struct mtk_iommu_data *data;
> >>> + int ret;
> >>> +
> >>> + if (!priv)
> >>> + return -ENODEV;
> >>> +
> >>> + data = dev_get_drvdata(priv->m4udev);
> >>> + if (!data) {
> >>> + /*
> >>> + * The DMA core will run earlier than this probe, and it will
> >>> + * create a default iommu domain for each a iommu device.
> >>> + * But here there is only one domain called the m4u domain
> >>> + * which all the multimedia HW share.
> >>> + * The default domain isn't needed here.
> >>> + */
> >>
> >> The iommu core creates one domain per iommu-group. In your case this
> >> means one default domain per iommu in the system.
> >
> > Yes. The iommu core will create one domain per iommu-group.
> > see the next "if" here.
> >
> > But the domain here is created by the current DMA64. It's from this
> > function do_iommu_attach which will be called too early and will help
> > create a default domain for each a iommu device.(my codebase is
> > v4.4-rc1).
>
> I still don't really understand the problem here. The M4U device is
> created early in mtk_iommu_init_fn, so it should be probed and ready to
> go long before anything else. Indeed, for your mtk_iommu_device_group()
> callback to work then everything must already be happening in the right
> order - add_device will only call iommu_group_get_for_dev() if of_xlate
> has populated dev->archdata.iommu, and of_xlate will only do that if the
> M4U was up and running before the client device started probing.
> Furthermore, if mtk_iommu_device_group() *does* work, then the IOMMU
> core will go ahead and allocate the default domain there and then, which
> the arch code should find and use later.
Thanks. This is very helpful.
I understand your confuse right now and your expectant flow.
Our IOMMU probe was PROBE_DEFER by our SMI device, so currently it probe
was delayed, then have to add the workaround code.
Following your comment above, I test as below. Then the flows seems meet
the "best case" that the iommu core will help create default DMA domain.
@@ -664,19 +636,41 @@ static int mtk_iommu_probe(struct platform_device
*pdev)
for (i = 0; i < larb_nr; i++) {
struct device_node *larbnode;
struct platform_device *plarbdev;
larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
if (!larbnode)
return -EINVAL;
plarbdev = of_find_device_by_node(larbnode);
of_node_put(larbnode);
- if (!plarbdev)
- return -EPROBE_DEFER;
+ if (!plarbdev) {
+ plarbdev = of_platform_device_create(larbnode,
NULL, platform_bus_type.dev_root);
+ if (IS_ERR(pdev))
+ return -EPROBE_DEFER;
+ }
}
I only add of_platform_device_create for the SMI local arbiter devices
here.
This is a big improvement for us. If this is ok, I will send a quick
next version for this.
>
> The potential issue I *do* see, looking more closely, is that
> iommu_group_get_for_dev() is setting group->domain but not calling the
> attach_dev callback, which looks wrong...
This is the backtrace,
(151216_09:58:05.207)Call trace:
(151216_09:58:05.207)[] mtk_iommu_attach_device
+0xb8/0x178
(151216_09:58:05.207)[] iommu_group_add_device
+0x1d8/0x31c
(151216_09:58:05.207)[] iommu_group_get_for_dev
+0x88/0x108
(151216_09:58:05.207)[] mtk_iommu_add_device+0x14/0x34
(151216_09:58:05.207)[] add_iommu_group+0x20/0x44
(151216_09:58:05.207)[] bus_for_each_dev+0x58/0x98
(151216_09:58:05.207)[] bus_set_iommu+0x9c/0xf8
If I change like above, I will delete the workaround code..
>
> >
> > //=the next "if"===
> > } else if (!data->m4u_dom) {
> > /*
> > * While a device is added into a iommu group, the iommu core
> > * will create a default domain for each a iommu group.
> > * This default domain is reserved as the m4u domain and is
> > * initiated here.
> > */
> > data->m4u_dom = dom;
> > if (domain->type == IOMMU_DOMAIN_DMA) {
> > ret = iommu_dma_init_domain(domain, 0,
> > DMA_BIT_MASK(32));
> > if (ret)
> > goto err_uninit_dom;
> > }
> >
> > ret = mtk_iommu_domain_finalise(data);
> > if (ret)
> > goto err_uninit_dom;
> > }
> > //==
> >
> >>
> >>> +
[PATCH v4 3/3] usb: renesas_usbhs: add device tree support for r8a779[23]
Simply document new compatibility string. As a previous patch adds a generic R-Car Gen2 compatibility string there appears to be no need for a driver updates. Signed-off-by: Simon Horman Acked-by: Rob Herring Acked-by: Kuninori Morimoto --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index 45d9ae13ffa3..b6040563e51a 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -5,6 +5,8 @@ Required properties: - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device + - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device + - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] usb: renesas_usbhs: add SoC names to compatibility string documentation
This extends the documentation of compatibility strings a little to include the SoC names. Signed-off-by: Simon Horman Acked-by: Kuninori Morimoto --- v3 * Split into separate patch --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index 7d48f63db44e..a14c0bb561d5 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -2,10 +2,10 @@ Renesas Electronics USBHS driver Required properties: - compatible: Must contain one of the following: - - "renesas,usbhs-r8a7790" - - "renesas,usbhs-r8a7791" - - "renesas,usbhs-r8a7794" - - "renesas,usbhs-r8a7795" + - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device + - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device + - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device + - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - reg: Base address and length of the register for the USBHS - interrupts: Interrupt specifier for the USBHS - clocks: A list of phandle + clock specifier pairs -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] usb: renesas_usbhs: add fallback compatibility strings
Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: Simon Horman
Acked-by: Kuninori Morimoto
---
v4
* State that one or more compat string should be used
v3
* Moved documentation of SoC names to a separate patch
* Use correct fallback compatibility string in example
v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
a single compatibility string for all of R-Car.
---
Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 12 ++--
drivers/usb/renesas_usbhs/common.c | 9 +
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index a14c0bb561d5..45d9ae13ffa3 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -1,11 +1,19 @@
Renesas Electronics USBHS driver
Required properties:
- - compatible: Must contain one of the following:
+ - compatible: Must contain one or more of the following:
+
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
+ - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+ - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: Base address and length of the register for the USBHS
- interrupts: Interrupt specifier for the USBHS
- clocks: A list of phandle + clock specifier pairs
@@ -22,7 +30,7 @@ Optional properties:
Example:
usbhs: usb@e659 {
- compatible = "renesas,usbhs-r8a7790";
+ compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..db9a17bd8997 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+ {
+ .compatible = "renesas,rcar-gen2-usbhs",
+ .data = (void *)USBHS_TYPE_RCAR_GEN2,
+ },
+ {
+ /* Gen3 is compatible with Gen2 */
+ .compatible = "renesas,rcar-gen3-usbhs",
+ .data = (void *)USBHS_TYPE_RCAR_GEN2,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, usbhs_of_match);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/3] usb: renesas_usbhs: More compat strings
Hi, this short series adds generic, and soc-specific r8a7792 and r8a7793 compat strings to the Renesas USBHS driver. The intention is to provide a complete set of compat strings for known R-Car SoCs. Changes since v3: * State that one or more compat string should be used Changes since v2: * Split documentation of SoC names into separate patch * Use correct fallback compatibility string in example Changes since v1: * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than a single compatibility string for all of R-Car. Simon Horman (3): usb: renesas_usbhs: add SoC names to compatibility string documentation usb: renesas_usbhs: add fallback compatibility strings usb: renesas_usbhs: add device tree support for r8a779[23] .../devicetree/bindings/usb/renesas_usbhs.txt | 22 -- drivers/usb/renesas_usbhs/common.c | 9 + 2 files changed, 25 insertions(+), 6 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] of: Move of_io_request_and_map prototype to correct context
of_io_request_and_map() is defined in of/address.c, which is compiled
if CONFIG_OF_ADDRESS is configured. However, it is defined in the context
of CONFIG_OF. This results in the following build errors for
sparc:allmodconfig (which defines CONFIG_OF but not CONFIG_OF_ADDRESS).
drivers/built-in.o: In function `meson6_timer_init':
meson6_timer.c:(.init.text+0x62a8):
undefined reference to `of_io_request_and_map'
drivers/built-in.o: In function `mtk_timer_init':
mtk_timer.c:(.init.text+0x6e70):
undefined reference to `of_io_request_and_map'
drivers/built-in.o: In function `asm9260_timer_init':
asm9260_timer.c:(.init.text+0x6fcc):
undefined reference to `of_io_request_and_map'
Move function prototype and dummy function into the CONFIG_OF_ADDRESS
conditional to fix the problem.
Exposed by commit bec8c4617611 ("clocksource/drivers/mediatek: Add the
COMPILE_TEST option").
Cc: Daniel Lezcano
Signed-off-by: Guenter Roeck
---
include/linux/of_address.h | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 507daad0bc8d..b5324c0553bd 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -56,6 +56,8 @@ extern struct of_pci_range *of_pci_range_parser_one(
extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
u64 *paddr, u64 *size);
extern bool of_dma_is_coherent(struct device_node *np);
+void __iomem *of_io_request_and_map(struct device_node *device,
+ int index, const char *name);
#else /* CONFIG_OF_ADDRESS */
static inline u64 of_translate_address(struct device_node *np,
@@ -106,18 +108,22 @@ static inline bool of_dma_is_coherent(struct device_node
*np)
{
return false;
}
+
+#include
+
+static inline void __iomem *of_io_request_and_map(struct device_node *device,
+ int index, const char *name)
+{
+ return IOMEM_ERR_PTR(-EINVAL);
+}
#endif /* CONFIG_OF_ADDRESS */
#ifdef CONFIG_OF
extern int of_address_to_resource(struct device_node *dev, int index,
struct resource *r);
void __iomem *of_iomap(struct device_node *node, int index);
-void __iomem *of_io_request_and_map(struct device_node *device,
- int index, const char *name);
#else
-#include
-
static inline int of_address_to_resource(struct device_node *dev, int index,
struct resource *r)
{
@@ -129,11 +135,6 @@ static inline void __iomem *of_iomap(struct device_node
*device, int index)
return NULL;
}
-static inline void __iomem *of_io_request_and_map(struct device_node *device,
- int index, const char *name)
-{
- return IOMEM_ERR_PTR(-EINVAL);
-}
#endif
#if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] thermal: mediatek: Add cpu dynamic power cooling model.
On 16-12-15, 11:59, Dawei Chien wrote: > Use Intelligent Power Allocation (IPA) technical to add dynamic power model > for binding CPU thermal zone. The power allocator governor allocates power > budget to control CPU temperature. > > Power Allocator governor is able to keep SOC temperature within a defined > temperature range to avoid SOC overheat and keep it's performance. > mt8173-cpufreq.c need to register its' own power model with power allocator > thermal governor, so that power allocator governor can allocates suitable > power budget to control CPU temperature. > > Binding document is refer to this patchset > https://lkml.org/lkml/2015/11/30/239 > > Change since V4: > 1. Remove unnecessary error-checking for mt8173-cpufreq.c > 2. Initializing variable capacitance with 0 Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Tue, Dec 15, 2015 at 09:32:18AM -0200, Fabio Estevam wrote: > On Tue, Dec 15, 2015 at 4:28 AM, Peter Chen wrote: > > > Thanks, Fabio. > > > > I am afraid I forget to set gpio as output, would you please apply > > below patch against my original ones: > > Same error happens with these changes applied. > > Here are more details: if I run a pure 4.3.2 then I do see the USB > stick to get detected if I boot it with the USB stick connected to > Udoo board: > > [2.170178] usb 1-1.1: new high-speed USB device number 3 using ci_hdrc > [2.305840] usb-storage 1-1.1:1.0: USB Mass Storage device detected > [2.314803] scsi host1: usb-storage 1-1.1:1.0 > [2.400283] usb 1-1.3: new high-speed USB device number 4 using ci_hdrc > [3.327925] scsi 1:0:0:0: Direct-Access General USB Flash Disk 1.0 > P2 > [3.347070] sd 1:0:0:0: [sda] 7831552 512-byte logical blocks: (4.01 > GB/3.73) > [3.356181] sd 1:0:0:0: [sda] Write Protect is off > [3.362550] sd 1:0:0:0: [sda] No Caching mode page found > [3.367899] sd 1:0:0:0: [sda] Assuming drive cache: write through > [3.387401] sda: sda1 > [3.400238] sd 1:0:0:0: [sda] Attached SCSI removable disk > [4.931847] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow > contx > [4.941414] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > [4.961400] Sending DHCP requests ., OK > [5.380247] IP-Config: Got DHCP answer from 10.29.244.251, my address is > 10.1 > [5.390461] IP-Config: Complete: > [5.393731] device=eth0, hwaddr=00:c0:08:88:0c:b5, > ipaddr=10.29.244.61,4 > [5.404074] host=10.29.244.61, domain=am.freescale.net, > nis-domain=(non) > [5.411362] bootserver=0.0.0.0, rootserver=10.29.244.24, rootpath= > 0 > [5.423964] ALSA device list: > [5.426969] No soundcards found. > [5.469374] VFS: Mounted root (nfs filesystem) readonly on device 0:14. > [5.478119] devtmpfs: mounted > [5.482376] Freeing unused kernel memory: 456K (c0a7e000 - c0af) > starting pid 160, tty '': '/etc/rc.d/rcS' > Mounting /proc and /sys > Starting the hotplug events dispatcher udevd > Synthesizing initial hotplug even[6.085842] udevd (173): > /proc/173/oom_adj . > > ,but the system hangs here. > > If I boot it with the USB stick disconnected, then the system boots > until the prompt, but the insertion of the USB stick is never detected > afterwards. > Thanks, Fabio, but I am curious how things like that? The USBOH3 clock is not opened, the usb driver will hang when it tries to access registers. If this clock is always on, then, why the system will hang later? > With your patch applied, the error message (usb 1-1: device descriptor > read/64, error -7) is shown with USB stick connected or disconnected > during boot. Would you help to check again the clock is IMX6QDL_CLK_CKO and the reset pin is GPIO7 bit 12? If they are, check below two things please: - The clock is opened (You can check if through clock tree) - The gpio is high (phy_addr is 0x20b4000, the bit is 12) If they are correct, try to toggle gpio manually to see if it can work. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 19/19] drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable time
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
OUT <-- analogix_dp_bridge
OUT <-- DRM IOCTL
The dead lock flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
IN --> analogix_dp_hotplug
IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in
previous step 1)
** Dead Lock Now **
It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.
The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.
Signed-off-by: Yakir Yang
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 26 +
3 files changed, 55 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bc4a9e0..c66c522 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -848,47 +848,40 @@ static void analogix_dp_enable_scramble(struct
analogix_dp_device *dp,
}
}
-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
{
struct analogix_dp_device *dp = arg;
-
+ irqreturn_t ret = IRQ_NONE;
enum dp_irq_type irq_type;
irq_type = analogix_dp_get_irq_type(dp);
- switch (irq_type) {
- case DP_IRQ_TYPE_HP_CABLE_IN:
- dev_dbg(dp->dev, "Received irq - cable in\n");
- schedule_work(&dp->hotplug_work);
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CABLE_OUT:
- dev_dbg(dp->dev, "Received irq - cable out\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CHANGE:
- /*
-* We get these change notifications once in a while, but there
-* is nothing we can do with them. Just ignore it for now and
-* only handle cable changes.
-*/
- dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- default:
- dev_err(dp->dev, "Received irq - unknown type!\n");
- break;
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_mute_hpd_interrupt(dp);
+ ret = IRQ_WAKE_THREAD;
}
- return IRQ_HANDLED;
+
+ return ret;
}
-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
{
- struct analogix_dp_device *dp;
+ struct analogix_dp_device *dp = arg;
+ enum dp_irq_type irq_type;
+
+ irq_type = analogix_dp_get_irq_type(dp);
+ if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+ irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+ dev_dbg(dp->dev, "Detected cable status changed!\n");
+ if (dp->drm_dev)
+ drm_helper_hpd_irq_event(dp->drm_dev);
+ }
- dp = container_of(work, struct analogix_dp_device, hotplug_work);
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_clear_hotplug_interrupts(dp);
+ analogix_dp_unmute_hpd_interrupt(dp);
+ }
- if (dp->drm_dev)
- drm_helper_hpd_irq_event(dp->drm_dev);
+ return IRQ_HANDLED;
}
static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1034,7 +1027,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
}
disable_irq(dp->irq);
- flush_work(&dp->hotplug_work);
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
@@ -1293,8 +1285,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
return -ENODEV;
}
- INIT_WORK(&dp->hotplug_work, analogix_dp_hotplug);
-
pm_runtime_enable(dev);
phy_power_on(dp->phy);
@@ -130
[PATCH v11 18/19] drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time
Turn off the panel power in suspend time would help to reduce
power waste.
Signed-off-by: Yakir Yang
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d18054d..bc4a9e0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1357,6 +1357,12 @@ int analogix_dp_suspend(struct device *dev)
struct analogix_dp_device *dp = dev_get_drvdata(dev);
clk_disable_unprepare(dp->clock);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1372,6 +1378,13 @@ int analogix_dp_resume(struct device *dev)
return ret;
}
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_resume);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] thermal: mediatek: Add cpu dynamic power cooling model.
MT8173 cpufreq driver select of_cpufreq_power_cooling_register registering
cooling devices with dynamic power coefficient.
Signed-off-by: Dawei Chien
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
drivers/cpufreq/mt8173-cpufreq.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
index 83001dc..d00bab5 100644
--- a/drivers/cpufreq/mt8173-cpufreq.c
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -263,17 +263,24 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
*policy,
return 0;
}
+#define DYNAMIC_POWER "dynamic-power-coefficient"
+
static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
{
struct mtk_cpu_dvfs_info *info = policy->driver_data;
struct device_node *np = of_node_get(info->cpu_dev->of_node);
+ u32 capacitance = 0;
if (WARN_ON(!np))
return;
if (of_find_property(np, "#cooling-cells", NULL)) {
- info->cdev = of_cpufreq_cooling_register(np,
-policy->related_cpus);
+ of_property_read_u32(np, DYNAMIC_POWER, &capacitance);
+
+ info->cdev = of_cpufreq_power_cooling_register(np,
+ policy->related_cpus,
+ capacitance,
+ NULL);
if (IS_ERR(info->cdev)) {
dev_err(info->cpu_dev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] arm64: dts: mt8173: Add dynamic power node.
This device node is for calculating dynamic power in mW.
Since mt8173 has two clusters, there are two dynamic power
coefficient as well.
Signed-off-by: Dawei Chien
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 4114cee..33fabe4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -71,6 +71,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <263>;
};
cpu1: cpu@1 {
@@ -95,6 +96,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <263>;
};
cpu2: cpu@100 {
@@ -119,6 +121,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <530>;
};
cpu3: cpu@101 {
@@ -143,6 +146,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <530>;
};
idle-states {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply
After test on rockchiop platform, i found sometims driver would failed
at reading EDID message. After debugging more, i found that it's okay
to read_a byte from i2c, but it would failed at AUX transcation if we
try to ready multi-bytes from i2c.
Driver just can't received the AUX CH reply command, even no AUX error
code. I may guess that the AUX wait time is not enough, so I try to
expand the AUX wait time, and i do see this could fix the EDID read
failed at rockchip platform.
And I thought that expand the wait time won't hurt Exynos platform too
much, cause Exynos didn't have this problem, then driver would received
the reply command very soon, so no more additional wait time would bring
to Exynos platform.
Signed-off-by: Yakir Yang
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index c7e2959..dc376bd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct
analogix_dp_device *dp)
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
while (!(reg & RPLY_RECEIV)) {
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/3] arm64: dts: mt8173: Add thermal zone node.
This adds thermal zone node to Mediatek MT8173 dtsi file.
Signed-off-by: Dawei Chien
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/30/239
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index fda805d..4114cee 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -188,6 +188,49 @@
clock-output-names = "cpum_ck";
};
+ thermal-zones {
+ cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ thermal-sensors = <&thermal 0>;
+ sustainable-power = <1500>; /* milliwatts */
+
+ trips {
+ threshold: trip-point@0 {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ target: trip-point@1 {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit: cpu_crit@0 {
+ temperature = <115000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map@0 {
+ trip = <&target>;
+ cooling-device = <&cpu0 0 0>;
+ contribution = <1024>;
+ };
+ map@1 {
+ trip = <&target>;
+ cooling-device = <&cpu2 0 0>;
+ contribution = <2048>;
+ };
+ };
+ };
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/3] thermal: mediatek: Add cpu dynamic power cooling model.
Use Intelligent Power Allocation (IPA) technical to add dynamic power model for binding CPU thermal zone. The power allocator governor allocates power budget to control CPU temperature. Power Allocator governor is able to keep SOC temperature within a defined temperature range to avoid SOC overheat and keep it's performance. mt8173-cpufreq.c need to register its' own power model with power allocator thermal governor, so that power allocator governor can allocates suitable power budget to control CPU temperature. Binding document is refer to this patchset https://lkml.org/lkml/2015/11/30/239 Change since V4: 1. Remove unnecessary error-checking for mt8173-cpufreq.c 2. Initializing variable capacitance with 0 Change since V3: 1. Remove static power model 2. Split V3's device tree in two for thermal zones and dynamic power models respectively Change since V2: 1. Move dynamic/static power model in device tree Change since V1: 1. Include mt8171.h and sort header file for mt8173.dtsi Dawei Chien (3): thermal: mediatek: Add cpu dynamic power cooling model. arm64: dts: mt8173: Add thermal zone node. arm64: dts: mt8173: Add dynamic power node. arch/arm64/boot/dts/mediatek/mt8173.dtsi | 47 ++ drivers/cpufreq/mt8173-cpufreq.c | 12 ++-- 2 files changed, 57 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 16/19] drm: bridge: analogix/dp: add edid modes parse in get_modes method
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
power on before driver try to read edid message.
Changes in v3:
- Add edid modes parse support
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 19 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
2 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 952c2c3..d18054d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
static int analogix_dp_read_edid(struct analogix_dp_device *dp)
{
- unsigned char edid[EDID_BLOCK_LENGTH * 2];
+ unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_handle_edid(dp);
- if (ret) {
- dev_err(dp->dev, "unable to handle edid\n");
- return;
- }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
dp->video_info.max_link_rate);
if (ret) {
@@ -947,8 +941,17 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
int analogix_dp_get_modes(struct device *dev)
{
struct analogix_dp_device *dp = dev_get_drvdata(dev);
+ struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
+ if (analogix_dp_handle_edid(dp)) {
+ dev_err(dp->dev, "unable to handle edid\n");
+ return -EINVAL;
+ }
+
+ drm_mode_connector_update_edid_property(dp->connector, edid);
+ num_modes += drm_add_edid_modes(dp->connector, edid);
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
@@ -1303,6 +1306,8 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
}
}
+ analogix_dp_init_dp(dp);
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
irq_flags, "analogix-dp", dp);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index baa06e2..73b780e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
#define MAX_CR_LOOP5
#define MAX_EQ_LOOP5
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR 0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH 0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM 0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x) (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x) (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x) (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x) (((x) >> 0) & 0x3)
+
enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
+ unsigned char edid[EDID_BLOCK_LENGTH * 2];
struct analogix_dp_plat_data *plat_data;
};
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct
analogix_dp_device *dp);
void analogix_dp_config_video_slave_
[PATCH v11 15/19] drm: bridge: analogix/dp: move hpd detect to connector detect function
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v11:
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 9eb17ce..952c2c3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_detect_hpd(dp);
- if (ret) {
- /* Cable has been disconnected, we're done */
- return;
- }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
{
+ struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+ if (analogix_dp_detect_hpd(dp))
+ return connector_status_disconnected;
+
return connector_status_connected;
}
EXPORT_SYMBOL_GPL(analogix_dp_detect);
@@ -1006,13 +1005,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge
*bridge)
pm_runtime_get_sync(dp->dev);
- if (dp->plat_data->panel) {
- if (drm_panel_prepare(dp->plat_data->panel)) {
- DRM_ERROR("failed to setup the panel\n");
- return;
- }
- }
-
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
@@ -1045,11 +1037,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
- if (dp->plat_data->panel) {
- if (drm_panel_unprepare(dp->plat_data->panel))
- DRM_ERROR("failed to turnoff the panel\n");
- }
-
pm_runtime_put_sync(dp->dev);
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1307,6 +1294,15 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
pm_runtime_enable(dev);
+ phy_power_on(dp->phy);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
irq_flags, "analogix-dp", dp);
if (ret) {
@@ -1340,6 +1336,12 @@ void analogix_dp_unbind(struct device *dev, struct
device *master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
analogix_dp_bridge_disable(dp->bridge);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
pm_runtime_disable(dev);
}
EXPORT_SYMBOL_GPL(analogix_dp_unbind);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 14/19] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Martinez Canillas
---
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+ -analogix,need-force-hpd (optional)
-video interfaces (optional)
Deprecated properties for DisplayPort:
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f624810..9eb17ce 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+ dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+ analo
[PATCH v11 13/19] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10:
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
flag. (Thierry)
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 4 +--
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a0d97cb..f624810 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1158,16 +1158,25 @@ static int analogix_dp_dt_parse_pdata(struct
analogix_dp_device *dp)
struct device_node *dp_node = dp->dev->of_node;
struct video_info *video_info = &dp->video_info;
- if (of_property_read_u32(dp_node, "samsung,link-rate",
-&video_info->link_rate)) {
- dev_err(dp->dev, "failed to get link-rate\n");
- return -EINVAL;
- }
-
- if (of_property_read_u32(dp_node, "samsung,lane-count",
-&video_info->lane_count)) {
- dev_err(dp->dev, "failed to get lane-count\n");
- return -EINVAL;
+ switch (dp->plat_data->dev_type) {
+ case RK3288_DP:
+ /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+ video_info->max_link_rate = 0x0A;
+ video_info->max_lane_count = 0x04;
+ break;
+ case EXYNOS_DP:
+ /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+ of_property_read_u32(dp_node, "samsung,link-rate",
+&video_info->max_link_rate);
+ of_property_read_u32(dp_node, "samsung,lane-count",
+&video_info->max_lane_count);
+ break;
}
return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 0416d23..4ec 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
- enum link_rate_type link_rate;
- enum link_lane_count_type lane_count;
+ enum link_rate_type max_link_rate;
+ enum link_lane_count_type max_lane_count;
};
struct link_train {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 12/19] drm: bridge: analogix/dp: add some rk3288 special registers setting
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 861097a..21a3287 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+
#include "analogix_dp_core.h"
#include "analogix_dp_reg.h"
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+ writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+ writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+ writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+ writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+ writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+ }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
bool enable)
{
u32 reg;
+ u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+
[PATCH v11 11/19] drm: rockchip: vop: add bpc and color mode setting
From: Mark Yao
Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.
Signed-off-by: Mark Yao
Signed-off-by: Yakir Yang
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
video mode, but hard code CRTC video output mode to RGBaaa.
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 ++---
4 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2c82a9a..3990951 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -180,14 +180,29 @@ static void rockchip_dp_drm_encoder_mode_set(struct
drm_encoder *encoder,
static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
{
struct rockchip_dp_device *dp = to_dp(encoder);
+ struct drm_connector *cn = &dp->connector;
+ int ret = -1;
u32 val;
- int ret;
- ret = rockchip_drm_crtc_mode_config(encoder->crtc,
- DRM_MODE_CONNECTOR_eDP,
- ROCKCHIP_OUT_MODE_);
+ /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+ if (cn->display_info.color_formats & DRM_COLOR_FORMAT_RGB444)
+ ret = rockchip_drm_crtc_mode_config(encoder->crtc,
+ DRM_MODE_CONNECTOR_eDP,
+ 10, DRM_COLOR_FORMAT_RGB444);
if (ret < 0) {
- dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
+ dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
return;
}
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder)
static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
{
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
}
static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs =
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device *dev,
int pipe);
int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
- int out_mode);
+ int bpc, int color);
int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct device *dev);
void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..9ef4a1f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1062,14 +1062,40 @@ static const struct drm_plane_funcs vop_plane_funcs = {
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
int connector_type,
- int out_mode)
+ int bpc, int color)
{
struct vop *vop = to_vop(crtc);
+
[PATCH v11 10/19] dt-bindings: add document for rockchip dp phy
Add dt binding documentation for rockchip display port PHY.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Simplify the commit message. (Kishon)
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..50c4f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip specific extensions to the Analogix Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 09/19] phy: Add driver for rockchip Display Port PHY
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Signed-off-by: Yakir Yang
Reviewed-by: Heiko Stuebner
---
Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.
Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
the exist "grf" syscon already. And rename the example DT node from
"edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
struct" to "static const struct". And correct the input paramters of
devm_phy_create() interfaces. (Heiko)
Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
function, move those code to probe() method. And remove driver .owner
number. (Kishon)
Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
power control. (Heiko)
Changes in v2: None
drivers/phy/Kconfig | 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 151 ++
3 files changed, 159 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..3cb3bf8
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_SOC_CON12 0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(20)
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+ struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+ int ret;
+
+ if (enable) {
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+ GRF_EDP_PHY_SIDDQ_ON);
+ if (ret < 0) {
+ dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(dp->phy_24m);
+ } else {
+ clk_disable_unprepare(dp->phy_24m);
+
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+ GRF_EDP_PHY_SIDDQ_OFF);
+ }
+
+ return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+ return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy
[PATCH v11 08/19] dt-bindings: add document for rockchip variant of analogix_dp
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring
Changes in v9:
- Document more details for 'ports' property.
Changes in v8:
- Modify the commit subject name. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../display/rockchip/analogix_dp-rockchip.txt | 91 ++
1 file changed, 91 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..04d99e3
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the output of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "dp";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins = <7 11 RK_FUNC_2
&pcfg_pull_none>;
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 07/19] drm: rockchip: dp: add rockchip platform dp driver
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.
Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
and leave "sclk_edp" to analogix dp core driver which name to "dp",
and leave "pclk_edp" to rockchip dp platform driver which name to
"pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.
Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 442
include/drm/bridge/analogix_dp.h| 1 +
4 files changed, 453 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..686cb49 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
for the Synopsys DesignWare HDMI driver. If you want to
enable HDMI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_ANALOGIX_DP
+ tristate "Rockchip specific extensions for Analogix DP driver"
+ depends on DRM_ROCKCHIP
+ select DRM_ANALOGIX_DP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..8ad01fb 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
rockchip_drm_gem.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..2c82a9a
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,442 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan
+ * Yakir Yang
+ * Jeff Chen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+ struct drm_device*drm_dev;
+ struct device*dev;
+ struct drm_encoder encoder;
+ struct drm_connector connector;
+ struct drm_display_mode mode;
+
+ struct clk *pclk;
+ struct regmap*grf;
+ struct reset_control *rst;
+
+ struct analogix_dp_plat_data plat_data;
+};
+
+static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
+{
+ reset_control_assert(dp->rst);
+ usleep_range(10, 20);
+
[PATCH v11 06/19] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)
Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
arch/arm/boot/dts/exynos5250-spring.dts | 4 +---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
7 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
&dp {
status = "okay";
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
&dp {
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 5cb33ba..b96624b 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
- samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
};
&ehci {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..2f37c87 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e4..363c95f 100644
--- a/arch/arm/boot/dts/exynos5
[PATCH v11 05/19] dt-bindings: add document for analogix display port driver
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring
Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth" &
"analogix,link-rate" & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high" & "interlaces"
Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 50 +
.../bindings/display/exynos/exynos_dp.txt | 65 --
2 files changed, 72 insertions(+), 43 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+ -hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 64693f2..9905081 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
- -samsung,color-space:
- input video data format.
- COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
- -samsung,dynamic-range:
- dynamic range for input video data.
- VESA = 0, CEA = 1
- -samsung,ycbcr-coeff:
- YCbCr co-efficients for input video.
- COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
- -samsung,color-depth:
- number of bits per colour component.
- COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
- -samsung
[PATCH v11 04/19] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)
Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
struct drm_display_info. (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
3 files changed, 103 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6f899cd..a0d97cb 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1032,6 +1032,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ struct drm_display_info *display_info = &dp->connector->display_info;
+ struct video_info *video = &dp->video_info;
+ struct device_node *dp_node = dp->dev->of_node;
+ int vic;
+
+ /* Input video interlaces & hsync pol & vsync pol */
+ video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+ video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+ video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+ /* Input video dynamic_range & colorimetry */
+ vic = drm_match_cea_mode(mode);
+ if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+ (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR601;
+ } else if (vic) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ } else {
+ video->dynamic_range = VESA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ }
+
+ /* Input vide bpc and color_formats */
+ switch (display_info->bpc) {
+ case 12:
+ video->color_depth = COLOR_12;
+ break;
+ case 10:
+ video->color_depth = COLOR_10;
+ break;
+ case 8:
+ video->color_depth = COLOR_8;
+ break;
+ case 6:
+ video->color_depth = COLOR_6;
+ break;
+ default:
+ video->color_depth = COLOR_8;
+ break;
+ }
+ if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ video->color_space = COLOR_YCBCR444;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+ video->color_space = COLOR_YCBCR422;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+ video->color_space = COLOR_RGB;
+ else
+ video->color_space = COLOR_RGB;
+
+ /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep th
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
David Miller wrote: I think you did something much worse. You quoted the entire huge patch which is entirely inappropriate given the feedback you were trying to give. Sorry about that. I usually do trim it, but I got tired and forgot before I hit send. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 03/19] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
directly, but we can take those as hardware limite. For example, RK3288
only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
like "link-rate = 0x0a" "lane-count = 4". (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 4a05c2b..6f899cd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
- (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+ (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+ (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
- analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
- analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 8e84208..57aa4b0d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
#define MAX_EQ_LOOP5
enum link_rate_type {
- LINK_RATE_1_62GBPS = 0x06,
- LINK_RATE_2_70GBPS = 0x0a
+ LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+ LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+ LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
};
enum link_lane_count_type {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 02/19] drm: bridge: analogix/dp: fix some obvious code style
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
uncommon style like bellow: (Joe Preches)
- retval = exynos_dp_read_bytes_from_i2c(...
...);
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 72 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 124 ++--
3 files changed, 163 insertions(+), 162 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index fb8bda8..4a05c2b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_EXTENSION_FLAG,
- &extend_block);
+ EDID_EXTENSION_FLAG,
+ &extend_block);
if (retval)
return retval;
@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
- retval = analogix_dp_read_bytes_from_i2c(dp,
I2C_EDID_DEVICE_ADDR,
+ retval = analogix_dp_read_bytes_from_i2c(dp,
+ I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
&edid[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
}
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
- &test_vector);
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- &edid[EDID_HEADER_PATTERN]);
+ I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct
analogix_dp_device *dp)
return -EIO;
}
- analogix_dp_read_byte_from_dpcd(dp,
- DP_TEST_REQUEST,
- &test_vector);
+ analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
- DP_TEST_EDID_CHEC
[PATCH v11 0/19] Add Analogix Core Display Port Driver
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM
But there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
This series have been well tested on Rockchip platform with eDP panel on
Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier@Samsung
help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook,
glad to say that things works rightlly.
Thanks,
- Yakir
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9:
- Document more details for 'ports' property.
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
- Simplify the commit message. (Kishon)
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
-
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
From: Timur Tabi Date: Tue, 15 Dec 2015 18:15:50 -0600 > You forgot to add "[v2]" to the subject line of this email. I think you did something much worse. You quoted the entire huge patch which is entirely inappropriate given the feedback you were trying to give. Thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] doc: dt-binding: generic onboard USB HUB
On Tue, Dec 15, 2015 at 09:21:09PM +0100, Ulf Hansson wrote: > On 9 December 2015 at 09:55, Arnd Bergmann wrote: > > On Wednesday 09 December 2015 16:12:24 Peter Chen wrote: > >> On Tue, Dec 08, 2015 at 09:24:03PM -0600, Rob Herring wrote: > >> > On Tue, Dec 08, 2015 at 10:58:48AM +0100, Arnd Bergmann wrote: > >> > > On Tuesday 08 December 2015 10:50:49 Philipp Zabel wrote: > >> > > > This something we don't have to define ad-hoc. The hub hangs off an > >> > > > USB > >> > > > controller, right? The "Open Firmware recommended practice: USB" > >> > > > document already describes how to represent USB devices in a generic > >> > > > manner: > >> > > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps > >> > > > > >> > > > Is there a reason not to reuse this? > >> > > > > >> > > > The usb hub node would be a child of the usb controller node, and it > >> > > > could use > >> > > > compatible = "usb,class9"; /* bDeviceClass 9 (Hub) */ > >> > > > >> > > Good point, I had not thought of that when I looked at the patches. > >> > > > >> > > Yes, let's do this way. I don't know if we ever implemented the simple > >> > > patch to associate a USB device with a device_node, but if not, then > >> > > let's do it now for this driver. A lot of people have asked for it in > >> > > the past. > >> > > >> > Agreed. Also, some hubs have I2C buses as well, but I still think under > >> > the USB bus is the right place. > >> > > >> > However, one complication here is often (probably this case) these > >> > addtional signals need to be controlled before the device enumerates. > >> > > >> > >> Yes, I did not find a way to let the USB bus code handle it, so I had to > >> write a platform driver to do it > > > > Looping in Ulf, he solved the same problem for SDIO devices recently, > > and probably remembers the details best. > > > > Thanks Arnd! > > Yes, that was a kind of a long outstanding issue we have had for SDIO devices. > > Several generic attempts was made to have a framework/library > available to support so called "power sequences" for exactly the same > reasons as above. > Others and myself failed to get those attempts accepted. > > Instead, I invented a mmc subsystem specific DT based solution, the > "mmc-pwrseq". > > DT documentation: > Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt > Documentation/devicetree/bindings/mmc/mmc.txt > > Long story short: The mmc host device may contain a phandle to a > mmc-pwrseq, which will describe the resources needed to power on/off > the SDIO card. > > The code is available at: > drivers/mmc/core/pwrseq* > > We didn't implement this as platform driver, but that was mostly > because I initially wanted things to be simple. Although, nothing > prevents us from converting to this as a follow up, which would make > the solution a bit less "hacky". > Thanks for your information, Ulf. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller
R-Car H3 has USB3.0 peripheral controllers. This controller's has the
following features:
- Supports super, high and full speed
- Contains 30 pipes for bulk or interrupt transfer
- Contains dedicated DMA controller
This driver doesn't support the dedicated DMAC for now.
Signed-off-by: Yoshihiro Shimoda
---
This patch is based on the latest Felipe's usb.git / testing/next branch.
(commit id = e9284de9fae69f1d5e57a4817bfc36dc5f3adf71)
Changes from v1:
- fix build error in i386 environment if COMPILE_TEST=y
- merge the header file code into the .c file
- revise the device tree document about "clocks"
- remove prototype declarations
- use udelay(1) instead of ndelay(1) in usb3_wait()
- remove empty function "usb3_init_phy()"
- use module_platform_driver()
- remove bit fields member in some structures
.../devicetree/bindings/usb/renesas_usb3.txt | 23 +
drivers/usb/gadget/udc/Kconfig | 11 +
drivers/usb/gadget/udc/Makefile|1 +
drivers/usb/gadget/udc/renesas_usb3.c | 1975
4 files changed, 2010 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/renesas_usb3.txt
create mode 100644 drivers/usb/gadget/udc/renesas_usb3.c
diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
new file mode 100644
index 000..71bee11
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -0,0 +1,23 @@
+Renesas Electronics USB3.0 Peripheral driver
+
+Required properties:
+ - compatible: Must contain one of the following:
+ - "renesas,usb3-peri-r8a7795"
+ - reg: Base address and length of the register for the USB3.0 Peripheral
+ - interrupts: Interrupt specifier for the USB3.0 Peripheral
+ - clocks: clock phandle and specifier pair
+
+Example:
+ usb3_peri0: usb@ee02 {
+ compatible = "renesas,usb3-peri-r8a7795";
+ reg = <0 0xee02 0 0x400>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 328>;
+ };
+
+ usb3_peri1: usb@ee06 {
+ compatible = "renesas,usb3-peri-r8a7795";
+ reg = <0 0xee06 0 0x400>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 327>;
+ };
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index cdbff54..753c29b 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -174,6 +174,17 @@ config USB_RENESAS_USBHS_UDC
dynamically linked module called "renesas_usbhs" and force all
gadget drivers to also be dynamically linked.
+config USB_RENESAS_USB3
+ tristate 'Renesas USB3.0 Peripheral controller'
+ depends on ARCH_SHMOBILE || COMPILE_TEST
+ help
+ Renesas USB3.0 Peripheral controller is a USB peripheral controller
+ that supports super, high, and full speed USB 3.0 data transfers.
+
+ Say "y" to link the driver statically, or "m" to build a
+ dynamically linked module called "renesas_usb3" and force all
+ gadget drivers to also be dynamically linked.
+
config USB_PXA27X
tristate "PXA 27x"
help
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index fba2049..dfee534 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -19,6 +19,7 @@ fsl_usb2_udc-y:= fsl_udc_core.o
fsl_usb2_udc-$(CONFIG_ARCH_MXC)+= fsl_mxc_udc.o
obj-$(CONFIG_USB_M66592) += m66592-udc.o
obj-$(CONFIG_USB_R8A66597) += r8a66597-udc.o
+obj-$(CONFIG_USB_RENESAS_USB3) += renesas_usb3.o
obj-$(CONFIG_USB_FSL_QE) += fsl_qe_udc.o
obj-$(CONFIG_USB_S3C_HSUDC)+= s3c-hsudc.o
obj-$(CONFIG_USB_LPC32XX) += lpc32xx_udc.o
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c
b/drivers/usb/gadget/udc/renesas_usb3.c
new file mode 100644
index 000..38f02bc
--- /dev/null
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -0,0 +1,1975 @@
+/*
+ * Renesas USB3.0 Peripheral driver (USB gadget)
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* register definitions */
+#define USB3_AXI_INT_STA 0x008
+#define USB3_AXI_INT_ENA 0x00c
+#define USB3_DMA_INT_STA 0x010
+#define USB3_DMA_INT_ENA 0x014
+#define USB3_USB_COM_CON 0x200
+#define USB3_USB20_CON 0x204
+#define USB3_USB30_CON 0x208
+#define USB3_USB_STA 0x210
+#define USB3_DRD_CON 0x218
+#define USB3_USB_INT_STA_1 0x220
+#define USB3_USB_INT_STA_2 0x224
+
RE: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller
Hi Arnd again,
> From: Yoshihiro Shimoda
> Sent: Wednesday, December 16, 2015 10:43 AM
< snip >
> > > +static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
> > > +{
> > > + iowrite32(data, usb3->reg + offs);
> > > +}
> > > +
> > > +static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
> > > +{
> > > + return ioread32(usb3->reg + offs);
> > > +}
> >
> > I think using readl() is more common than ioread32() if the driver cannot
> > use IORESOURCE_IO but only IORESOURCE_MEM.
> >
> > On ARM, the two are the same, but on some architectures ioread32 is more
> > expensive, so using the former is preferred.
>
> I will use {read,write}l() instead of io{read,write}32().
> Also I will change io{read,write}32_rep() functions too.
Oops. If I used {read,write}sl() instead of io{read,write}32_rep(),
build error happened in x86 environment.
CC [M] drivers/usb/gadget/udc/renesas_usb3.o
./drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_write_pipe':
./drivers/usb/gadget/udc/renesas_usb3.c:879:3: error: implicit declaration of
function 'writesl' [-Werror=implicit-function-declaration]
writesl(usb3->reg + fifo_reg, buf, len / 4);
^
./drivers/usb/gadget/udc/renesas_usb3.c: In function 'usb3_read_pipe':
./drivers/usb/gadget/udc/renesas_usb3.c:923:3: error: implicit declaration of
function 'readsl' [-Werror=implicit-function-declaration]
readsl(usb3->reg + fifo_reg, buf, len / 4);
So, I will keep to use io{read,write}32(_rep) functions.
Best regards,
Yoshihiro Shimoda
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller
Hi Arnd,
Thank you very much for your review!
> From: Arnd Bergmann
> Sent: Tuesday, December 15, 2015 6:30 PM
>
> On Tuesday 15 December 2015 15:54:32 Yoshihiro Shimoda wrote:
> > R-Car H3 has USB3.0 peripheral controllers. This controller's has the
> > following features:
> > - Supports super, high and full speed
> > - Contains 30 pipes for bulk or interrupt transfer
> > - Contains dedicated DMA controller
> >
> > This driver doesn't support the dedicated DMAC for now.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > This patch is based on the latest Felipe's usb.git / testing/next branch.
> > (commit id = e9284de9fae69f1d5e57a4817bfc36dc5f3adf71)
>
> Looks good overall, I've found a few small details:
>
> > .../devicetree/bindings/usb/renesas_usb3.txt | 23 +
> > drivers/usb/gadget/udc/Kconfig | 11 +
> > drivers/usb/gadget/udc/Makefile|1 +
> > drivers/usb/gadget/udc/renesas_usb3.c | 1720
> >
> > drivers/usb/gadget/udc/renesas_usb3.h | 284
>
> The header file is only used by one .c file, so just merge it all into that
> file.
I got it. I will merge the header file to the c file.
> > +Required properties:
> > + - compatible: Must contain one of the following:
> > + - "renesas,usb3-peri-r8a7795"
> > + - reg: Base address and length of the register for the USB3.0 Peripheral
> > + - interrupts: Interrupt specifier for the USB3.0 Peripheral
> > + - clocks: A list of phandle + clock specifier pairs
>
> The clock specifier contains the phandle, please rephrase the last line
I will revise it as the following:
- clocks: clock phandle and specifier pair
> > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c
> > b/drivers/usb/gadget/udc/renesas_usb3.c
> > new file mode 100644
> > index 000..f302c89
> > --- /dev/null
> > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
< snip >
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> As the 0-say bot found, this needs #include
Thank you for the detail. I will add it here.
> > +static int renesas_usb3_ep_queue(struct usb_ep *_ep, struct usb_request
> > *_req,
> > +gfp_t gfp_flags);
> > +static void usb3_start_pipen(struct renesas_usb3_ep *usb3_ep,
> > +struct renesas_usb3_request *usb3_req);
>
> Can you try to reorder the functions so you don't need forward declarations?
Thank you for the point. I could reorder the functions.
> > +static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
> > +{
> > + iowrite32(data, usb3->reg + offs);
> > +}
> > +
> > +static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
> > +{
> > + return ioread32(usb3->reg + offs);
> > +}
>
> I think using readl() is more common than ioread32() if the driver cannot
> use IORESOURCE_IO but only IORESOURCE_MEM.
>
> On ARM, the two are the same, but on some architectures ioread32 is more
> expensive, so using the former is preferred.
I will use {read,write}l() instead of io{read,write}32().
Also I will change io{read,write}32_rep() functions too.
> > + for (i = 0; i < USB3_WAIT_NS; i++) {
> > + if ((usb3_read(usb3, reg) & mask) == expected)
> > + return 0;
> > + ndelay(1);
> > + }
>
> ndelay(1) is unusual, maybe use cpu_relax() instead, or document why
> you call ndelay()?
Thank you for the point. udelay(1) is enough in this function.
So, I will fix it.
> > +static void usb3_init_phy(struct renesas_usb3 *usb3)
> > +{
> > +}
>
> If the function is empty, don't add or call it, it's easy to add if you
> need it later.
Thank you for the point. I will remove it.
> > +static struct platform_driver renesas_usb3_driver = {
> > + .remove = __exit_p(renesas_usb3_remove),
> > + .driver = {
> > + .name = (char *)udc_name,
> > + .of_match_table = of_match_ptr(usb3_of_match),
> > + },
> > +};
> > +module_platform_driver_probe(renesas_usb3_driver, renesas_usb3_probe);
>
> module_platform_driver_probe() won't work if you get into deferred probing,
> I'd suggest using module_platform_driver() and not marking the remove
> function as __exit
Thank you for your suggestion. I will use module_platform_driver().
> > +struct renesas_usb3;
> > +struct renesas_usb3_request {
> > + struct usb_request req;
> > + struct list_headqueue;
> > +};
>
> There is already a list_head in struct usb_request. Could you use that?
> (I don't know, just asking because this looks odd)
The list_head in strcut usb_request is used by a gadget driver
(drivers/usb/gadget/function/*.c).
So, a udc driver (e.g. drivers/usb/gadget/udc/*.c) cannot use it.
> > +#define USB3_EP_NAME_SIZE 8
> > +struct renesas_usb3_ep {
> > + struct usb_ep ep;
> > + struct renesas_usb3 *usb3;
> > + int num;
> > + char ep_na
Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
2015-12-16 10:11 GMT+09:00 Sebastian Reichel : > Hi, > > On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote: >> >>> What motivated the location of this power domain driver in >> >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or >> >>> somewhere in drivers/ at the very least? >> >> >> >> ls stronly suggests that power contains drivers for power supplies and >> >> batteries, not power domains. > > Indeed it's used for fuel gauges and chargers, but also for > reboot/powerdown and adaptive voltage scaling, so another > subdirectory for power-domains wouldn't be that odd. > >> >> There are 6 power domain drivers in >> >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc. >> > >> > If we ever have to support a different architecture which happens to use >> > a similar power domain, then we want it to be in a location which makes >> > it easy for sharing it in the first place. As it stands today, it does >> > not seem useful to me to have this code in arch/arm/mach-bcm/ at all. >> > >> > Maybe there is room from a drivers/power/domains/ of some kind? > > I like the idea, but let's include generic power domain maintainers > in this discussion, as I suggested here (I got a power domain driver > patch for drivers/power just a few days ago): > > https://lkml.org/lkml/2015/12/15/815 > > Also somebody would have to step up to maintain that directory. This could go into drivers/soc. We put there a lot of mach-specific stuff which we want to make a little more generic (like generic enough multiplatform, multiarchitecture etc). Rockchip has its own power domains there. Dove and Mediatek seem as well but I am not sure. Some other architectures keep this still in arm/mach (exynos, ux500, zx, imx, s34c64xx, shmobile) but this looks more of like a legacy choice. However, since generic power domains have its own maintainers entry and reside under drivers/base/power, maybe making a separate directory for power domains drivers makes sense? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
Hi, On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote: > >>> What motivated the location of this power domain driver in > >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or > >>> somewhere in drivers/ at the very least? > >> > >> ls stronly suggests that power contains drivers for power supplies and > >> batteries, not power domains. Indeed it's used for fuel gauges and chargers, but also for reboot/powerdown and adaptive voltage scaling, so another subdirectory for power-domains wouldn't be that odd. > >> There are 6 power domain drivers in > >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc. > > > > If we ever have to support a different architecture which happens to use > > a similar power domain, then we want it to be in a location which makes > > it easy for sharing it in the first place. As it stands today, it does > > not seem useful to me to have this code in arch/arm/mach-bcm/ at all. > > > > Maybe there is room from a drivers/power/domains/ of some kind? I like the idea, but let's include generic power domain maintainers in this discussion, as I suggested here (I got a power domain driver patch for drivers/power just a few days ago): https://lkml.org/lkml/2015/12/15/815 Also somebody would have to step up to maintain that directory. > The great thing about git is that moving code is easy, even after it's > first committed. > > The subsystem maintainer didn't comment on the code's location in v1 or > v2, and I think they probably have the final say on that. Whatever they > want, where there is currently a genpd driver, is fine with me. sounds reasonable. P.S.: Thanks for taking bringing RPI support upstream :) -- Sebastian signature.asc Description: PGP signature
Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
Florian Fainelli writes: > On 15/12/15 15:55, Eric Anholt wrote: >> Florian Fainelli writes: >> >>> On 15/12/15 13:40, Eric Anholt wrote: From: Alexander Aring This patch adds support for several power domains on Raspberry Pi, including USB (so it can be enabled even if the bootloader didn't do it), and graphics. This patch is the combined work of Eric Anholt (who wrote USB support inside of the Raspberry Pi firmware driver, and wrote the non-USB domain support) and Alexander Aring (who separated the original USB work out from the firmware driver). Signed-off-by: Alexander Aring Signed-off-by: Eric Anholt --- v2: Add support for power domains other than USB, using the new firmware interface, reword commit message (changes by Eric) v3: Restructure as a builtin driver, and drop of_genpd_add_provider_onecell error handling to avoid pm_genpd_exit() dependency until that API can be settled. Clean up copyright header, add missing ISP initialization, and fix typo in transposer's name. arch/arm/mach-bcm/Kconfig | 10 ++ arch/arm/mach-bcm/Makefile | 1 + arch/arm/mach-bcm/raspberrypi-power.c | 247 include/dt-bindings/arm/raspberrypi-power.h | 41 + 4 files changed, 299 insertions(+) create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c >>> >>> What motivated the location of this power domain driver in >>> arch/arm/mach-bcm? Should not we have this in drivers/power/ or >>> somewhere in drivers/ at the very least? >> >> ls stronly suggests that power contains drivers for power supplies and >> batteries, not power domains. There are 6 power domain drivers in >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc. > > If we ever have to support a different architecture which happens to use > a similar power domain, then we want it to be in a location which makes > it easy for sharing it in the first place. As it stands today, it does > not seem useful to me to have this code in arch/arm/mach-bcm/ at all. > > Maybe there is room from a drivers/power/domains/ of some kind? The great thing about git is that moving code is easy, even after it's first committed. The subsystem maintainer didn't comment on the code's location in v1 or v2, and I think they probably have the final say on that. Whatever they want, where there is currently a genpd driver, is fine with me. signature.asc Description: PGP signature
Re: [PATCH v10 0/17] Add Analogix Core Display Port Driver
Hi Heiko, On 12/15/2015 08:06 AM, Heiko Stübner wrote: Hi Yakir, Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang: The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM so it looks like the hotplug works nicely now. I was able to test it sucessfully on both a Jerry and a Minnie device without needing to force hotplug :-) . As I needed to adapt some patches when applying the lastest ones, I think it would be good for a full send of the latest version as v11. Got it, will send soon ;) When going over the patches before sending, please also fix the indentation issues in analogix_dp_core.h - both newly added elements to analogix_dp_device use spaces between type and name, where the rest uses tabs. [This should of course be fixed in the patches adding these lines :-) ] Done, Thanks, - Yakir Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
On 15/12/15 15:55, Eric Anholt wrote: > Florian Fainelli writes: > >> On 15/12/15 13:40, Eric Anholt wrote: >>> From: Alexander Aring >>> >>> This patch adds support for several power domains on Raspberry Pi, >>> including USB (so it can be enabled even if the bootloader didn't do >>> it), and graphics. >>> >>> This patch is the combined work of Eric Anholt (who wrote USB support >>> inside of the Raspberry Pi firmware driver, and wrote the non-USB >>> domain support) and Alexander Aring (who separated the original USB >>> work out from the firmware driver). >>> >>> Signed-off-by: Alexander Aring >>> Signed-off-by: Eric Anholt >>> --- >>> >>> v2: Add support for power domains other than USB, using the new >>> firmware interface, reword commit message (changes by Eric) >>> >>> v3: Restructure as a builtin driver, and drop >>> of_genpd_add_provider_onecell error handling to avoid >>> pm_genpd_exit() dependency until that API can be settled. Clean >>> up copyright header, add missing ISP initialization, and fix typo >>> in transposer's name. >>> >>> arch/arm/mach-bcm/Kconfig | 10 ++ >>> arch/arm/mach-bcm/Makefile | 1 + >>> arch/arm/mach-bcm/raspberrypi-power.c | 247 >>> >>> include/dt-bindings/arm/raspberrypi-power.h | 41 + >>> 4 files changed, 299 insertions(+) >>> create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c >> >> What motivated the location of this power domain driver in >> arch/arm/mach-bcm? Should not we have this in drivers/power/ or >> somewhere in drivers/ at the very least? > > ls stronly suggests that power contains drivers for power supplies and > batteries, not power domains. There are 6 power domain drivers in > arch/arm, 3 in drivers/clk, and 3 in drivers/soc. If we ever have to support a different architecture which happens to use a similar power domain, then we want it to be in a location which makes it easy for sharing it in the first place. As it stands today, it does not seem useful to me to have this code in arch/arm/mach-bcm/ at all. Maybe there is room from a drivers/power/domains/ of some kind? -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
Florian Fainelli writes: > On 15/12/15 13:40, Eric Anholt wrote: >> From: Alexander Aring >> >> This patch adds support for several power domains on Raspberry Pi, >> including USB (so it can be enabled even if the bootloader didn't do >> it), and graphics. >> >> This patch is the combined work of Eric Anholt (who wrote USB support >> inside of the Raspberry Pi firmware driver, and wrote the non-USB >> domain support) and Alexander Aring (who separated the original USB >> work out from the firmware driver). >> >> Signed-off-by: Alexander Aring >> Signed-off-by: Eric Anholt >> --- >> >> v2: Add support for power domains other than USB, using the new >> firmware interface, reword commit message (changes by Eric) >> >> v3: Restructure as a builtin driver, and drop >> of_genpd_add_provider_onecell error handling to avoid >> pm_genpd_exit() dependency until that API can be settled. Clean >> up copyright header, add missing ISP initialization, and fix typo >> in transposer's name. >> >> arch/arm/mach-bcm/Kconfig | 10 ++ >> arch/arm/mach-bcm/Makefile | 1 + >> arch/arm/mach-bcm/raspberrypi-power.c | 247 >> >> include/dt-bindings/arm/raspberrypi-power.h | 41 + >> 4 files changed, 299 insertions(+) >> create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c > > What motivated the location of this power domain driver in > arch/arm/mach-bcm? Should not we have this in drivers/power/ or > somewhere in drivers/ at the very least? ls stronly suggests that power contains drivers for power supplies and batteries, not power domains. There are 6 power domain drivers in arch/arm, 3 in drivers/clk, and 3 in drivers/soc. signature.asc Description: PGP signature
[PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.
These will be used for enabling UART1, SPI1, and SPI2.
Signed-off-by: Eric Anholt
---
v2: Make the binding cover both the IRQ and clock enable registers.
.../bindings/clock/brcm,bcm2835-aux-clock.txt | 31 ++
include/dt-bindings/clock/bcm2835-aux.h| 17
2 files changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
new file mode 100644
index 000..7a837d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
@@ -0,0 +1,31 @@
+Broadcom BCM2835 auxiliary peripheral support
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The auxiliary peripherals (UART, SPI1, and SPI2) have a small register
+area controlling clock gating to the peripherals, and providing an IRQ
+status register.
+
+Required properties:
+- compatible: Should be "brcm,bcm2835-aux"
+- #clock-cells:Should be <1>. The permitted clock-specifier values can
be
+ found in include/dt-bindings/clock/bcm2835-aux.h
+- reg: Specifies base physical address and size of the registers
+- clocks: The parent clock phandle
+
+Example:
+
+ clocks: cprman@7e101000 {
+ compatible = "brcm,bcm2835-cprman";
+ #clock-cells = <1>;
+ reg = <0x7e101000 0x2000>;
+ clocks = <&clk_osc>;
+ };
+
+ aux: aux@0x7e215004 {
+ compatible = "brcm,bcm2835-aux";
+ #clock-cells = <1>;
+ reg = <0x7e215000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>;
+ };
diff --git a/include/dt-bindings/clock/bcm2835-aux.h
b/include/dt-bindings/clock/bcm2835-aux.h
new file mode 100644
index 000..d91156e
--- /dev/null
+++ b/include/dt-bindings/clock/bcm2835-aux.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define BCM2835_AUX_CLOCK_UART 0
+#define BCM2835_AUX_CLOCK_SPI1 1
+#define BCM2835_AUX_CLOCK_SPI2 2
+#define BCM2835_AUX_CLOCK_COUNT3
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.
These will be used for enabling UART1, SPI1, and SPI2.
Signed-off-by: Eric Anholt
---
v2: Make the binding cover both the IRQ and clock enable registers.
arch/arm/boot/dts/bcm2835.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..a27d40b 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -73,6 +73,13 @@
clocks = <&clk_osc>;
};
+ aux: aux@0x7e215000 {
+ compatible = "brcm,bcm2835-aux";
+ #clock-cells = <1>;
+ reg = <0x7e215000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>;
+ };
+
rng@7e104000 {
compatible = "brcm,bcm2835-rng";
reg = <0x7e104000 0x10>;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.
There are a pair of SPI masters and a mini UART that were last minute
additions. As a result, they didn't get integrated in the same way as
the other gates off of the VPU clock in CPRMAN.
Signed-off-by: Eric Anholt
---
v2: Make the binding cover both the IRQ and clock enable registers.
Use devm_ allocation, ioremap, and and clock get functions. Don't
return the error from of_clk_add_provider(), since that would
leave the clocks registered, but their registers unmapped. Trim
includes.
drivers/clk/bcm/Makefile | 1 +
drivers/clk/bcm/clk-bcm2835-aux.c | 85 +++
2 files changed, 86 insertions(+)
create mode 100644 drivers/clk/bcm/clk-bcm2835-aux.c
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 3fc9506..183484c 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o
clk-iproc-asiu.o
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
+obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835-aux.o
obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o
obj-$(CONFIG_ARCH_BCM_CYGNUS) += clk-cygnus.o
obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o
diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c
b/drivers/clk/bcm/clk-bcm2835-aux.c
new file mode 100644
index 000..e4f89e2
--- /dev/null
+++ b/drivers/clk/bcm/clk-bcm2835-aux.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BCM2835_AUXIRQ 0x00
+#define BCM2835_AUXENB 0x04
+
+static int bcm2835_aux_clk_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct clk_onecell_data *onecell;
+ const char *parent;
+ struct clk *parent_clk;
+ struct resource *res;
+ void __iomem *reg, *gate;
+
+ parent_clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(parent_clk))
+ return PTR_ERR(parent_clk);
+ parent = __clk_get_name(parent_clk);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap_resource(dev, res);
+ if (!reg)
+ return -ENODEV;
+
+ onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
+ if (!onecell)
+ return -ENOMEM;
+ onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
+ onecell->clks = devm_kcalloc(dev, BCM2835_AUX_CLOCK_COUNT,
+sizeof(*onecell->clks), GFP_KERNEL);
+ if (!onecell->clks)
+ return -ENOMEM;
+
+ gate = reg + BCM2835_AUXENB;
+ onecell->clks[BCM2835_AUX_CLOCK_UART] =
+ clk_register_gate(dev, "aux_uart", parent, 0, gate, 0, 0, NULL);
+
+ onecell->clks[BCM2835_AUX_CLOCK_SPI1] =
+ clk_register_gate(dev, "aux_spi1", parent, 0, gate, 1, 0, NULL);
+
+ onecell->clks[BCM2835_AUX_CLOCK_SPI2] =
+ clk_register_gate(dev, "aux_spi2", parent, 0, gate, 2, 0, NULL);
+
+ of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get, onecell);
+
+ return 0;
+}
+
+static const struct of_device_id bcm2835_aux_clk_of_match[] = {
+ { .compatible = "brcm,bcm2835-aux", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bcm2835_aux_clk_of_match);
+
+static struct platform_driver bcm2835_aux_clk_driver = {
+ .driver = {
+ .name = "bcm2835-aux-clk",
+ .of_match_table = bcm2835_aux_clk_of_match,
+ },
+ .probe = bcm2835_aux_clk_probe,
+};
+builtin_platform_driver(bcm2835_aux_clk_driver);
+
+MODULE_AUTHOR("Eric Anholt ");
+MODULE_DESCRIPTION("BCM2835 auxiliary peripheral clock driver");
+MODULE_LICENSE("GPL v2");
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] ARM: dts: exynos: replace legacy *,wakeup property with wakeup-source
On 16.12.2015 01:35, Sudeep Holla wrote: > > > On 21/10/15 11:10, Sudeep Holla wrote: >> Though the keyboard and other driver will continue to support the legacy >> "gpio-key,wakeup", "linux-keypad,wakeup" boolean property to enable the >> wakeup source, "wakeup-source" is the new standard binding. >> >> This patch replaces all the legacy wakeup properties with the unified >> "wakeup-source" property in order to avoid any futher copy-paste >> duplication. >> >> Cc: Kukjin Kim >> Cc: Krzysztof Kozlowski > > Ping, do you prefer taking via your tree or should I send to armsoc > directly ? Usually it depends on the dependencies... but: 1. I just received this patch - 12/19. 2. No cover letter, no other patches, no explanation about any dependencies or other related changes. Nothing. Just one patch. 3. The patch mentions new standard binding. Was the new binding already merged? Or is it part of these series? What about backward compatibility? BR, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 1/2] power: Add brcm,bcm6358-power-controller device tree binding
Hi, On Wed, Dec 09, 2015 at 10:29:35PM +, Simon Arlott wrote: > The BCM6358 contains power domains controlled with a register. Power > domains are indexed by bits in the register. Power domain bits can be > interleaved with other status bits and clocks in the same register. > > Newer SoCs with dedicated power domain registers are active low. That's neither a power supply driver (like a battery charger or a fuel gauge), nor a reboot/poweroff driver, so does not really fit into my tree. I will add generic PM maintainers to the discussion. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH v4 1/3] dt-binding: power: Add otg regulator binding
Hi, On Tue, Dec 15, 2015 at 11:52:10AM -0800, Tim Bird wrote: > Add a binding for the regulator which controls the OTG chargepath switch. > The OTG switch gets its power from pm8941_5vs1, and that should be > expressed as a usb_otg_in-supply property in the DT node for the > charger driver. The regulator name is "otg-vbus". I would like to get an acked-by from either the regulator framework maintainers, or DT binding maintainers (or both ;)) on the binding. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
On Mon, 14 Dec 2015 17:39:09 -0800
Florian Fainelli wrote:
> On 14/12/15 16:19, Gilad Avidov wrote:
>
> [snip]
>
> > + "sgmii_irq";
> > + qcom,emac-gpio-mdc = <&msmgpio 123 0>;
> > + qcom,emac-gpio-mdio = <&msmgpio 124 0>;
> > + qcom,emac-tstamp-en;
> > + qcom,emac-ptp-frac-ns-adj = <12500 1>;
> > + phy-addr = <0>;
>
> Please use the standard Ethernet PHY and MDIO device tree bindings to
> describe your MAC to PHY connection here, that includes using a
> phy-connection-type property to describe the (x)MII lanes.
>
Hi Florian,
Thank you for the review.
Unfortunately this Ethernet controller's PHY is non standard and fits
poorly into the standard MDIO framework layer. Rather than read/writs
over MDIO only, this hw have some of the PHY registers internal and
accessed by memory mapped IO, while others are accessed over the MDIO.
Some standard functions requires using both. Additionally a number
of different functions are controlled from different fields of the
same register.
> [snip]
>
> > +/* EMAC_MAC_CTRL */
> > +#define SINGLE_PAUSE_MODE
> > 0x1000 +#define
> > DEBUG_MODE 0x800
> > +#define BROAD_EN
> > 0x400 +#define
> > MULTI_ALL0x200
> > +#define RX_CHKSUM_EN
> > 0x100 +#define
> > HUGE 0x80
> > +#define SPEED_BMSK
> > 0x30 +#define
> > SPEED_SHFT 20
> > +#define SIMR
> > 0x8 +#define
> > TPAUSE 0x1
> > +#define PROM_MODE
> > 0x8000 +#define
> > VLAN_STRIP 0x4000
> > +#define PRLEN_BMSK
> > 0x3c00 +#define
> > PRLEN_SHFT 10
> > +#define HUGEN
> > 0x200 +#define
> > FLCHK0x100
> > +#define PCRCE
> > 0x80 +#define
> > CRCE 0x40
> > +#define FULLD
> > 0x20 +#define
> > MAC_LP_EN 0x10
> > +#define RXFC
> > 0x8 +#define
> > TXFC 0x4
> > +#define RXEN
> > 0x2 +#define
> > TXEN 0x1
>
> BIT(x)? which would avoid making this reverse christmas tree, I know
> this is the time of year though.
>
:)
Agree.
> [snip]
>
> > +/* DMA address */
> > +#define DMA_ADDR_HI_MASK
> > 0xULL +#define
> > DMA_ADDR_LO_MASK 0xULL +
> > +#define
> > EMAC_DMA_ADDR_HI(_addr) \
> > + ((u32)(((u64)(_addr) & DMA_ADDR_HI_MASK) >> 32))
> > +#define
> > EMAC_DMA_ADDR_LO(_addr) \
> > + ((u32)((u64)(_addr) & DMA_ADDR_LO_MASK))
>
> The kernel provides helpers for that: upper_32bits and lower_32bits().
>
lower_32_bits(n) and upper_32_bits(n), thanks. I'll use them here.
> [snip]
>
> > +struct emac_skb_cb {
> > + u32 tpd_idx;
> > + unsigned long jiffies;
> > +};
> > +
> > +struct emac_tx_ts_cb {
> > + u32 sec;
> > + u32 ns;
> > +};
> > +
> > +#define EMAC_SKB_CB(skb) ((struct emac_skb_cb *)(skb)->cb)
> > +#define EMAC_TX_TS_CB(skb) ((struct emac_tx_ts_cb
> > *)(skb)->cb)
>
> Should not these two have different offsets within skb->cb in case
> they both end-up being added to the same SKB?
>
Good point. I'll look into this.
> [snip]
>
> > +
> > + /* enable RX/TX Flow Control */
> > + switch (phy->cur_fc_mode) {
> > + case EMAC_FC_FULL:
> > + mac |= (TXFC | RXFC);
> > + break;
> > + case EMAC_FC_RX_PAUSE:
> > + mac |= RXFC;
> > + break;
> > + case EMAC_FC_TX_PAUSE:
> > + mac |= TXFC;
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > + /* setup link speed */
> > + mac &= ~SPEED_BMSK;
> > + switch (phy->link_speed) {
> > + case EMAC_LINK_SPEED_1GB_FULL:
> > + mac |= ((emac_mac_speed_1000 << SPEED_SHFT) &
> > SPEED_BMSK);
> > + csr1 |= FREQ_MODE;
> > + break;
> > + default:
> > + mac |= ((emac_mac_speed_10_100 << SPEED_SHFT) &
> > SPEED_BMSK);
> > + csr1 &= ~FREQ_MODE;
> > + break;
> > + }
> > +
> > + switch (phy->link_speed) {
> > + case EMAC_LINK_SPEED_1GB_FULL:
> > + case EMAC_LINK_SPEED_100_FULL:
> > + case EMAC_LINK_SPEED_10_FULL:
> > + mac |= FULLD;
> > + break;
> > + default:
> > + mac &= ~FULLD;
> > + }
>
> You should use the PHY library and implement an adjust_link callback
> which does exactly that above.
> [snip]
>
> > +static bool emac_tx_has_enough_descs(struct emac_tx_queue *tx_q,
> > +const struct sk_buff *skb)
> > +{
> > +
Re: [PATCH v4 1/3] dt-binding: power: Add otg regulator binding
On Tue, Dec 15, 2015 at 11:52:10AM -0800, Tim Bird wrote: > Add a binding for the regulator which controls the OTG chargepath switch. > The OTG switch gets its power from pm8941_5vs1, and that should be > expressed as a usb_otg_in-supply property in the DT node for the > charger driver. The regulator name is "otg-vbus". > > Signed-off-by: Tim Bird > --- > Changes since v3 > - switch supply name to have underscores instead of dashes >- (switched back to match the name used in data sheets) > - switch regulator node name to otg-vbus > Changes since v1 > - switch supply name to have dashes instead of underscores > - remove superfluous DT explanations in the otg node description Reviewed-by: Andy Gross -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] power: qcom_smbb: Add otg regulator for control of vbus
On Tue, Dec 15, 2015 at 11:52:11AM -0800, Tim Bird wrote: > Add a regulator to control the OTG chargepath switch. This > is used by USB code to control VBUS direction - out for host mode > on the OTG port, and in for charging mode. > > Signed-off-by: Tim Bird > --- > Changes since v3: > - changed DT node name to otg-vbus > - removed fixed-voltage setup from otg regulator rdesc > Changes since v1: > - changed name of supply to remove underscores > --- Reviewed-by: Andy Gross -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
On 15/12/15 13:40, Eric Anholt wrote: > From: Alexander Aring > > This patch adds support for several power domains on Raspberry Pi, > including USB (so it can be enabled even if the bootloader didn't do > it), and graphics. > > This patch is the combined work of Eric Anholt (who wrote USB support > inside of the Raspberry Pi firmware driver, and wrote the non-USB > domain support) and Alexander Aring (who separated the original USB > work out from the firmware driver). > > Signed-off-by: Alexander Aring > Signed-off-by: Eric Anholt > --- > > v2: Add support for power domains other than USB, using the new > firmware interface, reword commit message (changes by Eric) > > v3: Restructure as a builtin driver, and drop > of_genpd_add_provider_onecell error handling to avoid > pm_genpd_exit() dependency until that API can be settled. Clean > up copyright header, add missing ISP initialization, and fix typo > in transposer's name. > > arch/arm/mach-bcm/Kconfig | 10 ++ > arch/arm/mach-bcm/Makefile | 1 + > arch/arm/mach-bcm/raspberrypi-power.c | 247 > > include/dt-bindings/arm/raspberrypi-power.h | 41 + > 4 files changed, 299 insertions(+) > create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c What motivated the location of this power domain driver in arch/arm/mach-bcm? Should not we have this in drivers/power/ or somewhere in drivers/ at the very least? -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] dt-binding: power: Add otg regulator binding
On Tue 15 Dec 11:52 PST 2015, Tim Bird wrote: > Add a binding for the regulator which controls the OTG chargepath switch. > The OTG switch gets its power from pm8941_5vs1, and that should be > expressed as a usb_otg_in-supply property in the DT node for the > charger driver. The regulator name is "otg-vbus". > > Signed-off-by: Tim Bird > --- > Changes since v3 > - switch supply name to have underscores instead of dashes >- (switched back to match the name used in data sheets) Thanks, now it matches the datasheet again. > - switch regulator node name to otg-vbus > Changes since v1 > - switch supply name to have dashes instead of underscores > - remove superfluous DT explanations in the otg node description > --- Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] Input: synaptics-rmi4: Add device tree support for 2d sensors and F11
Hi Rob, I'm taking a look at this patchset again and I had a couple follow up questions. On 11/27/2015 01:10 PM, Rob Herring wrote: On Wed, Nov 25, 2015 at 04:09:13PM -0800, Andrew Duggan wrote: 2D sensors have several parameter which can be set in the platform data. This patch adds support for getting those values from devicetree. Signed-off-by: Andrew Duggan --- .../bindings/input/rmi4/rmi_2d_sensor.txt | 54 +++ drivers/input/rmi4/rmi_2d_sensor.c | 103 + drivers/input/rmi4/rmi_2d_sensor.h | 3 + drivers/input/rmi4/rmi_f11.c | 7 +- 4 files changed, 166 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt new file mode 100644 index 000..bbff31b --- /dev/null +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt @@ -0,0 +1,54 @@ +Synaptics RMI4 2D Sensor Device Binding + +The Synaptics RMI4 core is able to support RMI4 devices using differnet s/differnet/different/ Oops! That's a lot of typos. I'll make sure to run spell check next time. +transports and differnet functions. This file describes the device tree ditto. +bindings for devices which contain 2D sensors using Function 11 or +Function 12. Complete documentation for transports and other functions +can be found in: +Documentation/devicetree/bindings/input/rmi4. + +RMI4 Function 11 and Function 12 are for 2D touch position sensing. +Additional documentation for F11 can be found at: +http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf + +Optional Properties: +- syna,swap-axes: Swap X and Y positions when reporting (boolean). +- syna,flip-x: Reverse the direction of X (boolean). +- syna,flip-y: Reverse the direction of Y (boolean). We already have similar, generic properties for these. Are you referring to the generic properties documented here? Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt The rmi4 driver will be used for both touchpads and touchscreens so having a touchpad set a property like touchscreen-inverted-y could be confusing. It looks like there used to be more generic parameters which are now deprecated. Now the generic parameters are specific to touchscreens. Would it make sense to create touch-* parameters instead of touchscreen-*? Thanks, Andrew +- syna,clip-x-low: Sets a minimum value for X. +- syna,clip-y-low: Sets a minimum value for Y. +- syna,clip-x-high: Sets a maximum value for X. +- syna,clip-y-high: Sets a maximum value for Y. +- syna,offset-x: Add an offset to X. +- syna,offset_y: Add an offset to Y. Don't use "_". +- syna,delta-x-threshold: Set the minimum distance on the X axis required + to generate an interrupt in reduced reporting + mode. +- syna,delta-y-threshold: Set the minimum distance on the Y axis required + to generate an interrupt in reduced reporting + mode. +- syna,type-a: Report type A multitouch events. +- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad. +- syna,x-mm: The length in millimeters of the X axis. +- syna,y-mm: The length in millimeters of the Y axis. I think some of these have common properties defined too. If not, we should add them. +- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to + disable reporing absolute position data. +- syna,rezero-wait: Time in miliseconds to wait after issuing a rezero + command. Add -msec suffix. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] power: qcom_smbb: Add otg regulator for control of vbus
On Tue 15 Dec 11:52 PST 2015, Tim Bird wrote: > Add a regulator to control the OTG chargepath switch. This > is used by USB code to control VBUS direction - out for host mode > on the OTG port, and in for charging mode. > > Signed-off-by: Tim Bird > --- > Changes since v3: > - changed DT node name to otg-vbus > - removed fixed-voltage setup from otg regulator rdesc > Changes since v1: > - changed name of supply to remove underscores > --- Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] ARM: dts: qcom: add charger otg regulator
On Tue 15 Dec 11:52 PST 2015, Tim Bird wrote:
> Add the otg regulator provided by the charger block.
>
> Signed-off-by: Tim Bird
> ---
> Changes since V3:
> - change name of charger regulator to "otg-vbus"
> ---
> arch/arm/boot/dts/qcom-pm8941.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi
> b/arch/arm/boot/dts/qcom-pm8941.dtsi
> index b0d4439..d0ffca7 100644
> --- a/arch/arm/boot/dts/qcom-pm8941.dtsi
> +++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
> @@ -45,6 +45,10 @@
> "chg-gone",
> "usb-valid",
> "dc-valid";
> +
> + usb_otg_in-supply = <&pm8941_5vs1>;
Although this could be coming from some other supply I think it's
perfectly fine that we define this on a platform level.
> +
> + chg_otg: otg-vbus { };
> };
>
> pm8941_gpios: gpios@c000 {
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gpio: sx150x: Add support for sx1502
From: Peter Rosin
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/gpio/gpio-sx150x.txt | 3 +-
drivers/gpio/gpio-sx150x.c | 53 --
2 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
b/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
index ba2bb84eeac3..c809acb9c71b 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-sx150x.txt
@@ -5,7 +5,8 @@ Required properties:
- compatible: should be "semtech,sx1506q",
"semtech,sx1508q",
- "semtech,sx1509q".
+ "semtech,sx1509q",
+ "semtech,sx1502q".
- reg: The I2C slave address for this device.
diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
index 76f920173a2f..0a3105cde82d 100644
--- a/drivers/gpio/gpio-sx150x.c
+++ b/drivers/gpio/gpio-sx150x.c
@@ -32,8 +32,19 @@
#define NO_UPDATE_PENDING -1
/* The chip models of sx150x */
-#define SX150X_456 0
-#define SX150X_789 1
+#define SX150X_123 0
+#define SX150X_456 1
+#define SX150X_789 2
+
+struct sx150x_123_pri {
+ u8 reg_pld_mode;
+ u8 reg_pld_table0;
+ u8 reg_pld_table1;
+ u8 reg_pld_table2;
+ u8 reg_pld_table3;
+ u8 reg_pld_table4;
+ u8 reg_advance;
+};
struct sx150x_456_pri {
u8 reg_pld_mode;
@@ -65,6 +76,7 @@ struct sx150x_device_data {
u8 reg_sense;
u8 ngpios;
union {
+ struct sx150x_123_pri x123;
struct sx150x_456_pri x456;
struct sx150x_789_pri x789;
} pri;
@@ -142,12 +154,33 @@ static const struct sx150x_device_data sx150x_devices[] =
{
},
.ngpios = 16
},
+ [3] = { /* sx1502q */
+ .model = SX150X_123,
+ .reg_pullup = 0x02,
+ .reg_pulldn = 0x03,
+ .reg_dir= 0x01,
+ .reg_data = 0x00,
+ .reg_irq_mask = 0x05,
+ .reg_irq_src= 0x08,
+ .reg_sense = 0x07,
+ .pri.x123 = {
+ .reg_pld_mode = 0x10,
+ .reg_pld_table0 = 0x11,
+ .reg_pld_table1 = 0x12,
+ .reg_pld_table2 = 0x13,
+ .reg_pld_table3 = 0x14,
+ .reg_pld_table4 = 0x15,
+ .reg_advance= 0xad,
+ },
+ .ngpios = 8,
+ },
};
static const struct i2c_device_id sx150x_id[] = {
{"sx1508q", 0},
{"sx1509q", 1},
{"sx1506q", 2},
+ {"sx1502q", 3},
{}
};
MODULE_DEVICE_TABLE(i2c, sx150x_id);
@@ -156,6 +189,7 @@ static const struct of_device_id sx150x_of_match[] = {
{ .compatible = "semtech,sx1508q" },
{ .compatible = "semtech,sx1509q" },
{ .compatible = "semtech,sx1506q" },
+ { .compatible = "semtech,sx1502q" },
{},
};
MODULE_DEVICE_TABLE(of, sx150x_of_match);
@@ -545,10 +579,14 @@ static int sx150x_init_hw(struct sx150x_chip *chip,
err = sx150x_i2c_write(chip->client,
chip->dev_cfg->pri.x789.reg_misc,
0x01);
- else
+ else if (chip->dev_cfg->model == SX150X_456)
err = sx150x_i2c_write(chip->client,
chip->dev_cfg->pri.x456.reg_advance,
0x04);
+ else
+ err = sx150x_i2c_write(chip->client,
+ chip->dev_cfg->pri.x123.reg_advance,
+ 0x00);
if (err < 0)
return err;
@@ -574,13 +612,20 @@ static int sx150x_init_hw(struct sx150x_chip *chip,
pdata->io_polarity);
if (err < 0)
return err;
- } else {
+ } else if (chip->dev_cfg->model == SX150X_456) {
/* Set all pins to work in normal mode */
err = sx150x_init_io(chip,
chip->dev_cfg->pri.x456.reg_pld_mode,
0);
if (err < 0)
return err;
+ } else {
+ /* Set all pins to work in normal mode */
+ err = sx150x_init_io(chip,
+ chip->dev_cfg->pri.x123.reg_pld_mode,
+ 0);
+ if (err < 0)
+ return err;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
On Tuesday 15 December 2015 15:09:23 Timur Tabi wrote: > Arnd Bergmann wrote: > > If that's in the probe() called from it function, just use writel() > > everywhere, > > a few extra microseconds won't kill the boot time. In general, if a user > > would > > notice the difference, use the relaxed version and add a comment to explain > > how you proved it's correct, otherwise stay with the default accessors. > > What about adding a wmb() after the last writel()? This driver does > that a lot. Is that something we want to discourage? I can understand > how we would want to make sure that the last write is posted before the > function exits. Please explain in a comment specifically which race you are closing by ensuring that the write gets posted. What does it race against? As I said earlier, guaranteeing that a write gets posted does not mean it has arrived at the device, we only get that behavior after a subsequent read from the same device, but you don't need a wmb() between the write and the read to guarantee this. If you have an odd bus that does not follow those rules, it may in fact be best to have a separate set of I/O accessors and not use readl/writel at all. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] serial: support for 16550A serial ports on LP-8x4x
On Wednesday 16 December 2015 00:04:45 Sergei Ianovich wrote:
> index 000..5f9a4c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/lp8x4x-serial.txt
> @@ -0,0 +1,35 @@
> +UART ports on ICP DAS LP-8x4x
> +
> +ICP DAS LP-8x4x contains three additional serial ports interfaced via
> +Analog Devices ADM213EA chips in addition to 3 serial ports on PXA CPU.
> +
> +Required properties:
> +- compatible : should be "icpdas,uart-lp8x4x"
Compatible strings should not include a 'x' wildcard like this, better use
the specific chip name.
Also, it sounds like you named them after the board vendor, which sounds
wrong as the vendor part of the compatible string should be the whoever
made that part (analog?)
> +- reg : should provide 16 byte man IO memory region and 1 byte region for
> + termios
> +
> +- interrupts : should provide interrupt
> +
> +- interrupt-parent : should provide a link to interrupt controller either
> +explicitly or implicitly from a parent node
interrupt-parent should be an optional property, or you can leave it out,
as this is a standard property that can always be there when there is
interrupts.
> +Examples (from pxa27x-lp8x4x.dts):
> +
> + uart@9050 {
By convention, the name should be 'serial', not 'uart'.
Arnd.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] ARM: bcm2835: Define two new packets from the latest firmware.
These packets give us direct access to the firmware's power management
code, as opposed to GET/SET_POWER_STATE packets that only had a couple
of domains implemented.
Signed-off-by: Eric Anholt
---
include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
b/include/soc/bcm2835/raspberrypi-firmware.h
index c07d74a..3fb3571 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -72,10 +72,12 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_ENABLE_QPU = 0x00030012,
RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
+ RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
RPI_FIRMWARE_SET_CLOCK_STATE =0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE =0x00038003,
RPI_FIRMWARE_SET_TURBO = 0x00038009,
+ RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
From: Alexander Aring
This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.
This patch is the combined work of Eric Anholt (who wrote USB support
inside of the Raspberry Pi firmware driver, and wrote the non-USB
domain support) and Alexander Aring (who separated the original USB
work out from the firmware driver).
Signed-off-by: Alexander Aring
Signed-off-by: Eric Anholt
---
v2: Add support for power domains other than USB, using the new
firmware interface, reword commit message (changes by Eric)
v3: Restructure as a builtin driver, and drop
of_genpd_add_provider_onecell error handling to avoid
pm_genpd_exit() dependency until that API can be settled. Clean
up copyright header, add missing ISP initialization, and fix typo
in transposer's name.
arch/arm/mach-bcm/Kconfig | 10 ++
arch/arm/mach-bcm/Makefile | 1 +
arch/arm/mach-bcm/raspberrypi-power.c | 247
include/dt-bindings/arm/raspberrypi-power.h | 41 +
4 files changed, 299 insertions(+)
create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
create mode 100644 include/dt-bindings/arm/raspberrypi-power.h
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8c53c55..0f23bad 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -134,6 +134,16 @@ config ARCH_BCM2835
This enables support for the Broadcom BCM2835 SoC. This SoC is
used in the Raspberry Pi and Roku 2 devices.
+config RASPBERRYPI_POWER
+ bool "Raspberry Pi power domain driver"
+ depends on ARCH_BCM2835 || COMPILE_TEST
+ depends on RASPBERRYPI_FIRMWARE
+ select PM_GENERIC_DOMAINS if PM
+ select PM_GENERIC_DOMAINS_OF if PM
+ help
+ This enables support for the RPi power domains which can be enabled
+ or disabled via the RPi firmware.
+
config ARCH_BCM_63XX
bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..fec2d6b 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -36,6 +36,7 @@ endif
# BCM2835
obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o
# BCM5301X
obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o
diff --git a/arch/arm/mach-bcm/raspberrypi-power.c
b/arch/arm/mach-bcm/raspberrypi-power.c
new file mode 100644
index 000..9dc8b43
--- /dev/null
+++ b/arch/arm/mach-bcm/raspberrypi-power.c
@@ -0,0 +1,247 @@
+/* (C) 2015 Pengutronix, Alexander Aring
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Authors:
+ * Alexander Aring
+ * Eric Anholt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Firmware indices for the old power domains interface. Only a few
+ * of them were actually implemented.
+ */
+#define RPI_OLD_POWER_DOMAIN_USB 3
+#define RPI_OLD_POWER_DOMAIN_V3D 10
+
+struct rpi_power_domain {
+ u32 domain;
+ bool enabled;
+ bool old_interface;
+ struct generic_pm_domain base;
+ struct rpi_firmware *fw;
+};
+
+struct rpi_power_domains {
+ bool has_new_interface;
+ struct genpd_onecell_data xlate;
+ struct rpi_firmware *fw;
+ struct rpi_power_domain domains[RPI_POWER_DOMAIN_COUNT];
+};
+
+/*
+ * Packet definition used by RPI_FIRMWARE_SET_POWER_STATE and
+ * RPI_FIRMWARE_SET_DOMAIN_STATE
+ */
+struct rpi_power_domain_packet {
+ u32 domain;
+ u32 on;
+} __packet;
+
+/*
+ * Asks the firmware to enable or disable power on a specific power
+ * domain.
+ */
+static int rpi_firmware_set_power(struct rpi_power_domain *rpi_domain, bool on)
+{
+ struct rpi_power_domain_packet packet;
+
+ packet.domain = rpi_domain->domain;
+ packet.on = on;
+ return rpi_firmware_property(rpi_domain->fw,
+rpi_domain->old_interface ?
+RPI_FIRMWARE_SET_POWER_STATE :
+RPI_FIRMWARE_SET_DOMAIN_STATE,
+&packet, sizeof(packet));
+}
+
+static int rpi_domain_off(struct generic_pm_domain *domain)
+{
+ struct rpi_power_domain *rpi_domain =
+ container_of(domain, struct rpi_power_domain, base);
+
+ return rpi_firmware_set_power(rpi_domain, false);
+}
+
+static int rpi_domain_on(struct generic_pm_domain *domain)
+{
+ struct rpi_power_domain *rpi_domain =
+ container_of(domain, struct rpi_power_domain, base);
+
+ return rpi_firmware_set_power(rpi_domain, true);
+}
+
+static void rpi_common_init_power_domain(struct
[PATCH v3 0/4] Raspberry Pi power domains
Since the pm_genpd_exit() patch is still going through review, and other drivers in the tree just ignore the error cases, Ulf offered to merge the series as a builtin driver not depending on that interface. We still avoid dangling pointer references, by just continuing with probing if of_genpd_add_provider_onecell() fails. We can easily go back and update the driver when a pm_genpd_exit() lands. Alexander Aring (3): ARM: bcm2835: add rpi power domain driver dt-bindings: add rpi power domain driver bindings ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. Eric Anholt (1): ARM: bcm2835: Define two new packets from the latest firmware. .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 + arch/arm/boot/dts/bcm2835.dtsi | 2 +- arch/arm/mach-bcm/Kconfig | 10 + arch/arm/mach-bcm/Makefile | 1 + arch/arm/mach-bcm/raspberrypi-power.c | 247 + include/dt-bindings/arm/raspberrypi-power.h| 41 include/soc/bcm2835/raspberrypi-firmware.h | 2 + 8 files changed, 360 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c create mode 100644 include/dt-bindings/arm/raspberrypi-power.h -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
From: Alexander Aring
This connects the USB driver to the USB power domain, so that USB can
actually be turned on at boot if the bootloader didn't do it for us.
Signed-off-by: Alexander Aring
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 +++
arch/arm/boot/dts/bcm2835.dtsi | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..f828202 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include
#include "bcm2835.dtsi"
/ {
@@ -20,6 +21,12 @@
compatible = "raspberrypi,bcm2835-firmware";
mboxes = <&mailbox>;
};
+
+ power: power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <&firmware>;
+ #power-domain-cells = <1>;
+ };
};
};
@@ -60,3 +67,7 @@
status = "okay";
bus-width = <4>;
};
+
+&usb {
+ power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..6d62af0 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -177,7 +177,7 @@
status = "disabled";
};
- usb@7e98 {
+ usb: usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
interrupts = <1 9>;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] dt-bindings: add rpi power domain driver bindings
From: Alexander Aring
This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.
Signed-off-by: Alexander Aring
Acked-by: Rob Herring
Signed-off-by: Eric Anholt
---
v2: Add the new domains present in v2 to the list.
.../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
diff --git
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 000..30942cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,47 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible: Should be "raspberrypi,bcm2835-power".
+- firmware:Reference to the RPi firmware device node.
+- #power-domain-cells: Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_I2C0
+ RPI_POWER_DOMAIN_I2C1
+ RPI_POWER_DOMAIN_I2C2
+ RPI_POWER_DOMAIN_VIDEO_SCALER
+ RPI_POWER_DOMAIN_VPU1
+ RPI_POWER_DOMAIN_HDMI
+ RPI_POWER_DOMAIN_USB
+ RPI_POWER_DOMAIN_VEC
+ RPI_POWER_DOMAIN_JPEG
+ RPI_POWER_DOMAIN_H264
+ RPI_POWER_DOMAIN_V3D
+ RPI_POWER_DOMAIN_ISP
+ RPI_POWER_DOMAIN_UNICAM0
+ RPI_POWER_DOMAIN_UNICAM1
+ RPI_POWER_DOMAIN_CCP2RX
+ RPI_POWER_DOMAIN_CSI2
+ RPI_POWER_DOMAIN_CPI
+ RPI_POWER_DOMAIN_DSI0
+ RPI_POWER_DOMAIN_DSI1
+ RPI_POWER_DOMAIN_TRANSPOSER
+ RPI_POWER_DOMAIN_CCP2TX
+ RPI_POWER_DOMAIN_CDP
+ RPI_POWER_DOMAIN_ARM
+
+Example:
+
+power: power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <&firmware>;
+ #power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+ power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
Arnd Bergmann wrote: If that's in the probe() called from it function, just use writel() everywhere, a few extra microseconds won't kill the boot time. In general, if a user would notice the difference, use the relaxed version and add a comment to explain how you proved it's correct, otherwise stay with the default accessors. What about adding a wmb() after the last writel()? This driver does that a lot. Is that something we want to discourage? I can understand how we would want to make sure that the last write is posted before the function exits. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] serial: support for 16550A serial ports on LP-8x4x
The patch adds support for 3 additional LP-8x4x built-in serial
ports.
The device can also host up to 8 extension cards with 4 serial ports
on each card for a total of 35 ports. However, I don't have
the hardware to test extension cards, so they are not supported, yet.
Signed-off-by: Sergei Ianovich
Reviewed-by: Heikki Krogerus
CC: Alan Cox
---
v4..v5
* constify struct of_device_id
* drop .owner from struct platform_driver
* rewrite set_termios() baud rate hadnling as suggested by Alan Cox
v3..v4
* move DTS bindings to a different patch (8/21) as suggested by
Heikki Krogerus
v2..v3
* no changes (except number 10/16 -> 12/21)
v0..v2
* register platform driver instead of platform device
* use device tree
* use devm helpers where possible
.../devicetree/bindings/serial/lp8x4x-serial.txt | 35 +
drivers/tty/serial/8250/8250_lp8x4x.c | 168 +
drivers/tty/serial/8250/Kconfig| 12 ++
drivers/tty/serial/8250/Makefile | 1 +
4 files changed, 216 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/lp8x4x-serial.txt
create mode 100644 drivers/tty/serial/8250/8250_lp8x4x.c
diff --git a/Documentation/devicetree/bindings/serial/lp8x4x-serial.txt
b/Documentation/devicetree/bindings/serial/lp8x4x-serial.txt
new file mode 100644
index 000..5f9a4c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/lp8x4x-serial.txt
@@ -0,0 +1,35 @@
+UART ports on ICP DAS LP-8x4x
+
+ICP DAS LP-8x4x contains three additional serial ports interfaced via
+Analog Devices ADM213EA chips in addition to 3 serial ports on PXA CPU.
+
+Required properties:
+- compatible : should be "icpdas,uart-lp8x4x"
+
+- reg : should provide 16 byte man IO memory region and 1 byte region for
+ termios
+
+- interrupts : should provide interrupt
+
+- interrupt-parent : should provide a link to interrupt controller either
+explicitly or implicitly from a parent node
+
+Examples (from pxa27x-lp8x4x.dts):
+
+ uart@9050 {
+ compatible = "icpdas,uart-lp8x4x";
+ reg = <0x9050 0x10
+ 0x9030 0x02>;
+ interrupt-parent = <&fpgairg>;
+ interrupts = <13>;
+ status = "okay";
+ };
+
+ uart@9060 {
+ compatible = "icpdas,uart-lp8x4x";
+ reg = <0x9060 0x10
+ 0x9032 0x02>;
+ interrupt-parent = <&fpgairg>;
+ interrupts = <14>;
+ status = "okay";
+ };
diff --git a/drivers/tty/serial/8250/8250_lp8x4x.c
b/drivers/tty/serial/8250/8250_lp8x4x.c
new file mode 100644
index 000..0e07220
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_lp8x4x.c
@@ -0,0 +1,168 @@
+/* linux/drivers/tty/serial/8250/8250_lp8x4x.c
+ *
+ * Support for 16550A serial ports on ICP DAS LP-8x4x
+ *
+ * Copyright (C) 2013 Sergei Ianovich
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct lp8x4x_serial_data {
+ int line;
+ void*ios_mem;
+};
+
+static void lp8x4x_serial_set_termios(struct uart_port *port,
+ struct ktermios *termios, struct ktermios *old)
+{
+ unsigned int len;
+ unsigned int baud;
+ struct lp8x4x_serial_data *data = port->private_data;
+
+ serial8250_do_set_termios(port, termios, old);
+
+ switch (termios->c_cflag & CSIZE) {
+ case CS5:
+ len = 7;
+ break;
+ case CS6:
+ len = 8;
+ break;
+ case CS7:
+ len = 9;
+ break;
+ default:
+ case CS8:
+ len = 10;
+ break;
+ }
+
+ if (termios->c_cflag & CSTOPB)
+ len++;
+ if (termios->c_cflag & PARENB)
+ len++;
+ if (!(termios->c_cflag & PARODD))
+ len++;
+#ifdef CMSPAR
+ if (termios->c_cflag & CMSPAR)
+ len++;
+#endif
+
+ len -= 9;
+ len &= 3;
+ len <<= 3;
+ /*
+* Ask the core to calculate the divisor for us.
+*/
+ baud = tty_termios_baud_rate(termios);
+
+ switch (baud) {
+ case 115200:
+ len |= 7;
+ break;
+ case 57600:
+ len |= 6;
+ break;
+ case 38400:
+ len |= 5;
+ break;
+ case 19200:
+ len |= 4;
+ break;
+ case 9600:
+ len |= 3;
+ break;
+ case 4800:
+
Re: [PATCH v5 2/2] arm: pxa27x: support for ICP DAS LP-8x4x w/ DT
On Tuesday 15 December 2015 21:01:35 Robert Jarzmik wrote: > Arnd Bergmann writes: > > > On Tuesday 15 December 2015 21:50:13 Sergei Ianovich wrote: > >> On Tue, 2015-12-15 at 19:06 +0100, Robert Jarzmik wrote: > >> Updated plan: > >> 1. MACH_PXA27X_DT > >> 2. PXA_FB and 8250_PXA to enable console > What about gpio-pxa ? And maybe pinctrl-pxa27x (only in linux-next by now) ? > Can > a pxafb work without gpio-pxa ? Also usually for pxafb you have pwm and pwm_bl > to see something. > > >> 3. MMC, MMC_PXA and EXT4_FS to enable boot from MMC > >> 3.1. MTD, MTD_CFI, MTD_PHYSMAP_OF and JFFS2_FS to enable boot from MTD > Ok. Is pxa2xx-pcmcia out of scope ? I seem to remember we have several boards > where pcmcia is the rootfs (even if that is a small mess right now I still > have > to work on). Or do we consider pcmcia as obsolete ? I'm definitely fine with tossing in everything that is PXA specific, even if it's rarely used. If someone wants a smaller kernel, they can still start out with the defconfig and disable stuff they don't need, which tends to be easier than the opposite, and it gives us compile-time coverage with the autobuilders that compile every defconfig. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver
On Tuesday 15 December 2015 18:42:36 Thierry Reding wrote: > On Tue, Dec 15, 2015 at 05:34:00PM +0100, Arnd Bergmann wrote: > > On Tuesday 15 December 2015 17:31:22 Thierry Reding wrote: > > > On Mon, Dec 14, 2015 at 12:39:44PM +0100, Arnd Bergmann wrote: > > > > On Wednesday 18 November 2015 17:56:22 Andy Yan wrote: > > > > > rockchip platform have a protocol to pass the kernel reboot > > > > > mode to bootloader by some special registers when system reboot. > > > > > By this way the bootloader can take different action according > > > > > to the different kernel reboot mode, for example, command > > > > > "reboot loader" will reboot the board to rockusb mode, this is > > > > > a very convenient way to get the board enter download mode. > > > > > > > > > > Signed-off-by: Andy Yan > > > > > > > > Adding John Stultz to Cc > > > > > > > > I just saw this thread pop up again, and had to think of John's recent > > > > patch to unify this across platforms. > > > > > > > > John, can you have a look at this driver too, and see how it fits in? > > > > I think this is yet another variant, using an MMIO register rather than > > > > RAM (as HTC / NVIDIA does) or SRAM (as Qualcomm does), but otherwise > > > > it conceptually fits in with what you had. > > > > > > FWIW, Tegra typically does use an MMIO register as well. See > > > drivers/soc/tegra/pmc.c:tegra_pmc_restart_notify(). I don't know what > > > HTC does, but if it's writing somewhere in RAM it isn't using the > > > standard way of resetting the SoC. There's early boot ROM code which I > > > think evaluates the PMC_SCRATCH0 register on Tegra to determine which > > > mode to boot into. That's before even any firmware gets the chance of > > > doing anything. I just checked the android lollipop tree, and I could not find a pmc_restart_notify function, only this file https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/drivers/htc_debug/stability/reboot_params.c with the device that stores into RAM. It looks like HTC ported over a driver that they were already using on some Qualcomm MSM8960 device, as in https://gitlab.com/MaC/android_kernel_htc_msm8960/blob/859977fc723f59a6b707df1d70e80826ee1dccc4/arch/arm/mach-msm/htc/htc_restart_handler.c On Android marshmallow (Flounder), that file again does not exist, and I don't see how it's done. > > HTC apparently uses a separate RAM area to pass the reboot reason, > > and they have a driver to store that, which is separate from the > > driver that they use for actually rebooting the machine. > > I wasn't very clear, but the PMC_SCRATCH0 register is used to store the > reset reason. It supports the recovery mode, which I think is really an > Android thing, "bootloader" will typically cause the bootloader not to > boot anything, and "forced-recovery" will go into a recovery mode that > is used to bootstrap the device (usually by uploading a "miniloader" > that initializes RAM, downloads a bootloader for booting or flashing an > operating system, ...). > > The write that resets the SoC is to a different register. So is this scratch register interpreted by some maskrom code, or by code that can be provided by the OEM? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] doc: dt-binding: generic onboard USB HUB
On 9 December 2015 at 09:55, Arnd Bergmann wrote: > On Wednesday 09 December 2015 16:12:24 Peter Chen wrote: >> On Tue, Dec 08, 2015 at 09:24:03PM -0600, Rob Herring wrote: >> > On Tue, Dec 08, 2015 at 10:58:48AM +0100, Arnd Bergmann wrote: >> > > On Tuesday 08 December 2015 10:50:49 Philipp Zabel wrote: >> > > > This something we don't have to define ad-hoc. The hub hangs off an USB >> > > > controller, right? The "Open Firmware recommended practice: USB" >> > > > document already describes how to represent USB devices in a generic >> > > > manner: >> > > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps >> > > > >> > > > Is there a reason not to reuse this? >> > > > >> > > > The usb hub node would be a child of the usb controller node, and it >> > > > could use >> > > > compatible = "usb,class9"; /* bDeviceClass 9 (Hub) */ >> > > >> > > Good point, I had not thought of that when I looked at the patches. >> > > >> > > Yes, let's do this way. I don't know if we ever implemented the simple >> > > patch to associate a USB device with a device_node, but if not, then >> > > let's do it now for this driver. A lot of people have asked for it in >> > > the past. >> > >> > Agreed. Also, some hubs have I2C buses as well, but I still think under >> > the USB bus is the right place. >> > >> > However, one complication here is often (probably this case) these >> > addtional signals need to be controlled before the device enumerates. >> > >> >> Yes, I did not find a way to let the USB bus code handle it, so I had to >> write a platform driver to do it > > Looping in Ulf, he solved the same problem for SDIO devices recently, > and probably remembers the details best. > Thanks Arnd! Yes, that was a kind of a long outstanding issue we have had for SDIO devices. Several generic attempts was made to have a framework/library available to support so called "power sequences" for exactly the same reasons as above. Others and myself failed to get those attempts accepted. Instead, I invented a mmc subsystem specific DT based solution, the "mmc-pwrseq". DT documentation: Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt Documentation/devicetree/bindings/mmc/mmc.txt Long story short: The mmc host device may contain a phandle to a mmc-pwrseq, which will describe the resources needed to power on/off the SDIO card. The code is available at: drivers/mmc/core/pwrseq* We didn't implement this as platform driver, but that was mostly because I initially wanted things to be simple. Although, nothing prevents us from converting to this as a follow up, which would make the solution a bit less "hacky". Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] power: qcom_smbb: Add otg regulator for control of vbus
Add a regulator to control the OTG chargepath switch. This
is used by USB code to control VBUS direction - out for host mode
on the OTG port, and in for charging mode.
Signed-off-by: Tim Bird
---
Changes since v3:
- changed DT node name to otg-vbus
- removed fixed-voltage setup from otg regulator rdesc
Changes since v1:
- changed name of supply to remove underscores
---
drivers/power/qcom_smbb.c | 72 +++
1 file changed, 72 insertions(+)
diff --git a/drivers/power/qcom_smbb.c b/drivers/power/qcom_smbb.c
index 5eb1e9e..8998f4d 100644
--- a/drivers/power/qcom_smbb.c
+++ b/drivers/power/qcom_smbb.c
@@ -34,6 +34,9 @@
#include
#include
#include
+#include
+#include
+#include
#define SMBB_CHG_VMAX 0x040
#define SMBB_CHG_VSAFE 0x041
@@ -71,6 +74,8 @@
#define BTC_CTRL_HOT_EXT_N BIT(0)
#define SMBB_USB_IMAX 0x344
+#define SMBB_USB_OTG_CTL 0x348
+#define OTG_CTL_EN BIT(0)
#define SMBB_USB_ENUM_TIMER_STOP 0x34e
#define ENUM_TIMER_STOPBIT(0)
#define SMBB_USB_SEC_ACCESS0x3d0
@@ -123,6 +128,9 @@ struct smbb_charger {
struct power_supply *dc_psy;
struct power_supply *bat_psy;
struct regmap *regmap;
+
+ struct regulator_desc otg_rdesc;
+ struct regulator_dev *otg_reg;
};
static int smbb_vbat_weak_fn(unsigned int index)
@@ -778,12 +786,56 @@ static const struct power_supply_desc dc_psy_desc = {
.property_is_writeable = smbb_charger_writable_property,
};
+static int smbb_chg_otg_enable(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+ OTG_CTL_EN, OTG_CTL_EN);
+ if (rc)
+ dev_err(chg->dev, "failed to update OTG_CTL\n");
+ return rc;
+}
+
+static int smbb_chg_otg_disable(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+ OTG_CTL_EN, 0);
+ if (rc)
+ dev_err(chg->dev, "failed to update OTG_CTL\n");
+ return rc;
+}
+
+static int smbb_chg_otg_is_enabled(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ unsigned int value = 0;
+ int rc;
+
+ rc = regmap_read(chg->regmap, chg->addr + SMBB_USB_OTG_CTL, &value);
+ if (rc)
+ dev_err(chg->dev, "failed to read OTG_CTL\n");
+
+ return !!(value & OTG_CTL_EN);
+}
+
+static struct regulator_ops smbb_chg_otg_ops = {
+ .enable = smbb_chg_otg_enable,
+ .disable = smbb_chg_otg_disable,
+ .is_enabled = smbb_chg_otg_is_enabled,
+};
+
static int smbb_charger_probe(struct platform_device *pdev)
{
struct power_supply_config bat_cfg = {};
struct power_supply_config usb_cfg = {};
struct power_supply_config dc_cfg = {};
struct smbb_charger *chg;
+ struct regulator_config config = { };
int rc, i;
chg = devm_kzalloc(&pdev->dev, sizeof(*chg), GFP_KERNEL);
@@ -884,6 +936,26 @@ static int smbb_charger_probe(struct platform_device *pdev)
}
}
+ /*
+* otg regulator is used to control VBUS voltage direction
+* when USB switches between host and gadget mode
+*/
+ chg->otg_rdesc.id = -1;
+ chg->otg_rdesc.name = "otg-vbus";
+ chg->otg_rdesc.ops = &smbb_chg_otg_ops;
+ chg->otg_rdesc.owner = THIS_MODULE;
+ chg->otg_rdesc.type = REGULATOR_VOLTAGE;
+ chg->otg_rdesc.supply_name = "usb-otg-in";
+ chg->otg_rdesc.of_match = "otg-vbus";
+
+ config.dev = &pdev->dev;
+ config.driver_data = chg;
+
+ chg->otg_reg = devm_regulator_register(&pdev->dev, &chg->otg_rdesc,
+ &config);
+ if (IS_ERR(chg->otg_reg))
+ return PTR_ERR(chg->otg_reg);
+
chg->jeita_ext_temp = of_property_read_bool(pdev->dev.of_node,
"qcom,jeita-extended-temp-range");
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] ARM: dts: qcom: add charger otg regulator
Add the otg regulator provided by the charger block.
Signed-off-by: Tim Bird
---
Changes since V3:
- change name of charger regulator to "otg-vbus"
---
arch/arm/boot/dts/qcom-pm8941.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index b0d4439..d0ffca7 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -45,6 +45,10 @@
"chg-gone",
"usb-valid",
"dc-valid";
+
+ usb_otg_in-supply = <&pm8941_5vs1>;
+
+ chg_otg: otg-vbus { };
};
pm8941_gpios: gpios@c000 {
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] dt-binding: power: Add otg regulator binding
Add a binding for the regulator which controls the OTG chargepath switch.
The OTG switch gets its power from pm8941_5vs1, and that should be
expressed as a usb_otg_in-supply property in the DT node for the
charger driver. The regulator name is "otg-vbus".
Signed-off-by: Tim Bird
---
Changes since v3
- switch supply name to have underscores instead of dashes
- (switched back to match the name used in data sheets)
- switch regulator node name to otg-vbus
Changes since v1
- switch supply name to have dashes instead of underscores
- remove superfluous DT explanations in the otg node description
---
.../devicetree/bindings/power_supply/qcom_smbb.txt| 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
index 65b88fa..06f8a5d 100644
--- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
+++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
@@ -105,6 +105,22 @@ PROPERTIES
regulation must be done externally to fully comply with
the JEITA safety guidelines if this flag is set.
+- usb_otg_in-supply:
+ Usage: optional
+ Value type:
+ Description: Reference to the regulator supplying power to the USB_OTG_IN
+ pin.
+
+child nodes:
+- otg-vbus:
+ Usage: optional
+ Description: This node defines a regulator used to control the direction
+ of VBUS voltage - specifically: whether to supply voltage
+ to VBUS for host mode operation of the OTG port, or allow
+ input voltage from external VBUS for charging. In the
+ hardware, the supply for this regulator comes from
+ usb_otg_in-supply.
+
EXAMPLE
charger@1000 {
compatible = "qcom,pm8941-charger";
@@ -128,4 +144,7 @@ charger@1000 {
qcom,fast-charge-current-limit = <100>;
qcom,dc-charge-current-limit = <100>;
+ usb_otg_in-supply = <&pm8941_5vs1>;
+
+ otg-vbus {};
};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] arm: pxa27x: support for ICP DAS LP-8x4x w/ DT
Arnd Bergmann writes: > On Tuesday 15 December 2015 21:50:13 Sergei Ianovich wrote: >> On Tue, 2015-12-15 at 19:06 +0100, Robert Jarzmik wrote: >> Updated plan: >> 1. MACH_PXA27X_DT >> 2. PXA_FB and 8250_PXA to enable console What about gpio-pxa ? And maybe pinctrl-pxa27x (only in linux-next by now) ? Can a pxafb work without gpio-pxa ? Also usually for pxafb you have pwm and pwm_bl to see something. >> 3. MMC, MMC_PXA and EXT4_FS to enable boot from MMC >> 3.1. MTD, MTD_CFI, MTD_PHYSMAP_OF and JFFS2_FS to enable boot from MTD Ok. Is pxa2xx-pcmcia out of scope ? I seem to remember we have several boards where pcmcia is the rootfs (even if that is a small mess right now I still have to work on). Or do we consider pcmcia as obsolete ? >> 4. all optional pxa stuff as modules >> 5. all stuff on supported pxa boards as modules >> 6. supported boards should boot the kernel built with >> `pxa27x-dt_defconfig` after `make olddefconfig` >> >> It is probably a good idea to put this plan somewhere in Documentation/ >> and to have a comment about that in the defconfig itself. >> >> Is the plan acceptable? > > Sounds good to me. Sounds good to me too. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/14] DEVICETREE: Add bindings for PIC32 UART driver
On Mon, Dec 14, 2015 at 03:42:11PM -0700, Joshua Henderson wrote:
> From: Andrei Pistirica
>
> Document the devicetree bindings for the UART peripheral found on
> Microchip PIC32 class devices.
>
> Signed-off-by: Andrei Pistirica
> Signed-off-by: Joshua Henderson
> Cc: Ralf Baechle
Acked-by: Rob Herring
> ---
> .../bindings/serial/microchip,pic32-uart.txt | 29
>
> 1 file changed, 29 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt
>
> diff --git
> a/Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt
> b/Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt
> new file mode 100644
> index 000..65b38bf6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt
> @@ -0,0 +1,29 @@
> +* Microchip Universal Asynchronous Receiver Transmitter (UART)
> +
> +Required properties:
> +- compatible: Should be "microchip,pic32mzda-uart"
> +- reg: Should contain registers location and length
> +- interrupts: Should contain interrupt
> +- clocks: Phandle to the clock.
> + See: Documentation/devicetree/bindings/clock/clock-bindings.txt
> +- pinctrl-names: A pinctrl state names "default" must be defined.
> +- pinctrl-0: Phandle referencing pin configuration of the UART peripheral.
> + See:
> Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
> +
> +Optional properties:
> +- cts-gpios: CTS pin for UART
> +
> +Example:
> + uart1: serial@1f822000 {
> + compatible = "microchip,pic32mzda-uart";
> + reg = <0x1f822000 0x50>;
> + interrupts = <112 IRQ_TYPE_LEVEL_HIGH>,
> + <113 IRQ_TYPE_LEVEL_HIGH>,
> + <114 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&PBCLK2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1
> + &pinctrl_uart1_cts
> + &pinctrl_uart1_rts>;
> + cts-gpios = <&gpio1 15 0>;
> + };
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/14] DEVICETREE: Add bindings for PIC32 SDHCI host controller
On Mon, Dec 14, 2015 at 03:42:13PM -0700, Joshua Henderson wrote:
> From: Andrei Pistirica
>
> Document the devicetree bindings for the SDHCI peripheral found on
> Microchip PIC32 class devices.
>
> Signed-off-by: Andrei Pistirica
> Signed-off-by: Joshua Henderson
> Cc: Ralf Baechle
Acked-by: Rob Herring
> ---
> .../bindings/mmc/microchip,sdhci-pic32.txt | 29
>
> 1 file changed, 29 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt
> b/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt
> new file mode 100644
> index 000..71ad57e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt
> @@ -0,0 +1,29 @@
> +* Microchip PIC32 SDHCI Controller
> +
> +This file documents differences between the core properties in mmc.txt
> +and the properties used by the sdhci-pic32 driver.
> +
> +Required properties:
> +- compatible: Should be "microchip,pic32mzda-sdhci"
> +- interrupts: Should contain interrupt
> +- clock-names: Should be "base_clk", "sys_clk".
> + See: Documentation/devicetree/bindings/resource-names.txt
> +- clocks: Phandle to the clock.
> + See: Documentation/devicetree/bindings/clock/clock-bindings.txt
> +- pinctrl-names: A pinctrl state names "default" must be defined.
> +- pinctrl-0: Phandle referencing pin configuration of the SDHCI controller.
> + See:
> Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
> +
> +Example:
> +
> + sdhci@1f8ec000 {
> + compatible = "microchip,pic32mzda-sdhci";
> + reg = <0x1f8ec000 0x100>;
> + interrupts = <191 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&REFCLKO4>, <&PBCLK5>;
> + clock-names = "base_clk", "sys_clk";
> + bus-width = <4>;
> + cap-sd-highspeed;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sdhc1>;
> + };
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/14] DEVICETREE: Add bindings for PIC32 pin control and GPIO
On Mon, Dec 14, 2015 at 03:42:09PM -0700, Joshua Henderson wrote:
> Document the devicetree bindings for PINCTRL and GPIO found on Microchip
> PIC32 class devices.
>
> Signed-off-by: Joshua Henderson
> Cc: Ralf Baechle
Acked-by: Rob Herring
> ---
> .../bindings/gpio/microchip,pic32-gpio.txt | 49
> .../bindings/pinctrl/microchip,pic32-pinctrl.txt | 60
>
> 2 files changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
> create mode 100644
> Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
> b/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
> new file mode 100644
> index 000..ef37528
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
> @@ -0,0 +1,49 @@
> +* Microchip PIC32 GPIO devices (PIO).
> +
> +Required properties:
> + - compatible: "microchip,pic32mzda-gpio"
> + - reg: Base address and length for the device.
> + - interrupts: The port interrupt shared by all pins.
> + - gpio-controller: Marks the port as GPIO controller.
> + - #gpio-cells: Two. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity as defined in
> + defined in :
> + 0 = GPIO_ACTIVE_HIGH
> + 1 = GPIO_ACTIVE_LOW
> + 2 = GPIO_OPEN_DRAIN
> + - interrupt-controller: Marks the device node as an interrupt controller.
> + - #interrupt-cells: Two. The first cell is the GPIO number and second cell
> + is used to specify the trigger type as defined in
> + :
> + IRQ_TYPE_EDGE_RISING
> + IRQ_TYPE_EDGE_FALLING
> + IRQ_TYPE_EDGE_BOTH
> + - clocks: Clock specifier (see clock bindings for details).
> + - microchip,gpio-bank: Specifies which bank a controller owns.
> + - gpio-ranges: Interaction with the PINCTRL subsystem.
> +
> +Example:
> +
> +/* PORTA */
> +gpio0: gpio0@1f86 {
> + compatible = "microchip,pic32mzda-gpio";
> + reg = <0x1f86 0x100>;
> + interrupts = <118 IRQ_TYPE_LEVEL_HIGH>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + clocks = <&PBCLK4>;
> + microchip,gpio-bank = <0>;
> + gpio-ranges = <&pic32_pinctrl 0 0 16>;
> +};
> +
> +keys {
> + ...
> +
> + button@sw1 {
> + label = "ESC";
> + linux,code = <1>;
> + gpios = <&gpio0 12 0>;
> + };
> +};
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
> new file mode 100644
> index 000..4b5efa5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
> @@ -0,0 +1,60 @@
> +* Microchip PIC32 Pin Controller
> +
> +Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and
> +../interrupt-controller/interrupts.txt for generic information regarding
> +pin controller, GPIO, and interrupt bindings.
> +
> +PIC32 'pin configuration node' is a node of a group of pins which can be
> +used for a specific device or function. This node represents configuraions of
> +pins, optional function, and optional mux related configuration.
> +
> +Required properties for pin controller node:
> + - compatible: "microchip,pic32mada-pinctrl"
> + - reg: Address range of the pinctrl registers.
> + - clocks: Clock specifier (see clock bindings for details)
> +
> +Required properties for pin configuration sub-nodes:
> + - pins: List of pins to which the configuration applies.
> +
> +Optional properties for pin configuration sub-nodes:
> +
> + - function: Mux function for the specified pins.
> + - bias-pull-up: Enable weak pull-up.
> + - bias-pull-down: Enable weak pull-down.
> + - input-enable: Set the pin as an input.
> + - output-low: Set the pin as an output level low.
> + - output-high: Set the pin as an output level high.
> + - microchip,digital: Enable digital I/O.
> + - microchip,analog: Enable analog I/O.
> +
> +Example:
> +
> +pic32_pinctrl: pinctrl@1f801400{
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "microchip,pic32mzda-pinctrl";
> + reg = <0x1f801400 0x400>;
> + clocks = <&PBCLK1>;
> +
> + pinctrl_uart2: pinctrl_uart2 {
> + uart2-tx {
> + pins = "G9";
> + function = "U2TX";
> + microchip,digital;
> + output-low;
> + };
> + uart2-rx {
> + pins = "B0";
> + function = "U2RX";
> + microchip,digital;
> + input-enable;
> + };
> + };
> +};
> +
> +uart2: serial@1f822200 {
> + compatible = "microchip,pic32mzda-uart";
> + reg = <0x1f822200 0x50>;
> + pinc
Re: [PATCH V4 16/16] ARM64: tegra: select PM_GENERIC_DOMAINS
On 4 December 2015 at 15:57, Jon Hunter wrote: > Enable PM_GENERIC_DOMAINS for tegra 64-bit devices. To ensure that devices > dependent upon a particular power-domain are only probed when that power > domain has been powered up, requires that PM is made mandatory for tegra > 64-bit devices and so select this option for tegra as well. > > Signed-off-by: Jon Hunter > --- > arch/arm64/Kconfig.platforms | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 9806324fa215..e0b5bd0aff0f 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -93,6 +93,8 @@ config ARCH_TEGRA > select GENERIC_CLOCKEVENTS > select HAVE_CLK > select PINCTRL > + select PM > + select PM_GENERIC_DOMAINS If you still want to allow ARCH_TEGRA to run without PM, you should probably change to: select PM_GENERIC_DOMAINS if PM > select RESET_CONTROLLER > help > This enables support for the NVIDIA Tegra SoC family. > -- > 2.1.4 > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] arm: pxa: support ICP DAS LP-8x4x FPGA irq
ICP DAS LP-8x4x contains FPGA chip. The chip functions as an interrupt
source providing 16 additional interrupts among other things. The
interrupt lines are muxed to a GPIO pin of a 2nd level PXA-GPIO
interrupt controller. GPIO pins of the 2nd level controller are in turn
muxed to a CPU interrupt line.
Until pxa is completely converted to device tree, it is impossible
to use IRQCHIP_DECLARE() and the irqdomain needs to added manually.
Drivers for the on-CPU IRQs and GPIO-IRQs are loaded using
postcore_initcall(). We need to have all irq domain drivers loaded prior
to DT parsing in order to allow normal initialization of IRQ resources
with DT.
Signed-off-by: Sergei Ianovich
Reviewed-by: Linus Walleij
CC: Arnd Bergmann
---
v4..v5
* constify struct of_device_id
* drop irq number from handler signature
v3.2..v4
* move DTS binding to a different patch (8/21)
v3.1..v3.2
fixes to apply Linus Walleij's "Reviewed-by":
* add kerneldoc comment for state container struct
* rename irq -> hwirq for clarity
* drop overzealous error checks from the hotpaths
v3..v3.1
fixes according to Linus Walleij review comments:
* update commit message
* use state container instead of global variables
* get hardware irq nums from irq_data, don't calculate them
* use BIT() macro
* add defines for system irq register masks
* replace cycle control variable with break
* use better names for resource variables
* add a linear domain instead of a legacy one
* use irq_create_mapping() instead of irq_alloc_desc()
v2..v3
* no changes (except number 09/16 -> 11/21)
v0..v2
* extract irqchip and move to drivers/irqchip/
* use device tree
* use devm helpers where possible
.../bindings/interrupt-controller/irq-lp8x4x.txt | 49 +
drivers/irqchip/Kconfig| 5 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-lp8x4x.c | 227 +
4 files changed, 282 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
create mode 100644 drivers/irqchip/irq-lp8x4x.c
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
b/Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
new file mode 100644
index 000..c8940d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
@@ -0,0 +1,49 @@
+ICP DAS LP-8x4x FPGA Interrupt Controller
+
+ICP DAS LP-8x4x contains FPGA chip. The chip functions as a interrupt
+source providing 16 additional interrupts among other things.
+
+Required properties:
+- compatible : should be "icpdas,irq-lp8x4x"
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupt-controller : identifies the node as an interrupt controller
+
+- #interrupt-cells : should be 1
+
+- interrupts : should provide interrupt
+
+- interrupt-parent : should provide a link to interrupt controller either
+explicitly and implicitly from a parent node
+
+Example:
+
+ fpga: fpga@1706 {
+ compatible = "icpdas,irq-lp8x4x";
+ reg = <0x1706 0x16>;
+ interrupt-parent = <&gpio>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ status = "okay";
+ };
+
+ uart@17009050 {
+ compatible = "icpdas,uart-lp8x4x";
+ reg = <0x17009050 0x10
+ 0x17009030 0x02>;
+ interrupt-parent = <&fpga>;
+ interrupts = <13>;
+ status = "okay";
+ };
+
+ uart@17009060 {
+ compatible = "icpdas,uart-lp8x4x";
+ reg = <0x17009060 0x10
+ 0x17009032 0x02>;
+ interrupt-parent = <&fpga>;
+ interrupts = <14>;
+ status = "okay";
+ };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4d7294e..1de7361 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -193,3 +193,8 @@ config IRQ_MXS
def_bool y if MACH_ASM9260 || ARCH_MXS
select IRQ_DOMAIN
select STMP_DEVICE
+
+config LP8X4X_IRQ
+ bool
+ depends on OF && ARCH_PXA
+ select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 177f78f..ab9ca67 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_RENESAS_H8S_INTC)+=
irq-renesas-h8s.o
obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
+obj-$(CONFIG_LP8X4X_IRQ) += irq-lp8x4x.o
diff --git a/drivers/irqchip/irq-lp8x4x.c b/drivers/irqchip/irq-lp8x4x.c
new file mode 10
Re: [PATCH v5 2/2] arm: pxa27x: support for ICP DAS LP-8x4x w/ DT
On Tuesday 15 December 2015 21:50:13 Sergei Ianovich wrote: > On Tue, 2015-12-15 at 19:06 +0100, Robert Jarzmik wrote: > > > 4. all optional pxa stuff as modules > > > 5. all stuff on supported pxa boards as modules > > > > > If #5 is extended when support for new boards is added, it should be > > > possible to run any supported pxa27x board with pxa27x_defconfig. > > > > I'm very eager to see a patch on that. I can feed my Jenkins with it, > > it would > > greatly help me catch issues earlier. Moreover it would for free test > > it on > > lubbock, mainstone and mioa701. If there was one also for pxa3xx, I > > would launch > > it on zylonite cm-x300 ... (that's a bonus, I know :)) > > > > Updated plan: > 1. MACH_PXA27X_DT > 2. PXA_FB and 8250_PXA to enable console > 3. MMC, MMC_PXA and EXT4_FS to enable boot from MMC > 3.1. MTD, MTD_CFI, MTD_PHYSMAP_OF and JFFS2_FS to enable boot from MTD > 4. all optional pxa stuff as modules > 5. all stuff on supported pxa boards as modules > 6. supported boards should boot the kernel built with > `pxa27x-dt_defconfig` after `make olddefconfig` > > It is probably a good idea to put this plan somewhere in Documentation/ > and to have a comment about that in the defconfig itself. > > Is the plan acceptable? Sounds good to me. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
On 12/15/2015 04:20 AM, Chanwoo Choi wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to ^^ ^^ enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, ^^ ^^ ^^ ^^ the chip also passes thru the ID signal from the USB OTG connector. ^^ On some Renesas boards, this signal is just fed into the SoC thru a GPIO ^^ ^^ pin -- there's no real OTG controller, only host and gadget USB controllers ^^ ^^ sharing the same USB bus; however, we'd like to allow host or gadget drivers ^^ to be loaded depending on the cable type, hence the need for the MAX3355 ^^ extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by ^^ ^^ the host controllers, there's also the SHDN# signal wired to a GPIO, it ^^ should be driven high for the normal operation. ^^ As above '^' expression, you used the double space between words. You should fix it. OK, since so many people seem to be offended by that, I'll fix it. Meanwhile, please comment on the patch itself. Thanks, Chanwoo Choi [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
Hello. On 12/15/2015 09:51 PM, Greg KH wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, the chip also passes thru the ID signal from the USB OTG connector. On some Renesas boards, this signal is just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only host and gadget USB controllers sharing the same USB bus; however, we'd like to allow host or gadget drivers to be loaded depending on the cable type, hence the need for the MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by the host controllers, there's also the SHDN# signal wired to a GPIO, it should be driven high for the normal operation. As multiple people have said, fix the spacing here. You are the first to complain abou _this_ patch. If you don't have other issues with this driver in which case you should have trimmed the reply at this point), I'd like to keep my spacing as is. Thank you. Your previous version was not "extcon-usb-gpio: add enable pin support"[1] which has now been re-written to be max3355 specific? No, the MAX3355 driver pre-dates that version. First there was a driver, then I tried to re-use the existing stuff (there was no extcon-usb-gpio at the time of writing my driver), then had to return to the separate driver idea... "So what" and "I'd like to keep my spacing as is" aren't valid reasons. Fix it, then I'll look at the rest again. I'll consider doing that if you care to explain what's the problem with my spacing. TIA. You are mixing 2 and 1 spaces between words, don't do that. Care to just explain why? Because the rules of typography and grammer do not allow this. Typography? Are you serious? The books are all printed using filled up lines with arbitrary spaces between words. Grammar, maybe. Are you really arguing this? If so, it's trivial for us to just ignore your patches if you insist on this. I haven't had the opposite side's arguments so far, just "don't do it because we say so". Geert's mail was the first with such argument, and it didn't really seem a serious one, sorry. And please don't try to intimidate me with ignoring my patches. With 750+ merged patches I don't care that much... greg k-h MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] arm: pxa27x: support for ICP DAS LP-8x4x w/ DT
On Tue, 2015-12-15 at 19:06 +0100, Robert Jarzmik wrote: > > > > Maybe we can have a pxa_defconfig file that enables lots of boards > > > and then we remove the individual configs? We don't have to remove > > > them all at once, but it would make me very happy if we could at > > > least kill off some of the ones that are not used regularly. > Yeah, I'd be happy too, that would simplify also my life. > > Actually I was thinking of 2 defconfigs : > - one for platform_data based boards pxa2xx > - one for DT only boards pxa2xx I sincerely hope that dealing with ancient platform_data defconfigs is out of the scope this patch. > > lp8x4x seems to be the first pxa board which requires DT. > Most probably AFAIK. > > > We can create pxa27x-dt_defconfig which selects: > > 1. PXA27X_DT > > 2. PXA_FB and 8250_PXA to enable console > > 3. MMC, MMC_PXA and EXT4_FS to enable boot from MMC > If you put MMC_PXA, one can argue why not any MTD device used on pxa > devices, > such as pxa2xx-flash or docg3/docg4, etc ... I won't argue, I'm just > pondering > about the right choice. Great point. We should enable MTD for sure. There is no PXA-specific MTD drivers, however. That's why MTD failed the grep test. > > 4. all optional pxa stuff as modules > > 5. all stuff on supported pxa boards as modules > > > If #5 is extended when support for new boards is added, it should be > > possible to run any supported pxa27x board with pxa27x_defconfig. > > I'm very eager to see a patch on that. I can feed my Jenkins with it, > it would > greatly help me catch issues earlier. Moreover it would for free test > it on > lubbock, mainstone and mioa701. If there was one also for pxa3xx, I > would launch > it on zylonite cm-x300 ... (that's a bonus, I know :)) > Updated plan: 1. MACH_PXA27X_DT 2. PXA_FB and 8250_PXA to enable console 3. MMC, MMC_PXA and EXT4_FS to enable boot from MMC 3.1. MTD, MTD_CFI, MTD_PHYSMAP_OF and JFFS2_FS to enable boot from MTD 4. all optional pxa stuff as modules 5. all stuff on supported pxa boards as modules 6. supported boards should boot the kernel built with `pxa27x-dt_defconfig` after `make olddefconfig` It is probably a good idea to put this plan somewhere in Documentation/ and to have a comment about that in the defconfig itself. Is the plan acceptable? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] mtd: support BB SRAM on ICP DAS LP-8x4x
This provides an MTD device driver for 512kB of battery backed up SRAM
on ICPDAS LP-8X4X programmable automation controllers.
SRAM chip is connected via FPGA and is not accessible without a driver,
unlike flash memory which is wired to CPU MMU.
This SRAM becomes an excellent persisent storage of volatile process
data like counter values and sensor statuses. Storing those data in
flash or mmc card is not a viable solution.
Signed-off-by: Sergei Ianovich
Reviewed-by: Brian Norris
---
v4..v5
* remove .owner from struct platform_driver
* constify struct of_device_id
for further Brian Norris comments:
* drop unused property from doc file
* move defconfig update to a different file
* drop extra match w/ of_match_device()
v3..v4 for Brian Norris 'Reviewed-by'
* add doc file for DT binding
* move DTS binding to a different patch (8/21)
* drop unused include directive
* drop safely unused callback
* drop non-default partion probe types
* drop duplicate error checks
* drop duplicate error reporting
* fixed error message on MTD registeration
* fixed module removal routine
v2..v3
* no changes (except number 08/16 -> 10/21)
v0..v2
* use device tree
* use devm helpers where possible
.../devicetree/bindings/mtd/sram-lp8x4x.txt| 20 +++
drivers/mtd/devices/Kconfig| 14 ++
drivers/mtd/devices/Makefile | 1 +
drivers/mtd/devices/sram_lp8x4x.c | 199 +
4 files changed, 234 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
create mode 100644 drivers/mtd/devices/sram_lp8x4x.c
diff --git a/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
new file mode 100644
index 000..476934f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
@@ -0,0 +1,20 @@
+512kB battery backed up SRAM on LP-8x4x industrial computers
+
+Required properties:
+- compatible : should be "icpdas,sram-lp8x4x"
+
+- reg: physical base addresses and region lengths of
+ * IO memory range
+ * SRAM page selector
+
+SRAM chip is connected via FPGA and is not accessible without a driver,
+unlike flash memory which is wired to CPU MMU. Driver is essentially
+an address translation routine.
+
+Example:
+
+ sram@a000 {
+ compatible = "icpdas,sram-lp8x4x";
+ reg = <0xa000 0x1000
+ 0x901e 0x1>;
+ };
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index f73c416..a4573f6 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -233,4 +233,18 @@ config BCH_CONST_T
default 4
endif
+config MTD_SRAM_LP8X4X
+ tristate "SRAM on ICPDAS LP-8X4X"
+ depends on OF && ARCH_PXA
+ ---help---
+This provides an MTD device driver for 512kiB of battery backed up SRAM
+on ICPDAS LP-8X4X programmable automation controllers.
+
+SRAM chip is connected via FPGA and is not accessible without a driver,
+unlike flash memory which is wired to CPU MMU.
+
+Say N, unless you plan to run this kernel on LP-8X4X.
+
+If you say M, the module will be called sram_lp8x4x.
+
endmenu
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index 7912d3a..2fd5b7a 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MTD_SST25L) += sst25l.o
obj-$(CONFIG_MTD_BCM47XXSFLASH)+= bcm47xxsflash.o
obj-$(CONFIG_MTD_ST_SPI_FSM)+= st_spi_fsm.o
obj-$(CONFIG_MTD_POWERNV_FLASH)+= powernv_flash.o
+obj-$(CONFIG_MTD_SRAM_LP8X4X) += sram_lp8x4x.o
CFLAGS_docg3.o += -I$(src)
diff --git a/drivers/mtd/devices/sram_lp8x4x.c
b/drivers/mtd/devices/sram_lp8x4x.c
new file mode 100644
index 000..e43c7a7
--- /dev/null
+++ b/drivers/mtd/devices/sram_lp8x4x.c
@@ -0,0 +1,199 @@
+/*
+ * linux/drivers/mtd/devices/lp8x4x_sram.c
+ *
+ * MTD Driver for SRAM on ICPDAS LP-8x4x
+ * Copyright (C) 2013 Sergei Ianovich
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation or any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct lp8x4x_sram_info {
+ void __iomem*bank;
+ void __iomem*virt;
+ struct mutexlock;
+ unsignedactive_bank;
+ struct mtd_info mtd;
+};
+
+static int
+lp8x4x_sram_erase(struct mtd_info *mtd, struct erase_info *instr)
+{
+ struct lp8x4x_sram_info *info = mtd->priv;
+ unsigned bank = instr->addr >> 11;
+ unsigned offset = (instr->addr & 0x7ff) << 1;
+ loff_t i;
+
+ mutex_lock(&info->lock);
+ if
Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings
On 15 December 2015 at 18:15, Mark Rutland wrote: > On Tue, Dec 15, 2015 at 05:59:34PM +0100, Vincent Guittot wrote: >> On 15 December 2015 at 17:41, Mark Rutland wrote: >> > On Tue, Dec 15, 2015 at 04:23:18PM +, Catalin Marinas wrote: >> >> On Tue, Dec 15, 2015 at 03:57:37PM +, Mark Rutland wrote: >> >> > On Tue, Dec 15, 2015 at 03:46:51PM +, Juri Lelli wrote: >> >> > > On 15/12/15 15:32, Mark Rutland wrote: >> >> > > > On Tue, Dec 15, 2015 at 03:08:13PM +, Mark Brown wrote: >> >> > > > > My expectation is that we just need good enough, not perfect, and >> >> > > > > that >> >> > > > > seems to match what Juri is saying about the expectation that >> >> > > > > most of >> >> > > > > the fine tuning is done via other knobs. >> >> > > > >> >> > > > My expectation is that if a ballpark figure is good enough, it >> >> > > > should be >> >> > > > possible to implement something trivial like bogomips / >> >> > > > loop_per_jiffy >> >> > > > calculation. >> >> > > >> >> > > I didn't really followed that, so I might be wrong here, but isn't >> >> > > already happened a discussion about how we want/like to stop exposing >> >> > > bogomips info or rely on it for anything but in kernel delay loops? >> >> > >> >> > I meant that we could have a benchmark of that level of complexity, >> >> > rather than those specific values. >> >> >> >> Or we could simply let user space use whatever benchmarks or hard-coded >> >> values it wants and set the capacity via sysfs (during boot). By >> >> default, the kernel would assume all CPUs equal. >> > >> > I assume that a userspace override would be available regardless of >> > whatever mechanism the kernel uses to determine relative >> > performance/effinciency. >> >> Don't you think that if we let a complete latitude to the userspace >> to set whatever it wants, it will be used to abuse the kernel (and the >> scheduler in particular ) and that this will finish in a real mess to >> understand what is wrong when a task is not placed where it should be. > > I'm not sure I follow what you mean by "abuse" here. Userspace currently > can force the scheduler to make sub-optimal decisions in a number of > ways, e.g. > > * Hot-unplugging the preferred CPUs > * Changing a task's affinity mask > * Setting the nice value of a task > * Using rlimits and/or cgroups > * Using a cpufreq governor > * Fork-bombing All these are parameters have a meaning (except the last one). By abusing i mean setting the capacity of the most powerful cpu to 1 for no good reason except to abuse the scheduler so the latter will not put that much tasks on it just because the current running use case is more efficient if the big core is not used. > > Practically all of these are prvileged operations. I would envisage the > userspace interface for "capacity" management to be similar. > >> We can probably provide a debug mode to help soc manufacturer to >> define their capacity value but IMHO we should not let complete >> latitude in normal operation > > In normal operation userspace wouldn't mess with this, as with most of > the cases above. Userspace can already shooti tself in the foot. > >> In normal operation we need to give some methods to tweak the value to >> reflect a memory bounded or integer calculation work or other kind of >> work that currently runs on the cpu but not more > > You can already do that with the mechanisms above, to some extent. I'm > not sure I follow. > > Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] rtc: support DS1302 RTC on ICP DAS LP-8x4x
Signed-off-by: Sergei Ianovich
CC: Alexandre Belloni
---
v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt
v3..v4
* move DTS bindings to a different patch
v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)
v0..v2
* use device tree
* use devm helpers where possible
.../devicetree/bindings/rtc/rtc-ds1302.txt | 14 +++
drivers/rtc/Kconfig| 2 +-
drivers/rtc/rtc-ds1302.c | 100 -
3 files changed, 113 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
new file mode 100644
index 000..810613b
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
@@ -0,0 +1,14 @@
+* Dallas Semiconductor DS-1302 RTC
+
+Simple device which could be used to store date/time between reboots.
+
+Required properties:
+- compatible : Should be "dallas,rtc-ds1302"
+- reg : Should be address and size of IO memory region
+
+Examples:
+
+rtc@4090 {
+ compatible = "dallas,rtc-ds1302";
+ reg = <0x1700901c 0x1>;
+};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2a52424..cf36483 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -803,7 +803,7 @@ config RTC_DRV_DS1286
config RTC_DRV_DS1302
tristate "Dallas DS1302"
- depends on SH_SECUREEDGE5410
+ depends on SH_SECUREEDGE5410 || (ARCH_PXA && HIGH_RES_TIMERS)
help
If you say yes here you get support for the Dallas DS1302 RTC chips.
diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 6bef7a5..bd68214 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -50,7 +50,7 @@
#define ds1302_set_tx()
#define ds1302_set_rx()
-static inline int ds1302_hw_init(void)
+static inline int ds1302_hw_init(struct platform_device *pdev)
{
return 0;
}
@@ -86,6 +86,101 @@ static inline int ds1302_rxbit(void)
return !!(get_dp() & RTC_IODATA);
}
+#elif defined(CONFIG_ARCH_PXA) && defined(CONFIG_HIGH_RES_TIMERS)
+
+#include
+#include
+
+#defineRTC_CE 0x01
+#defineRTC_CLK 0x02
+#defineRTC_nWE 0x04
+#defineRTC_IODATA 0x08
+
+static unsigned long ds1302_state;
+
+static void *mem;
+
+static inline int ds1302_hw_init(struct platform_device *pdev)
+{
+ struct resource *r;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!r)
+ return -ENODEV;
+
+ mem = devm_ioremap_resource(&pdev->dev, r);
+ if (!mem)
+ return -EFAULT;
+
+ return 0;
+}
+
+static inline void ds1302_reset(void)
+{
+ ds1302_state = 0;
+ iowrite8(ds1302_state, mem);
+ usleep_range(4, 5);
+}
+
+static inline void ds1302_clock(void)
+{
+ usleep_range(1, 2);
+ ds1302_state |= RTC_CLK;
+ iowrite8(ds1302_state, mem);
+ usleep_range(1, 2);
+ ds1302_state &= ~RTC_CLK;
+ iowrite8(ds1302_state, mem);
+}
+
+static inline void ds1302_start(void)
+{
+ ds1302_state &= ~RTC_CLK;
+ ds1302_state |= RTC_CE;
+ iowrite8(ds1302_state, mem);
+ usleep_range(3, 4);
+}
+
+static inline void ds1302_stop(void)
+{
+ ds1302_state &= ~RTC_CE;
+ iowrite8(ds1302_state, mem);
+}
+
+static inline void ds1302_set_tx(void)
+{
+ ds1302_state &= ~RTC_nWE;
+ iowrite8(ds1302_state, mem);
+}
+
+static inline void ds1302_set_rx(void)
+{
+ ds1302_state |= RTC_nWE;
+ iowrite8(ds1302_state, mem);
+}
+
+static inline void ds1302_txbit(int bit)
+{
+ if (bit)
+ ds1302_state |= RTC_IODATA;
+ else
+ ds1302_state &= ~RTC_IODATA;
+ iowrite8(ds1302_state, mem);
+}
+
+static inline int ds1302_rxbit(void)
+{
+ return ioread8(mem) & 0x1;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id ds1302_dt_ids[] = {
+ { .compatible = "dallas,rtc-ds1302" },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, ds1302_dt_ids);
+#endif
+
#else
#error "Add support for your platform"
#endif
@@ -216,7 +311,7 @@ static int __init ds1302_rtc_probe(struct platform_device
*pdev)
{
struct rtc_device *rtc;
- if (ds1302_hw_init()) {
+ if (ds1302_hw_init(pdev)) {
dev_err(&pdev->dev, "Failed to init communication channel");
return -EINVAL;
}
@@ -244,6 +339,7 @@ static int __init ds1302_rtc_probe(struct platform_device
*pdev)
static struct platform_driver ds1302_platform_driver = {
.driver = {
.name = DRV_NAME,
+ .of_match_table = of_match_ptr(ds1302_dt_ids),
},
};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a
Re: [PATCH v5 2/2] arm: pxa27x: support for ICP DAS LP-8x4x w/ DT
On Tue, 2015-12-15 at 18:02 +0100, Arnd Bergmann wrote: > On Tuesday 15 December 2015 19:42:07 Sergei Ianovich wrote: > > There are several board-specific devices on LP8x4x: custom FPGA, > > custom > > UART, custom IRQ on FPGA, custom parallel bus for industrial IO. The > > defconfig file could alert potential users to this fact. If this is > > not > > a sufficient reason to have a defconfig file, it can be dropped. > > > > I use the full .config anyway > > I would like those drivers to be enabled in some defconfig, so we get > compile-time coverage, but we generally stopped having one-config-per- > board > files. > > Maybe we can have a pxa_defconfig file that enables lots of boards > and then we remove the individual configs? We don't have to remove > them all at once, but it would make me very happy if we could at > least kill off some of the ones that are not used regularly. lp8x4x seems to be the first pxa board which requires DT. We can create pxa27x-dt_defconfig which selects: 1. PXA27X_DT 2. PXA_FB and 8250_PXA to enable console 3. MMC, MMC_PXA and EXT4_FS to enable boot from MMC 4. all optional pxa stuff as modules 5. all stuff on supported pxa boards as modules If #5 is extended when support for new boards is added, it should be possible to run any supported pxa27x board with pxa27x_defconfig. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings
On Tue, Dec 15, 2015 at 05:28:37PM +, Mark Rutland wrote: > On Tue, Dec 15, 2015 at 05:17:13PM +, Mark Brown wrote: > > Obviously people are going to get upset if we introduce performance > > regressions - but that's true always, we can also introduce problems > > with numbers people have put in DT. It seems like it'd be harder to > > manage regressions due to externally provided magic numbers since > > there's inherently less information there. > It's certainly still possible to have regressions in that case. Those > regressions would be due to code changes in the kernel, given the DT > didn't change. > I'm not sure I follow w.r.t. "inherently less information", unless you > mean trying to debug without access to that DTB? If what the kernel knows about the system is that it's got a bunch of cores with numbers assigned to them then all it's really got is those numbers. If something changes that causes problems for some systems (eg, because the numbers have been picked poorly but in a way that happened to work well with the old code) that's not a lot to go on, the more we know about the system the more likely it is that we'll be able to adjust the assumptions in whatever new thing we do that causes problems for any particular systems where we run into trouble. > > My point there is that if we're not that concerned about the specific > > number something in kernel is safer. > I don't entirely disagree there. I think an in-kernel benchmark is > likely safer. Yes, I think that something where we just observe the system performance at runtime is likely one of the best solutions if we can get something that gives reasonable results. > > That does have the issue that we need to scale with regard to the > > frequency the benchmark gets run at. That's not an insurmountable > > obstacle but it's not completely trivial either. > If we change clock frequency, then regardless of where the information > comes from we need to perform scaling, no? Yes, it's just a question of making the benchmarking bit talk to the scaling bit so we know where we're at when we do the benchmark. Like I say it should be doable. > One nice thing about doing a benchmark to derive the numbers is that > when the kernel is that when the frequency is fixed but the kernel > cannot query it, the numbers will be representative. Definitely. signature.asc Description: PGP signature
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
On Tue, Dec 15, 2015 at 02:24:56PM +0300, Sergei Shtylyov wrote: > Hello. > > On 12/15/2015 2:44 AM, Greg KH wrote: > > >>Maxim Integrated MAX3355E chip integrates a charge pump and > >>comparators > >>to > >>enable a system with an integrated USB OTG dual-role transceiver to > >>function > >>as an USB OTG dual-role device. In addition to sensing/controlling > >>Vbus, > >>the chip also passes thru the ID signal from the USB OTG connector. > >>On some Renesas boards, this signal is just fed into the SoC thru a > >>GPIO > >>pin -- there's no real OTG controller, only host and gadget USB > >>controllers > >>sharing the same USB bus; however, we'd like to allow host or gadget > >>drivers > >>to be loaded depending on the cable type, hence the need for the > >>MAX3355 > >>extcon driver. The Vbus status signals are also wired to GPIOs > >>(however, > >>we > >>aren't currently interested in them), the OFFVBUS# signal is controlled > >>by > >>the host controllers, there's also the SHDN# signal wired to a GPIO, it > >>should be driven high for the normal operation. > > > > > >As multiple people have said, fix the spacing here. > > > You are the first to complain abou _this_ patch. If you don't have > other > issues with this driver in which case you should have trimmed the reply at > this point), I'd like to keep my spacing as is. Thank you. > >>> > >>>Your previous version was not "extcon-usb-gpio: add enable pin > >>>support"[1] which has now been re-written to be max3355 specific? > >> > >>No, the MAX3355 driver pre-dates that version. First there was a driver, > >>then I tried to re-use the existing stuff (there was no extcon-usb-gpio at > >>the time of writing my driver), then had to return to the separate driver > >>idea... > >> > >>>"So > >>>what" and "I'd like to keep my spacing as is" aren't valid reasons. > >>>Fix it, then I'll look at the rest again. > >> > >>I'll consider doing that if you care to explain what's the problem with > >>my spacing. TIA. > > > >You are mixing 2 and 1 spaces between words, don't do that. > >Care to just explain why? Because the rules of typography and grammer do not allow this. Are you really arguing this? If so, it's trivial for us to just ignore your patches if you insist on this. greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver
On Tue, Dec 15, 2015 at 05:34:00PM +0100, Arnd Bergmann wrote: > On Tuesday 15 December 2015 17:31:22 Thierry Reding wrote: > > On Mon, Dec 14, 2015 at 12:39:44PM +0100, Arnd Bergmann wrote: > > > On Wednesday 18 November 2015 17:56:22 Andy Yan wrote: > > > > rockchip platform have a protocol to pass the kernel reboot > > > > mode to bootloader by some special registers when system reboot. > > > > By this way the bootloader can take different action according > > > > to the different kernel reboot mode, for example, command > > > > "reboot loader" will reboot the board to rockusb mode, this is > > > > a very convenient way to get the board enter download mode. > > > > > > > > Signed-off-by: Andy Yan > > > > > > Adding John Stultz to Cc > > > > > > I just saw this thread pop up again, and had to think of John's recent > > > patch to unify this across platforms. > > > > > > John, can you have a look at this driver too, and see how it fits in? > > > I think this is yet another variant, using an MMIO register rather than > > > RAM (as HTC / NVIDIA does) or SRAM (as Qualcomm does), but otherwise > > > it conceptually fits in with what you had. > > > > FWIW, Tegra typically does use an MMIO register as well. See > > drivers/soc/tegra/pmc.c:tegra_pmc_restart_notify(). I don't know what > > HTC does, but if it's writing somewhere in RAM it isn't using the > > standard way of resetting the SoC. There's early boot ROM code which I > > think evaluates the PMC_SCRATCH0 register on Tegra to determine which > > mode to boot into. That's before even any firmware gets the chance of > > doing anything. > > HTC apparently uses a separate RAM area to pass the reboot reason, > and they have a driver to store that, which is separate from the > driver that they use for actually rebooting the machine. I wasn't very clear, but the PMC_SCRATCH0 register is used to store the reset reason. It supports the recovery mode, which I think is really an Android thing, "bootloader" will typically cause the bootloader not to boot anything, and "forced-recovery" will go into a recovery mode that is used to bootstrap the device (usually by uploading a "miniloader" that initializes RAM, downloads a bootloader for booting or flashing an operating system, ...). The write that resets the SoC is to a different register. Thierry signature.asc Description: PGP signature
Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings
On Tue, Dec 15, 2015 at 05:17:13PM +, Mark Brown wrote: > On Tue, Dec 15, 2015 at 03:32:19PM +, Mark Rutland wrote: > > On Tue, Dec 15, 2015 at 03:08:13PM +, Mark Brown wrote: > > > On Tue, Dec 15, 2015 at 02:01:36PM +, Mark Rutland wrote: > > > > > I really don't want to see a table of magic numbers in the kernel. > > > > Right, there's pitfalls there too although not being part of an ABI > > > does make them more manageable. > > > I think that people are very likely to treat them exactly like an ABI, > > w.r.t. any regressions in performance that result from their addition, > > modification, or removal. That becomes really horrible when new CPUs > > appear. > > Obviously people are going to get upset if we introduce performance > regressions - but that's true always, we can also introduce problems > with numbers people have put in DT. It seems like it'd be harder to > manage regressions due to externally provided magic numbers since > there's inherently less information there. It's certainly still possible to have regressions in that case. Those regressions would be due to code changes in the kernel, given the DT didn't change. I'm not sure I follow w.r.t. "inherently less information", unless you mean trying to debug without access to that DTB? > > > One thing it's probably helpful to establish here is how much the > > > specific numbers are going to matter in the grand scheme of things. If > > > the specific numbers *are* super important then nobody is going to want > > > to touch them as they'll be prone to getting tweaked. If instead the > > > numbers just need to be ballpark accurate so the scheduler starts off in > > > roughly the right place and the specific numbers don't matter it's a lot > > > easier and having a table in the kernel until we think of something > > > better (if that ever happens) gets a lot easier. > > > I agree that we first need to figure out the importance of these > > numbers. I disagree that our first step should be to add a table. > > My point there is that if we're not that concerned about the specific > number something in kernel is safer. I don't entirely disagree there. I think an in-kernel benchmark is likely safer. > > > My expectation is that we just need good enough, not perfect, and that > > > seems to match what Juri is saying about the expectation that most of > > > the fine tuning is done via other knobs. > > > My expectation is that if a ballpark figure is good enough, it should be > > possible to implement something trivial like bogomips / loop_per_jiffy > > calculation. > > That does have the issue that we need to scale with regard to the > frequency the benchmark gets run at. That's not an insurmountable > obstacle but it's not completely trivial either. If we change clock frequency, then regardless of where the information comes from we need to perform scaling, no? One nice thing about doing a benchmark to derive the numbers is that when the kernel is that when the frequency is fixed but the kernel cannot query it, the numbers will be representative. Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver
Am Dienstag, 15. Dezember 2015, 17:34:00 schrieb Arnd Bergmann: > On Tuesday 15 December 2015 17:31:22 Thierry Reding wrote: > > On Mon, Dec 14, 2015 at 12:39:44PM +0100, Arnd Bergmann wrote: > > > On Wednesday 18 November 2015 17:56:22 Andy Yan wrote: > > > > rockchip platform have a protocol to pass the kernel reboot > > > > mode to bootloader by some special registers when system reboot. > > > > By this way the bootloader can take different action according > > > > to the different kernel reboot mode, for example, command > > > > "reboot loader" will reboot the board to rockusb mode, this is > > > > a very convenient way to get the board enter download mode. > > > > > > > > Signed-off-by: Andy Yan > > > > > > Adding John Stultz to Cc > > > > > > I just saw this thread pop up again, and had to think of John's recent > > > patch to unify this across platforms. > > > > > > John, can you have a look at this driver too, and see how it fits in? > > > I think this is yet another variant, using an MMIO register rather than > > > RAM (as HTC / NVIDIA does) or SRAM (as Qualcomm does), but otherwise > > > it conceptually fits in with what you had. > > > > FWIW, Tegra typically does use an MMIO register as well. See > > drivers/soc/tegra/pmc.c:tegra_pmc_restart_notify(). I don't know what > > HTC does, but if it's writing somewhere in RAM it isn't using the > > standard way of resetting the SoC. There's early boot ROM code which I > > think evaluates the PMC_SCRATCH0 register on Tegra to determine which > > mode to boot into. That's before even any firmware gets the chance of > > doing anything. > > HTC apparently uses a separate RAM area to pass the reboot reason, > and they have a driver to store that, which is separate from the > driver that they use for actually rebooting the machine. same on Rockchip. The general restart handling doesn't care about any reason, it is merely an agreement between kernel and bootloader to store a reason value in some reboot-safe register of the soc. Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] devicetree: mxsfb: add reset-active property
Some boards connect the LCD_RESET pin to a reset input on the display panel. On these boards, this pin must be set to the proper level for the display to function. This adds an optional "reset-active" property to the "display" subnode such that devicetrees can specify the desired polarity of the LCD_RESET pin. Signed-off-by: Mans Rullgard --- Documentation/devicetree/bindings/display/mxsfb.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt index 96ec517..cb7212a 100644 --- a/Documentation/devicetree/bindings/display/mxsfb.txt +++ b/Documentation/devicetree/bindings/display/mxsfb.txt @@ -13,6 +13,11 @@ Required properties: - bits-per-pixel : <16> for RGB565, <32> for RGB888/666. - bus-width : number of data lines. Could be <8>, <16>, <18> or <24>. +Optional properties: +- reset-active : <0>: reset pin is active low + <1>: reset pin is active high + omitted: reset pin not used + Required sub-node: - display-timings : Refer to binding doc display-timing.txt for details. -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Tue, 15 Dec 2015, Russell King - ARM Linux wrote: > On Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote: > > So am I understand correctly that solution would be to hack > > arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET? > > That's completely unnecessary: there are enough platform hooks to cope > with whatever the platform requires. Indeed. I didn't notice that mdesc->reserve() exists these days and is perfect for this purpose as you say. Nicolas
Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings
On Tue, Dec 15, 2015 at 06:10:03PM +, Mark Rutland wrote: > On Tue, Dec 15, 2015 at 05:45:16PM +, Mark Brown wrote: > > > I'm not sure I follow w.r.t. "inherently less information", unless you > > > mean trying to debug without access to that DTB? > > If what the kernel knows about the system is that it's got a bunch of > > cores with numbers assigned to them then all it's really got is those > > numbers. If something changes that causes problems for some systems > > (eg, because the numbers have been picked poorly but in a way that > > happened to work well with the old code) that's not a lot to go on, the > > more we know about the system the more likely it is that we'll be able > > to adjust the assumptions in whatever new thing we do that causes > > problems for any particular systems where we run into trouble. > Regardless of where the numbers live (DT or kernel), all we have are > numbers. I can see that changing the in-kernel numbers would be possible > when modifyign the DT is not, but I don't see how that gives you more > information. It's mainly the modifying the DT case - you're not dealing with some external misguided number selection method you'd never thought of and you're not forcing some third party to redo benchmarks or adjust DTs they may not want to adjust. You're also able to readjust the numbers based on feedback if you need to rather than having to adapt algorithms to handle particular number selections, the algorithm and number selection are done together rather than separately. signature.asc Description: PGP signature
Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings
On Tue, Dec 15, 2015 at 06:47:20PM +0100, Vincent Guittot wrote: > On 15 December 2015 at 18:15, Mark Rutland wrote: > > On Tue, Dec 15, 2015 at 05:59:34PM +0100, Vincent Guittot wrote: > >> On 15 December 2015 at 17:41, Mark Rutland wrote: > >> > On Tue, Dec 15, 2015 at 04:23:18PM +, Catalin Marinas wrote: > >> >> On Tue, Dec 15, 2015 at 03:57:37PM +, Mark Rutland wrote: > >> >> > On Tue, Dec 15, 2015 at 03:46:51PM +, Juri Lelli wrote: > >> >> > > On 15/12/15 15:32, Mark Rutland wrote: > >> >> > > > On Tue, Dec 15, 2015 at 03:08:13PM +, Mark Brown wrote: > >> >> > > > > My expectation is that we just need good enough, not perfect, > >> >> > > > > and that > >> >> > > > > seems to match what Juri is saying about the expectation that > >> >> > > > > most of > >> >> > > > > the fine tuning is done via other knobs. > >> >> > > > > >> >> > > > My expectation is that if a ballpark figure is good enough, it > >> >> > > > should be > >> >> > > > possible to implement something trivial like bogomips / > >> >> > > > loop_per_jiffy > >> >> > > > calculation. > >> >> > > > >> >> > > I didn't really followed that, so I might be wrong here, but isn't > >> >> > > already happened a discussion about how we want/like to stop > >> >> > > exposing > >> >> > > bogomips info or rely on it for anything but in kernel delay loops? > >> >> > > >> >> > I meant that we could have a benchmark of that level of complexity, > >> >> > rather than those specific values. > >> >> > >> >> Or we could simply let user space use whatever benchmarks or hard-coded > >> >> values it wants and set the capacity via sysfs (during boot). By > >> >> default, the kernel would assume all CPUs equal. > >> > > >> > I assume that a userspace override would be available regardless of > >> > whatever mechanism the kernel uses to determine relative > >> > performance/effinciency. > >> > >> Don't you think that if we let a complete latitude to the userspace > >> to set whatever it wants, it will be used to abuse the kernel (and the > >> scheduler in particular ) and that this will finish in a real mess to > >> understand what is wrong when a task is not placed where it should be. > > > > I'm not sure I follow what you mean by "abuse" here. Userspace currently > > can force the scheduler to make sub-optimal decisions in a number of > > ways, e.g. > > > > * Hot-unplugging the preferred CPUs > > * Changing a task's affinity mask > > * Setting the nice value of a task > > * Using rlimits and/or cgroups > > * Using a cpufreq governor > > * Fork-bombing > > All these are parameters have a meaning (except the last one). By > abusing i mean setting the capacity of the most powerful cpu to 1 for > no good reason except to abuse the scheduler so the latter will not > put that much tasks on it just because the current running use case > is more efficient if the big core is not used. Surely it's better to allow them to "abuse" the kernel in that manner than to place otherwise insane values into a DT? Especially if they can later change to a sane value? For that particular case it's easy to hotplug out the big core, or to set the affinity of tasks to avoid it. Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v14 0/7] fpga area and fpga bridge framework
Hi Alan, On Mon, Dec 14, 2015 at 5:56 PM, Alan Tull wrote: >> I had an offline discussion with Josh Cartwright about his concerns. >> He brought up a good >> point on w.r.t to the way FPGA Area (Bus) deals with things. >> >> Currently we only support complete status = "okay" vs "disabled" kind >> of overlays. > Maybe i don't understand what you are saying; could you write out a > sequence you want to be able to do? Let's say you have a UART in the FPGA. You want to reprogram the FPGA fabric that includes the UART (assuming proper resets etc happen) 1) Driver gets notified of impending doom, keeps hands off of FPGA 2) FPGA Manager reloads FPGA 3) FPGA Manager lets driver know FPGA is back 4) Driver can continue to function as always It wouldn't even have to be a UART, on some boards simple SPI lines or UART lines go from the processor through the FPGA logic out to a pin. When you reload the FPGA for a short moment of time that doesn't work, while after the reload it works just fine. Maybe something like extcon could be used for that? > Is this a separate question/issue from the above? Are you talking > about acceleration? I meant stuff like SPI that gets routed through the FPGA, sorry for being unclear ;-) >> >> I've been toying around with hacking up struct device to include a >> FPGA 'domain', and then, similar >> to power domains allow devices to register suspend() / resume() style >> callbacks (could call them pre_reload() or something like that ...) >> >> I haven't gotten around to think it through. At this point it's just >> an idea and I don't have real code to show. >> >> I realize the issue with that is we'd have to make changes to struct device. > > That's interesting. Usually a FPGA image has many devices in it, so > so way of making that dependency clear would be needed. If any of the > devices involved are powered up, that FPGA image would need to be > loaded. Yeah. That's why I think the power domain model we have has a bunch of similarities. > Currently I'm trying to get some bindings approved for doing device > tree control of loading the FPGA and probing the devices. My idea is > that these bindings could be useful for some use cases where we are > loading hardware onto the FPGA that needs to show up in the device > tree. Some of Rob's feedback is that my proposal may be > Altera-specific. If the bindings that I am proposing are useful for at > least some uses with Xilinx parts, that would be valuable feedback at > this point. If they are Altera-specific, then I may need to add > "altr," to some of the compatible strings like "altr,fpga-bus" and > "altr,fpga-area". My original intent was to implement something that > you could use also, so I hope that's not the future here. > > So my question for you is: is this stuff useful for you? Definitely, I'm pretty happy with what you have so far! I think the points I mentioned above apply to Altera devices, too. Maybe we can solve this in two parts, and the first step is getting the loading bindings accepted ;-) Cheers, Moritz -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
