Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Wed, Sep 3, 2014 at 8:12 PM, Felipe Balbi wrote: > Hi, > > On Wed, Sep 03, 2014 at 12:59:27PM +0530, Vivek Gautam wrote: >> > On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: >> >> Adding phy calibrate callback, which facilitates setting certain >> >> PHY settings post initialization of the PHY controller. >> >> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which >> >> the Loss-of-Signal (LOS) Detector Threshold Level as well as >> >> Tx-Vboost-Level should be controlled for Super-Speed operations. >> >> >> >> Additionally set proper time to wait for RxDetect measurement, >> >> for desired PHY reference clock, so as to solve issue with enumeration >> >> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive >> >> on the controller. >> >> We are using CR_port for this purpose to send required data >> >> to override the LOS values. >> >> >> >> On testing with USB 3.0 devices on USB 3.0 port present on >> >> SMDK5420, and peach-pit boards should see following message: >> >> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd >> >> >> >> and without this patch, should see below shown message: >> >> usb 1-1: new high-speed USB device number 2 using xhci-hcd >> >> >> >> [Also removed unnecessary extra lines in the register macro definitions] >> >> >> >> Signed-off-by: Vivek Gautam >> >> --- >> >> drivers/phy/phy-exynos5-usbdrd.c | 185 >> >> ++ >> >> 1 file changed, 170 insertions(+), 15 deletions(-) >> >> >> >> diff --git a/drivers/phy/phy-exynos5-usbdrd.c >> >> b/drivers/phy/phy-exynos5-usbdrd.c >> >> index 47f47fe..85742b0 100644 >> >> --- a/drivers/phy/phy-exynos5-usbdrd.c >> >> +++ b/drivers/phy/phy-exynos5-usbdrd.c >> >> @@ -37,13 +37,11 @@ >> >> >> >> /* EXYNOS5: USB 3.0 DRD PHY registers */ >> >> #define EXYNOS5_DRD_LINKSYSTEM 0x04 >> >> - >> >> #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) >> >> #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) >> >> #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) >> >> >> >> #define EXYNOS5_DRD_PHYUTMI 0x08 >> >> - >> >> #define PHYUTMI_OTGDISABLE BIT(6) >> >> #define PHYUTMI_FORCESUSPEND BIT(1) >> >> #define PHYUTMI_FORCESLEEP BIT(0) >> >> @@ -51,26 +49,20 @@ >> >> #define EXYNOS5_DRD_PHYPIPE 0x0c >> >> >> >> #define EXYNOS5_DRD_PHYCLKRST0x10 >> >> - >> >> #define PHYCLKRST_EN_UTMISUSPEND BIT(31) >> >> - >> >> #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) >> >> #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) >> >> - >> >> #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) >> >> #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) >> >> - >> >> #define PHYCLKRST_SSC_EN BIT(20) >> >> #define PHYCLKRST_REF_SSP_EN BIT(19) >> >> #define PHYCLKRST_REF_CLKDIV2BIT(18) >> >> - >> >> #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) >> >> - >> >> #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) >> >> #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) >> >> #define PHYCLKRST_FSEL(_x) ((_x) << 5) >> >> @@ -78,46 +70,68 @@ >> >> #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) >> >> #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) >> >> #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) >> >> - >> >> #define PHYCLKRST_RETENABLEN BIT(4) >> >> - >> >> #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) >> >> #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) >> >> #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) >> >> - >> >> #define PHYCLKRST_PORTRESET BIT(1) >> >> #define PHYCLKRST_COMMONONN BIT(0) >> >> >> >> #define EXYNOS5_DRD_PHYREG0 0x14 >> >> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) >> >> +#define PHYREG0_SSC_RANGEBIT(20) >> >> +#define PHYREG0_CR_WRITE BIT(19) >> >> +#define PHYREG0_CR_READ BIT(18) >> >> +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) >> >> +#define PHYREG0_CR_CAP_DATA BIT(1) >> >> +#define PHYREG0_CR_CAP_ADDR BIT(0) >> >> + >> >> #define EXYNOS5_DRD_PHYREG1 0x18 >> >> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) >> >> +#define PHYREG1_CR_ACK BIT(0) >> >> >> >> #def
Re: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
Hi Pankaj
On Thu, 04 Sep 2014 10:15:27 +0530
Pankaj Dubey wrote:
> Hi Boris,
>
> On Wednesday, September 03, 2014 Boris BREZILLON wrote,
> > To: Arnd Bergmann
> > Cc: Pankaj Dubey; kgene@samsung.com; li...@arm.linux.org.uk; Alexander
> > Shiyan; naus...@samsung.com; Tomasz Figa; linux-ker...@vger.kernel.org;
> > jo...@samsung.com; linux-samsung-soc@vger.kernel.org;
> thomas...@samsung.com;
> > tomasz.f...@gmail.com; vikas.saj...@samsung.com; chow@samsung.com;
> > lee.jo...@linaro.org; Michal Simek; linux-arm-ker...@lists.infradead.org;
> Mark
> > Brown
> > Subject: Re: [PATCH v2] mfd: syscon: Decouple syscon interface from
> platform
> > devices
> >
> > On Wed, 03 Sep 2014 15:49:04 +0200
> > Arnd Bergmann wrote:
> >
> > > On Wednesday 03 September 2014 15:16:11 Boris BREZILLON wrote:
> > > > I checked that part, and it appears most of the code is already
> > > > there (see usage of regmap_attach_dev function here [1]).
> > > >
> > > > The only problem I see is that errors are still printed with
> > > > dev_err, which, AFAIK, will trigger a kernel panic if dev is NULL.
> > >
> > > Actually not:
> > >
> > > static int __dev_printk(const char *level, const struct device *dev,
> > > struct va_format *vaf) {
> > > if (!dev)
> > > return printk("%s(NULL device *): %pV", level, vaf);
> > >
> > > return dev_printk_emit(level[1] - '0', dev,
> > >"%s %s: %pV",
> > >dev_driver_string(dev), dev_name(dev),
> > > vaf); }
> > >
> >
> > My bad then (I don't know where I looked at to think NULL dev was not
> gracefully
> > handled :-)). Thanks for pointing this out.
> > Given that, I think it should work fine even with a NULL dev.
> > I'll give it a try on at91 ;-).
> >
>
> We have tested this patch, on Exynos board and found working well.
> In our use case DT based drivers such as USB Phy, SATA Phy, Watchdog are
> calling
> syscon_regmap_lookup_by APIs to get regmap handle to Exynos PMU and it
> worked
> well for these drivers.
Great!
>
> It would be great if after testing you share result here or give a
> Tested-By.
Yep, that's the idea.
Let me some time to rework the PMC drivers (drivers/clk/at91/pmc.c) and
test it, and I'll add my Tested-by ;-).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v2] mfd: syscon: Decouple syscon interface from platform devices
Thu, 04 Sep 2014 10:09:19 +0530 от Pankaj Dubey :
> Hi Arnd,
>
> On Tuesday, September 02, 2014 Arnd Bergmann wrote,
> > To: Pankaj Dubey
> > Cc: linux-arm-ker...@lists.infradead.org;
> linux-samsung-soc@vger.kernel.org; linux-
> > ker...@vger.kernel.org; lee.jo...@linaro.org; kgene@samsung.com;
> > li...@arm.linux.org.uk; vikas.saj...@samsung.com; jo...@samsung.com;
> > naus...@samsung.com; thomas...@samsung.com; chow@samsung.com;
> > tomasz.f...@gmail.com; Tomasz Figa; Alexander Shiyan; Michal Simek
> > Subject: Re: [PATCH v2] mfd: syscon: Decouple syscon interface from
> platform
> > devices
...
> > > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) -{
> > > - struct device *dev;
> > > - struct syscon *syscon;
> > > -
> > > - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
> > > - syscon_match_pdevname);
> > > - if (!dev)
> > > - return ERR_PTR(-EPROBE_DEFER);
> > > -
> > > - syscon = dev_get_drvdata(dev);
> > > -
> > > - return syscon->regmap;
> > > -}
> > > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
> >
> > I think this can actually be left intact if that helps with clps71xx.
> > It could be done in a hacky way using bus_find_device_by_name() to keep it
> simple,
> > or in a somewhat nicer way by keeping the syscon platform_driver around
> for the
> > non-DT case.
> >
>
> Ok as per our last discussion you mentioned that clps71xx will be soon
> migrating to DT.
> So if that is not going to happen sooner, I would also prefer better keep
> syscon_regmap_lookup_by_pdevname and syscon platform_driver for non-DT case,
> so that this issue should not block this patch.
>
> So please let's make final call to keep syscon platform_driver for non-DT
> case which eventually
> can be dropped once clps71xx driver migrates to DT based. So that I can
> prepare next patchset
> keeping syscon platform_driver support and syscon_regmap_lookup_by_pdevname
> API support
> for non-DT case and send across for review.
Arnd, can you force the applying of the latest clps711x patches to accelerate
the process?
I mean latest 3 arm-soc patches from Aug, 19.
After that I will need to make a patch for the SPI and TTY subsystems, then
initial DT
support will be introduced.
---
RE: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
Hi Boris,
On Wednesday, September 03, 2014 Boris BREZILLON wrote,
> To: Arnd Bergmann
> Cc: Pankaj Dubey; kgene@samsung.com; li...@arm.linux.org.uk; Alexander
> Shiyan; naus...@samsung.com; Tomasz Figa; linux-ker...@vger.kernel.org;
> jo...@samsung.com; linux-samsung-soc@vger.kernel.org;
thomas...@samsung.com;
> tomasz.f...@gmail.com; vikas.saj...@samsung.com; chow@samsung.com;
> lee.jo...@linaro.org; Michal Simek; linux-arm-ker...@lists.infradead.org;
Mark
> Brown
> Subject: Re: [PATCH v2] mfd: syscon: Decouple syscon interface from
platform
> devices
>
> On Wed, 03 Sep 2014 15:49:04 +0200
> Arnd Bergmann wrote:
>
> > On Wednesday 03 September 2014 15:16:11 Boris BREZILLON wrote:
> > > I checked that part, and it appears most of the code is already
> > > there (see usage of regmap_attach_dev function here [1]).
> > >
> > > The only problem I see is that errors are still printed with
> > > dev_err, which, AFAIK, will trigger a kernel panic if dev is NULL.
> >
> > Actually not:
> >
> > static int __dev_printk(const char *level, const struct device *dev,
> > struct va_format *vaf) {
> > if (!dev)
> > return printk("%s(NULL device *): %pV", level, vaf);
> >
> > return dev_printk_emit(level[1] - '0', dev,
> >"%s %s: %pV",
> >dev_driver_string(dev), dev_name(dev),
> > vaf); }
> >
>
> My bad then (I don't know where I looked at to think NULL dev was not
gracefully
> handled :-)). Thanks for pointing this out.
> Given that, I think it should work fine even with a NULL dev.
> I'll give it a try on at91 ;-).
>
We have tested this patch, on Exynos board and found working well.
In our use case DT based drivers such as USB Phy, SATA Phy, Watchdog are
calling
syscon_regmap_lookup_by APIs to get regmap handle to Exynos PMU and it
worked
well for these drivers.
It would be great if after testing you share result here or give a
Tested-By.
Thanks,
Pankaj Dubey
> Best Regards,
>
> Boris
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
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 v2] mfd: syscon: Decouple syscon interface from platform devices
Hi Arnd,
On Tuesday, September 02, 2014 Arnd Bergmann wrote,
> To: Pankaj Dubey
> Cc: linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org; linux-
> ker...@vger.kernel.org; lee.jo...@linaro.org; kgene@samsung.com;
> li...@arm.linux.org.uk; vikas.saj...@samsung.com; jo...@samsung.com;
> naus...@samsung.com; thomas...@samsung.com; chow@samsung.com;
> tomasz.f...@gmail.com; Tomasz Figa; Alexander Shiyan; Michal Simek
> Subject: Re: [PATCH v2] mfd: syscon: Decouple syscon interface from
platform
> devices
>
> On Tuesday 02 September 2014 20:12:15 Pankaj Dubey wrote:
> > Currently a syscon entity can only be registered directly through a
> > platform device that binds to a dedicated syscon driver. However in
> > certain cases it is required to bind a device with it's dedicated
> > driver rather than binding with syscon driver.
> >
> > For example, certain SoCs (e.g. Exynos) contain system controller
> > blocks which perform various functions such as power domain control,
> > CPU power management, low power mode control, but in addition contain
> > certain IP integration glue, such as various signal masks, coprocessor
> > power control, etc. In such case, there is a need to have a dedicated
> > driver for such system controller but also share registers with other
> > drivers. The latter is where the syscon interface is helpful.
> >
> > This patch decouples syscon object from syscon platform driver, and
> > allows to create syscon objects first time when it is required by
> > calling of syscon_regmap_lookup_by APIs and keeps a list of such
> > syscon objects along with syscon provider device_nodes and regmap
handles.
> >
> > Signed-off-by: Pankaj Dubey
> > Signed-off-by: Tomasz Figa
> > ---
> > V1 of this patchset [1] and related discussion can be found here [1].
> >
> > Changes since v1:
> > - Removed of_syscon_unregister function.
> > - Modified of_syscon_register function and it will be used by syscon.c
> >to create syscon objects whenever required.
> > - Removed platform device support from syscon.
> > - Removed syscon_regmap_lookup_by_pdevname API support.
> > - As there are significant changes w.r.t patchset v1, I am taking over
> >author for this patchset from Tomasz Figa.
>
> Note that you got the Signed-off-by: list wrong, you should never have any
people
> listed as Signed-off-by after your own name, and they should be listed
before your
> name only when you are forwarding their patches.
>
Sorry, I was not aware of this. I will take care in future.
> > Note: Current kernel has clps711x user of
> > syscon_regmap_lookup_by_pdevname and will be broken after this patch.
> > As per discussion over here [1], patches for making these drivers DT
> > based are ready and once that is done they can use
> syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible.
> >
> > [1]: https://lkml.org/lkml/2014/8/22/81
>
> Adding Alexander Shiyan to Cc here, so we can make sure this is well
coordinated.
>
> I'm also adding Michal Simek, since here was involved in earlier
discussions about
> doing this.
>
Thanks.
> > drivers/mfd/syscon.c | 143
+---
> > include/linux/mfd/syscon.h |1 +
> > 2 files changed, 44 insertions(+), 100 deletions(-)
>
> I certainly like the diffstat ;-)
>
> > struct syscon {
> > + struct device_node *np;
> > struct regmap *regmap;
> > + struct list_head list;
> > };
>
> Right
>
> > @@ -68,27 +72,6 @@ struct regmap
> > *syscon_regmap_lookup_by_compatible(const char *s) }
> > EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> >
> > -static int syscon_match_pdevname(struct device *dev, void *data) -{
> > - return !strcmp(dev_name(dev), (const char *)data);
> > -}
> > -
> > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) -{
> > - struct device *dev;
> > - struct syscon *syscon;
> > -
> > - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
> > -syscon_match_pdevname);
> > - if (!dev)
> > - return ERR_PTR(-EPROBE_DEFER);
> > -
> > - syscon = dev_get_drvdata(dev);
> > -
> > - return syscon->regmap;
> > -}
> > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
>
> I think this can actually be left intact if that helps with clps71xx.
> It could be done in a hacky way using bus_find_device_by_name() to keep it
simple,
> or in a somewhat nicer way by keeping the syscon platform_driver around
for the
> non-DT case.
>
Ok as per our last discussion you mentioned that clps71xx will be soon
migrating to DT.
So if that is not going to happen sooner, I would also prefer better keep
syscon_regmap_lookup_by_pdevname and syscon platform_driver for non-DT case,
so that this issue should not block this patch.
So please let's make final call to keep syscon platform_driver for non-DT
case which eventually
can be dropped once clps71xx driver migrates to DT based. So that I can
prepare next patchset
kee
[PATCH] [media] s5p_mfc: correct the loop condition
It should take ctx->dst_fmt->num_planes as
the loop condition for CAPTURE.
Signed-off-by: Zhaowei Yuan
---
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 9103258..af367c3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -990,7 +990,7 @@ static int s5p_mfc_buf_init(struct vb2_buffer *vb)
if (vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (ctx->capture_state == QUEUE_BUFS_MMAPED)
return 0;
- for (i = 0; i <= ctx->src_fmt->num_planes ; i++) {
+ for (i = 0; i < ctx->dst_fmt->num_planes; i++) {
if (IS_ERR_OR_NULL(ERR_PTR(
vb2_dma_contig_plane_dma_addr(vb, i
{
mfc_err("Plane mem not allocated\n");
--
1.7.9.5
--
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] [media] s5p_mfc: unify variable naming style
Variable frame_size represents the size of plane luminance
here, not just frame size, its naming style should be unified
as frame_size_ch and frame_size_mv.
Signed-off-by: Zhaowei Yuan
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index 58ec7bb..94023db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -377,7 +377,7 @@ static int s5p_mfc_set_dec_stream_buffer_v5(struct
s5p_mfc_ctx *ctx,
/* Set decoding frame buffer */
static int s5p_mfc_set_dec_frame_buffer_v5(struct s5p_mfc_ctx *ctx)
{
- unsigned int frame_size, i;
+ unsigned int frame_size_lu, i;
unsigned int frame_size_ch, frame_size_mv;
struct s5p_mfc_dev *dev = ctx->dev;
unsigned int dpb;
@@ -465,10 +465,10 @@ static int s5p_mfc_set_dec_frame_buffer_v5(struct
s5p_mfc_ctx *ctx)
ctx->codec_mode);
return -EINVAL;
}
- frame_size = ctx->luma_size;
+ frame_size_lu = ctx->luma_size;
frame_size_ch = ctx->chroma_size;
frame_size_mv = ctx->mv_size;
- mfc_debug(2, "Frm size: %d ch: %d mv: %d\n", frame_size, frame_size_ch,
+ mfc_debug(2, "Frm size: %d ch: %d mv: %d\n", frame_size_lu,
frame_size_ch,
frame_size_mv);
for (i = 0; i < ctx->total_dpb_count; i++) {
/* Bank2 */
@@ -496,7 +496,7 @@ static int s5p_mfc_set_dec_frame_buffer_v5(struct
s5p_mfc_ctx *ctx)
mfc_debug(2, "Not enough memory has been allocated\n");
return -ENOMEM;
}
- s5p_mfc_write_info_v5(ctx, frame_size, ALLOC_LUMA_DPB_SIZE);
+ s5p_mfc_write_info_v5(ctx, frame_size_lu, ALLOC_LUMA_DPB_SIZE);
s5p_mfc_write_info_v5(ctx, frame_size_ch, ALLOC_CHROMA_DPB_SIZE);
if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC)
s5p_mfc_write_info_v5(ctx, frame_size_mv, ALLOC_MV_SIZE);
--
1.7.9.5
--
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 13/15] drivers: sh: Leave disabling of unused PM domains to genpd
On Wed, Sep 03, 2014 at 12:52:29PM +0200, Ulf Hansson wrote:
> Since genpd at late init, will try to disable unused PM domains we
> don't need to do it from here as well.
>
> Cc: Simon Horman
> Cc: Magnus Damm
> Signed-off-by: Ulf Hansson
Acked-by: Simon Horman
> ---
> drivers/sh/pm_runtime.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
> index 72f6381..fe2c2d5 100644
> --- a/drivers/sh/pm_runtime.c
> +++ b/drivers/sh/pm_runtime.c
> @@ -75,8 +75,6 @@ static struct pm_clk_notifier_block platform_bus_notifier =
> {
> .con_ids = { NULL, },
> };
>
> -static bool default_pm_on;
> -
> static int __init sh_pm_runtime_init(void)
> {
> if (IS_ENABLED(CONFIG_ARCH_SHMOBILE_MULTI)) {
> @@ -96,16 +94,7 @@ static int __init sh_pm_runtime_init(void)
> return 0;
> }
>
> - default_pm_on = true;
> pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
> return 0;
> }
> core_initcall(sh_pm_runtime_init);
> -
> -static int __init sh_pm_runtime_late_init(void)
> -{
> - if (default_pm_on)
> - pm_genpd_poweroff_unused();
> - return 0;
> -}
> -late_initcall(sh_pm_runtime_late_init);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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 v2 7/7] Input: cros_ec_keyb: Optimize ghosting algorithm.
On Mon, Aug 25, 2014 at 03:40:08PM +0200, Javier Martinez Canillas wrote: > From: Todd Broch > > Previous algorithm was a bit conservative and complicating with > respect to identifying key ghosting. This CL uses the bitops hamming > weight function (hweight8) to count the number of matching rows for > colM & colN. If that number is > 1 ghosting is present. > > Additionally it removes NULL keys and our one virtual keypress > KEY_BATTERY from consideration as these inputs are never physical > keypresses. > > Signed-off-by: Todd Broch > Reviewed-by: Vincent Palatin > Reviewed-by: Luigi Semenzato > Tested-by: Andreas Färber > Signed-off-by: Javier Martinez Canillas Applied, thank you. -- Dmitry -- 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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Thomas, Thomas Abraham writes: [...] > A new branch [1] has been created using commits from exynos5-v3.17-rc1 > branch + cpufreq + regulator + temp fixes. I have tested this branch > on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand > and performance governors. Please let me know if there are any issues > with this new branch. It is based on v3.17-rc3. Excellent! Thank you. The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up. With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled? Thanks again for your work on this, we're getting close! Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279028.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
[PATCH 40/46] [media] marvel-ccic: just return 0 instead of using a var
Instead of allocating a var to store 0 and just return it,
change the code to return 0 directly.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c
b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 93f9cf2ebcd6..9d8d885558e5 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -313,7 +313,6 @@ static int isp_video_release(struct file *file)
struct fimc_is_video *ivc = &isp->video_capture;
struct media_entity *entity = &ivc->ve.vdev.entity;
struct media_device *mdev = entity->parent;
- int ret = 0;
mutex_lock(&isp->video_lock);
@@ -335,7 +334,7 @@ static int isp_video_release(struct file *file)
pm_runtime_put(&isp->pdev->dev);
mutex_unlock(&isp->video_lock);
- return ret;
+ return 0;
}
static const struct v4l2_file_operations isp_video_fops = {
--
1.9.3
--
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 v7 11/11] clk: rockchip: add restart handler
Quoting Guenter Roeck (2014-08-19 17:45:38)
> From: Heiko Stübner
>
> Add infrastructure to write the correct value to the restart register and
> register the restart notifier for both rk3188 (including rk3066) and rk3288.
>
> Signed-off-by: Heiko Stuebner
> Signed-off-by: Guenter Roeck
Acked-by: Mike Turquette
> ---
> v7: Added patch to series.
>
> drivers/clk/rockchip/clk-rk3188.c | 2 ++
> drivers/clk/rockchip/clk-rk3288.c | 2 ++
> drivers/clk/rockchip/clk.c| 25 +
> drivers/clk/rockchip/clk.h| 1 +
> 4 files changed, 30 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk-rk3188.c
> b/drivers/clk/rockchip/clk-rk3188.c
> index a83a6d8..71b661a 100644
> --- a/drivers/clk/rockchip/clk-rk3188.c
> +++ b/drivers/clk/rockchip/clk-rk3188.c
> @@ -631,6 +631,8 @@ static void __init rk3188_common_clk_init(struct
> device_node *np)
>
> rockchip_register_softrst(np, 9, reg_base + RK2928_SOFTRST_CON(0),
> ROCKCHIP_SOFTRST_HIWORD_MASK);
> +
> + rockchip_register_restart_notifier(RK2928_GLB_SRST_FST);
> }
>
> static void __init rk3066a_clk_init(struct device_node *np)
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c
> index 0d8c6c5..b604217 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -713,5 +713,7 @@ static void __init rk3288_clk_init(struct device_node *np)
>
> rockchip_register_softrst(np, 9, reg_base + RK3288_SOFTRST_CON(0),
> ROCKCHIP_SOFTRST_HIWORD_MASK);
> +
> + rockchip_register_restart_notifier(RK3288_GLB_SRST_FST);
> }
> CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init);
> diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
> index 278cf9d..aa41433 100644
> --- a/drivers/clk/rockchip/clk.c
> +++ b/drivers/clk/rockchip/clk.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include "clk.h"
>
> /**
> @@ -242,3 +243,27 @@ void __init rockchip_clk_register_branches(
> rockchip_clk_add_lookup(clk, list->id);
> }
> }
> +
> +static unsigned int reg_restart;
> +static int rockchip_restart_notify(struct notifier_block *this,
> + unsigned long mode, void *cmd)
> +{
> + writel(0xfdb9, reg_base + reg_restart);
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block rockchip_restart_handler = {
> + .notifier_call = rockchip_restart_notify,
> + .priority = 128,
> +};
> +
> +void __init rockchip_register_restart_notifier(unsigned int reg)
> +{
> + int ret;
> +
> + reg_restart = reg;
> + ret = register_restart_handler(&rockchip_restart_handler);
> + if (ret)
> + pr_err("%s: cannot register restart handler, %d\n",
> + __func__, ret);
> +}
> diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
> index 887cbde..0b5eab5 100644
> --- a/drivers/clk/rockchip/clk.h
> +++ b/drivers/clk/rockchip/clk.h
> @@ -329,6 +329,7 @@ void rockchip_clk_register_branches(struct
> rockchip_clk_branch *clk_list,
> unsigned int nr_clk);
> void rockchip_clk_register_plls(struct rockchip_pll_clock *pll_list,
> unsigned int nr_pll, int grf_lock_offset);
> +void rockchip_register_restart_notifier(unsigned int reg);
>
> #define ROCKCHIP_SOFTRST_HIWORD_MASK BIT(0)
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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 v7 10/11] clk: samsung: register restart handlers for s3c2412 and s3c2443
Quoting Guenter Roeck (2014-08-19 17:45:37)
> From: Heiko Stübner
>
> S3C2412, S3C2443 and their derivatives contain a special software-reset
> register in their system-controller.
>
> Therefore register a restart handler for those.
>
> Tested on a s3c2416-based board, s3c2412 compile-tested.
>
> Signed-off-by: Heiko Stuebner
> Signed-off-by: Guenter Roeck
Acked-by: Mike Turquette
> ---
> v7: Added patch to series.
>
> drivers/clk/samsung/clk-s3c2412.c | 29 +
> drivers/clk/samsung/clk-s3c2443.c | 19 +++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-s3c2412.c
> b/drivers/clk/samsung/clk-s3c2412.c
> index 34af09f..2ceedaf 100644
> --- a/drivers/clk/samsung/clk-s3c2412.c
> +++ b/drivers/clk/samsung/clk-s3c2412.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -26,6 +27,7 @@
> #define CLKCON 0x0c
> #define CLKDIVN0x14
> #define CLKSRC 0x1c
> +#define SWRST 0x30
>
> /* list of PLLs to be registered */
> enum s3c2412_plls {
> @@ -204,6 +206,28 @@ struct samsung_clock_alias s3c2412_aliases[] __initdata
> = {
> ALIAS(MSYSCLK, NULL, "fclk"),
> };
>
> +static int s3c2412_restart(struct notifier_block *this,
> + unsigned long mode, void *cmd)
> +{
> + /* errata "Watch-dog/Software Reset Problem" specifies that
> +* this reset must be done with the SYSCLK sourced from
> +* EXTCLK instead of FOUT to avoid a glitch in the reset
> +* mechanism.
> +*
> +* See the watchdog section of the S3C2412 manual for more
> +* information on this fix.
> +*/
> +
> + __raw_writel(0x00, reg_base + CLKSRC);
> + __raw_writel(0x533C2412, reg_base + SWRST);
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block s3c2412_restart_handler = {
> + .notifier_call = s3c2412_restart,
> + .priority = 129,
> +};
> +
> /*
> * fixed rate clocks generated outside the soc
> * Only necessary until the devicetree-move is complete
> @@ -233,6 +257,7 @@ void __init s3c2412_common_clk_init(struct device_node
> *np, unsigned long xti_f,
> unsigned long ext_f, void __iomem *base)
> {
> struct samsung_clk_provider *ctx;
> + int ret;
> reg_base = base;
>
> if (np) {
> @@ -267,6 +292,10 @@ void __init s3c2412_common_clk_init(struct device_node
> *np, unsigned long xti_f,
> s3c2412_clk_sleep_init();
>
> samsung_clk_of_add_provider(np, ctx);
> +
> + ret = register_restart_handler(&s3c2412_restart_handler);
> + if (ret)
> + pr_warn("cannot register restart handler, %d\n", ret);
> }
>
> static void __init s3c2412_clk_init(struct device_node *np)
> diff --git a/drivers/clk/samsung/clk-s3c2443.c
> b/drivers/clk/samsung/clk-s3c2443.c
> index c92f853..0c3c182 100644
> --- a/drivers/clk/samsung/clk-s3c2443.c
> +++ b/drivers/clk/samsung/clk-s3c2443.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -33,6 +34,7 @@
> #define HCLKCON0x30
> #define PCLKCON0x34
> #define SCLKCON0x38
> +#define SWRST 0x44
>
> /* the soc types */
> enum supported_socs {
> @@ -354,6 +356,18 @@ struct samsung_clock_alias s3c2450_aliases[] __initdata
> = {
> ALIAS(PCLK_I2C1, "s3c2410-i2c.1", "i2c"),
> };
>
> +static int s3c2443_restart(struct notifier_block *this,
> + unsigned long mode, void *cmd)
> +{
> + __raw_writel(0x533c2443, reg_base + SWRST);
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block s3c2443_restart_handler = {
> + .notifier_call = s3c2443_restart,
> + .priority = 129,
> +};
> +
> /*
> * fixed rate clocks generated outside the soc
> * Only necessary until the devicetree-move is complete
> @@ -378,6 +392,7 @@ void __init s3c2443_common_clk_init(struct device_node
> *np, unsigned long xti_f,
> void __iomem *base)
> {
> struct samsung_clk_provider *ctx;
> + int ret;
> reg_base = base;
>
> if (np) {
> @@ -447,6 +462,10 @@ void __init s3c2443_common_clk_init(struct device_node
> *np, unsigned long xti_f,
> s3c2443_clk_sleep_init();
>
> samsung_clk_of_add_provider(np, ctx);
> +
> + ret = register_restart_handler(&s3c2443_restart_handler);
> + if (ret)
> + pr_warn("cannot register restart handler, %d\n", ret);
> }
>
> static void __init s3c2416_clk_init(struct device_node *np)
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lk
Re: [PATCH v2 5/7] arm64: dts: Add initial device tree support for EXYNOS7
On Thursday 04 September 2014 01:31:21 Kukjin Kim wrote:
> > This is the board specific file, so it seems ok.
> >
> I mean there are many espresso boards are having different exynos7
> SoC. I mean exynos7-espresso cannot represent all of espresso boards.
>
Ah, I see, that makes sense.
We definitely need a top-level .dts file for each board that is different
in a nondiscoverable way then.
If the mmc settings and possibly some other nodes (to be added later)
are common across them, those can be in a board specific .dtsi file.
For the memory node, I would actually expect that to be filled by
the boot loader, so we could leave it out entirely. The same applies
to the command line: the parts that are in there at the moment (
"console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x4200,16M")
clearly don't belong into a generic dts file and none of them should be
set that way.
For the initial version, that would mean that the file comes down to having
as its only contents
/dts-v1/;
#include
#include "exynos7123.dtsi"
#include "exynos7-espresso.dtsi" // for the mmc nodes
/ {
model = "Samsung ESPRESSO board based on EXYNOS7123";
compatible = "samsung,espresso", "samsung,exynos7123", "samsung,exynos7";
};
One more thing I just noticed is the GPL statement in the dts files.
Can we please change that to a permissive license in order to allow
including it in non-GPL boot loaders and operating systems?
Dual GPL+MIT or GPL+BSD would make most sense here.
Arnd
--
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 v2 5/7] arm64: dts: Add initial device tree support for EXYNOS7
Arnd Bergmann wrote:
>
Hi, Arnd
> On Thursday 04 September 2014 01:15:20 Kukjin Kim wrote:
> > Naveen Krishna Chatradhi wrote:
> >
> > > diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> > > b/arch/arm64/boot/dts/exynos/exynos7-
> > > espresso.dts
> > > new file mode 100644
> > > index 000..f6a8879
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> > > @@ -0,0 +1,31 @@
> > > +/*
> > > + * SAMSUNG Exynos7 Espresso board device tree source
> > > + *
> > > + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> > > + * http://www.samsung.com
> > > + *
> > > + * 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.
> > > +*/
> > > +
> > > +/dts-v1/;
> > > +#include "exynos7.dtsi"
> > > +
> > > +/ {
> > > + model = "Samsung Exynos7 Espresso board based on EXYNOS7";
> > > + compatible = "samsung,exynos7-espresso", "samsung,exynos7";
> > > +
> > > + chosen {
> > > + linux,stdout-path = &serial_2;
> >
> > Well...
> >
> > > + };
> > > +
> > > + memory@4000 {
> > > + device_type = "memory";
> > > + reg = <0x0 0x4000 0x0 0xC000>;
> >
> > The base address of system memory is depending on each board, actually some
> > of
> > them are 0x2000.
>
> This is the board specific file, so it seems ok.
>
I mean there are many espresso boards are having different exynos7 SoC. I mean
exynos7-espresso cannot represent all of espresso boards.
- Kukjin
--
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/1] ARM: exynos_defconfig: Enable options for display panel support
Javier Martinez Canillas wrote: > > Many Exynos devices have a display panel, most of them just have > a simple panel while others have more complex configurations that > requires an embedded DisplayPort (eDP) to LVDS display bridge. > > This patch enables the following features to support both setups: > > - Direct Rendering Manager (DRM) > - DRM bridge registration and lookup framework > - Parade ps8622/ps8625 eDP/LVDS bridge > - NXP ptn3460 eDP/LVDS bridge > - Exynos Fully Interactive Mobile Display controller (FIMD) > - Panel registration and lookup framework > - Simple panels > - Backlight and LCD device support > Thanks a lot. > Signed-off-by: Javier Martinez Canillas > --- > > Some of the options enabled here (e.g: the eDP/LVDS bridges) > are still not merged in mainline so this patch depends on > the following posted patches that were still not merged: > > "drm/bridge: Modify drm_bridge core to support driver model" [0] > "drm/bridge: Add i2c based driver for ptn3460 bridge" [1] > "drm/bridge: Add i2c based driver for ps8622/ps8625 bridge" [2] > BTW, I can't find its re-spin...how was going on? > But I wanted to post anyways to make easier for others to > figure out what are the needed options to have the display > working on their Exynos machines. > > In order to test the display panel on the Peach machines, > the following patches are also needed: > > "ARM: dts: Add DT changes for display on peach_pit" [3] > "ARM: dts: Add DT changes for display on peach_pi" [4] > I'll have a look them soon. - Kukjin > Best regards, > Javier > > [0]: http://patchwork.ozlabs.org/patch/373792/ > [1]: http://patchwork.ozlabs.org/patch/373793/ > [2]: http://patchwork.ozlabs.org/patch/373794/ > [3]: http://www.spinics.net/lists/arm-kernel/msg350568.html > [4]: http://www.spinics.net/lists/arm-kernel/msg350569.html > > arch/arm/configs/exynos_defconfig | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 676c744..f69d57e 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -101,11 +101,25 @@ CONFIG_REGULATOR_S2MPA01=y > CONFIG_REGULATOR_S2MPS11=y > CONFIG_REGULATOR_S5M8767=y > CONFIG_REGULATOR_TPS65090=y > +CONFIG_DRM=y > +CONFIG_DRM_BRIDGE=y > +CONFIG_DRM_PS8622=y > +CONFIG_DRM_EXYNOS=y > +CONFIG_DRM_EXYNOS_FIMD=y > +CONFIG_DRM_EXYNOS_DP=y > +CONFIG_DRM_PANEL=y > +CONFIG_DRM_PANEL_SIMPLE=y > CONFIG_FB=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_FB_SIMPLE=y > CONFIG_EXYNOS_VIDEO=y > CONFIG_EXYNOS_MIPI_DSI=y > +CONFIG_BACKLIGHT_LCD_SUPPORT=y > +CONFIG_LCD_CLASS_DEVICE=y > +CONFIG_LCD_PLATFORM=y > +CONFIG_BACKLIGHT_CLASS_DEVICE=y > +CONFIG_BACKLIGHT_GENERIC=y > +CONFIG_BACKLIGHT_PWM=y > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FONTS=y > CONFIG_FONT_7x14=y > -- > 2.0.1 -- 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 v2 5/7] arm64: dts: Add initial device tree support for EXYNOS7
On Thursday 04 September 2014 01:15:20 Kukjin Kim wrote:
> Naveen Krishna Chatradhi wrote:
>
> > diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> > b/arch/arm64/boot/dts/exynos/exynos7-
> > espresso.dts
> > new file mode 100644
> > index 000..f6a8879
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> > @@ -0,0 +1,31 @@
> > +/*
> > + * SAMSUNG Exynos7 Espresso board device tree source
> > + *
> > + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> > + * http://www.samsung.com
> > + *
> > + * 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.
> > +*/
> > +
> > +/dts-v1/;
> > +#include "exynos7.dtsi"
> > +
> > +/ {
> > + model = "Samsung Exynos7 Espresso board based on EXYNOS7";
> > + compatible = "samsung,exynos7-espresso", "samsung,exynos7";
> > +
> > + chosen {
> > + linux,stdout-path = &serial_2;
>
> Well...
>
> > + };
> > +
> > + memory@4000 {
> > + device_type = "memory";
> > + reg = <0x0 0x4000 0x0 0xC000>;
>
> The base address of system memory is depending on each board, actually some of
> them are 0x2000.
This is the board specific file, so it seems ok.
> > +#include
> > +
> > +/ {
> > + compatible = "samsung,exynos7";
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + aliases {
> > + serial0 = &serial_0;
> > + serial1 = &serial_1;
> > + serial2 = &serial_2;
> > + serial3 = &serial_3;
>
> There are exynos7 SoC is having 3 serial IPs...
These aliases should just go into the board file as well, and
since it seems to have only one uart, the best way is to list
that as serial0:
serial0 = &serial_2;
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + soc: soc {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0 0 0x1800>;
> > +
> > + chipid@1000 {
> > + compatible = "samsung,exynos4210-chipid";
> > + reg = <0x1000 0x100>;
> > + };
> > +
> > + fin_pll: xxti {
> > + compatible = "fixed-clock";
> > + clock-frequency = <2400>;
>
> It's wrong on some exynos7 SoCs...
>
Is this an external clock input? If so, the frequency should
also go into the board file, otherwise into the soc-specific
one.
Arnd
--
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 v2 5/7] arm64: dts: Add initial device tree support for EXYNOS7
Naveen Krishna Chatradhi wrote:
>
> Add initial device tree nodes for EXYNOS7 SoC and board dts file
> to support Espresso board based on Exynos7 SoC.
>
> Signed-off-by: Naveen Krishna Chatradhi
> Cc: Rob Herring
> Cc: Catalin Marinas
NAK.
There are several exynos7 SoCs which cannot be supported with one dt file. I
mean just one exynos7 cannot represent all of exynos7 SoCs...
> ---
> arch/arm64/boot/dts/Makefile|1 +
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 31 +
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 168
> +++
> 3 files changed, 200 insertions(+)
> create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index c52bdb0..a3bc18a 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,3 +1,4 @@
> +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos/exynos7-espresso.dtb
> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> b/arch/arm64/boot/dts/exynos/exynos7-
> espresso.dts
> new file mode 100644
> index 000..f6a8879
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -0,0 +1,31 @@
> +/*
> + * SAMSUNG Exynos7 Espresso board device tree source
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * 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.
> +*/
> +
> +/dts-v1/;
> +#include "exynos7.dtsi"
> +
> +/ {
> + model = "Samsung Exynos7 Espresso board based on EXYNOS7";
> + compatible = "samsung,exynos7-espresso", "samsung,exynos7";
> +
> + chosen {
> + linux,stdout-path = &serial_2;
Well...
> + };
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0x0 0x4000 0x0 0xC000>;
The base address of system memory is depending on each board, actually some of
them are 0x2000.
> + };
> +};
> +
> +&serial_2 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> new file mode 100644
> index 000..e593af55
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -0,0 +1,168 @@
> +/*
> + * SAMSUNG EXYNOS7 SoC device tree source
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * 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
> +
> +/ {
> + compatible = "samsung,exynos7";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &serial_0;
> + serial1 = &serial_1;
> + serial2 = &serial_2;
> + serial3 = &serial_3;
There are exynos7 SoC is having 3 serial IPs...
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x0>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x1>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x2>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + enable-method = "psci";
> + reg = <0x3>;
> + };
> + };
Naveen, please don't assume all of exynos7 SoCs are having quad a57s...
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0 0x1800>;
> +
> + chipid@1000 {
> + compatible = "samsung,exynos4210-chipid";
> + reg = <0x1000 0x100>;
> + };
> +
> + fin_pll: xxti {
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Wed, Sep 03, 2014 at 09:32:14AM +0530, Vivek Gautam wrote: > On Tue, Sep 2, 2014 at 8:07 PM, Felipe Balbi wrote: > > On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: > >> On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi wrote: > >> > 2014-08-28 10:02 GMT+02:00 Vivek Gautam: > >> > > >> >> This USB 3.0 PHY controller is also present on Exynos7 > >> >> platform, so adding the dependency on ARCH_EXYNOS7 for this driver. > >> > > >> >> +++ b/drivers/phy/Kconfig > >> >> @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 > >> >> > >> >> config PHY_EXYNOS5_USBDRD > >> >> tristate "Exynos5 SoC series USB DRD PHY driver" > >> >> - depends on ARCH_EXYNOS5 && OF > >> >> + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF > >> > > >> > shouldn't that prompt and its help text be updated to mention also > >> > Exynos7? > >> > >> Right, even that has to be updated accordingly. Will update the same in > >> next > >> version of the patch. Thanks for pointing this. > > > > I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like > > that idea. The thing is that this will likely need to be patches for > > exynos8, 9, 10, 11... > > Yes, after we have the 2nd version of Exynos7 support patches, it makes > more sense to keep dependency on ARCH_EXYNOS. thank you, that'll help new silicon wakeup; one less thing to patch :-p -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Wed, Sep 03, 2014 at 12:59:27PM +0530, Vivek Gautam wrote: > > On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: > >> Adding phy calibrate callback, which facilitates setting certain > >> PHY settings post initialization of the PHY controller. > >> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which > >> the Loss-of-Signal (LOS) Detector Threshold Level as well as > >> Tx-Vboost-Level should be controlled for Super-Speed operations. > >> > >> Additionally set proper time to wait for RxDetect measurement, > >> for desired PHY reference clock, so as to solve issue with enumeration > >> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive > >> on the controller. > >> We are using CR_port for this purpose to send required data > >> to override the LOS values. > >> > >> On testing with USB 3.0 devices on USB 3.0 port present on > >> SMDK5420, and peach-pit boards should see following message: > >> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd > >> > >> and without this patch, should see below shown message: > >> usb 1-1: new high-speed USB device number 2 using xhci-hcd > >> > >> [Also removed unnecessary extra lines in the register macro definitions] > >> > >> Signed-off-by: Vivek Gautam > >> --- > >> drivers/phy/phy-exynos5-usbdrd.c | 185 > >> ++ > >> 1 file changed, 170 insertions(+), 15 deletions(-) > >> > >> diff --git a/drivers/phy/phy-exynos5-usbdrd.c > >> b/drivers/phy/phy-exynos5-usbdrd.c > >> index 47f47fe..85742b0 100644 > >> --- a/drivers/phy/phy-exynos5-usbdrd.c > >> +++ b/drivers/phy/phy-exynos5-usbdrd.c > >> @@ -37,13 +37,11 @@ > >> > >> /* EXYNOS5: USB 3.0 DRD PHY registers */ > >> #define EXYNOS5_DRD_LINKSYSTEM 0x04 > >> - > >> #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) > >> #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) > >> #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) > >> > >> #define EXYNOS5_DRD_PHYUTMI 0x08 > >> - > >> #define PHYUTMI_OTGDISABLE BIT(6) > >> #define PHYUTMI_FORCESUSPEND BIT(1) > >> #define PHYUTMI_FORCESLEEP BIT(0) > >> @@ -51,26 +49,20 @@ > >> #define EXYNOS5_DRD_PHYPIPE 0x0c > >> > >> #define EXYNOS5_DRD_PHYCLKRST0x10 > >> - > >> #define PHYCLKRST_EN_UTMISUSPEND BIT(31) > >> - > >> #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) > >> #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) > >> - > >> #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) > >> #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) > >> - > >> #define PHYCLKRST_SSC_EN BIT(20) > >> #define PHYCLKRST_REF_SSP_EN BIT(19) > >> #define PHYCLKRST_REF_CLKDIV2BIT(18) > >> - > >> #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) > >> - > >> #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) > >> #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) > >> #define PHYCLKRST_FSEL(_x) ((_x) << 5) > >> @@ -78,46 +70,68 @@ > >> #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) > >> #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) > >> #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) > >> - > >> #define PHYCLKRST_RETENABLEN BIT(4) > >> - > >> #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) > >> #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) > >> #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) > >> - > >> #define PHYCLKRST_PORTRESET BIT(1) > >> #define PHYCLKRST_COMMONONN BIT(0) > >> > >> #define EXYNOS5_DRD_PHYREG0 0x14 > >> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) > >> +#define PHYREG0_SSC_RANGEBIT(20) > >> +#define PHYREG0_CR_WRITE BIT(19) > >> +#define PHYREG0_CR_READ BIT(18) > >> +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) > >> +#define PHYREG0_CR_CAP_DATA BIT(1) > >> +#define PHYREG0_CR_CAP_ADDR BIT(0) > >> + > >> #define EXYNOS5_DRD_PHYREG1 0x18 > >> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) > >> +#define PHYREG1_CR_ACK BIT(0) > >> > >> #define EXYNOS5_DRD_PHYPARAM00x1c > >> - > >> #define PHYPARAM0_REF_USE_PADBIT(31) > >> #define PHYPARAM0_REF_LOSLE
Re: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
On Wed, 03 Sep 2014 15:49:04 +0200
Arnd Bergmann wrote:
> On Wednesday 03 September 2014 15:16:11 Boris BREZILLON wrote:
> > I checked that part, and it appears most of the code is already there
> > (see usage of regmap_attach_dev function here [1]).
> >
> > The only problem I see is that errors are still printed with dev_err,
> > which, AFAIK, will trigger a kernel panic if dev is NULL.
>
> Actually not:
>
> static int __dev_printk(const char *level, const struct device *dev,
> struct va_format *vaf)
> {
> if (!dev)
> return printk("%s(NULL device *): %pV", level, vaf);
>
> return dev_printk_emit(level[1] - '0', dev,
>"%s %s: %pV",
>dev_driver_string(dev), dev_name(dev), vaf);
> }
>
My bad then (I don't know where I looked at to think NULL dev was not
gracefully handled :-)). Thanks for pointing this out.
Given that, I think it should work fine even with a NULL dev.
I'll give it a try on at91 ;-).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: [PATCHv6 0/2] thermal: exynos: Add support for TRIMINFO feature of Exynos3250
Dear Eduardo, On 08/30/2014 11:39 AM, Eduardo Valentin wrote: > Hi, > > On Wed, Sep 03, 2014 at 12:09:01PM +0900, Chanwoo Choi wrote: >> This patchset add the support of TRIMINFO_RELOAD feature for Exynos3250. >> But Exynos3250 has two TRIMINFO_CTRL register instead other Exynos has only >> one >> TRIMINFO_CTRL register. So, this patchset support the some Exynos SoC which >> has more than one TRIMINF_CTRL. >> >> Also, this patchset fix wrong value of TRIMINFO_RELOAD_SHIFT and remove >> duplicate code when reading triminfo register of Exynos5440. >> >> Changes from v5: >> - Rebase this patchset on next branch of linux-soc-thermal.git >> > > Pulled into my next branch. Thanks. Thanks. Best Regards, Chanwoo Choi -- 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] ARM: dts: exynos4x12: Fix pull setting in sd4_width8 pin group
Tomasz Figa wrote:
>
> The group has the samsung,pin-pud property set to 4, which is not a
> correct value. This patch fixes this by replacing it with 3, which is
> the correct value for pull-up.
>
Yes, I checked the value. You're right.
Will apply into fixes.
Thanks,
Kukjin
> Signed-off-by: Tomasz Figa
> ---
> arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
> b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
> index 927fec6..c141931 100644
> --- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
> @@ -691,7 +691,7 @@
> sd4_bus8: sd4-bus-width8 {
> samsung,pins = "gpk1-3", "gpk1-4", "gpk1-5", "gpk1-6";
> samsung,pin-function = <4>;
> - samsung,pin-pud = <4>;
> + samsung,pin-pud = <3>;
> samsung,pin-drv = <3>;
> };
>
> --
> 2.0.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 v2] mfd: syscon: Decouple syscon interface from platform devices
On Wednesday 03 September 2014 15:16:11 Boris BREZILLON wrote:
> I checked that part, and it appears most of the code is already there
> (see usage of regmap_attach_dev function here [1]).
>
> The only problem I see is that errors are still printed with dev_err,
> which, AFAIK, will trigger a kernel panic if dev is NULL.
Actually not:
static int __dev_printk(const char *level, const struct device *dev,
struct va_format *vaf)
{
if (!dev)
return printk("%s(NULL device *): %pV", level, vaf);
return dev_printk_emit(level[1] - '0', dev,
"%s %s: %pV",
dev_driver_string(dev), dev_name(dev), vaf);
}
Arnd
--
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: [RESEND PATCH v4 2/2] ARM: EXYNOS: Refactor the pm code to use DT based lookup
Vikas Sajjan wrote: > > Hi, > Hi, Sorry for late response... > On Tue, Aug 19, 2014 at 3:05 PM, Bartlomiej Zolnierkiewicz > wrote: > > > > Hi, > > > > On Tuesday, August 19, 2014 01:26:49 PM Vikas Sajjan wrote: > >> Hi Kukjin, > >> > >> On Tue, Aug 19, 2014 at 12:22 PM, Vikas Sajjan > >> wrote: > >> > Refactoring the pm.c to avoid using "soc_is_exynos" checks, > >> > instead use the DT based lookup. > >> > > >> > While at it, consolidate the common code across SoCs > >> > and create static helper functions. > >> > > >> > Signed-off-by: Vikas Sajjan > >> > Reviewed-by: Tomasz Figa > >> > >> Can you pick this series... > > > > I think that my PM_SLEEP=n build fixes should go in before this cleanup > > series: > > Its better for Kukjin to decide which series he wants to pick first. > Hmm...I need to have a look at the Bart's fix then I'll let you know. Maybe tomorrow morning ;) > > > > > > > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35430.html > > - Kukjin -- 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: [PATCHv6 0/2] thermal: exynos: Add support for TRIMINFO feature of Exynos3250
Hi,
On Wed, Sep 03, 2014 at 12:09:01PM +0900, Chanwoo Choi wrote:
> This patchset add the support of TRIMINFO_RELOAD feature for Exynos3250.
> But Exynos3250 has two TRIMINFO_CTRL register instead other Exynos has only
> one
> TRIMINFO_CTRL register. So, this patchset support the some Exynos SoC which
> has more than one TRIMINF_CTRL.
>
> Also, this patchset fix wrong value of TRIMINFO_RELOAD_SHIFT and remove
> duplicate code when reading triminfo register of Exynos5440.
>
> Changes from v5:
> - Rebase this patchset on next branch of linux-soc-thermal.git
>
Pulled into my next branch. Thanks.
> Changes from v4:
> - Remove un-necessary triminfo_ctrl_{shift, mask} field
> - Includes Bartlomiej's patch[1] that Exynos5260 / Exynos5420 should not use
> TRIM_RELOAD flag
> [2] https://lkml.org/lkml/2014/8/20/481
>
> Changes from v3:
> - Add reviewed message of Amit Daniel Kachhap
> - Split RELOAD patch as two patch
> - Fix 'TRIMINFO_RELOAD_SHIFT' value
> - This series includes separate patch[1]
> [1] https://lkml.org/lkml/2014/8/20/5
> - Drop ACTIME bit setting because TRM includes not enough information of
> ACTIME bit.
>
> Changes from v2:
> - Fix build break because of missing 'or' operation.
>
> Changes from v1:
> - Add missing 'TMU_SUPPORT_TRIM_RELOAD' features
>
> Chanwoo Choi (2):
> thermal: exynos: Add support for many TRIMINFO_CTRL registers
> thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
>
> drivers/thermal/samsung/exynos_thermal_common.h | 1 +
> drivers/thermal/samsung/exynos_tmu.c| 15 ---
> drivers/thermal/samsung/exynos_tmu.h| 7 +--
> drivers/thermal/samsung/exynos_tmu_data.c | 11 +--
> drivers/thermal/samsung/exynos_tmu_data.h | 8 ++--
> 5 files changed, 33 insertions(+), 9 deletions(-)
>
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" 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 14/15] PM / Domains: Remove default_stop_ok() API
Hi Ulf,
On Wed, Sep 3, 2014 at 12:52 PM, Ulf Hansson wrote:
> --- a/drivers/base/power/domain_governor.c
> +++ b/drivers/base/power/domain_governor.c
> @@ -229,10 +229,7 @@ static bool always_on_power_down_ok(struct dev_pm_domain
> *domain)
>
> #else /* !CONFIG_PM_RUNTIME */
>
> -bool default_stop_ok(struct device *dev)
> -{
> - return false;
> -}
> +static inline bool default_stop_ok(struct device *dev) { return false; }
The "inline" doesn't make much sense here. This function is only
referenced from places that need its address:
struct dev_power_governor simple_qos_governor = {
.stop_ok = default_stop_ok,
.power_down_ok = default_power_down_ok,
};
and
struct dev_power_governor pm_domain_always_on_gov = {
.power_down_ok = always_on_power_down_ok,
.stop_ok = default_stop_ok,
};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
On Wed, Sep 3, 2014 at 9:56 AM, Thomas Abraham wrote: > Hi Kevin, > > On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman wrote: >> HI Thomas, >> >> Thomas Abraham writes: >> >>> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham wrote: > Hi Kevin, > > On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman wrote: >> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman wrote: >>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap >>> wrote: >> >> [...] >> > > Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ >>> >>> Thanks. >>> >>> I've applied your patch, and bootup shows vdd_arm and vdd_kfc at >>> 1500mV, but still when booting with cpuidle enabled (bL switcher >>> disabled), I'm seeing lockups with no kernel output. With CPUidle >>> disabled, things are pretty stable. >>> >>> What tree are you using to test this out on 5420? I'm using mainline >>> v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my >>> wip/exynos/integ branch at >>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. >> >> I mis-stated this. Actually my tree is based on the v3.17-rc1 branch >> of the exynos-reference tree[1] + the above mentioned patches for >> cpuidle and cpufreq. >> >> Also, I've narrowed down the instability a bit, and it's not related >> to CPUidle. I can now trigger a boot hang even without CPUidle >> enabled. Here's a quick way to cause a boot lockup. With the switcher >> disabled, I enable CPUfreq and set the default governor to >> performance. As soon as cpufreq driver loads, it tries to use the top >> frequences for both clusters, and it hangs. >> >> Selectively disabling frequencies, I narrowed it down to the 1.3GHz >> and 1.2GHz frequencies of the little cluster. With these commented >> out in the DT, it will fully boot with the performance governor >> enabled. >> >> So that leads to the question. Are all of the operating points in >> exynos5420.dtsi valid for exynos5800, and have they been validated? > > I tried to recreate the boot lockup issue using the same steps you > listed above for the Exynos5800 peach-pi platform (Chromebook2), but I > do not see any issues. I can see both clusters with max clock speed > after boot (1.8GHz and 1.3GHz). > > I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support > patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 > voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. >>> >>> The branch with the patches that have been used to test cpufreq on >>> Exynos5800 is available at >>> >>> https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq >>> >>> Please let me know if this works or if there are any issues. >> >> Yes, your branch works fine, but it's because of the last (unposted) >> patch on your branch[1]: >> ARM: dts: remove all supplies sourced from tps65090 PMIC > > I must have explicitly stated that I am using local changes to get > vdd_arm and vdd_kfc to required levels. I apologize for that. These > are local temporary changes which I did not want to post. I am working > on adding voltage scaling support in arm bL cpufreq driver with which > these local hacks would not be necessary. > >> >> That patch had not been posted, so I hadn't seen it before, but based on >> the changelog, it's pretty clear you had the same problems that I had >> without it, so I'm not sure why it wasn't mentioned earlier in this >> thread. > > At the time of posting, this patch series was only tested on > Exynos5420 based smdk5420 board. There was no regulator support for > peach-pit and peach-pi at that time and so I had not tested this > series on Exynos5800 Chromebook2. But the code was written to be fully > compatible for Exynos5800 as well. It was when you reported a problem > with Exynos5800 that I tested this series on Exynos5800 with the > regulator patches from Javier. > >> >> I also noticed that the "force vdd_arm and vdd_kfc to max voltage" patch >> is not actually using the max voltage, which appears to be 1.5V from the >> DT, but actually using 1.35 V, however the changelog has no explanation >> for this. > > This also is a temporary patch and by "max voltage" I actually meant > max voltage required to operate the cpus and not the max voltage that > the buck can supply. > >> >> One other thing, your temp-cpufreq
Re: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
Hi,
I'm joining the thread cause I'm really interested in having a syscon
dev available during early init (I need it to share at91 PMC
registers among several subsystems, one of this subsystem being the CCF
which is called during early ARM boot process to register system
clocks).
On Tue, 02 Sep 2014 17:20:03 +0200
Arnd Bergmann wrote:
> On Tuesday 02 September 2014 20:12:15 Pankaj Dubey wrote:
> > Currently a syscon entity can only be registered directly through a
> > platform device that binds to a dedicated syscon driver. However in
> > certain cases it is required to bind a device with it's dedicated
> > driver rather than binding with syscon driver.
> >
> > For example, certain SoCs (e.g. Exynos) contain system controller
> > blocks which perform various functions such as power domain control,
> > CPU power management, low power mode control, but in addition contain
> > certain IP integration glue, such as various signal masks,
> > coprocessor power control, etc. In such case, there is a need to have
> > a dedicated driver for such system controller but also share registers
> > with other drivers. The latter is where the syscon interface is helpful.
> >
> > This patch decouples syscon object from syscon platform driver, and
> > allows to create syscon objects first time when it is required by
> > calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon
> > objects along with syscon provider device_nodes and regmap handles.
> >
> > Signed-off-by: Pankaj Dubey
> > Signed-off-by: Tomasz Figa
> > ---
> > V1 of this patchset [1] and related discussion can be found here [1].
> >
> > Changes since v1:
> > - Removed of_syscon_unregister function.
> > - Modified of_syscon_register function and it will be used by syscon.c
> >to create syscon objects whenever required.
> > - Removed platform device support from syscon.
> > - Removed syscon_regmap_lookup_by_pdevname API support.
> > - As there are significant changes w.r.t patchset v1, I am taking over
> >author for this patchset from Tomasz Figa.
>
> Note that you got the Signed-off-by: list wrong, you should never have
> any people listed as Signed-off-by after your own name, and they should
> be listed before your name only when you are forwarding their patches.
>
> > Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname
> > and
> > will be broken after this patch. As per discussion over here [1], patches
> > for making these drivers DT based are ready and once that is done they can
> > use
> > syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible.
> >
> > [1]: https://lkml.org/lkml/2014/8/22/81
>
> Adding Alexander Shiyan to Cc here, so we can make sure this is well
> coordinated.
>
> I'm also adding Michal Simek, since here was involved in earlier discussions
> about doing this.
>
> > drivers/mfd/syscon.c | 143
> > +---
> > include/linux/mfd/syscon.h |1 +
> > 2 files changed, 44 insertions(+), 100 deletions(-)
>
> I certainly like the diffstat ;-)
>
> > struct syscon {
> > + struct device_node *np;
> > struct regmap *regmap;
> > + struct list_head list;
> > };
>
> Right
>
> > @@ -68,27 +72,6 @@ struct regmap *syscon_regmap_lookup_by_compatible(const
> > char *s)
> > }
> > EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> >
> > -static int syscon_match_pdevname(struct device *dev, void *data)
> > -{
> > - return !strcmp(dev_name(dev), (const char *)data);
> > -}
> > -
> > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
> > -{
> > - struct device *dev;
> > - struct syscon *syscon;
> > -
> > - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
> > -syscon_match_pdevname);
> > - if (!dev)
> > - return ERR_PTR(-EPROBE_DEFER);
> > -
> > - syscon = dev_get_drvdata(dev);
> > -
> > - return syscon->regmap;
> > -}
> > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
>
> I think this can actually be left intact if that helps with clps71xx.
> It could be done in a hacky way using bus_find_device_by_name()
> to keep it simple, or in a somewhat nicer way by keeping the
> syscon platform_driver around for the non-DT case.
>
>
> > + regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
> > + if (IS_ERR(regmap)) {
> > + pr_err("regmap init failed\n");
> > + return ERR_CAST(regmap);
> > + }
>
> The last time I looked over this code, I think it was not safe to
> call regmap_init_mmio() with a NULL device pointer, and we decided
> that should be fixed. Have you checked whether it is ok now?
I checked that part, and it appears most of the code is already there
(see usage of regmap_attach_dev function here [1]).
The only problem I see is that errors are still printed with dev_err,
which, AFAIK, will trigger a kernel panic if dev is NULL.
This is an issue in both the regmap_init function it
Re: [PATCH v2] irqchip: exynos-combiner: Fix compilation error on ARM64
On Wed, Sep 03, 2014 at 11:02:09AM +0530, Naveen Krishna Chatradhi wrote: > The following compilation error occurs on 64-bit Exynos7 SoC: > > drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: > drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of > function ‘set_irq_flags’ [-Werror=implicit-function-declaration] > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > ^ > drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared > (first use in this function) > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > ^ > drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is > reported only once for each function it appears in > drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared > (first use in this function) > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > > Fix the build error by including linux/interrupt.h. > > Signed-off-by: Naveen Krishna Chatradhi > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Sudeep Holla > --- > Changes since v1: > Used linux/interrupt.h instead of asm/hardirq.h > > drivers/irqchip/exynos-combiner.c |1 + > 1 file changed, 1 insertion(+) Applied to irqchip/urgent thx, Jason. -- 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 08/15] PM / Domains: Remove pm_genpd_syscore_switch() API
The pm_genpd_syscore_poweroff() API and pm_genpd_syscore_poweron() API
makes the pm_genpd_syscore_switch() API redundant.
Moreover, since there are no active users, let's just remove it.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 17 ++---
include/linux/pm_domain.h | 16
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index b910d0f..601e35b 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1292,13 +1292,13 @@ static void pm_genpd_complete(struct device *dev)
}
/**
- * pm_genpd_syscore_switch - Switch power during system core suspend or resume.
+ * genpd_syscore_switch - Switch power during system core suspend or resume.
* @dev: Device that normally is marked as "always on" to switch power for.
*
* This routine may only be called during the system core (syscore) suspend or
* resume phase for devices whose "always on" flags are set.
*/
-void pm_genpd_syscore_switch(struct device *dev, bool suspend)
+static void genpd_syscore_switch(struct device *dev, bool suspend)
{
struct generic_pm_domain *genpd;
@@ -1314,7 +1314,18 @@ void pm_genpd_syscore_switch(struct device *dev, bool
suspend)
genpd->suspended_count--;
}
}
-EXPORT_SYMBOL_GPL(pm_genpd_syscore_switch);
+
+void pm_genpd_syscore_poweroff(struct device *dev)
+{
+ genpd_syscore_switch(dev, true);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_syscore_poweroff);
+
+void pm_genpd_syscore_poweron(struct device *dev)
+{
+ genpd_syscore_switch(dev, false);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_syscore_poweron);
#else
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index f2545a8..eeba1a4 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -266,19 +266,11 @@ static inline void pm_genpd_poweroff_unused(void) {}
#endif
#ifdef CONFIG_PM_GENERIC_DOMAINS_SLEEP
-extern void pm_genpd_syscore_switch(struct device *dev, bool suspend);
+extern void pm_genpd_syscore_poweroff(struct device *dev);
+extern void pm_genpd_syscore_poweron(struct device *dev);
#else
-static inline void pm_genpd_syscore_switch(struct device *dev, bool suspend) {}
+static inline void pm_genpd_syscore_poweroff(struct device *dev) {}
+static inline void pm_genpd_syscore_poweron(struct device *dev) {}
#endif
-static inline void pm_genpd_syscore_poweroff(struct device *dev)
-{
- pm_genpd_syscore_switch(dev, true);
-}
-
-static inline void pm_genpd_syscore_poweron(struct device *dev)
-{
- pm_genpd_syscore_switch(dev, false);
-}
-
#endif /* _LINUX_PM_DOMAIN_H */
--
1.9.1
--
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 04/15] ARM: shmobile: Drop dev_irq_safe from r8a7779 genpd config
The dev_irq_safe configuration is redundant, genpd don't have any special treatmeant for handling it. Let's remove it. Cc: Simon Horman Cc: Magnus Damm Signed-off-by: Ulf Hansson --- arch/arm/mach-shmobile/pm-r8a7779.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-shmobile/pm-r8a7779.c b/arch/arm/mach-shmobile/pm-r8a7779.c index 69f70b7..82fe3d7 100644 --- a/arch/arm/mach-shmobile/pm-r8a7779.c +++ b/arch/arm/mach-shmobile/pm-r8a7779.c @@ -87,7 +87,6 @@ static void r8a7779_init_pm_domain(struct r8a7779_pm_domain *r8a7779_pd) genpd->dev_ops.stop = pm_clk_suspend; genpd->dev_ops.start = pm_clk_resume; genpd->dev_ops.active_wakeup = pd_active_wakeup; - genpd->dev_irq_safe = true; genpd->power_off = pd_power_down; genpd->power_on = pd_power_up; -- 1.9.1 -- 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] tty/serial: fix config dependencies for samsung serial
On Wednesday 03 September 2014 13:51:56 Naveen Krishna Ch wrote: > On 2 September 2014 21:16, Arnd Bergmann wrote: > > On Tuesday 02 September 2014 20:52:00 Naveen Krishna Chatradhi wrote: > >> Make the config symbols SERIAL_SAMSUNG_UARTS_4 and > >> SERIAL_SAMSUNG_UARTS depend on SERIAL_SAMSUNG rather than > >> PLAT_SAMSUNG. > > > > Please always describe why you are doing a change. This patch > > seems really pointless. > > The SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS config options are > meaningful only if SERIAL_SAMSUNG is enabled. Hence the dependency > rules were changed. I will repost this patch with better description. My point is that the options are used by both the uart driver and the platform code, e.g. for the purpose of PM debugging which can be enabled even when the serial-samsung driver is turned off. > >> config SERIAL_SAMSUNG_UARTS_4 > >> bool > >> - depends on PLAT_SAMSUNG > >> + depends on SERIAL_SAMSUNG > >> default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || > >> CPU_S3C2442) > >> help > >> Internal node for the common case of 4 Samsung compatible UARTs > >> > >> config SERIAL_SAMSUNG_UARTS > >> int > >> - depends on PLAT_SAMSUNG > >> + depends on SERIAL_SAMSUNG > >> default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 > >> default 3 > >> help > >> > > > > Have you checked that it still builds on all samsung platforms when > > SERIAL_SAMSUNG is disabled? We have had build errors in this area > > in the past. > > Yes, it builds for other Samsung platforms. Ok. Arnd -- 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 03/15] PM / Domains: Remove system PM callbacks from gpd_dev_ops
There no users of these callbacks, let's simplify the generic power
domain by removing them.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 64 ++---
include/linux/pm_domain.h | 8 --
2 files changed, 8 insertions(+), 64 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index aa5b14c..e777609 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -770,46 +770,6 @@ static bool genpd_dev_active_wakeup(struct
generic_pm_domain *genpd,
return GENPD_DEV_CALLBACK(genpd, bool, active_wakeup, dev);
}
-static int genpd_suspend_dev(struct generic_pm_domain *genpd, struct device
*dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, suspend, dev);
-}
-
-static int genpd_suspend_late(struct generic_pm_domain *genpd, struct device
*dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, suspend_late, dev);
-}
-
-static int genpd_resume_early(struct generic_pm_domain *genpd, struct device
*dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, resume_early, dev);
-}
-
-static int genpd_resume_dev(struct generic_pm_domain *genpd, struct device
*dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, resume, dev);
-}
-
-static int genpd_freeze_dev(struct generic_pm_domain *genpd, struct device
*dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, freeze, dev);
-}
-
-static int genpd_freeze_late(struct generic_pm_domain *genpd, struct device
*dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, freeze_late, dev);
-}
-
-static int genpd_thaw_early(struct generic_pm_domain *genpd, struct device
*dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, thaw_early, dev);
-}
-
-static int genpd_thaw_dev(struct generic_pm_domain *genpd, struct device *dev)
-{
- return GENPD_DEV_CALLBACK(genpd, int, thaw, dev);
-}
-
/**
* pm_genpd_sync_poweroff - Synchronously power off a PM domain and its
masters.
* @genpd: PM domain to power off, if possible.
@@ -991,7 +951,7 @@ static int pm_genpd_suspend(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_suspend_dev(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_suspend(dev);
}
/**
@@ -1012,7 +972,7 @@ static int pm_genpd_suspend_late(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_suspend_late(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_suspend_late(dev);
}
/**
@@ -1099,7 +1059,7 @@ static int pm_genpd_resume_early(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_resume_early(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_resume_early(dev);
}
/**
@@ -1120,7 +1080,7 @@ static int pm_genpd_resume(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_resume_dev(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_resume(dev);
}
/**
@@ -1141,7 +1101,7 @@ static int pm_genpd_freeze(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_freeze_dev(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_freeze(dev);
}
/**
@@ -1163,7 +1123,7 @@ static int pm_genpd_freeze_late(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_freeze_late(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_freeze_late(dev);
}
/**
@@ -1227,7 +1187,7 @@ static int pm_genpd_thaw_early(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_thaw_early(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_thaw_early(dev);
}
/**
@@ -1248,7 +1208,7 @@ static int pm_genpd_thaw(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : genpd_thaw_dev(genpd, dev);
+ return genpd->suspend_power_off ? 0 : pm_generic_thaw(dev);
}
/**
@@ -1956,14 +1916,6 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
genpd->domain.ops.complete = pm_genpd_complete;
genpd->dev_ops.save_state = pm_genpd_default_save_state;
genpd->dev_ops.restore_state = pm_genpd_default_restore_state;
- genpd->dev_ops.suspend = pm_generic_suspend;
- genpd->dev_ops.suspend_late = pm_generic_suspend_late;
- genpd->dev_ops.resume_early = pm_generic_resume_early;
- genpd->dev_ops.resume = pm_generic_resume;
- genpd->dev_ops.freeze = pm_generic_freeze;
- genpd->dev_ops.freeze_late = pm_generic_freeze_late;
- genpd->dev_ops.thaw_early = pm_generic_thaw_early;
-
[PATCH 02/15] PM / Domains: Ignore callbacks for subsys generic_pm_domain_data
In a step of simplifying the generic power domain let's move away from
using these callbacks.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 131 +++-
include/linux/pm_domain.h | 1 -
2 files changed, 8 insertions(+), 124 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e613e3c..aa5b14c 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -25,10 +25,6 @@
__routine = genpd->dev_ops.callback;\
if (__routine) {\
__ret = __routine(dev); \
- } else {\
- __routine = dev_gpd_data(dev)->ops.callback;\
- if (__routine) \
- __ret = __routine(dev); \
} \
__ret; \
})
@@ -1871,10 +1867,6 @@ static int pm_genpd_default_save_state(struct device
*dev)
{
int (*cb)(struct device *__dev);
- cb = dev_gpd_data(dev)->ops.save_state;
- if (cb)
- return cb(dev);
-
if (dev->type && dev->type->pm)
cb = dev->type->pm->runtime_suspend;
else if (dev->class && dev->class->pm)
@@ -1898,10 +1890,6 @@ static int pm_genpd_default_restore_state(struct device
*dev)
{
int (*cb)(struct device *__dev);
- cb = dev_gpd_data(dev)->ops.restore_state;
- if (cb)
- return cb(dev);
-
if (dev->type && dev->type->pm)
cb = dev->type->pm->runtime_resume;
else if (dev->class && dev->class->pm)
@@ -1917,109 +1905,6 @@ static int pm_genpd_default_restore_state(struct device
*dev)
return cb ? cb(dev) : 0;
}
-#ifdef CONFIG_PM_SLEEP
-
-/**
- * pm_genpd_default_suspend - Default "device suspend" for PM domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_suspend(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.suspend;
-
- return cb ? cb(dev) : pm_generic_suspend(dev);
-}
-
-/**
- * pm_genpd_default_suspend_late - Default "late device suspend" for PM
domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_suspend_late(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.suspend_late;
-
- return cb ? cb(dev) : pm_generic_suspend_late(dev);
-}
-
-/**
- * pm_genpd_default_resume_early - Default "early device resume" for PM
domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_resume_early(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.resume_early;
-
- return cb ? cb(dev) : pm_generic_resume_early(dev);
-}
-
-/**
- * pm_genpd_default_resume - Default "device resume" for PM domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_resume(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.resume;
-
- return cb ? cb(dev) : pm_generic_resume(dev);
-}
-
-/**
- * pm_genpd_default_freeze - Default "device freeze" for PM domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_freeze(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.freeze;
-
- return cb ? cb(dev) : pm_generic_freeze(dev);
-}
-
-/**
- * pm_genpd_default_freeze_late - Default "late device freeze" for PM domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_freeze_late(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.freeze_late;
-
- return cb ? cb(dev) : pm_generic_freeze_late(dev);
-}
-
-/**
- * pm_genpd_default_thaw_early - Default "early device thaw" for PM domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_thaw_early(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.thaw_early;
-
- return cb ? cb(dev) : pm_generic_thaw_early(dev);
-}
-
-/**
- * pm_genpd_default_thaw - Default "device thaw" for PM domians.
- * @dev: Device to handle.
- */
-static int pm_genpd_default_thaw(struct device *dev)
-{
- int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.thaw;
-
- return cb ? cb(dev) : pm_generic_thaw(dev);
-}
-
-#else /* !CONFIG_PM_SLEEP */
-
-#define pm_genpd_default_suspend NULL
-#define pm_genpd_default_suspend_late NULL
-#define pm_genpd_default_resume_early NULL
-#define pm_genpd_default_resumeNULL
-#define pm_genpd_default_freezeNULL
-#define pm_genpd_default_freeze_late NULL
-#define pm_genpd_default_thaw_earlyNULL
-#define pm_genpd_default_thaw NULL
-
-#endif /* !CONFIG_PM_SLEEP */
-
/**
* pm_genpd_init - Initialize a generic I/O PM domain object.
* @
[PATCH 11/15] ARM: exynos: Leave disabling of unused PM domains to genpd
Since genpd at late init, will try to disable unused PM domains we don't need to do it from here as well. Cc: Kukjin Kim Signed-off-by: Ulf Hansson --- arch/arm/mach-exynos/exynos.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index 6a24e11..b89e5f3 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -193,7 +193,6 @@ static void __init exynos_init_late(void) /* to be supported later */ return; - pm_genpd_poweroff_unused(); exynos_pm_init(); } -- 1.9.1 -- 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 07/15] PM / Domains: Remove redundant check for CONFIG_PM
CONFIG_PM_GENERIC_DOMAINS depends on CONFIG_PM, thus there are no need
to check explicity for it.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4298a2b..b910d0f 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -66,8 +66,6 @@ static struct generic_pm_domain *pm_genpd_lookup_name(const
char *domain_name)
return genpd;
}
-#ifdef CONFIG_PM
-
struct generic_pm_domain *dev_to_genpd(struct device *dev)
{
if (IS_ERR_OR_NULL(dev->pm_domain))
@@ -281,8 +279,6 @@ int pm_genpd_name_poweron(const char *domain_name)
return genpd ? pm_genpd_poweron(genpd) : -EINVAL;
}
-#endif /* CONFIG_PM */
-
#ifdef CONFIG_PM_RUNTIME
static int genpd_start_dev_no_timing(struct generic_pm_domain *genpd,
--
1.9.1
--
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 10/15] PM / Domains: Add late_initcall to disable unused PM domains
As default behavior let genpd at late init try to disable the unused
PM domains.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index d71d045..cf4651a 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -721,6 +721,13 @@ void pm_genpd_poweroff_unused(void)
mutex_unlock(&gpd_list_lock);
}
+static int __init genpd_poweroff_unused(void)
+{
+ pm_genpd_poweroff_unused();
+ return 0;
+}
+late_initcall(genpd_poweroff_unused);
+
#else
static inline int genpd_dev_pm_qos_notifier(struct notifier_block *nb,
--
1.9.1
--
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 00/15] PM / Domains: Cleanups and remove superfluous APIs
This patchset has a bit of a history and some parts of it has been posted earlier. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262725.html The intent is to simplify code for the generic power domain and also some of the machine specific code that uses the generic power domain. Do note, there are dependencies through this patchset, especially related to the ARM SoC changes, thus they all need to be kept together. Ulf Hansson (15): PM / Domains: Remove the pm_genpd_add|remove_callbacks APIs PM / Domains: Ignore callbacks for subsys generic_pm_domain_data PM / Domains: Remove system PM callbacks from gpd_dev_ops ARM: shmobile: Drop dev_irq_safe from r8a7779 genpd config ARM: shmobile: Drop dev_irq_safe from R-mobile genpd config PM / Domains: Remove dev_irq_safe from genpd config PM / Domains: Remove redundant check for CONFIG_PM PM / Domains: Remove pm_genpd_syscore_switch() API PM / Domains: Remove genpd_queue_power_off_work() API PM / Domains: Add late_initcall to disable unused PM domains ARM: exynos: Leave disabling of unused PM domains to genpd ARM: s3c64xx: Leave disabling of unused PM domains to genpd drivers: sh: Leave disabling of unused PM domains to genpd PM / Domains: Remove default_stop_ok() API PM / Domains: Keep declaration of dev_power_governors together arch/arm/mach-exynos/exynos.c | 1 - arch/arm/mach-s3c64xx/common.c| 5 - arch/arm/mach-s3c64xx/common.h| 7 - arch/arm/mach-s3c64xx/mach-anw6410.c | 1 - arch/arm/mach-s3c64xx/mach-crag6410.c | 1 - arch/arm/mach-s3c64xx/mach-hmt.c | 1 - arch/arm/mach-s3c64xx/mach-mini6410.c | 1 - arch/arm/mach-s3c64xx/mach-ncp.c | 1 - arch/arm/mach-s3c64xx/mach-real6410.c | 1 - arch/arm/mach-s3c64xx/mach-smartq5.c | 1 - arch/arm/mach-s3c64xx/mach-smartq7.c | 1 - arch/arm/mach-s3c64xx/mach-smdk6400.c | 1 - arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 - arch/arm/mach-s3c64xx/pm.c| 7 - arch/arm/mach-shmobile/pm-r8a7779.c | 1 - arch/arm/mach-shmobile/pm-rmobile.c | 1 - drivers/base/power/domain.c | 322 -- drivers/base/power/domain_governor.c | 7 +- drivers/sh/pm_runtime.c | 11 -- include/linux/pm_domain.h | 56 +- 20 files changed, 40 insertions(+), 388 deletions(-) -- 1.9.1 -- 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 05/15] ARM: shmobile: Drop dev_irq_safe from R-mobile genpd config
The dev_irq_safe configuration is redundant, genpd don't have any special treatmeant for handling it. Let's remove it. Cc: Simon Horman Cc: Magnus Damm Signed-off-by: Ulf Hansson --- arch/arm/mach-shmobile/pm-rmobile.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-shmobile/pm-rmobile.c b/arch/arm/mach-shmobile/pm-rmobile.c index ebdd16e..818de2f 100644 --- a/arch/arm/mach-shmobile/pm-rmobile.c +++ b/arch/arm/mach-shmobile/pm-rmobile.c @@ -111,7 +111,6 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd) genpd->dev_ops.stop = pm_clk_suspend; genpd->dev_ops.start= pm_clk_resume; genpd->dev_ops.active_wakeup= rmobile_pd_active_wakeup; - genpd->dev_irq_safe = true; genpd->power_off= rmobile_pd_power_down; genpd->power_on = rmobile_pd_power_up; __rmobile_pd_power_up(rmobile_pd, false); -- 1.9.1 -- 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 00/15] PM / Domains: Cleanups and remove superfluous APIs
On Wednesday 03 September 2014 12:52:16 Ulf Hansson wrote: > > arch/arm/mach-exynos/exynos.c | 1 - > arch/arm/mach-s3c64xx/common.c| 5 - > arch/arm/mach-s3c64xx/common.h| 7 - > arch/arm/mach-s3c64xx/mach-anw6410.c | 1 - > arch/arm/mach-s3c64xx/mach-crag6410.c | 1 - > arch/arm/mach-s3c64xx/mach-hmt.c | 1 - > arch/arm/mach-s3c64xx/mach-mini6410.c | 1 - > arch/arm/mach-s3c64xx/mach-ncp.c | 1 - > arch/arm/mach-s3c64xx/mach-real6410.c | 1 - > arch/arm/mach-s3c64xx/mach-smartq5.c | 1 - > arch/arm/mach-s3c64xx/mach-smartq7.c | 1 - > arch/arm/mach-s3c64xx/mach-smdk6400.c | 1 - > arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 - > arch/arm/mach-s3c64xx/pm.c| 7 - > arch/arm/mach-shmobile/pm-r8a7779.c | 1 - > arch/arm/mach-shmobile/pm-rmobile.c | 1 - > drivers/base/power/domain.c | 322 > -- > drivers/base/power/domain_governor.c | 7 +- > drivers/sh/pm_runtime.c | 11 -- > include/linux/pm_domain.h | 56 +- > 20 files changed, 40 insertions(+), 388 deletions(-) > Wow, great diffstat! I have no idea what this series really does, but I love it ;-) Arnd -- 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 01/15] PM / Domains: Remove the pm_genpd_add|remove_callbacks APIs
There are no users of these APIs. To simplify the generic power domain
let's remove them.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 106
include/linux/pm_domain.h | 19
2 files changed, 125 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index eee55c1..e613e3c 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1744,112 +1744,6 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain
*genpd,
}
/**
- * pm_genpd_add_callbacks - Add PM domain callbacks to a given device.
- * @dev: Device to add the callbacks to.
- * @ops: Set of callbacks to add.
- * @td: Timing data to add to the device along with the callbacks (optional).
- *
- * Every call to this routine should be balanced with a call to
- * __pm_genpd_remove_callbacks() and they must not be nested.
- */
-int pm_genpd_add_callbacks(struct device *dev, struct gpd_dev_ops *ops,
- struct gpd_timing_data *td)
-{
- struct generic_pm_domain_data *gpd_data_new, *gpd_data = NULL;
- int ret = 0;
-
- if (!(dev && ops))
- return -EINVAL;
-
- gpd_data_new = __pm_genpd_alloc_dev_data(dev);
- if (!gpd_data_new)
- return -ENOMEM;
-
- pm_runtime_disable(dev);
- device_pm_lock();
-
- ret = dev_pm_get_subsys_data(dev);
- if (ret)
- goto out;
-
- spin_lock_irq(&dev->power.lock);
-
- if (dev->power.subsys_data->domain_data) {
- gpd_data = to_gpd_data(dev->power.subsys_data->domain_data);
- } else {
- gpd_data = gpd_data_new;
- dev->power.subsys_data->domain_data = &gpd_data->base;
- }
- gpd_data->refcount++;
- gpd_data->ops = *ops;
- if (td)
- gpd_data->td = *td;
-
- spin_unlock_irq(&dev->power.lock);
-
- out:
- device_pm_unlock();
- pm_runtime_enable(dev);
-
- if (gpd_data != gpd_data_new)
- __pm_genpd_free_dev_data(dev, gpd_data_new);
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(pm_genpd_add_callbacks);
-
-/**
- * __pm_genpd_remove_callbacks - Remove PM domain callbacks from a given
device.
- * @dev: Device to remove the callbacks from.
- * @clear_td: If set, clear the device's timing data too.
- *
- * This routine can only be called after pm_genpd_add_callbacks().
- */
-int __pm_genpd_remove_callbacks(struct device *dev, bool clear_td)
-{
- struct generic_pm_domain_data *gpd_data = NULL;
- bool remove = false;
- int ret = 0;
-
- if (!(dev && dev->power.subsys_data))
- return -EINVAL;
-
- pm_runtime_disable(dev);
- device_pm_lock();
-
- spin_lock_irq(&dev->power.lock);
-
- if (dev->power.subsys_data->domain_data) {
- gpd_data = to_gpd_data(dev->power.subsys_data->domain_data);
- gpd_data->ops = (struct gpd_dev_ops){ NULL };
- if (clear_td)
- gpd_data->td = (struct gpd_timing_data){ 0 };
-
- if (--gpd_data->refcount == 0) {
- dev->power.subsys_data->domain_data = NULL;
- remove = true;
- }
- } else {
- ret = -EINVAL;
- }
-
- spin_unlock_irq(&dev->power.lock);
-
- device_pm_unlock();
- pm_runtime_enable(dev);
-
- if (ret)
- return ret;
-
- dev_pm_put_subsys_data(dev);
- if (remove)
- __pm_genpd_free_dev_data(dev, gpd_data);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(__pm_genpd_remove_callbacks);
-
-/**
* pm_genpd_attach_cpuidle - Connect the given PM domain with cpuidle.
* @genpd: PM domain to be connected with cpuidle.
* @state: cpuidle state this domain can disable/enable.
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 7c1d252..0aa9ad9 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -151,10 +151,6 @@ extern int pm_genpd_add_subdomain_names(const char
*master_name,
const char *subdomain_name);
extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
struct generic_pm_domain *target);
-extern int pm_genpd_add_callbacks(struct device *dev,
- struct gpd_dev_ops *ops,
- struct gpd_timing_data *td);
-extern int __pm_genpd_remove_callbacks(struct device *dev, bool clear_td);
extern int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state);
extern int pm_genpd_name_attach_cpuidle(const char *name, int state);
extern int pm_genpd_detach_cpuidle(struct generic_pm_domain *genpd);
@@ -217,16 +213,6 @@ static inline int pm_genpd_remove_subdomain(struct
generic_pm_domain *genpd,
{
return -ENOSYS;
}
-static inline int pm_genpd_add_callbacks(struct device *dev,
-
[PATCH 13/15] drivers: sh: Leave disabling of unused PM domains to genpd
Since genpd at late init, will try to disable unused PM domains we
don't need to do it from here as well.
Cc: Simon Horman
Cc: Magnus Damm
Signed-off-by: Ulf Hansson
---
drivers/sh/pm_runtime.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index 72f6381..fe2c2d5 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -75,8 +75,6 @@ static struct pm_clk_notifier_block platform_bus_notifier = {
.con_ids = { NULL, },
};
-static bool default_pm_on;
-
static int __init sh_pm_runtime_init(void)
{
if (IS_ENABLED(CONFIG_ARCH_SHMOBILE_MULTI)) {
@@ -96,16 +94,7 @@ static int __init sh_pm_runtime_init(void)
return 0;
}
- default_pm_on = true;
pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
return 0;
}
core_initcall(sh_pm_runtime_init);
-
-static int __init sh_pm_runtime_late_init(void)
-{
- if (default_pm_on)
- pm_genpd_poweroff_unused();
- return 0;
-}
-late_initcall(sh_pm_runtime_late_init);
--
1.9.1
--
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 12/15] ARM: s3c64xx: Leave disabling of unused PM domains to genpd
Since genpd at late init, will try to disable unused PM domains we
don't need to do it from the machine specific code as well.
Cc: Ben Dooks
Cc: Kukjin Kim
Signed-off-by: Ulf Hansson
---
arch/arm/mach-s3c64xx/common.c| 5 -
arch/arm/mach-s3c64xx/common.h| 7 ---
arch/arm/mach-s3c64xx/mach-anw6410.c | 1 -
arch/arm/mach-s3c64xx/mach-crag6410.c | 1 -
arch/arm/mach-s3c64xx/mach-hmt.c | 1 -
arch/arm/mach-s3c64xx/mach-mini6410.c | 1 -
arch/arm/mach-s3c64xx/mach-ncp.c | 1 -
arch/arm/mach-s3c64xx/mach-real6410.c | 1 -
arch/arm/mach-s3c64xx/mach-smartq5.c | 1 -
arch/arm/mach-s3c64xx/mach-smartq7.c | 1 -
arch/arm/mach-s3c64xx/mach-smdk6400.c | 1 -
arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 -
arch/arm/mach-s3c64xx/pm.c| 7 ---
13 files changed, 29 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 5c45aae..16547f2 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -440,8 +440,3 @@ void s3c64xx_restart(enum reboot_mode mode, const char *cmd)
/* if all else fails, or mode was for soft, jump to 0 */
soft_restart(0);
}
-
-void __init s3c64xx_init_late(void)
-{
- s3c64xx_pm_late_initcall();
-}
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index 7043e7a..9eb8644 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -23,7 +23,6 @@ void s3c64xx_init_irq(u32 vic0, u32 vic1);
void s3c64xx_init_io(struct map_desc *mach_desc, int size);
void s3c64xx_restart(enum reboot_mode mode, const char *cmd);
-void s3c64xx_init_late(void);
void s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
unsigned long xusbxti_f, bool is_s3c6400, void __iomem *reg_base);
@@ -52,12 +51,6 @@ extern void s3c6410_map_io(void);
#define s3c6410_init NULL
#endif
-#ifdef CONFIG_PM
-int __init s3c64xx_pm_late_initcall(void);
-#else
-static inline int s3c64xx_pm_late_initcall(void) { return 0; }
-#endif
-
#ifdef CONFIG_S3C64XX_PL080
extern struct pl08x_platform_data s3c64xx_dma0_plat_data;
extern struct pl08x_platform_data s3c64xx_dma1_plat_data;
diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c
b/arch/arm/mach-s3c64xx/mach-anw6410.c
index 60576df..6224c67 100644
--- a/arch/arm/mach-s3c64xx/mach-anw6410.c
+++ b/arch/arm/mach-s3c64xx/mach-anw6410.c
@@ -233,7 +233,6 @@ MACHINE_START(ANW6410, "A&W6410")
.init_irq = s3c6410_init_irq,
.map_io = anw6410_map_io,
.init_machine = anw6410_machine_init,
- .init_late = s3c64xx_init_late,
.init_time = samsung_timer_init,
.restart= s3c64xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index fe11633..10b913b 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -857,7 +857,6 @@ MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410")
.init_irq = s3c6410_init_irq,
.map_io = crag6410_map_io,
.init_machine = crag6410_machine_init,
- .init_late = s3c64xx_init_late,
.init_time = samsung_timer_init,
.restart= s3c64xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index 19e8feb..e4b087c 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -277,7 +277,6 @@ MACHINE_START(HMT, "Airgoo-HMT")
.init_irq = s3c6410_init_irq,
.map_io = hmt_map_io,
.init_machine = hmt_machine_init,
- .init_late = s3c64xx_init_late,
.init_time = samsung_timer_init,
.restart= s3c64xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c
b/arch/arm/mach-s3c64xx/mach-mini6410.c
index 9cbc076..ab61af5 100644
--- a/arch/arm/mach-s3c64xx/mach-mini6410.c
+++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
@@ -366,7 +366,6 @@ MACHINE_START(MINI6410, "MINI6410")
.init_irq = s3c6410_init_irq,
.map_io = mini6410_map_io,
.init_machine = mini6410_machine_init,
- .init_late = s3c64xx_init_late,
.init_time = samsung_timer_init,
.restart= s3c64xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-s3c64xx/mach-ncp.c b/arch/arm/mach-s3c64xx/mach-ncp.c
index 4bae7dc..80cb144 100644
--- a/arch/arm/mach-s3c64xx/mach-ncp.c
+++ b/arch/arm/mach-s3c64xx/mach-ncp.c
@@ -103,7 +103,6 @@ MACHINE_START(NCP, "NCP")
.init_irq = s3c6410_init_irq,
.map_io = ncp_map_io,
.init_machine = ncp_machine_init,
- .init_late = s3c64xx_init_late,
.init_time = samsung_timer_init,
.restart= s3c64xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c
b/arch/arm/mach-s3c64xx/mach-real6410.c
index fbad2af..85fa959 100644
---
[PATCH 09/15] PM / Domains: Remove genpd_queue_power_off_work() API
There are no active users of this API. Let's remove it and if future
needs shows up we could consider to have a get/put API instead.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 5 -
include/linux/pm_domain.h | 2 --
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 601e35b..d71d045 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -422,7 +422,7 @@ static bool genpd_abort_poweroff(struct generic_pm_domain
*genpd)
* Queue up the execution of pm_genpd_poweroff() unless it's already been done
* before.
*/
-void genpd_queue_power_off_work(struct generic_pm_domain *genpd)
+static void genpd_queue_power_off_work(struct generic_pm_domain *genpd)
{
queue_work(pm_wq, &genpd->power_off_work);
}
@@ -729,6 +729,9 @@ static inline int genpd_dev_pm_qos_notifier(struct
notifier_block *nb,
return NOTIFY_DONE;
}
+static inline void
+genpd_queue_power_off_work(struct generic_pm_domain *genpd) {}
+
static inline void genpd_power_off_work_fn(struct work_struct *work) {}
#define pm_genpd_runtime_suspend NULL
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index eeba1a4..abeb5dc 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -258,10 +258,8 @@ static inline int pm_genpd_name_add_device(const char
*domain_name,
}
#ifdef CONFIG_PM_GENERIC_DOMAINS_RUNTIME
-extern void genpd_queue_power_off_work(struct generic_pm_domain *genpd);
extern void pm_genpd_poweroff_unused(void);
#else
-static inline void genpd_queue_power_off_work(struct generic_pm_domain *gpd) {}
static inline void pm_genpd_poweroff_unused(void) {}
#endif
--
1.9.1
--
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 06/15] PM / Domains: Remove dev_irq_safe from genpd config
The genpd dev_irq_safe configuration somewhat overlaps with the runtime
PM pm_runtime_irq_safe() option. Also, currently genpd don't have a
good way to deal with these device. So, until we figured out if and how
to support this in genpd, let's remove the option to configure it.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 4
include/linux/pm_domain.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e777609..4298a2b 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -615,8 +615,6 @@ static int pm_genpd_runtime_suspend(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- might_sleep_if(!genpd->dev_irq_safe);
-
stop_ok = genpd->gov ? genpd->gov->stop_ok : NULL;
if (stop_ok && !stop_ok(dev))
return -EBUSY;
@@ -661,8 +659,6 @@ static int pm_genpd_runtime_resume(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- might_sleep_if(!genpd->dev_irq_safe);
-
/* If power.irq_safe, the PM domain is never powered off. */
if (dev->power.irq_safe)
return genpd_start_dev_no_timing(genpd, dev);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index fd5efc8..f2545a8 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -63,7 +63,6 @@ struct generic_pm_domain {
unsigned int suspended_count; /* System suspend device counter */
unsigned int prepared_count;/* Suspend counter of prepared devices
*/
bool suspend_power_off; /* Power status before system suspend */
- bool dev_irq_safe; /* Device callbacks are IRQ-safe */
int (*power_off)(struct generic_pm_domain *domain);
s64 power_off_latency_ns;
int (*power_on)(struct generic_pm_domain *domain);
--
1.9.1
--
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 15/15] PM / Domains: Keep declaration of dev_power_governors together
This is a pure code cleanup in the header file for the PM domain. No functional change. Signed-off-by: Ulf Hansson --- include/linux/pm_domain.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h index ebf52ae..324b927 100644 --- a/include/linux/pm_domain.h +++ b/include/linux/pm_domain.h @@ -117,8 +117,6 @@ static inline struct generic_pm_domain_data *dev_gpd_data(struct device *dev) return to_gpd_data(dev->power.subsys_data->domain_data); } -extern struct dev_power_governor simple_qos_governor; - extern struct generic_pm_domain *dev_to_genpd(struct device *dev); extern int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev, @@ -151,6 +149,7 @@ extern void pm_genpd_init(struct generic_pm_domain *genpd, extern int pm_genpd_poweron(struct generic_pm_domain *genpd); extern int pm_genpd_name_poweron(const char *domain_name); +extern struct dev_power_governor simple_qos_governor; extern struct dev_power_governor pm_domain_always_on_gov; #else -- 1.9.1 -- 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 14/15] PM / Domains: Remove default_stop_ok() API
There are currently no need to export default_stop_ok() as an API,
instead let's keep it local to the PM domain governor.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain_governor.c | 7 ++-
include/linux/pm_domain.h| 6 --
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/domain_governor.c
b/drivers/base/power/domain_governor.c
index a089e3b..d88a62e 100644
--- a/drivers/base/power/domain_governor.c
+++ b/drivers/base/power/domain_governor.c
@@ -42,7 +42,7 @@ static int dev_update_qos_constraint(struct device *dev, void
*data)
* default_stop_ok - Default PM domain governor routine for stopping devices.
* @dev: Device to check.
*/
-bool default_stop_ok(struct device *dev)
+static bool default_stop_ok(struct device *dev)
{
struct gpd_timing_data *td = &dev_gpd_data(dev)->td;
unsigned long flags;
@@ -229,10 +229,7 @@ static bool always_on_power_down_ok(struct dev_pm_domain
*domain)
#else /* !CONFIG_PM_RUNTIME */
-bool default_stop_ok(struct device *dev)
-{
- return false;
-}
+static inline bool default_stop_ok(struct device *dev) { return false; }
#define default_power_down_ok NULL
#define always_on_power_down_okNULL
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index abeb5dc..ebf52ae 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -151,8 +151,6 @@ extern void pm_genpd_init(struct generic_pm_domain *genpd,
extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
extern int pm_genpd_name_poweron(const char *domain_name);
-extern bool default_stop_ok(struct device *dev);
-
extern struct dev_power_governor pm_domain_always_on_gov;
#else
@@ -231,10 +229,6 @@ static inline int pm_genpd_name_poweron(const char
*domain_name)
{
return -ENOSYS;
}
-static inline bool default_stop_ok(struct device *dev)
-{
- return false;
-}
#define simple_qos_governor NULL
#define pm_domain_always_on_gov NULL
#endif
--
1.9.1
--
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] tty/serial: fix config dependencies for samsung serial
Hi Arnd, On 2 September 2014 21:16, Arnd Bergmann wrote: > On Tuesday 02 September 2014 20:52:00 Naveen Krishna Chatradhi wrote: >> Make the config symbols SERIAL_SAMSUNG_UARTS_4 and >> SERIAL_SAMSUNG_UARTS depend on SERIAL_SAMSUNG rather than >> PLAT_SAMSUNG. > > Please always describe why you are doing a change. This patch > seems really pointless. The SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS config options are meaningful only if SERIAL_SAMSUNG is enabled. Hence the dependency rules were changed. I will repost this patch with better description. > >> config SERIAL_SAMSUNG_UARTS_4 >> bool >> - depends on PLAT_SAMSUNG >> + depends on SERIAL_SAMSUNG >> default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || >> CPU_S3C2442) >> help >> Internal node for the common case of 4 Samsung compatible UARTs >> >> config SERIAL_SAMSUNG_UARTS >> int >> - depends on PLAT_SAMSUNG >> + depends on SERIAL_SAMSUNG >> default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 >> default 3 >> help >> > > Have you checked that it still builds on all samsung platforms when > SERIAL_SAMSUNG is disabled? We have had build errors in this area > in the past. Yes, it builds for other Samsung platforms. > > Arnd Thanks. -- Shine bright, (: Nav :) -- 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 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support
Hi Mark, On 27 August 2014 16:39, Mark Rutland wrote: > Hi, > > On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: >> From: Alim Akhtar >> >> This patch adds the necessary Kconfig entries to enable >> support for the ARMv8 based Exynos7 SoC. >> >> Signed-off-by: Alim Akhtar >> Signed-off-by: Naveen Krishna Chatradhi >> Cc: Rob Herring >> Cc: Catalin Marinas >> --- >> arch/arm64/Kconfig | 17 + >> 1 file changed, 17 insertions(+) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index fd4e81a..d58 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -134,6 +134,23 @@ source "kernel/Kconfig.freezer" >> >> menu "Platform selection" >> >> +config ARCH_EXYNOS7 >> + bool "ARMv8 based SAMSUNG EXYNOS7" >> + select HAVE_S3C2410_WATCHDOG if WATCHDOG >> + select CLKSRC_OF > > This seems to be implied by ARM_ARCH_TIMER in the core arm64 Kconfig, so > I'm not sure this is necessary. Ok. > >> + select COMMON_CLK_SAMSUNG >> + select GPIOLIB > > You select ARCH_REQUIRE_GPIOLIB below, so is this necessary? Yes, this is not required. Will remove. > >> + select PINCTRL >> + select PINCTRL_EXYNOS >> + select RTC_CLASS >> + select HAVE_S3C_RTC >> + select GENERIC_GPIO >> + select ARCH_REQUIRE_GPIOLIB >> + select HAVE_CLK > > Isn't this selected already through the core arm64 Kconfig? > > It looks like we have COMMON_CLK, which selects CLKDEV_LOOKUP, which > selects HAVE_CLK. Ok. > >> + select HAVE_SMP > > I may have missed something, but I didn't see any SMP support in this > series. As Catalin suggested, will remove this. > > Thanks, > Mark. Thanks for your comments. -- Shine bright, (: Nav :) -- 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 11/14] arm64: dts: Add initial device tree support for EXYNOS7
Hi Olof,
On 28 August 2014 09:26, Olof Johansson wrote:
> Hi,
>
> On Wed, Aug 27, 2014 at 03:14:18PM +0530, Naveen Krishna Chatradhi wrote:
>> Add initial device tree nodes for EXYNOS7 SoC.
>> Also, includes the dt-binding definitions for clock ids.
>
> Uh, no -- it just adds the dtsi.
Ok. Will fix.
>
>> Signed-off-by: Naveen Krishna Chatradhi
>> Cc: Thomas Abraham
>> Cc: Rob Herring
>> Cc: Catalin Marinas
>> ---
>> arch/arm64/boot/dts/exynos7.dtsi | 553
>> ++
>> 1 file changed, 553 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/exynos7.dtsi
>> b/arch/arm64/boot/dts/exynos7.dtsi
>> new file mode 100644
>> index 000..6b9eaf4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos7.dtsi
>
> Let's not make the same mistake as on 32-bit, and go with a directory
> hierarchy here from day one.
>
> So, please create a exynos subdirectory for this file. You also need
> a Makefile when you add a board dts.
Ok. Will fix.
>
>> @@ -0,0 +1,553 @@
>> +/*
>> + * SAMSUNG EXYNOS7 SoC device tree source
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file.
>> + * EXYNOS7 based board files can include this file and provide
>> + * values for board specfic bindings.
>> + *
>> + * 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
>> +
>> +/ {
>> + compatible = "samsung,exynos7";
>> + interrupt-parent = <&gic>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>
> You should probably use address-cells/size-cells 2/2 on a 64-bit platform.
Ok.
>
>> + aliases {
>> + pinctrl0 = &pinctrl_0;
>> + pinctrl1 = &pinctrl_1;
>> + pinctrl2 = &pinctrl_2;
>> + pinctrl3 = &pinctrl_3;
>> + pinctrl4 = &pinctrl_4;
>> + pinctrl5 = &pinctrl_5;
>> + pinctrl6 = &pinctrl_6;
>> + pinctrl7 = &pinctrl_7;
>> + pinctrl8 = &pinctrl_8;
>> + pinctrl9 = &pinctrl_9;
>> + mshc0 = &mmc_0;
>> + mshc2 = &mmc_2;
>> + };
>> +
>> + chipid@1000 {
>> + compatible = "samsung,exynos4210-chipid";
>> + reg = <0x1000 0x100>;
>> + };
>> +
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>
> Why size-cells=2? Can you not fit a cpuid in 32 bits?
>
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a57", "arm,armv8";
>> + reg = <0x0 0x0>;
>> + };
>> + };
>> +
>> + fin_pll: xxti {
>> + compatible = "fixed-clock";
>> + clock-frequency = <2400>;
>> + clock-output-names = "fin_pll";
>> + #clock-cells = <0>;
>> + };
>> +
>> + gic: interrupt-controller@11001000 {
>> + compatible = "arm,gic-400";
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0x11001000 0x1000>,
>> + <0x11002000 0x1000>,
>> + <0x11004000 0x2000>,
>> + <0x11006000 0x2000>;
>> + };
>> +
>> + hsi2c_0: hsi2c@1364 {
>> + compatible = "samsung,exynos7-hsi2c";
>
> Is the i2c controller here completely new?
It is almost the same as in Exynos5 but few register bits have been
changed. So we have added a new compatible string.
>
> Also, please use 'i2c' for node name on these nodes.
Ok.
>
>> + reg = <0x1364 0x1000>;
>> + interrupts = <0 441 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&hs_i2c0_bus>;
>> + clocks = <&clock_peric0 PCLK_HSI2C0>;
>> + clock-names = "hsi2c";
>> + status = "disabled";
>> + };
>> +
>> + hsi2c_1: hsi2c@1365 {
>> + compatible = "samsung,exynos7-hsi2c";
>> + reg = <0x1365 0x1000>;
>> + interrupts = <0 442 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&hs_i2c1_bus>;
>> + clocks = <&clock_peric0 PCLK_HSI2C1>;
>> + clock-names = "hsi2c";
>> + status = "disabled";
>> + };
>> +
>> + hsi2c_2: hsi2c@14E6 {
>
> I much prefer lowercase hex in unit addresses (and reg entries) below. I
> know 32-bit uses uppercase, but let's switch going forward here.
Ok. Will fix.
>
>> + mct@101C {
>> + compatible = "samsung,exynos4210-
Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7
Hi Tomasz,
On 27 August 2014 17:00, Tomasz Figa wrote:
> Hi Naveen,
>
> Please see my comments inline.
>
> On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote:
>> Add initial device tree nodes for EXYNOS7 SoC.
>> Also, includes the dt-binding definitions for clock ids.
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>> Cc: Thomas Abraham
>> Cc: Rob Herring
>> Cc: Catalin Marinas
>> ---
>> arch/arm64/boot/dts/exynos7.dtsi | 553
>> ++
>> 1 file changed, 553 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/exynos7.dtsi
>> b/arch/arm64/boot/dts/exynos7.dtsi
>> new file mode 100644
>> index 000..6b9eaf4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos7.dtsi
>> @@ -0,0 +1,553 @@
>> +/*
>> + * SAMSUNG EXYNOS7 SoC device tree source
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file.
>> + * EXYNOS7 based board files can include this file and provide
>> + * values for board specfic bindings.
>> + *
>> + * 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
>> +
>> +/ {
>> + compatible = "samsung,exynos7";
>> + interrupt-parent = <&gic>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + aliases {
>> + pinctrl0 = &pinctrl_0;
>> + pinctrl1 = &pinctrl_1;
>> + pinctrl2 = &pinctrl_2;
>> + pinctrl3 = &pinctrl_3;
>> + pinctrl4 = &pinctrl_4;
>> + pinctrl5 = &pinctrl_5;
>> + pinctrl6 = &pinctrl_6;
>> + pinctrl7 = &pinctrl_7;
>> + pinctrl8 = &pinctrl_8;
>> + pinctrl9 = &pinctrl_9;
>> + mshc0 = &mmc_0;
>> + mshc2 = &mmc_2;
>
> Please add aliases for serial controllers. Refer to relevant DT binding
> documentation for more information.
Ok.
>
>> + };
>> +
>> + chipid@1000 {
>> + compatible = "samsung,exynos4210-chipid";
>> + reg = <0x1000 0x100>;
>> + };
>
> Please put SoC components (except cpus node) under a simple-bus node
> called "soc". Please see exynos5260.dtsi as an example.
Ok.
>
>> +
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a57", "arm,armv8";
>> + reg = <0x0 0x0>;
>> + };
>
> Does this SoC really has only one CPU or this is a workaround for things
> like missing CPU bring-up code?
>
>> + };
>
> [snip]
>
>> + mct@101C {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x101C 0x800>;
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>
> MCT is not an interrupt controller.
>
>> + interrupt-parent = <&mct_map>;
>> + interrupts =<0>, <1>, <2>, <3>,
>> + <4>, <5>, <6>, <7>,
>> + <8>, <9>, <10>, <11>;
>> + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>;
>> + clock-names = "fin_pll", "mct";
>> +
>> + mct_map: mct-map {
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <0 &gic 0 112 0>,
>> + <1 &gic 0 113 0>,
>> + <2 &gic 0 114 0>,
>> + <3 &gic 0 115 0>,
>> + <4 &gic 0 116 0>,
>> + <5 &gic 0 117 0>,
>> + <6 &gic 0 118 0>,
>> + <7 &gic 0 119 0>,
>> + <8 &gic 0 120 0>,
>> + <9 &gic 0 121 0>,
>> + <10 &gic 0 122 0>,
>> + <11 &gic 0 123 0>;
>
> All inputs of this interrupt map come from the same interrupt
> controller. What's the point of this map then?
>
>> + };
>> + };
>> +
>> + mmc_0: mmc@1574 {
>> + compatible = "samsung,exynos7-dw-mshc-smu";
>> + interrupts = <0 201 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0x1574 0x2000>;
>> + clocks = <&clock_fsys1 ACLK_MMC0>,
>> + <&clock_top1 CLK_SCLK_MMC0>;
>> + clock-names = "biu", "ciu";
>> + fifo-depth = <0x40>;
>> + status = "disabled";
>> + };
>> +
>> + mmc_2: mmc@1556
Re: [PATCH 06/14] pinctrl: samsung: use CONFIG_PINCTRL_SAMSUNG symbol in makefile
On 29 August 2014 18:07, Linus Walleij wrote: > On Wed, Aug 27, 2014 at 11:48 AM, Naveen Krishna Chatradhi > wrote: > >> Samsung Exynos7 is a ARM64bit processor. Which does not select >> the CONFIG_PLAT_SAMSUNG symbol. CONFIG_PINCTRL_SAMSUNG is being >> selected for both PLAT_SAMSUNG and ARCH_EXYNOS7 symbols. >> >> This patch modifes the pinctrl/Makefile to use >> CONFIG_PINCTRL_SAMSUNG symbol to compile the pinctrl/samsung/*.c >> >> Signed-off-by: Naveen Krishna Chatradhi >> Cc: Tomasz Figa >> Cc: linus.wall...@linaro.org >> Cc: Thomas Abraham > > Excellent catch, thanks, patch applied! Thanks Linus. > > I should use this pattern on more places in the Makefile, > I was confused by logically thinking that Kconfig symbols > used in Makefile cannot be from a Kconfig one level below. > > Yours, > Linus Walleij -- Shine bright, (: Nav :) -- 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 11/14] arm64: dts: Add initial device tree support for EXYNOS7
Hi Mark,
On 27 August 2014 16:12, Mark Rutland wrote:
> Hi Naveen,
>
> On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote:
>> Add initial device tree nodes for EXYNOS7 SoC.
>> Also, includes the dt-binding definitions for clock ids.
>
> Fallout from a rebase? That latter part doesn't seem to be relevant.
Yes, this is fixed now.
>
>> Signed-off-by: Naveen Krishna Chatradhi
>> Cc: Thomas Abraham
>> Cc: Rob Herring
>> Cc: Catalin Marinas
>> ---
>> arch/arm64/boot/dts/exynos7.dtsi | 553
>> ++
>> 1 file changed, 553 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/exynos7.dtsi
>> b/arch/arm64/boot/dts/exynos7.dtsi
>> new file mode 100644
>> index 000..6b9eaf4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos7.dtsi
>> @@ -0,0 +1,553 @@
>> +/*
>> + * SAMSUNG EXYNOS7 SoC device tree source
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file.
>> + * EXYNOS7 based board files can include this file and provide
>> + * values for board specfic bindings.
>> + *
>> + * 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
>> +
>> +/ {
>> + compatible = "samsung,exynos7";
>> + interrupt-parent = <&gic>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>
> Can we guarantee everything going to live within 0x0 - 0x for
> all boards using the SoC?
>
> I suspect that we can't, so the addresses and sizes at the top level
> should be two cells. At some point there is bound to be something above
> 4GB that we'll need to map, so to save us from a painful dts refactoring
> we should have the dts organised to support that from the outside.
Ok, this is fixed with #address-cells = 2 and #size-cells = 2.
>
> [...]
>
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a57", "arm,armv8";
>> + reg = <0x0 0x0>;
>> + };
>> + };
>
> Only UP?
This is a quad core SoC and the rest of the CPU nodes have been added
in the second version of this series.
>
> [...]
>
>> + gic: interrupt-controller@11001000 {
>> + compatible = "arm,gic-400";
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0x11001000 0x1000>,
>> + <0x11002000 0x1000>,
>> + <0x11004000 0x2000>,
>> + <0x11006000 0x2000>;
>> + };
>
> Nice to see GICV and GICH.
>
> [...]
>
>> + mct@101C {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x101C 0x800>;
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> + interrupt-parent = <&mct_map>;
>> + interrupts =<0>, <1>, <2>, <3>,
>> + <4>, <5>, <6>, <7>,
>> + <8>, <9>, <10>, <11>;
>> + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>;
>> + clock-names = "fin_pll", "mct";
>> +
>> + mct_map: mct-map {
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <0 &gic 0 112 0>,
>> + <1 &gic 0 113 0>,
>> + <2 &gic 0 114 0>,
>> + <3 &gic 0 115 0>,
>> + <4 &gic 0 116 0>,
>> + <5 &gic 0 117 0>,
>> + <6 &gic 0 118 0>,
>> + <7 &gic 0 119 0>,
>> + <8 &gic 0 120 0>,
>> + <9 &gic 0 121 0>,
>> + <10 &gic 0 122 0>,
>> + <11 &gic 0 123 0>;
>> + };
>> + };
>
> I don't see why need the map here. Why can't we describe the GIC
> interrupts directly?
Right, it was not required. Also, we will try and use only arch timer
and not MCT.
>
> [...]
>
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <1 13 0xff01>,
>> +<1 14 0xff01>,
>> +<1 11 0xff01>,
>> +<1 10 0xff01>;
>> + clock-frequency = <
Re: [PATCH 08/14] i2c: exynos5: Add Kconfig dependencies
Hi Olof, On 28 August 2014 09:33, Olof Johansson wrote: > On Wed, Aug 27, 2014 at 03:15:40PM +0530, Naveen Krishna Chatradhi wrote: >> The i2c-exynos5.c driver can be reused for the HSI2C controller >> on Exynos7 SoCs from Samsung. >> >> This patch adds the Kconfig dependency to choose i2c-exynos5.c >> for CONFIG_ARCH_EXYNOS7. >> >> Signed-off-by: Naveen Krishna Chatradhi >> To: linux-...@vger.kernel.org >> Cc: Wolfram Sang >> --- >> drivers/i2c/busses/Kconfig |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> index 2ac87fa..bd18fa6 100644 >> --- a/drivers/i2c/busses/Kconfig >> +++ b/drivers/i2c/busses/Kconfig >> @@ -465,7 +465,7 @@ config I2C_EG20T >> >> config I2C_EXYNOS5 >> tristate "Exynos5 high-speed I2C driver" >> - depends on ARCH_EXYNOS5 && OF >> + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF > > Ick, this will keep growing. Please use ARCH_EXYNOS instead. Yes, > this means you need to add it to the arm64 Kconfig and select it from > ARCH_EXYNOS7. Ok, will repost with ARCH_EXYNOS. Thanks. > > > > -Olof -- Shine bright, (: Nav :) -- 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 04/14] clk: samsung: Add clock description for basic CMU blocks
Hi Tomasz,
On 27 August 2014 18:05, Tomasz Figa wrote:
> On 27.08.2014 11:48, Naveen Krishna Chatradhi wrote:
>> This patch adds clock description for MUX, DIV, GATE and PLL
>> clocks available in TOPC, TOP0, TOP1, BUS0, BUS1, FSYS0, FSYS1,
>> CCORE, PERIC0, PERIC1, PERIS, DISP, G3D, MSCL and MFC blocks.
>
> [snip]
>
>> +Phy clocks:
>> +
>> +There are several clocks which are generated by specific PHYs.
>> +These clocks are fed into the clock controller and then routed to
>> +the hardware blocks. These clocks are defined as fixed clocks in the
>> +driver with following names:
>> +
>
> The names are missing?
Ok. Will fix.
>
>> +Required Properties for Clock Controller:
>> +
>> + - compatible: should be one of the following.
>> + 1) "samsung,exynos7-clock-topc"
>> + 2) "samsung,exynos7-clock-top0"
>> + 3) "samsung,exynos7-clock-top1"
>> + 4) "samsung,exynos7-clock-atlas"
>> + 5) "samsung,exynos7-clock-ccore"
>
> [snip]
>
>> + - clocks: list of clock identifiers which are fed as the input to
>> + the given clock controller. Please refer the next section to find
>> + the input clocks for a given controller.
>> +
>> + - clock-names: list of names of clocks which are fed as the input
>> + to the given clock controller.
>
> In the dtsi file added by patch 11/14, I don't see those being specified.
Ok.
>
>> +
>> +Input clocks for topc clock controller:
>> + - fin_pll
>> + - fout_aud_pll
>
> [snip]
>
>> +/* PMS values for PLL 1451x */
>> +static const struct samsung_pll_rate_table pll1451x_24mhz_tbl[] = {
>> + /* rate, m, p, s */
>> + PLL_35XX_RATE(66000, 165, 3, 1),
>
> This array needs to be sorted by output rate. However you might want to
> rebase this series onto series [1] to eliminate this requirement. Be
> aware that mentioned series might need a respin, though.
Ok. Thanks for the pointer.
>
> Also the rates seem to be too nicely rounded. Are they the real values
> that can be obtained using the PLL equation (what is required by the PLL
> framework) or a copy paste from the documentation? Similarly, series [1]
> lessens the requirement a bit, due to recalculation of rates from
> specified coefficients and warning about incorrect entries.
These rates are from the user manual. I will check in detail about these rates.
>
> [1]
> https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35188.html
>
>> + PLL_35XX_RATE(18, 150, 2, 0),
>> + PLL_35XX_RATE(17, 425, 6, 0),
>> + PLL_35XX_RATE(16, 200, 3, 0),
>> + PLL_35XX_RATE(15, 125, 2, 0),
>> + PLL_35XX_RATE(14, 175, 3, 0),
>> + PLL_35XX_RATE(138000, 115, 2, 0),
>> + PLL_35XX_RATE(13, 325, 6, 0),
>> + PLL_35XX_RATE(12, 100, 2, 0),
>> + PLL_35XX_RATE(118000, 295, 6, 0),
>> + PLL_35XX_RATE(110400, 276, 6, 0),
>
> [snip]
>
>> + DIV(0, "dout_sclk_aud_pll", "mout_aud_pll_ctrl", DIV_TOPC3, 28, 3),
>> +};
>> +
>> +static struct samsung_gate_clock topc_gate_clks[] __initdata = {
>> + GATE(ACLK_CCORE_532, "aclk_ccore_532", "dout_aclk_ccore_532",
>> + ENABLE_ACLK_TOPC0, 0, CLK_IGNORE_UNUSED, 0),
>
> Why CLK_IGNORE_UNUSED? (The same question for all the gate clocks
> defined with it in the driver.)
Ok. Fixed.
Thanks.
>
> Best regards,
> Tomasz
--
Shine bright,
(: Nav :)
--
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 01/14] clk: samsung: add support for 145xx and 1460x PLLs
Hi Tomasz,
On 27 August 2014 17:40, Tomasz Figa wrote:
> On 27.08.2014 11:48, Naveen Krishna Chatradhi wrote:
>> By registers bits and offsets the 145xx PLL is similar to
>> pll_type "pll_35xx". Also, 1460x PLL is similar to pll_type
>> "pll_46xx".
>>
>> Hence, reusing the functions defined for pll_35xx and pll_46xx
>> to support 145xx and 1460x PLLs respectively.
>
> [snip]
>
>> @@ -139,6 +140,7 @@ static const struct clk_ops samsung_pll3000_clk_ops = {
>> #define PLL35XX_PDIV_SHIFT (8)
>> #define PLL35XX_SDIV_SHIFT (0)
>> #define PLL35XX_LOCK_STAT_SHIFT (29)
>> +#define PLL145XX_ENABLE BIT(31)
>
> The same bit is also present in PLL35XX.
>
>>
>> static unsigned long samsung_pll35xx_recalc_rate(struct clk_hw *hw,
>> unsigned long parent_rate)
>> @@ -186,6 +188,10 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw,
>> unsigned long drate,
>>
>> tmp = __raw_readl(pll->con_reg);
>>
>> + /* Enable PLL */
>> + if (pll->type == (pll_1450x || pll_1451x || pll_1452x))
>> + tmp |= PLL145XX_ENABLE;
>
> I believe that the need to enable the PLL is not really specific to
> pll_145xx. Any PLL which is initially disabled, should be enabled before
> trying to wait until it stabilizes.
Yes, all other PLL types would also need this. Since I was adding
support specifically for 145xx PLL, I put this in here. The 'if' check
can be removed and used for 45xx PLL as well.
>
>> +
>> if (!(samsung_pll35xx_mp_change(rate, tmp))) {
>> /* If only s change, change just s value only*/
>> tmp &= ~(PLL35XX_SDIV_MASK << PLL35XX_SDIV_SHIFT);
>> @@ -196,8 +202,12 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw,
>> unsigned long drate,
>> }
>>
>> /* Set PLL lock time. */
>> - __raw_writel(rate->pdiv * PLL35XX_LOCK_FACTOR,
>> - pll->lock_reg);
>> + if (pll->type == (pll_1450x || pll_1451x || pll_1452x))
>> + __raw_writel(rate->pdiv * PLL145XX_LOCK_FACTOR,
>> + pll->lock_reg);
>
> If we already have lock_reg in pll, then maybe lock_factor could be
> added there too and this code simply parametrized?
Ok.
>
>> + else
>> + __raw_writel(rate->pdiv * PLL35XX_LOCK_FACTOR,
>> + pll->lock_reg);
>>
>> /* Change PLL PMS values */
>> tmp &= ~((PLL35XX_MDIV_MASK << PLL35XX_MDIV_SHIFT) |
>> @@ -356,7 +366,6 @@ static const struct clk_ops samsung_pll36xx_clk_min_ops
>> = {
>>
>> #define PLL45XX_ENABLE BIT(31)
>> #define PLL45XX_LOCKED BIT(29)
>> -
>
> Stray change?
Yes. Fixed.
>
>> static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
>> unsigned long parent_rate)
>> {
>
> [snip]
>
>> @@ -573,14 +588,23 @@ static int samsung_pll46xx_set_rate(struct clk_hw *hw,
>> unsigned long drate,
>> lock = 0x;
>>
>> /* Set PLL PMS and VSEL values. */
>> - con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) |
>> + if (pll->type == pll_1460x) {
>> + con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) |
>
> Shouldn't PLL1460X_MDIV_MASK be used here instead?
Ok. Fixed.
Thanks.
>
> Best regards,
> Tomasz
--
Shine bright,
(: Nav )
--
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 v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi Felipe, On Tue, Sep 2, 2014 at 8:04 PM, Felipe Balbi wrote: > Hi, > > On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: >> Adding phy calibrate callback, which facilitates setting certain >> PHY settings post initialization of the PHY controller. >> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which >> the Loss-of-Signal (LOS) Detector Threshold Level as well as >> Tx-Vboost-Level should be controlled for Super-Speed operations. >> >> Additionally set proper time to wait for RxDetect measurement, >> for desired PHY reference clock, so as to solve issue with enumeration >> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive >> on the controller. >> We are using CR_port for this purpose to send required data >> to override the LOS values. >> >> On testing with USB 3.0 devices on USB 3.0 port present on >> SMDK5420, and peach-pit boards should see following message: >> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd >> >> and without this patch, should see below shown message: >> usb 1-1: new high-speed USB device number 2 using xhci-hcd >> >> [Also removed unnecessary extra lines in the register macro definitions] >> >> Signed-off-by: Vivek Gautam >> --- >> drivers/phy/phy-exynos5-usbdrd.c | 185 >> ++ >> 1 file changed, 170 insertions(+), 15 deletions(-) >> >> diff --git a/drivers/phy/phy-exynos5-usbdrd.c >> b/drivers/phy/phy-exynos5-usbdrd.c >> index 47f47fe..85742b0 100644 >> --- a/drivers/phy/phy-exynos5-usbdrd.c >> +++ b/drivers/phy/phy-exynos5-usbdrd.c >> @@ -37,13 +37,11 @@ >> >> /* EXYNOS5: USB 3.0 DRD PHY registers */ >> #define EXYNOS5_DRD_LINKSYSTEM 0x04 >> - >> #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) >> #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) >> #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) >> >> #define EXYNOS5_DRD_PHYUTMI 0x08 >> - >> #define PHYUTMI_OTGDISABLE BIT(6) >> #define PHYUTMI_FORCESUSPEND BIT(1) >> #define PHYUTMI_FORCESLEEP BIT(0) >> @@ -51,26 +49,20 @@ >> #define EXYNOS5_DRD_PHYPIPE 0x0c >> >> #define EXYNOS5_DRD_PHYCLKRST0x10 >> - >> #define PHYCLKRST_EN_UTMISUSPEND BIT(31) >> - >> #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) >> #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) >> - >> #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) >> #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) >> - >> #define PHYCLKRST_SSC_EN BIT(20) >> #define PHYCLKRST_REF_SSP_EN BIT(19) >> #define PHYCLKRST_REF_CLKDIV2BIT(18) >> - >> #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) >> - >> #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) >> #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) >> #define PHYCLKRST_FSEL(_x) ((_x) << 5) >> @@ -78,46 +70,68 @@ >> #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) >> #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) >> #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) >> - >> #define PHYCLKRST_RETENABLEN BIT(4) >> - >> #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) >> #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) >> #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) >> - >> #define PHYCLKRST_PORTRESET BIT(1) >> #define PHYCLKRST_COMMONONN BIT(0) >> >> #define EXYNOS5_DRD_PHYREG0 0x14 >> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) >> +#define PHYREG0_SSC_RANGEBIT(20) >> +#define PHYREG0_CR_WRITE BIT(19) >> +#define PHYREG0_CR_READ BIT(18) >> +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) >> +#define PHYREG0_CR_CAP_DATA BIT(1) >> +#define PHYREG0_CR_CAP_ADDR BIT(0) >> + >> #define EXYNOS5_DRD_PHYREG1 0x18 >> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) >> +#define PHYREG1_CR_ACK BIT(0) >> >> #define EXYNOS5_DRD_PHYPARAM00x1c >> - >> #define PHYPARAM0_REF_USE_PADBIT(31) >> #define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26) >> #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) >> >> #define EXYNOS5_DRD_PHYPARAM10x20 >> - >> #define PHYPARAM1_PCS_TXDEEMPH_
