RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Rahul Sharma
> Sent: Thursday, September 05, 2013 3:04 PM
> To: Inki Dae
> Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
> sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
> Shirish S
> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
>
> On 5 September 2013 10:52, Inki Dae wrote:
> >> >> >> >> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
> >> >> >> >> + {
> >> >> >> >> + .pixel_clock = 2700,
> >> >> >> >> + .conf = {
> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
> >> > 0x40,
> >> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
> >> > 0x87,
> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
> >> > 0xE0,
> >> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
> >> > 0x00,
> >> >> >> >> + },
> >> >> >> >> + },
> >> >> >> >> + {
> >> >> >> >> + .pixel_clock = 27027000,
> >> >> >> >> + .conf = {
> >> >> >> >> + 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
> >> > 0x64,
> >> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
> >> > 0x87,
> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
> >> > 0xE0,
> >> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
> >> > 0x00,
> >> >> >> >> + },
> >> >> >> >> + },
> >> >> >> >> + {
> >> >> >> >> + .pixel_clock = 74176000,
> >> >> >> >> + .conf = {
> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
> >> > 0x5B,
> >> >> >> >> + 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
> >> > 0xb9,
> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
> >> > 0xE0,
> >> >> >> >> + 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
> >> > 0x00,
> >> >> >> >> + },
> >> >> >> >> + },
> >> >> >> >> + {
> >> >> >> >> + .pixel_clock = 7425,
> >> >> >> >> + .conf = {
> >> >> >> >> + 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
> >> > 0x40,
> >> >> >> >> + 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
> >> > 0xba,
> >> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
> >> > 0xe0,
> >> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
> >> > 0x00,
> >> >> >> >> + },
> >> >> >> >> + },
> >> >> >> >> + {
> >> >> >> >> + .pixel_clock = 14850,
> >> >> >> >> + .conf = {
> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
> >> > 0x40,
> >> >> >> >> + 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
> >> > 0xba,
> >> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
> >> > 0xE0,
> >> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
> >> > 0x00,
> >> >> >> >> + },
> >> >> >> >> + },
> >> >> >> >> +};
> >> >> >> >> +
> >> >> >> >
> >> >> >> > Are you aware of the effort to move these to dt? Since these
> are
> >> >> >> > board-specific values, it seems incorrect to apply them
> >> universally.
> >> >> >> > Shirish has uploaded a patch to the chromium review site to
> push
> >> >> these
> >> >> >> > into dt (https://chromium-review.googlesource.com/#/c/65581).
> >> Maybe
> >> >> >> > you can work that into your patch set?
> >> >> >> >
> >> >> >
> >> >> > Are these really board-specific values?
> >> >>
> >> >> According to your hardware people:
> >> >>
> >> >> "If the signal pattern doesn't change for new board, the phy setting
> >> >> is same as the current board. But if changed, you need to confirm
> with
> >> >> measurement of signals, because it may vary slightly by resistance
> of
> >> >> board pattern"
> >> >>
> >> >
> >> > Right. it seems that the phy configuration should be adjusted
> according
> >> to
> >> > PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by
> PCB
> >> > even though most PCBs use 27MHz.
> >> >
> >> >> That indicates to me that we might need to tweak these on a per-
> board
> >> >> basis.
> >> >>
> >> >> In the 5420 datasheet, there are a few register descriptions
> available
> >> >> for the phy. 0x145D0004 is CLK_SEL which seems like it would be
> >> >> board-specific, same with TX_* registers.
> >> >>
> >> >
> >> > And we can select HDMI Tx PHY internal PLL input clock by setting
> >> CLK_SEL.
> >> > Ok, Shirish's patch set is reasonable to me. However, that patch set
> >> should
> >> > be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
> >> post
> >> > your patch
[PATCH] ARM: dts: disable PCIe for SD5v1 board
Disable PCIe for SD5v1 board, because there is no PCIe slot
on SD5v1 board.
Signed-off-by: Jingoo Han
---
Tested on SD5v1 board.
arch/arm/boot/dts/exynos5440-sd5v1.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5440-sd5v1.dts
b/arch/arm/boot/dts/exynos5440-sd5v1.dts
index 5b22508..78a239d 100644
--- a/arch/arm/boot/dts/exynos5440-sd5v1.dts
+++ b/arch/arm/boot/dts/exynos5440-sd5v1.dts
@@ -36,4 +36,11 @@
status = "disabled";
};
+ pcie@29 {
+ status = "disabled";
+ };
+
+ pcie@2a {
+ status = "disabled";
+ };
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 5 September 2013 10:52, Inki Dae wrote:
>> >> >> >> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
>> >> >> >> + {
>> >> >> >> + .pixel_clock = 2700,
>> >> >> >> + .conf = {
>> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
>> > 0x40,
>> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
>> > 0x87,
>> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
>> > 0xE0,
>> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
>> > 0x00,
>> >> >> >> + },
>> >> >> >> + },
>> >> >> >> + {
>> >> >> >> + .pixel_clock = 27027000,
>> >> >> >> + .conf = {
>> >> >> >> + 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09,
>> > 0x64,
>> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
>> > 0x87,
>> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
>> > 0xE0,
>> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
>> > 0x00,
>> >> >> >> + },
>> >> >> >> + },
>> >> >> >> + {
>> >> >> >> + .pixel_clock = 74176000,
>> >> >> >> + .conf = {
>> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef,
>> > 0x5B,
>> >> >> >> + 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54,
>> > 0xb9,
>> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
>> > 0xE0,
>> >> >> >> + 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00,
>> > 0x00,
>> >> >> >> + },
>> >> >> >> + },
>> >> >> >> + {
>> >> >> >> + .pixel_clock = 7425,
>> >> >> >> + .conf = {
>> >> >> >> + 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8,
>> > 0x40,
>> >> >> >> + 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54,
>> > 0xba,
>> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
>> > 0xe0,
>> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00,
>> > 0x00,
>> >> >> >> + },
>> >> >> >> + },
>> >> >> >> + {
>> >> >> >> + .pixel_clock = 14850,
>> >> >> >> + .conf = {
>> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8,
>> > 0x40,
>> >> >> >> + 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54,
>> > 0xba,
>> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
>> > 0xE0,
>> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00,
>> > 0x00,
>> >> >> >> + },
>> >> >> >> + },
>> >> >> >> +};
>> >> >> >> +
>> >> >> >
>> >> >> > Are you aware of the effort to move these to dt? Since these are
>> >> >> > board-specific values, it seems incorrect to apply them
>> universally.
>> >> >> > Shirish has uploaded a patch to the chromium review site to push
>> >> these
>> >> >> > into dt (https://chromium-review.googlesource.com/#/c/65581).
>> Maybe
>> >> >> > you can work that into your patch set?
>> >> >> >
>> >> >
>> >> > Are these really board-specific values?
>> >>
>> >> According to your hardware people:
>> >>
>> >> "If the signal pattern doesn't change for new board, the phy setting
>> >> is same as the current board. But if changed, you need to confirm with
>> >> measurement of signals, because it may vary slightly by resistance of
>> >> board pattern"
>> >>
>> >
>> > Right. it seems that the phy configuration should be adjusted according
>> to
>> > PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by PCB
>> > even though most PCBs use 27MHz.
>> >
>> >> That indicates to me that we might need to tweak these on a per-board
>> >> basis.
>> >>
>> >> In the 5420 datasheet, there are a few register descriptions available
>> >> for the phy. 0x145D0004 is CLK_SEL which seems like it would be
>> >> board-specific, same with TX_* registers.
>> >>
>> >
>> > And we can select HDMI Tx PHY internal PLL input clock by setting
>> CLK_SEL.
>> > Ok, Shirish's patch set is reasonable to me. However, that patch set
>> should
>> > be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
>> post
>> > your patch set after discussing how to rebase these patch set.
>> >
>> > Thanks,
>> > Inki Dae
>> >
>>
>> In that case, we need to test the phy confs for all the exynos boards,
>> supported in
>> mainline. Probably needs a analyser as well to precisely compare the
>> deviation.
>
> Shirish patch adds phy config data only to arndale and smdk5250 boards, and
> these config data should have each board specific values. Therefore, for
> other boards, shouldn't correct phy config data suitable to their boards be
> added to their board dts files? Is the above analyzer really needed?
>
Sorry, I had only seen his patches for chromium tree. In mainline
version, he added for 5250 as well. But both sets (for arn
Re: [RFC V3 2/4] mmc: dw_mmc: socfpga: move socfpga private init
On Thu, Sep 5, 2013 at 1:01 AM, Dinh Nguyen wrote:
> On Thu, 2013-08-29 at 20:59 +0900, Seungwon Jeon wrote:
>> On Wed, August 28, 2013, Yuvaraj Kumar C D wrote:
>> > Currently platform specific private data initialisation is done by
>> > dw_mci_socfpga_priv_init and dw_mci_socfpga_parse_dt.As we already have
>> > separate platform specific device tree parser dw_mci_socfpga_parse_dt,
>> > move the dw_mci_socfpga_priv_init code to dw_mci_socfpga_parse_dt.
>> > We can use the dw_mci_socfpga_priv_init to do some actual platform
>> > specific initialisation.
>
> I am looking to remove all of dw_mmc-socfpga file. The only reason for
> this file is to set the sdr timing values. But since the register that
> controls these SDR values are located out of the IP, it is probably best
> to implement the settings in platform specific code.
Well,This patch is included in this series becuase PATCHV4 3/4 of this
sereis will affect
dw_mmc-socfpga driver. However, if you are planning to remove the
whole file,still you can do
on top of this patch. :)
>
> Dinh
>> >
>> > This patch is compile tested only.
>> CC'ed Dinh Nguyen
>>
>> Thanks,
>> Seungwon Jeon
>>
>> >
>> > changes since V2: none
>> >
>> > Signed-off-by: Yuvaraj Kumar C D
>> > ---
>> > drivers/mmc/host/dw_mmc-socfpga.c | 29 ++---
>> > 1 file changed, 14 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/drivers/mmc/host/dw_mmc-socfpga.c
>> > b/drivers/mmc/host/dw_mmc-socfpga.c
>> > index 14b5961..953f260 100644
>> > --- a/drivers/mmc/host/dw_mmc-socfpga.c
>> > +++ b/drivers/mmc/host/dw_mmc-socfpga.c
>> > @@ -38,20 +38,6 @@ struct dw_mci_socfpga_priv_data {
>> >
>> > static int dw_mci_socfpga_priv_init(struct dw_mci *host)
>> > {
>> > - struct dw_mci_socfpga_priv_data *priv;
>> > -
>> > - priv = devm_kzalloc(host->dev, sizeof(*priv), GFP_KERNEL);
>> > - if (!priv) {
>> > - dev_err(host->dev, "mem alloc failed for private data\n");
>> > - return -ENOMEM;
>> > - }
>> > -
>> > - priv->sysreg = syscon_regmap_lookup_by_compatible("altr,sys-mgr");
>> > - if (IS_ERR(priv->sysreg)) {
>> > - dev_err(host->dev, "regmap for altr,sys-mgr lookup failed.\n");
>> > - return PTR_ERR(priv->sysreg);
>> > - }
>> > - host->priv = priv;
>> >
>> > return 0;
>> > }
>> > @@ -79,12 +65,24 @@ static void dw_mci_socfpga_prepare_command(struct
>> > dw_mci *host, u32 *cmdr)
>> >
>> > static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
>> > {
>> > - struct dw_mci_socfpga_priv_data *priv = host->priv;
>> > + struct dw_mci_socfpga_priv_data *priv;
>> > struct device_node *np = host->dev->of_node;
>> > u32 timing[2];
>> > u32 div = 0;
>> > int ret;
>> >
>> > + priv = devm_kzalloc(host->dev, sizeof(*priv), GFP_KERNEL);
>> > + if (!priv) {
>> > + dev_err(host->dev, "mem alloc failed for private data\n");
>> > + return -ENOMEM;
>> > + }
>> > +
>> > + priv->sysreg = syscon_regmap_lookup_by_compatible("altr,sys-mgr");
>> > + if (IS_ERR(priv->sysreg)) {
>> > + dev_err(host->dev, "regmap for altr,sys-mgr lookup failed.\n");
>> > + return PTR_ERR(priv->sysreg);
>> > + }
>> > +
>> > ret = of_property_read_u32(np, "altr,dw-mshc-ciu-div", &div);
>> > if (ret)
>> > dev_info(host->dev, "No dw-mshc-ciu-div specified, assuming
>> > 1");
>> > @@ -96,6 +94,7 @@ static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
>> > return ret;
>> >
>> > priv->hs_timing = SYSMGR_SDMMC_CTRL_SET(timing[0], timing[1]);
>> > + host->priv = priv;
>> > return 0;
>> > }
>> >
>> > --
>> > 1.7.9.5
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
> >> >> >> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
> >> >> >> + {
> >> >> >> + .pixel_clock = 2700,
> >> >> >> + .conf = {
> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
> > 0x40,
> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
> > 0x87,
> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
> > 0xE0,
> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
> > 0x00,
> >> >> >> + },
> >> >> >> + },
> >> >> >> + {
> >> >> >> + .pixel_clock = 27027000,
> >> >> >> + .conf = {
> >> >> >> + 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09,
> > 0x64,
> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
> > 0x87,
> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
> > 0xE0,
> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
> > 0x00,
> >> >> >> + },
> >> >> >> + },
> >> >> >> + {
> >> >> >> + .pixel_clock = 74176000,
> >> >> >> + .conf = {
> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef,
> > 0x5B,
> >> >> >> + 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54,
> > 0xb9,
> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
> > 0xE0,
> >> >> >> + 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00,
> > 0x00,
> >> >> >> + },
> >> >> >> + },
> >> >> >> + {
> >> >> >> + .pixel_clock = 7425,
> >> >> >> + .conf = {
> >> >> >> + 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8,
> > 0x40,
> >> >> >> + 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54,
> > 0xba,
> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
> > 0xe0,
> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00,
> > 0x00,
> >> >> >> + },
> >> >> >> + },
> >> >> >> + {
> >> >> >> + .pixel_clock = 14850,
> >> >> >> + .conf = {
> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8,
> > 0x40,
> >> >> >> + 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54,
> > 0xba,
> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
> > 0xE0,
> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00,
> > 0x00,
> >> >> >> + },
> >> >> >> + },
> >> >> >> +};
> >> >> >> +
> >> >> >
> >> >> > Are you aware of the effort to move these to dt? Since these are
> >> >> > board-specific values, it seems incorrect to apply them
> universally.
> >> >> > Shirish has uploaded a patch to the chromium review site to push
> >> these
> >> >> > into dt (https://chromium-review.googlesource.com/#/c/65581).
> Maybe
> >> >> > you can work that into your patch set?
> >> >> >
> >> >
> >> > Are these really board-specific values?
> >>
> >> According to your hardware people:
> >>
> >> "If the signal pattern doesn't change for new board, the phy setting
> >> is same as the current board. But if changed, you need to confirm with
> >> measurement of signals, because it may vary slightly by resistance of
> >> board pattern"
> >>
> >
> > Right. it seems that the phy configuration should be adjusted according
> to
> > PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by PCB
> > even though most PCBs use 27MHz.
> >
> >> That indicates to me that we might need to tweak these on a per-board
> >> basis.
> >>
> >> In the 5420 datasheet, there are a few register descriptions available
> >> for the phy. 0x145D0004 is CLK_SEL which seems like it would be
> >> board-specific, same with TX_* registers.
> >>
> >
> > And we can select HDMI Tx PHY internal PLL input clock by setting
> CLK_SEL.
> > Ok, Shirish's patch set is reasonable to me. However, that patch set
> should
> > be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
> post
> > your patch set after discussing how to rebase these patch set.
> >
> > Thanks,
> > Inki Dae
> >
>
> In that case, we need to test the phy confs for all the exynos boards,
> supported in
> mainline. Probably needs a analyser as well to precisely compare the
> deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards, and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards be
added to their board dts files? Is the above analyzer really needed?
> Shirish patch is only for 5420 Peach board. Else, to start with we can
> mark
> phyconf as optional property which overrides the default Phy Confs for
> given SoC.
Hm you mean that hdmiphy driver use the default phy config data in
driver; most boards use the same data, and only in special
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 5 September 2013 09:46, Inki Dae wrote:
>
>
>> -Original Message-
>> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
>> ow...@vger.kernel.org] On Behalf Of Sean Paul
>> Sent: Wednesday, September 04, 2013 11:52 PM
>> To: Inki Dae
>> Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
>> sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
>> Shirish S
>> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
>> driver
>>
>> On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
>> >> Sent: Wednesday, September 04, 2013 2:48 PM
>> >> To: Sean Paul
>> >> Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
>> >> InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
>> >> shir...@chromium.org
>> >> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
>> hdmiphy
>> >> driver
>> >>
>> >> Thanks Sean,
>> >>
>> >> On 3 September 2013 20:15, Sean Paul wrote:
>> >> > A few comments.
>> >> >
>> >> > On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
>>
>> >> wrote:
>> >> >> Exynos hdmiphy operations and configs are kept inside
>> >> >> the hdmi driver. Hdmiphy related code is tightly coupled
>> >> >> with hdmi IP driver.
>> >> >>
>> >> >> This patche moves hdmiphy related code to hdmiphy driver.
>> >> >
>> >> > s/patche/patch
>> >> >
>> >> ok.
>> >> >> It will help in cleanly supporting the hdmiphy variations
>> >> >> in further SoCs.
>> >> >>
>> >> >> Signed-off-by: Rahul Sharma
>> >> >> ---
>> >> >> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
>> >> >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
>> >> >> drivers/gpu/drm/exynos/exynos_hdmi.c | 343
>> > +++
>> >> >> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
>> >> +++-
>> >> >> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
>> >> >> 5 files changed, 533 insertions(+), 296 deletions(-)
>> >> >> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>> >> >>
>> >> >> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> >> index 50decf8..240eca5 100644
>> >> >> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> >> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> >> @@ -25,6 +25,7 @@ Required properties:
>> >> >> sclk_pixel.
>> >> >> - clock-names: aliases as per driver requirements for above clock
>> IDs:
>> >> >> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and
>> > "mout_hdmi".
>> >> >> +- phy: it points to hdmiphy dt node.
>> >> >> Example:
>> >> >>
>> >> >> hdmi {
>> >> >> @@ -32,4 +33,5 @@ Example:
>> >> >> reg = <0x1453 0x10>;
>> >> >> interrupts = <0 95 0>;
>> >> >> hpd-gpio = <&gpx3 7 1>;
>> >> >> + phy = <&hdmiphy>;
>> >> >> };
>> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> >> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> >> >> index 724cab1..1c839f8 100644
>> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> >> >> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
>> >> exynos_drm_hdmi_context *ctx);
>> >> >> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
>> >> >> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
>> >> >> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
>> >> >> +
>> >> >> +int exynos_hdmiphy_driver_register(void);
>> >> >> +void exynos_hdmiphy_driver_unregister(void);
>> >> >> +
>> >> >> +void exynos_hdmiphy_enable(struct device *dev);
>> >> >> +void exynos_hdmiphy_disable(struct device *dev);
>> >> >> +int exynos_hdmiphy_check_mode(struct device *dev,
>> >> >> + struct drm_display_mode *mode);
>> >> >> +int exynos_hdmiphy_set_mode(struct device *dev,
>> >> >> + struct drm_display_mode *mode);
>> >> >> +int exynos_hdmiphy_conf_apply(struct device *dev);
>> >> >> #endif
>> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> >> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> >> >> index f67ffca..3af4e4c 100644
>> >> >> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> >> >> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> >> >> @@ -34,6 +34,8 @@
>> >> >> #include
>> >> >> #include
>> >> >> #include
>> >> >> +#include
>> >> >> +#include
>> >> >>
>> >> >> #include
>> >> >>
>> >> >> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
>> >> >> };
>> >> >>
>> >> >> struct hdmi_conf_regs {
>> >> >> - int pixel_clock;
>> >> >> int cea_video_id;
>> >> >> union {
>> >> >> struct hdmi_v13_conf v13_conf;
>> >> >> @@ -193,9 +194,9 @@ struct hdmi_context {
>> >> >>
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Sean Paul
> Sent: Wednesday, September 04, 2013 11:52 PM
> To: Inki Dae
> Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
> sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
> Shirish S
> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
>
> On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae wrote:
> >
> >
> >> -Original Message-
> >> From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
> >> Sent: Wednesday, September 04, 2013 2:48 PM
> >> To: Sean Paul
> >> Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
> >> InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
> >> shir...@chromium.org
> >> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
> hdmiphy
> >> driver
> >>
> >> Thanks Sean,
> >>
> >> On 3 September 2013 20:15, Sean Paul wrote:
> >> > A few comments.
> >> >
> >> > On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
>
> >> wrote:
> >> >> Exynos hdmiphy operations and configs are kept inside
> >> >> the hdmi driver. Hdmiphy related code is tightly coupled
> >> >> with hdmi IP driver.
> >> >>
> >> >> This patche moves hdmiphy related code to hdmiphy driver.
> >> >
> >> > s/patche/patch
> >> >
> >> ok.
> >> >> It will help in cleanly supporting the hdmiphy variations
> >> >> in further SoCs.
> >> >>
> >> >> Signed-off-by: Rahul Sharma
> >> >> ---
> >> >> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
> >> >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
> >> >> drivers/gpu/drm/exynos/exynos_hdmi.c | 343
> > +++
> >> >> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
> >> +++-
> >> >> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
> >> >> 5 files changed, 533 insertions(+), 296 deletions(-)
> >> >> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> >> index 50decf8..240eca5 100644
> >> >> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> >> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> >> @@ -25,6 +25,7 @@ Required properties:
> >> >> sclk_pixel.
> >> >> - clock-names: aliases as per driver requirements for above clock
> IDs:
> >> >> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and
> > "mout_hdmi".
> >> >> +- phy: it points to hdmiphy dt node.
> >> >> Example:
> >> >>
> >> >> hdmi {
> >> >> @@ -32,4 +33,5 @@ Example:
> >> >> reg = <0x1453 0x10>;
> >> >> interrupts = <0 95 0>;
> >> >> hpd-gpio = <&gpx3 7 1>;
> >> >> + phy = <&hdmiphy>;
> >> >> };
> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> >> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> >> >> index 724cab1..1c839f8 100644
> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> >> >> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
> >> exynos_drm_hdmi_context *ctx);
> >> >> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
> >> >> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
> >> >> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
> >> >> +
> >> >> +int exynos_hdmiphy_driver_register(void);
> >> >> +void exynos_hdmiphy_driver_unregister(void);
> >> >> +
> >> >> +void exynos_hdmiphy_enable(struct device *dev);
> >> >> +void exynos_hdmiphy_disable(struct device *dev);
> >> >> +int exynos_hdmiphy_check_mode(struct device *dev,
> >> >> + struct drm_display_mode *mode);
> >> >> +int exynos_hdmiphy_set_mode(struct device *dev,
> >> >> + struct drm_display_mode *mode);
> >> >> +int exynos_hdmiphy_conf_apply(struct device *dev);
> >> >> #endif
> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> >> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> >> >> index f67ffca..3af4e4c 100644
> >> >> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> >> >> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> >> >> @@ -34,6 +34,8 @@
> >> >> #include
> >> >> #include
> >> >> #include
> >> >> +#include
> >> >> +#include
> >> >>
> >> >> #include
> >> >>
> >> >> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
> >> >> };
> >> >>
> >> >> struct hdmi_conf_regs {
> >> >> - int pixel_clock;
> >> >> int cea_video_id;
> >> >> union {
> >> >> struct hdmi_v13_conf v13_conf;
> >> >> @@ -193,9 +194,9 @@ struct hdmi_context {
> >> >> int irq;
> >> >>
> >> >> struct i2c_client *ddc_port;
> >> >> - struct i2c_client *hdmiphy
[PATCH v4 4/4] ARM: SAMSUNG: set s3c24xx_dma_filter for s3c64xx-spi0 device
The spi-s3c64xx device is also used on the s3c2416 and s3c2443 SoCs. The driver also already uses only generic dma-engine operations. Therefore add another elif to set the s3c24xx filter. Signed-off-by: Heiko Stuebner Acked-by: Linus Walleij --- arch/arm/plat-samsung/devs.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 8ce0ac0..a7b9b9e 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -32,6 +32,7 @@ #include #include #include +#include #include @@ -1499,8 +1500,10 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr, pd.num_cs = num_cs; pd.src_clk_nr = src_clk_nr; pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio; -#ifdef CONFIG_PL330_DMA +#if defined(CONFIG_PL330_DMA) pd.filter = pl330_filter; +#elif defined(CONFIG_S3C24XX_DMAC) + pd.filter = s3c24xx_dma_filter; #endif s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/4] ARM: S3C24XX: add platform-devices for new dma driver for s3c2412 and s3c2443
This includes defining the mapping for the request sources.
Signed-off-by: Heiko Stuebner
Acked-by: Linus Walleij
---
changes since v1:
- follow new pdata definition
arch/arm/mach-s3c24xx/common.c| 106 +
arch/arm/mach-s3c24xx/common.h|3 +
arch/arm/mach-s3c24xx/mach-jive.c |1 +
arch/arm/mach-s3c24xx/mach-smdk2413.c |1 +
arch/arm/mach-s3c24xx/mach-smdk2416.c |1 +
arch/arm/mach-s3c24xx/mach-smdk2443.c |1 +
arch/arm/mach-s3c24xx/mach-vstms.c|1 +
7 files changed, 114 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 457261c..16ac669 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
+#include
#include
#include
@@ -329,3 +331,107 @@ void __init_or_cpufreq s3c24xx_setup_clocks(unsigned long
fclk,
clk_p.rate = pclk;
clk_f.rate = fclk;
}
+
+#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2412) || \
+defined(CONFIG_CPU_S3C2440) || defined(CONFIG_CPU_S3C2442)
+static struct resource s3c2410_dma_resource[] = {
+ [0] = DEFINE_RES_MEM(S3C24XX_PA_DMA, S3C24XX_SZ_DMA),
+ [1] = DEFINE_RES_IRQ(IRQ_DMA0),
+ [2] = DEFINE_RES_IRQ(IRQ_DMA1),
+ [3] = DEFINE_RES_IRQ(IRQ_DMA2),
+ [4] = DEFINE_RES_IRQ(IRQ_DMA3),
+};
+#endif
+
+#ifdef CONFIG_CPU_S3C2412
+static struct s3c24xx_dma_channel s3c2412_dma_channels[DMACH_MAX] = {
+ [DMACH_XD0] = { S3C24XX_DMA_AHB, true, 17 },
+ [DMACH_XD1] = { S3C24XX_DMA_AHB, true, 18 },
+ [DMACH_SDI] = { S3C24XX_DMA_APB, false, 10 },
+ [DMACH_SPI0_RX] = { S3C24XX_DMA_APB, true, 1 },
+ [DMACH_SPI0_TX] = { S3C24XX_DMA_APB, true, 0 },
+ [DMACH_SPI1_RX] = { S3C24XX_DMA_APB, true, 3 },
+ [DMACH_SPI1_TX] = { S3C24XX_DMA_APB, true, 2 },
+ [DMACH_UART0] = { S3C24XX_DMA_APB, true, 19 },
+ [DMACH_UART1] = { S3C24XX_DMA_APB, true, 21 },
+ [DMACH_UART2] = { S3C24XX_DMA_APB, true, 23 },
+ [DMACH_UART0_SRC2] = { S3C24XX_DMA_APB, true, 20 },
+ [DMACH_UART1_SRC2] = { S3C24XX_DMA_APB, true, 22 },
+ [DMACH_UART2_SRC2] = { S3C24XX_DMA_APB, true, 24 },
+ [DMACH_TIMER] = { S3C24XX_DMA_APB, true, 9 },
+ [DMACH_I2S_IN] = { S3C24XX_DMA_APB, true, 5 },
+ [DMACH_I2S_OUT] = { S3C24XX_DMA_APB, true, 4 },
+ [DMACH_USB_EP1] = { S3C24XX_DMA_APB, true, 13 },
+ [DMACH_USB_EP2] = { S3C24XX_DMA_APB, true, 14 },
+ [DMACH_USB_EP3] = { S3C24XX_DMA_APB, true, 15 },
+ [DMACH_USB_EP4] = { S3C24XX_DMA_APB, true, 16 },
+};
+
+static struct s3c24xx_dma_platdata s3c2412_dma_platdata = {
+ .num_phy_channels = 4,
+ .channels = s3c2412_dma_channels,
+ .num_channels = DMACH_MAX,
+};
+
+struct platform_device s3c2412_device_dma = {
+ .name = "s3c2412-dma",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c2410_dma_resource),
+ .resource = s3c2410_dma_resource,
+ .dev= {
+ .platform_data = &s3c2412_dma_platdata,
+ },
+};
+#endif
+
+#if defined(CONFIG_CPUS_3C2443) || defined(CONFIG_CPU_S3C2416)
+static struct resource s3c2443_dma_resource[] = {
+ [0] = DEFINE_RES_MEM(S3C24XX_PA_DMA, S3C24XX_SZ_DMA),
+ [1] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA0),
+ [2] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA1),
+ [3] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA2),
+ [4] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA3),
+ [5] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA4),
+ [6] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA5),
+};
+
+static struct s3c24xx_dma_channel s3c2443_dma_channels[DMACH_MAX] = {
+ [DMACH_XD0] = { S3C24XX_DMA_AHB, true, 17 },
+ [DMACH_XD1] = { S3C24XX_DMA_AHB, true, 18 },
+ [DMACH_SDI] = { S3C24XX_DMA_APB, false, 10 },
+ [DMACH_SPI0_RX] = { S3C24XX_DMA_APB, true, 1 },
+ [DMACH_SPI0_TX] = { S3C24XX_DMA_APB, true, 0 },
+ [DMACH_SPI1_RX] = { S3C24XX_DMA_APB, true, 3 },
+ [DMACH_SPI1_TX] = { S3C24XX_DMA_APB, true, 2 },
+ [DMACH_UART0] = { S3C24XX_DMA_APB, true, 19 },
+ [DMACH_UART1] = { S3C24XX_DMA_APB, true, 21 },
+ [DMACH_UART2] = { S3C24XX_DMA_APB, true, 23 },
+ [DMACH_UART3] = { S3C24XX_DMA_APB, true, 25 },
+ [DMACH_UART0_SRC2] = { S3C24XX_DMA_APB, true, 20 },
+ [DMACH_UART1_SRC2] = { S3C24XX_DMA_APB, true, 22 },
+ [DMACH_UART2_SRC2] = { S3C24XX_DMA_APB, true, 24 },
+ [DMACH_UART3_SRC2] = { S3C24XX_DMA_APB, true, 26 },
+ [DMACH_TIMER] = { S3C24XX_DMA_APB, true, 9 },
+ [DMACH_I2S_IN] = { S3C24XX_DMA_APB, true, 5 },
+ [DMACH_I2S_OUT] = { S3C24XX_DMA_APB, true, 4 },
+ [DMACH_PCM_IN] = { S3C24XX_DMA_APB, true, 28 },
+ [DMACH_PCM_OUT] = { S3C24XX_DMA_APB, true, 27 },
+ [DMACH_MIC_IN] = { S3C24XX_DMA_APB, true, 29 },
+};
+
+static struct s3c24xx_dma_platdata s3c2443_dma_platdata = {
[PATCH v4 1/4] ARM: S3C24XX: number the dma clocks
Each dma channel has its own clock. The upcoming dma driver wants to
handle these itself and therefore needs to be able to get the correct
clock for a channel.
Therefore rename the dma clocks to "dma.X" for s3c2412, s3c2416 and
s3c2443. This does not change the behaviour for the old dma driver at
all, as all dma clocks are still always on and not handled by the old
dma driver at all.
Signed-off-by: Heiko Stuebner
Acked-by: Linus Walleij
---
changes since v2:
- remove noise from commit message
arch/arm/mach-s3c24xx/clock-s3c2412.c |8
arch/arm/mach-s3c24xx/common-s3c2443.c | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2412.c
b/arch/arm/mach-s3c24xx/clock-s3c2412.c
index d8f253f..11b3b28 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2412.c
@@ -484,22 +484,22 @@ static struct clk init_clocks_disable[] = {
static struct clk init_clocks[] = {
{
- .name = "dma",
+ .name = "dma.0",
.parent = &clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA0,
}, {
- .name = "dma",
+ .name = "dma.1",
.parent = &clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA1,
}, {
- .name = "dma",
+ .name = "dma.2",
.parent = &clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA2,
}, {
- .name = "dma",
+ .name = "dma.3",
.parent = &clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA3,
diff --git a/arch/arm/mach-s3c24xx/common-s3c2443.c
b/arch/arm/mach-s3c24xx/common-s3c2443.c
index f6b9f2e..65d3eef 100644
--- a/arch/arm/mach-s3c24xx/common-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/common-s3c2443.c
@@ -438,32 +438,32 @@ static struct clk init_clocks_off[] = {
static struct clk init_clocks[] = {
{
- .name = "dma",
+ .name = "dma.0",
.parent = &clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA0,
}, {
- .name = "dma",
+ .name = "dma.1",
.parent = &clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA1,
}, {
- .name = "dma",
+ .name = "dma.2",
.parent = &clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA2,
}, {
- .name = "dma",
+ .name = "dma.3",
.parent = &clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA3,
}, {
- .name = "dma",
+ .name = "dma.4",
.parent = &clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA4,
}, {
- .name = "dma",
+ .name = "dma.5",
.parent = &clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA5,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/4] dmaengine: add driver for Samsung s3c24xx SoCs
This adds a new driver to support the s3c24xx dma using the dmaengine and makes the old one in mach-s3c24xx obsolete in the long run. Conceptually the s3c24xx-dma feels like a distant relative of the pl08x with numerous virtual channels being mapped to a lot less physical ones. The driver therefore borrows a lot from the amba-pl08x driver in this regard. Functionality-wise the driver gains a memcpy ability in addition to the slave_sg one. The driver supports both the method for requesting the peripheral used by SoCs before the S3C2443 and the different method for S3C2443 and later. On earlier SoCs the hardware channels usable for specific peripherals is constrainted while on later SoCs all channels can be used for any peripheral. Tested on a s3c2416-based board, memcpy using the dmatest module and slave_sg partially using the spi-s3c64xx driver. Signed-off-by: Heiko Stuebner Acked-by: Linus Walleij --- changes since v3: - address comments from Tomasz Figa: - fixed a lot of nitpics - and added a rudimentary mechanism to select higher bus-widths for memcpy - address more comments from Vinod Koul - reorder dma_control contents changes since v2: - add missing channel validation in s3c24xx_dma_phy_free when repurposing a physical channel for another virtual channel - address comments from Vinod Koul: - fix naming of constants to prevent conflicts - better handle the unlikely case of an interrupt happening on an unused channel changes since v1: - address comments from Linus Walleij - support sg-lists with more than 1 element - add support for earlier s3c24xx SoCs - redo the channeldata definitions: - no need for static ids for the virtual channels - provide a way to encode constraints for earlier variants - better base for later dt bindings drivers/dma/Kconfig | 12 + drivers/dma/Makefile |1 + drivers/dma/s3c24xx-dma.c | 1340 + include/linux/platform_data/dma-s3c24xx.h | 43 + 4 files changed, 1396 insertions(+) create mode 100644 drivers/dma/s3c24xx-dma.c create mode 100644 include/linux/platform_data/dma-s3c24xx.h diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 526ec77..d639115 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -154,6 +154,18 @@ config TEGRA20_APB_DMA This DMA controller transfers data from memory to peripheral fifo or vice versa. It does not support memory to memory data transfer. +config S3C24XX_DMAC + tristate "Samsung S3C24XX DMA support" + depends on ARCH_S3C24XX && !S3C24XX_DMA + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + help + Support for the Samsung S3C24XX DMA controller driver. The + DMA controller is having multiple DMA channels which can be + configured for different peripherals like audio, UART, SPI. + The DMA controller can transfer data from memory to peripheral, + periphal to memory, periphal to periphal and memory to memory. + source "drivers/dma/sh/Kconfig" config COH901318 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index cb5a77a..afd1b14 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_SIRF_DMA) += sirf-dma.o obj-$(CONFIG_TI_EDMA) += edma.o obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o +obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o obj-$(CONFIG_PL330_DMA) += pl330.o obj-$(CONFIG_PCH_DMA) += pch_dma.o obj-$(CONFIG_AMBA_PL08X) += amba-pl08x.o diff --git a/drivers/dma/s3c24xx-dma.c b/drivers/dma/s3c24xx-dma.c new file mode 100644 index 000..d56a5ef --- /dev/null +++ b/drivers/dma/s3c24xx-dma.c @@ -0,0 +1,1340 @@ +/* + * S3C24XX DMA handling + * + * Copyright (c) 2013 Heiko Stuebner + * + * based on amba-pl08x.c + * + * Copyright (c) 2006 ARM Ltd. + * Copyright (c) 2010 ST-Ericsson SA + * + * Author: Peter Pearse + * Author: Linus Walleij + * + * 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. + * + * The DMA controllers in S3C24XX SoCs have a varying number of DMA signals + * that can be routed to any of the 4 to 8 hardware-channels. + * + * Therefore on these DMA controllers the number of channels + * and the number of incoming DMA signals are two totally different things. + * It is usually not possible to theoretically handle all physical signals, + * so a multiplexing scheme with possible denial of use is necessary. + * + * Open items: + * - bursts + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "dmaengine.h" +#include "virt-dma.h" + +#define MAX_DMA_CHANNELS 8 + +#define S3C24XX_DISRC 0x00 +#define S3C24
[PATCH v4 0/4] ARM: S3C24XX: add dmaengine based dma-driver
This series tries to provide a basic dmaengine driver for the s3c24xx SoCs to subsequently retire the old one with custom API. Since v3 more smaller fixes were added, and memcpy operations now have a very simple mechanism to try to use higher transfer widths. Since v2 only some small fixes to the dma driver itself were added. Since v1 three big changes happened (appart from fixing received comments): For one the limitation of sg-lists to 1 element is gone.Secondly the specifics of the virtual channels (target bus, handshake, etc) are not encoded with channel ids but in the platformdata - making a later dt binding easier, as these informations can there be gathered by the xlate function. And lastly I also added a preliminary mechanism to handle the specific needs for the earlier variants of the driver. While s3c2443 and later can use any channel for any peripheral with just marking the target-peripheral-id in a register, earlier SoCs can only use specific channels and the target-ids also vary depending on the channel. Therefore on newer SoCs the chansel element only needs to contain the requested target-id, while on the older variants use it to encode both the valid channels and the channel-specific peripheral-id. On affected SoCs the target-id is always 3 bit wide, so we use these and an additional 4th bit to hold the valid state. As the older SoCs all have 4 dma channels this can live happily in an u16 element. The s3c24xx series will most likely not see any new offspring, but even if it happens any new model will probably use the newer more flexible variant of the dma controller, so this should not restrict anything in the future. Example: SDI is valid on channels 0, 2 and 3 - with varying hw request sources. For it the chansel field would look like ((BIT(3) | 1) << 3 * 4) | // channel 3, with request source 1 ((BIT(3) | 2) << 2 * 4) | // channel 2, with request source 2 ((BIT(3) | 2) << 0 * 4) // channel 0, with request source 2 Heiko Stuebner (4): ARM: S3C24XX: number the dma clocks dmaengine: add driver for Samsung s3c24xx SoCs ARM: S3C24XX: add platform-devices for new dma driver for s3c2412 and s3c2443 ARM: SAMSUNG: set s3c24xx_dma_filter for s3c64xx-spi0 device arch/arm/mach-s3c24xx/clock-s3c2412.c |8 +- arch/arm/mach-s3c24xx/common-s3c2443.c| 12 +- arch/arm/mach-s3c24xx/common.c| 106 +++ arch/arm/mach-s3c24xx/common.h|3 + arch/arm/mach-s3c24xx/mach-jive.c |1 + arch/arm/mach-s3c24xx/mach-smdk2413.c |1 + arch/arm/mach-s3c24xx/mach-smdk2416.c |1 + arch/arm/mach-s3c24xx/mach-smdk2443.c |1 + arch/arm/mach-s3c24xx/mach-vstms.c|1 + arch/arm/plat-samsung/devs.c |5 +- drivers/dma/Kconfig | 12 + drivers/dma/Makefile |1 + drivers/dma/s3c24xx-dma.c | 1340 + include/linux/platform_data/dma-s3c24xx.h | 43 + 14 files changed, 1524 insertions(+), 11 deletions(-) create mode 100644 drivers/dma/s3c24xx-dma.c create mode 100644 include/linux/platform_data/dma-s3c24xx.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC V3 2/4] mmc: dw_mmc: socfpga: move socfpga private init
On Thu, 2013-08-29 at 20:59 +0900, Seungwon Jeon wrote:
> On Wed, August 28, 2013, Yuvaraj Kumar C D wrote:
> > Currently platform specific private data initialisation is done by
> > dw_mci_socfpga_priv_init and dw_mci_socfpga_parse_dt.As we already have
> > separate platform specific device tree parser dw_mci_socfpga_parse_dt,
> > move the dw_mci_socfpga_priv_init code to dw_mci_socfpga_parse_dt.
> > We can use the dw_mci_socfpga_priv_init to do some actual platform
> > specific initialisation.
I am looking to remove all of dw_mmc-socfpga file. The only reason for
this file is to set the sdr timing values. But since the register that
controls these SDR values are located out of the IP, it is probably best
to implement the settings in platform specific code.
Dinh
> >
> > This patch is compile tested only.
> CC'ed Dinh Nguyen
>
> Thanks,
> Seungwon Jeon
>
> >
> > changes since V2: none
> >
> > Signed-off-by: Yuvaraj Kumar C D
> > ---
> > drivers/mmc/host/dw_mmc-socfpga.c | 29 ++---
> > 1 file changed, 14 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/mmc/host/dw_mmc-socfpga.c
> > b/drivers/mmc/host/dw_mmc-socfpga.c
> > index 14b5961..953f260 100644
> > --- a/drivers/mmc/host/dw_mmc-socfpga.c
> > +++ b/drivers/mmc/host/dw_mmc-socfpga.c
> > @@ -38,20 +38,6 @@ struct dw_mci_socfpga_priv_data {
> >
> > static int dw_mci_socfpga_priv_init(struct dw_mci *host)
> > {
> > - struct dw_mci_socfpga_priv_data *priv;
> > -
> > - priv = devm_kzalloc(host->dev, sizeof(*priv), GFP_KERNEL);
> > - if (!priv) {
> > - dev_err(host->dev, "mem alloc failed for private data\n");
> > - return -ENOMEM;
> > - }
> > -
> > - priv->sysreg = syscon_regmap_lookup_by_compatible("altr,sys-mgr");
> > - if (IS_ERR(priv->sysreg)) {
> > - dev_err(host->dev, "regmap for altr,sys-mgr lookup failed.\n");
> > - return PTR_ERR(priv->sysreg);
> > - }
> > - host->priv = priv;
> >
> > return 0;
> > }
> > @@ -79,12 +65,24 @@ static void dw_mci_socfpga_prepare_command(struct
> > dw_mci *host, u32 *cmdr)
> >
> > static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
> > {
> > - struct dw_mci_socfpga_priv_data *priv = host->priv;
> > + struct dw_mci_socfpga_priv_data *priv;
> > struct device_node *np = host->dev->of_node;
> > u32 timing[2];
> > u32 div = 0;
> > int ret;
> >
> > + priv = devm_kzalloc(host->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv) {
> > + dev_err(host->dev, "mem alloc failed for private data\n");
> > + return -ENOMEM;
> > + }
> > +
> > + priv->sysreg = syscon_regmap_lookup_by_compatible("altr,sys-mgr");
> > + if (IS_ERR(priv->sysreg)) {
> > + dev_err(host->dev, "regmap for altr,sys-mgr lookup failed.\n");
> > + return PTR_ERR(priv->sysreg);
> > + }
> > +
> > ret = of_property_read_u32(np, "altr,dw-mshc-ciu-div", &div);
> > if (ret)
> > dev_info(host->dev, "No dw-mshc-ciu-div specified, assuming 1");
> > @@ -96,6 +94,7 @@ static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
> > return ret;
> >
> > priv->hs_timing = SYSMGR_SDMMC_CTRL_SET(timing[0], timing[1]);
> > + host->priv = priv;
> > return 0;
> > }
> >
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 v2 0/3] add temporary parent migration support
On Wednesday 04 of September 2013 10:43:28 Mike Turquette wrote: > Quoting Tomasz Figa (2013-09-03 15:36:50) > > > Hi Chander, > > > > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: > > > Some platform has provision to change cpu parent clock during > > > cpu frequency scaling. This patch series provides a mechanism to > > > implement the same using CCF. > > > > > > Patch1 provides mechanism to migrate to new parent temporarily. > > > > > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which > > > are modified to add support for clk migration. > > > > > > Patch3 adds support to Exynos5250 to use the clock parent migration > > > feature implemented in CCF. > > > > I don't really like this approach. A need to change mux setting > > temporarily is heavily platform-specific and I don't think it should > > be > > handled by generic code. > > I agree with Tomasz. > > > First of all there are many factor that you would > > > > have to account for to make this solution generic, such as: > > - board specific alternative parents, > > - exact moment of parent change, > > - some other platform specific conditions, like CPU voltage that must > > be> > > changed when mux is changed, because it changes CPU frequency, > > > > - and probably a lot of more factors that only people working with > > all > > > > the platforms supported (and unsupported yet) by Linux. > > > > I can see at least two solutions for this problem that don't require > > changing core code of common clock framework: > > > > 1) Implementing a special clock type using normal mux ops, but also > > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE > > events to perform parent switching. > > Creating a custom clock type is the way to go here. It is possible to > wrap the mux clk_ops to re-use that code, or just write a custom clock > type from scratch. > > I do not like using the clock rate-change notifiers for this purpose. > The notifiers provide hooks to drivers that need to take care around > clock transitions. Using the notifiers from within the clock framework > indicates poor design. I was not sure how a .set_parent() from inside a .set_rate() would interact with rate setting, so I mentioned notifiers here, but now as I think of it, CCF is supposed to be re-entrant, so things should be fine. > > 2) Using normal mux clock, but registering such notifiers in clock > > controller or cpufreq driver. > > This depends on what the data sheet or reference manual states. If using > a temporary parent is a property of the clock programming sequence > (e.g. to have a glitch-less transition) then that logic belongs in the > clock provider driver (i.e. a custom clock type needs to be created > with this logic). > > However if using a temporary parent is not required for programming the > clock, but is instead a requirement of the clock consumer (e.g. a CPU, > or some I/O controller) then perhaps putting this logic in that driver > is the right way to go. In that case the logic could be explicit: > > clk_set_parent(clk, temp_parent); > clk_set_rate(clk, target_rate); > clk_set_parent(clk, target_parent); > > Or it could implicit with the use of rate-change notifiers. Again the > rate-change notifiers exist for clock consumer drivers to use, so this > is OK. > > I have a hunch that the right way to do this is for a custom clock type > to be created which simply calls clk_set_parent from within the clock's > .set_rate callback, but I'll wait on feedback from Chander on the needs > of his platform. I believe Chander has exactly the same use case for this as we have for Exynos 4210 and 4x12. On these SoCs, CPU frequency is being scaled by reconfiguring PLL, which needs to be masked for locking time. To let the CPU operate normally, a mux that allows switching CPU clock domain between two PLLs can be switched to the other PLL (MPLL) until the main ARM PLL (APLL) starts operating again. However this issue is not limited to clocks, because there must be also a voltage transition involved if the utility PLL has frequency higher than the one currently being reconfigured. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 v2 0/3] add temporary parent migration support
Quoting Tomasz Figa (2013-09-03 15:36:50) > Hi Chander, > > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: > > Some platform has provision to change cpu parent clock during > > cpu frequency scaling. This patch series provides a mechanism to > > implement the same using CCF. > > > > Patch1 provides mechanism to migrate to new parent temporarily. > > > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are > > modified to add support for clk migration. > > > > Patch3 adds support to Exynos5250 to use the clock parent migration > > feature implemented in CCF. > > I don't really like this approach. A need to change mux setting > temporarily is heavily platform-specific and I don't think it should be > handled by generic code. I agree with Tomasz. > First of all there are many factor that you would > have to account for to make this solution generic, such as: > - board specific alternative parents, > - exact moment of parent change, > - some other platform specific conditions, like CPU voltage that must be > changed when mux is changed, because it changes CPU frequency, > - and probably a lot of more factors that only people working with all > the platforms supported (and unsupported yet) by Linux. > > I can see at least two solutions for this problem that don't require > changing core code of common clock framework: > > 1) Implementing a special clock type using normal mux ops, but also > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events > to perform parent switching. Creating a custom clock type is the way to go here. It is possible to wrap the mux clk_ops to re-use that code, or just write a custom clock type from scratch. I do not like using the clock rate-change notifiers for this purpose. The notifiers provide hooks to drivers that need to take care around clock transitions. Using the notifiers from within the clock framework indicates poor design. > > 2) Using normal mux clock, but registering such notifiers in clock > controller or cpufreq driver. This depends on what the data sheet or reference manual states. If using a temporary parent is a property of the clock programming sequence (e.g. to have a glitch-less transition) then that logic belongs in the clock provider driver (i.e. a custom clock type needs to be created with this logic). However if using a temporary parent is not required for programming the clock, but is instead a requirement of the clock consumer (e.g. a CPU, or some I/O controller) then perhaps putting this logic in that driver is the right way to go. In that case the logic could be explicit: clk_set_parent(clk, temp_parent); clk_set_rate(clk, target_rate); clk_set_parent(clk, target_parent); Or it could implicit with the use of rate-change notifiers. Again the rate-change notifiers exist for clock consumer drivers to use, so this is OK. I have a hunch that the right way to do this is for a custom clock type to be created which simply calls clk_set_parent from within the clock's .set_rate callback, but I'll wait on feedback from Chander on the needs of his platform. Regards, Mike > > Best regards, > Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.12 merge window exynos cpufreq driver fails to build
Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the exynos-cpufreq driver doesn't build because it includes a file that doesn't exist. + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp] #warning "TODO: return_address should use unwind tables" ^ arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA allocator does not (yet) support huge TLB [-Wcpp] #warning ARM Coherent DMA allocator does not (yet) support huge TLB ^ drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No such file or directory #include ^ compilation terminated. make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 I'm guessing that file is supposed to come from arch/arm/plat-samsung/include/plat/, but I don't see anything that specifies a -I there. Thoughts? josh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.12 merge window exynos cpufreq driver fails to build
On Wed, Sep 4, 2013 at 11:04 AM, Tomasz Figa wrote: > On Wednesday 04 of September 2013 10:41:31 Josh Boyer wrote: >> On Wed, Sep 4, 2013 at 10:36 AM, Tomasz Figa wrote: >> > Hi Josh, >> > >> > On Wednesday 04 of September 2013 10:13:16 Josh Boyer wrote: >> >> Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the >> >> exynos-cpufreq driver doesn't build because it includes a file that >> >> doesn't exist. >> >> >> >> + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 >> >> arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: >> >> return_address should use unwind tables" [-Wcpp] >> >> >> >> #warning "TODO: return_address should use unwind tables" >> >> >> >> ^ >> >> >> >> arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA >> >> allocator does not (yet) support huge TLB [-Wcpp] >> >> >> >> #warning ARM Coherent DMA allocator does not (yet) support huge TLB >> >> >> >> ^ >> >> >> >> drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No >> >> such file or directory >> >> >> >> #include >> >> >> >> ^ >> >> >> >> compilation terminated. >> >> make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 >> >> >> >> I'm guessing that file is supposed to come from >> >> arch/arm/plat-samsung/include/plat/, but I don't see anything that >> >> specifies a -I there. >> >> >> >> Thoughts? >> > >> > Could you attach config that could be used to trigger this? Thanks in >> > advance. >> >> Attached. > > Hmm, this does not look like config for kernel neither from Linus' nor > linux-next tree. The first thing I can see is CONFIG_ARCH_EXYNOS_MULTI > selected, which is not available in any mainline tree. Sigh. Yes, I see the issue now. > As for the build error itself, headers from plat/ are available for drivers > only in single platform builds, they can't be included when multiplatform > is enabled. The exynos-cpufreq driver is not multiplatform-aware yet and so > you get the failure. Someone added some exynos multiplatform patches to the Fedora kernel. That seems to have caused these build failures. Our mistake and my apologies for the inconvenience. Thank you for the quick response. josh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.12 merge window exynos cpufreq driver fails to build
On Wednesday 04 of September 2013 10:41:31 Josh Boyer wrote: > On Wed, Sep 4, 2013 at 10:36 AM, Tomasz Figa wrote: > > Hi Josh, > > > > On Wednesday 04 of September 2013 10:13:16 Josh Boyer wrote: > >> Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the > >> exynos-cpufreq driver doesn't build because it includes a file that > >> doesn't exist. > >> > >> + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 > >> arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: > >> return_address should use unwind tables" [-Wcpp] > >> > >> #warning "TODO: return_address should use unwind tables" > >> > >> ^ > >> > >> arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA > >> allocator does not (yet) support huge TLB [-Wcpp] > >> > >> #warning ARM Coherent DMA allocator does not (yet) support huge TLB > >> > >> ^ > >> > >> drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No > >> such file or directory > >> > >> #include > >> > >> ^ > >> > >> compilation terminated. > >> make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 > >> > >> I'm guessing that file is supposed to come from > >> arch/arm/plat-samsung/include/plat/, but I don't see anything that > >> specifies a -I there. > >> > >> Thoughts? > > > > Could you attach config that could be used to trigger this? Thanks in > > advance. > > Attached. Hmm, this does not look like config for kernel neither from Linus' nor linux-next tree. The first thing I can see is CONFIG_ARCH_EXYNOS_MULTI selected, which is not available in any mainline tree. As for the build error itself, headers from plat/ are available for drivers only in single platform builds, they can't be included when multiplatform is enabled. The exynos-cpufreq driver is not multiplatform-aware yet and so you get the failure. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
>> Sent: Wednesday, September 04, 2013 2:48 PM
>> To: Sean Paul
>> Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
>> InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
>> shir...@chromium.org
>> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
>> driver
>>
>> Thanks Sean,
>>
>> On 3 September 2013 20:15, Sean Paul wrote:
>> > A few comments.
>> >
>> > On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
>> wrote:
>> >> Exynos hdmiphy operations and configs are kept inside
>> >> the hdmi driver. Hdmiphy related code is tightly coupled
>> >> with hdmi IP driver.
>> >>
>> >> This patche moves hdmiphy related code to hdmiphy driver.
>> >
>> > s/patche/patch
>> >
>> ok.
>> >> It will help in cleanly supporting the hdmiphy variations
>> >> in further SoCs.
>> >>
>> >> Signed-off-by: Rahul Sharma
>> >> ---
>> >> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
>> >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
>> >> drivers/gpu/drm/exynos/exynos_hdmi.c | 343
> +++
>> >> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
>> +++-
>> >> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
>> >> 5 files changed, 533 insertions(+), 296 deletions(-)
>> >> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> index 50decf8..240eca5 100644
>> >> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> @@ -25,6 +25,7 @@ Required properties:
>> >> sclk_pixel.
>> >> - clock-names: aliases as per driver requirements for above clock IDs:
>> >> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and
> "mout_hdmi".
>> >> +- phy: it points to hdmiphy dt node.
>> >> Example:
>> >>
>> >> hdmi {
>> >> @@ -32,4 +33,5 @@ Example:
>> >> reg = <0x1453 0x10>;
>> >> interrupts = <0 95 0>;
>> >> hpd-gpio = <&gpx3 7 1>;
>> >> + phy = <&hdmiphy>;
>> >> };
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> >> index 724cab1..1c839f8 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> >> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
>> exynos_drm_hdmi_context *ctx);
>> >> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
>> >> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
>> >> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
>> >> +
>> >> +int exynos_hdmiphy_driver_register(void);
>> >> +void exynos_hdmiphy_driver_unregister(void);
>> >> +
>> >> +void exynos_hdmiphy_enable(struct device *dev);
>> >> +void exynos_hdmiphy_disable(struct device *dev);
>> >> +int exynos_hdmiphy_check_mode(struct device *dev,
>> >> + struct drm_display_mode *mode);
>> >> +int exynos_hdmiphy_set_mode(struct device *dev,
>> >> + struct drm_display_mode *mode);
>> >> +int exynos_hdmiphy_conf_apply(struct device *dev);
>> >> #endif
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> >> index f67ffca..3af4e4c 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> >> @@ -34,6 +34,8 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >> +#include
>> >>
>> >> #include
>> >>
>> >> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
>> >> };
>> >>
>> >> struct hdmi_conf_regs {
>> >> - int pixel_clock;
>> >> int cea_video_id;
>> >> union {
>> >> struct hdmi_v13_conf v13_conf;
>> >> @@ -193,9 +194,9 @@ struct hdmi_context {
>> >> int irq;
>> >>
>> >> struct i2c_client *ddc_port;
>> >> - struct i2c_client *hdmiphy_port;
>> >> + struct device *hdmiphy_dev;
>> >>
>> >> - /* current hdmiphy conf regs */
>> >> + /* current hdmi ip configuration registers. */
>> >> struct hdmi_conf_regs mode_conf;
>> >>
>> >> struct hdmi_resources res;
>> >> @@ -205,180 +206,6 @@ struct hdmi_context {
>> >> enum hdmi_type type;
>> >> };
>> >>
>> >> -struct hdmiphy_config {
>> >> - int pixel_clock;
>> >> - u8 conf[32];
>> >> -};
>> >> -
>> >> -/* list of phy config settings */
>> >> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
>> >> - {
>> >> - .pixel_clock = 2700,
>> >>
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On Wed, Sep 4, 2013 at 1:47 AM, Rahul Sharma wrote:
> Thanks Sean,
>
> On 3 September 2013 20:15, Sean Paul wrote:
>> A few comments.
>>
>> On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
>> wrote:
>>> Exynos hdmiphy operations and configs are kept inside
>>> the hdmi driver. Hdmiphy related code is tightly coupled
>>> with hdmi IP driver.
>>>
>>> This patche moves hdmiphy related code to hdmiphy driver.
>>
>> s/patche/patch
>>
> ok.
>>> It will help in cleanly supporting the hdmiphy variations
>>> in further SoCs.
>>>
>>> Signed-off-by: Rahul Sharma
>>> ---
>>> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
>>> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
>>> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
>>> +++-
>>> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
>>> 5 files changed, 533 insertions(+), 296 deletions(-)
>>> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> index 50decf8..240eca5 100644
>>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> @@ -25,6 +25,7 @@ Required properties:
>>> sclk_pixel.
>>> - clock-names: aliases as per driver requirements for above clock IDs:
>>> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>>> +- phy: it points to hdmiphy dt node.
>>> Example:
>>>
>>> hdmi {
>>> @@ -32,4 +33,5 @@ Example:
>>> reg = <0x1453 0x10>;
>>> interrupts = <0 95 0>;
>>> hpd-gpio = <&gpx3 7 1>;
>>> + phy = <&hdmiphy>;
>>> };
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>>> index 724cab1..1c839f8 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>>> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
>>> exynos_drm_hdmi_context *ctx);
>>> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
>>> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
>>> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
>>> +
>>> +int exynos_hdmiphy_driver_register(void);
>>> +void exynos_hdmiphy_driver_unregister(void);
>>> +
>>> +void exynos_hdmiphy_enable(struct device *dev);
>>> +void exynos_hdmiphy_disable(struct device *dev);
>>> +int exynos_hdmiphy_check_mode(struct device *dev,
>>> + struct drm_display_mode *mode);
>>> +int exynos_hdmiphy_set_mode(struct device *dev,
>>> + struct drm_display_mode *mode);
>>> +int exynos_hdmiphy_conf_apply(struct device *dev);
>>> #endif
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index f67ffca..3af4e4c 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -34,6 +34,8 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>>
>>> #include
>>>
>>> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
>>> };
>>>
>>> struct hdmi_conf_regs {
>>> - int pixel_clock;
>>> int cea_video_id;
>>> union {
>>> struct hdmi_v13_conf v13_conf;
>>> @@ -193,9 +194,9 @@ struct hdmi_context {
>>> int irq;
>>>
>>> struct i2c_client *ddc_port;
>>> - struct i2c_client *hdmiphy_port;
>>> + struct device *hdmiphy_dev;
>>>
>>> - /* current hdmiphy conf regs */
>>> + /* current hdmi ip configuration registers. */
>>> struct hdmi_conf_regs mode_conf;
>>>
>>> struct hdmi_resources res;
>>> @@ -205,180 +206,6 @@ struct hdmi_context {
>>> enum hdmi_type type;
>>> };
>>>
>>> -struct hdmiphy_config {
>>> - int pixel_clock;
>>> - u8 conf[32];
>>> -};
>>> -
>>> -/* list of phy config settings */
>>> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
>>> - {
>>> - .pixel_clock = 2700,
>>> - .conf = {
>>> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
>>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>>> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
>>> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
>>> - },
>>> - },
>>> - {
>>> - .pixel_clock = 27027000,
>>> - .conf = {
>>> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
>>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>>> -
Re: 3.12 merge window exynos cpufreq driver fails to build
Hi Josh, On Wednesday 04 of September 2013 10:13:16 Josh Boyer wrote: > Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the > exynos-cpufreq driver doesn't build because it includes a file that > doesn't exist. > > + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 > arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: > return_address should use unwind tables" [-Wcpp] > #warning "TODO: return_address should use unwind tables" > ^ > arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA > allocator does not (yet) support huge TLB [-Wcpp] > #warning ARM Coherent DMA allocator does not (yet) support huge TLB > ^ > drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No > such file or directory > #include > ^ > compilation terminated. > make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 > > I'm guessing that file is supposed to come from > arch/arm/plat-samsung/include/plat/, but I don't see anything that > specifies a -I there. > > Thoughts? Could you attach config that could be used to trigger this? Thanks in advance. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 0/8] PHY framework
On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: > On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: >> Hi Greg, >> >> On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: >>> Hi, >>> >>> On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: > Added a generic PHY framework that provides a set of APIs for the PHY > drivers > to create/destroy a PHY and APIs for the PHY users to obtain a reference > to > the PHY with or without using phandle. > > This framework will be of use only to devices that uses external PHY (PHY > functionality is not embedded within the controller). > > The intention of creating this framework is to bring the phy drivers > spread > all over the Linux kernel to drivers/phy to increase code re-use and to > increase code maintainability. > > Comments to make PHY as bus wasn't done because PHY devices can be part of > other bus and making a same device attached to multiple bus leads to bad > design. > > If the PHY driver has to send notification on connect/disconnect, the PHY > driver should make use of the extcon framework. Using this susbsystem > to use extcon framwork will have to be analysed. > > You can find this patch series @ > git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing Looks like there are not further comments on this series. Can you take this in your misc tree? >>> >>> Do you want me to queue these for you ? There are quite a few users for >>> this framework already and I know of at least 2 others which will show >>> up for v3.13. >> >> Can you queue this patch series? There are quite a few users already for this >> framework. > > It will have to wait for 3.13 as the merge window for new features has > been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 > is out. Alright, thanks. -Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
> -Original Message-
> From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
> Sent: Wednesday, September 04, 2013 2:48 PM
> To: Sean Paul
> Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
> InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
> shir...@chromium.org
> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
>
> Thanks Sean,
>
> On 3 September 2013 20:15, Sean Paul wrote:
> > A few comments.
> >
> > On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
> wrote:
> >> Exynos hdmiphy operations and configs are kept inside
> >> the hdmi driver. Hdmiphy related code is tightly coupled
> >> with hdmi IP driver.
> >>
> >> This patche moves hdmiphy related code to hdmiphy driver.
> >
> > s/patche/patch
> >
> ok.
> >> It will help in cleanly supporting the hdmiphy variations
> >> in further SoCs.
> >>
> >> Signed-off-by: Rahul Sharma
> >> ---
> >> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
> >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
> >> drivers/gpu/drm/exynos/exynos_hdmi.c | 343
+++
> >> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
> +++-
> >> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
> >> 5 files changed, 533 insertions(+), 296 deletions(-)
> >> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
> >>
> >> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> index 50decf8..240eca5 100644
> >> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> @@ -25,6 +25,7 @@ Required properties:
> >> sclk_pixel.
> >> - clock-names: aliases as per driver requirements for above clock IDs:
> >> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and
"mout_hdmi".
> >> +- phy: it points to hdmiphy dt node.
> >> Example:
> >>
> >> hdmi {
> >> @@ -32,4 +33,5 @@ Example:
> >> reg = <0x1453 0x10>;
> >> interrupts = <0 95 0>;
> >> hpd-gpio = <&gpx3 7 1>;
> >> + phy = <&hdmiphy>;
> >> };
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> >> index 724cab1..1c839f8 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> >> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
> exynos_drm_hdmi_context *ctx);
> >> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
> >> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
> >> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
> >> +
> >> +int exynos_hdmiphy_driver_register(void);
> >> +void exynos_hdmiphy_driver_unregister(void);
> >> +
> >> +void exynos_hdmiphy_enable(struct device *dev);
> >> +void exynos_hdmiphy_disable(struct device *dev);
> >> +int exynos_hdmiphy_check_mode(struct device *dev,
> >> + struct drm_display_mode *mode);
> >> +int exynos_hdmiphy_set_mode(struct device *dev,
> >> + struct drm_display_mode *mode);
> >> +int exynos_hdmiphy_conf_apply(struct device *dev);
> >> #endif
> >> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> >> index f67ffca..3af4e4c 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> >> @@ -34,6 +34,8 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +#include
> >>
> >> #include
> >>
> >> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
> >> };
> >>
> >> struct hdmi_conf_regs {
> >> - int pixel_clock;
> >> int cea_video_id;
> >> union {
> >> struct hdmi_v13_conf v13_conf;
> >> @@ -193,9 +194,9 @@ struct hdmi_context {
> >> int irq;
> >>
> >> struct i2c_client *ddc_port;
> >> - struct i2c_client *hdmiphy_port;
> >> + struct device *hdmiphy_dev;
> >>
> >> - /* current hdmiphy conf regs */
> >> + /* current hdmi ip configuration registers. */
> >> struct hdmi_conf_regs mode_conf;
> >>
> >> struct hdmi_resources res;
> >> @@ -205,180 +206,6 @@ struct hdmi_context {
> >> enum hdmi_type type;
> >> };
> >>
> >> -struct hdmiphy_config {
> >> - int pixel_clock;
> >> - u8 conf[32];
> >> -};
> >> -
> >> -/* list of phy config settings */
> >> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> >> - {
> >> - .pixel_clock = 2700,
> >> - .conf = {
> >> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
> >> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>
