[PATCH v2 3/4] i2c: s3c2410: enable RuntimePM before registering to the core

2015-10-09 Thread Wolfram Sang 
From: Wolfram Sang 

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-s3c2410.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 50bfd8cef5f224..336e34e1ca597d 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1243,19 +1243,21 @@ static int s3c24xx_i2c_probe(struct platform_device 
*pdev)
i2c->adap.nr = i2c->pdata->bus_num;
i2c->adap.dev.of_node = pdev->dev.of_node;
 
+   platform_set_drvdata(pdev, i2c);
+
+   pm_runtime_enable(>dev);
+   pm_runtime_enable(>adap.dev);
+
ret = i2c_add_numbered_adapter(>adap);
if (ret < 0) {
dev_err(>dev, "failed to add bus to i2c core\n");
+   pm_runtime_disable(>adap.dev);
+   pm_runtime_disable(>dev);
s3c24xx_i2c_deregister_cpufreq(i2c);
clk_unprepare(i2c->clk);
return ret;
}
 
-   platform_set_drvdata(pdev, i2c);
-
-   pm_runtime_enable(>dev);
-   pm_runtime_enable(>adap.dev);
-
dev_info(>dev, "%s: S3C I2C adapter\n", dev_name(>adap.dev));
return 0;
 }
-- 
2.1.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: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

2015-10-09 Thread Sjoerd Simons 
On Thu, 2015-10-08 at 16:41 +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote:
> > On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote:
> > > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:
> > > > On 08.10.2015 16:41, Arnd Bergmann wrote:
> > > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
> > > > > > diff --git a/arch/arm/configs/exynos_defconfig
> > > > > > b/arch/arm/configs/exynos_defconfig
> > > > > > index 1ff2bfa..5d1937b 100644
> > > > > > --- a/arch/arm/configs/exynos_defconfig
> > > > > > +++ b/arch/arm/configs/exynos_defconfig
> > > > > > @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
> > > > > >  CONFIG_DM_CRYPT=m
> > > > > >  CONFIG_NETDEVICES=y
> > > > > >  CONFIG_SMSC911X=y
> > > > > > +CONFIG_USB_RTL8152=y
> > > > > >  CONFIG_USB_USBNET=y
> > > > > >  CONFIG_USB_NET_SMSC75XX=y
> > > > > >  CONFIG_USB_NET_SMSC95XX=y
> > > > > 
> > > > > Can we make that a loadable module for multi_v7_defconfig?
> > > > 
> > > > What about nfsroot boots? We were discussing this also here:
> > > > http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-ar
> > > > m-mu
> > > > lti-v7-defconfig-enable-usb3503
> > > > 
> > > > and actually I would be happy to see a confirmed policy about
> > > > that.
> > > > Everything should be a module for multi_v7?
> > > 
> > > We try to make as much as possible modular here, and NFS root is
> > > a
> > > corner
> > > case: it's possible to do NFS root with an initramfs, but it's
> > > easier
> > > not
> > > to. Is it something you do a lot on this hardware?
> > 
> > It's a workflow thing though, not a hardware specific thing. I
> > personally tend to use NFS root quite often and so do various
> > colleagues irrespective of the hardware (and an XU4 is bound to
> > appear
> > on my desk someday). 
> > 
> > Now I personally really don't mind whether NFS root requires a
> > ramdisk
> > or not (though some consistency would be nice). However deciding it
> > on
> > a per device basis just makes everything quite fuzzy (e.g. my
> > recent
> > rockchip multi_v7 patchset first ended up in a similar discussion,
> > though v2 was merged without further comments when I indicated in
> > the
> > cover letter that i used the NFS root use-case as one of the
> > deciding
> > factors for y vs. m).
> > 
> > It would be really good to see someone put their foot down on the
> > general policy (e.g. the arm-soc maintainers?), such that this
> > discussion doesn't need to happen every time 
> 
> Yes, agreed, that what I'm trying to do here ;-)

I see, sorry I misunderstood what you were after.

> I realize that building things as modules is a hassle, it is so for
> some things more than for others, so I keep asking the question
> to everyone to find out what a good balance is to make as much as
> possible modules without hurting too much.

Fwiw, I don't find building modules overly cumbersome. Getting an
initramfs capable of moving on to an NFS root is mostly a one-time
thing (not unlike setting up the nfs root itself) and injecting modules
into it is relatively simple (doubly so if taking advantage of the
multiple cpio archive feature linux has). 

Interestingly, for me not building things as modules in multi_v7 tends
to cause more work as it hides a few categories of bugs that tend to
crop up once building distro kernels (e.g. missing module aliases,
missing module device table entries, implicitly relying on clocks being
active during probe as unused clocks only get turned of late in the
init sequence etc).

> Once we have a firm policy in place, we should probably change all
> the existing symbols.

++

-- 
Sjoerd Simons
Collabora Ltd.
--
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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Russell King - ARM Linux 
On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
> This passes a data pointer specified in the sched_clock_register()
> call to the read callback allowing simpler implementations thereof.
> 
> In this patch, existing uses of this interface are simply updated
> with a null pointer.

This is a bad description.  It tells us what the patch is doing,
(which we can see by reading the patch) but not _why_.  Please include
information on why the change is necessary - describe what you are
trying to achieve.

I generally don't accept patches what add new stuff to the kernel with
no users of that new stuff - that's called experience, experience of
people who submit stuff like that, and then vanish leaving their junk
in the kernel without any users.  Please ensure that this gets a user
very quickly, or better still, submit this patch as part of a series
which makes use of it.

Also, copying soo many people is guaranteed to be silently dropped by
mailing lists.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Måns Rullgård 
Russell King - ARM Linux  writes:

> On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote:
>> Russell King - ARM Linux  writes:
>> 
>> > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
>> >> This passes a data pointer specified in the sched_clock_register()
>> >> call to the read callback allowing simpler implementations thereof.
>> >> 
>> >> In this patch, existing uses of this interface are simply updated
>> >> with a null pointer.
>> >
>> > This is a bad description.  It tells us what the patch is doing,
>> > (which we can see by reading the patch) but not _why_.  Please include
>> > information on why the change is necessary - describe what you are
>> > trying to achieve.
>> 
>> Currently most of the callbacks use a global variable to store the
>> address of a counter register.  This has several downsides:
>> 
>> - Loading the address of a global variable can be more expensive than
>>   keeping a pointer next to the function pointer.
>> 
>> - It makes it impossible to have multiple instances of a driver call
>>   sched_clock_register() since the caller can't know which clock will
>>   win in the end.
>> 
>> - Many of the existing callbacks are practically identical and could be
>>   replaced with a common generic function if it had a pointer argument.
>> 
>> If I've missed something that makes this a stupid idea, please tell.
>
> So my next question is whether you intend to pass an iomem pointer
> through this, or a some kind of structure, or both.  It matters,
> because iomem pointers have a __iomem attribute to keep sparse
> happy.  Having to force that attribute on and off pointers is frowned
> upon, as it defeats the purpose of the sparse static checker.

So this is an instance where tools like sparse get in the way of doing
the simplest, most efficient, and obviously correct thing.  Who wins in
such cases?

-- 
Måns Rullgård
m...@mansr.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 1/5] thermal: exynos: Fix unbalanced regulator disable on probe failure

2015-10-09 Thread Alim Akhtar 
Hello,

On Fri, Oct 9, 2015 at 4:28 PM, Krzysztof Kozlowski
 wrote:
> W dniu 09.10.2015 o 01:45, Alim Akhtar pisze:
>> Hello,
>>
>> On Thu, Oct 8, 2015 at 11:04 AM, Krzysztof Kozlowski
>>  wrote:
>>> During probe if the regulator could not be enabled, the error exit path
>>> would still disable it. This could lead to unbalanced counter of
>>> regulator enable/disable.
>>>
>> Do you see a regulator unbalanced reported here during boot? You may
>> want to add that to commit message.
>
> I did not see the warning/error message about unbalanced disable. It
> would happen in certain condition only - no other enables of regulator
> and count going below 0.
>
> I would have to simulate this error to get the warning message. I don't
> think it is worth the effort.
>
Ok, looking at code, it does looks to be calling regulator disable in
case regulator enable fails.
Feel free to add
Reviewed-by: Alim Akhtar 
Thanks!!

> Best regards,
> Krzysztof
>
>>
>>> The patch moves code for getting and enabling the regulator from
>>> exynos_map_dt_data() to probe function because it is really not a part
>>> of getting Device Tree properties.
>>>
>>> Signed-off-by: Krzysztof Kozlowski 
>>> Fixes: 5f09a5cbd14a ("thermal: exynos: Disable the regulator on probe 
>>> failure")
>>> Cc: 
>>> ---
>>>  drivers/thermal/samsung/exynos_tmu.c | 34 
>>> +-
>>>  1 file changed, 17 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>>> b/drivers/thermal/samsung/exynos_tmu.c
>>> index 0bae8cc6c23a..23f4320f8ef7 100644
>>> --- a/drivers/thermal/samsung/exynos_tmu.c
>>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>>> @@ -1168,27 +1168,10 @@ static int exynos_map_dt_data(struct 
>>> platform_device *pdev)
>>> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>>> struct exynos_tmu_platform_data *pdata;
>>> struct resource res;
>>> -   int ret;
>>>
>>> if (!data || !pdev->dev.of_node)
>>> return -ENODEV;
>>>
>>> -   /*
>>> -* Try enabling the regulator if found
>>> -* TODO: Add regulator as an SOC feature, so that regulator enable
>>> -* is a compulsory call.
>>> -*/
>>> -   data->regulator = devm_regulator_get(>dev, "vtmu");
>>> -   if (!IS_ERR(data->regulator)) {
>>> -   ret = regulator_enable(data->regulator);
>>> -   if (ret) {
>>> -   dev_err(>dev, "failed to enable vtmu\n");
>>> -   return ret;
>>> -   }
>>> -   } else {
>>> -   dev_info(>dev, "Regulator node (vtmu) not found\n");
>>> -   }
>>> -
>>> data->id = of_alias_get_id(pdev->dev.of_node, "tmuctrl");
>>> if (data->id < 0)
>>> data->id = 0;
>>> @@ -1312,6 +1295,23 @@ static int exynos_tmu_probe(struct platform_device 
>>> *pdev)
>>> pr_err("thermal: tz: %p ERROR\n", data->tzd);
>>> return PTR_ERR(data->tzd);
>>> }
>>> +
>>> +   /*
>>> +* Try enabling the regulator if found
>>> +* TODO: Add regulator as an SOC feature, so that regulator enable
>>> +* is a compulsory call.
>>> +*/
>>> +   data->regulator = devm_regulator_get(>dev, "vtmu");
>>> +   if (!IS_ERR(data->regulator)) {
>>> +   ret = regulator_enable(data->regulator);
>>> +   if (ret) {
>>> +   dev_err(>dev, "failed to enable vtmu\n");
>>> +   return ret;
>>> +   }
>>> +   } else {
>>> +   dev_info(>dev, "Regulator node (vtmu) not found\n");
>>> +   }
>>> +
>>> ret = exynos_map_dt_data(pdev);
>>> if (ret)
>>> goto err_sensor;
>>> --
>>> 1.9.1
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>



-- 
Regards,
Alim
--
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: [RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

2015-10-09 Thread Krzysztof Kozlowski 
W dniu 10.10.2015 o 04:18, Kevin Hilman pisze:
> Hi Krzystof,
> 
> Krzysztof Kozlowski <k.kozlow...@samsung.com> writes:
> 
>> Introduction
>> 
>> This patchset tries to fix probing of usb3503 on Arndale board
>> if the Samsung PHY driver is probed later (or built as a module).
>>
>> *The patchset was not tested on Arndale board.*
>> I don't have that board. Please test it and say if the usb3503 deferred probe
>> works fine and the issue is solved.
> 
> FYI... I built this series on top of  next-20151009 and using
> exynos_defconfig.  I booted it on my arndale, and I still don't see the
> networking come up.  Full boot log attached.

+cc Tyler

Kevin,
Thanks for testing but I am not sure if this boot failure is related to
the patch. I mean if the patch should fix this particular boot failure.
The board stopped to boot after enabling DWC2 and network USB gadget:
http://www.spinics.net/lists/linux-samsung-soc/msg47009.html

The boot log shows that usb3503 was probed but asix network adapter was
not. I wonder how these things are related to each other...

Nevertheless it would be difficult to debug the issue without the
Arndale board. :)

Best regards,
Krzysztof
--
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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Måns Rullgård 
Russell King - ARM Linux  writes:

> On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
>> This passes a data pointer specified in the sched_clock_register()
>> call to the read callback allowing simpler implementations thereof.
>> 
>> In this patch, existing uses of this interface are simply updated
>> with a null pointer.
>
> This is a bad description.  It tells us what the patch is doing,
> (which we can see by reading the patch) but not _why_.  Please include
> information on why the change is necessary - describe what you are
> trying to achieve.

Currently most of the callbacks use a global variable to store the
address of a counter register.  This has several downsides:

- Loading the address of a global variable can be more expensive than
  keeping a pointer next to the function pointer.

- It makes it impossible to have multiple instances of a driver call
  sched_clock_register() since the caller can't know which clock will
  win in the end.

- Many of the existing callbacks are practically identical and could be
  replaced with a common generic function if it had a pointer argument.

If I've missed something that makes this a stupid idea, please tell.

-- 
Måns Rullgård
m...@mansr.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] sched_clock: add data pointer argument to read callback

2015-10-09 Thread Russell King - ARM Linux 
On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote:
> Russell King - ARM Linux  writes:
> 
> > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
> >> This passes a data pointer specified in the sched_clock_register()
> >> call to the read callback allowing simpler implementations thereof.
> >> 
> >> In this patch, existing uses of this interface are simply updated
> >> with a null pointer.
> >
> > This is a bad description.  It tells us what the patch is doing,
> > (which we can see by reading the patch) but not _why_.  Please include
> > information on why the change is necessary - describe what you are
> > trying to achieve.
> 
> Currently most of the callbacks use a global variable to store the
> address of a counter register.  This has several downsides:
> 
> - Loading the address of a global variable can be more expensive than
>   keeping a pointer next to the function pointer.
> 
> - It makes it impossible to have multiple instances of a driver call
>   sched_clock_register() since the caller can't know which clock will
>   win in the end.
> 
> - Many of the existing callbacks are practically identical and could be
>   replaced with a common generic function if it had a pointer argument.
> 
> If I've missed something that makes this a stupid idea, please tell.

So my next question is whether you intend to pass an iomem pointer
through this, or a some kind of structure, or both.  It matters,
because iomem pointers have a __iomem attribute to keep sparse
happy.  Having to force that attribute on and off pointers is frowned
upon, as it defeats the purpose of the sparse static checker.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

2015-10-09 Thread Arnd Bergmann 
On Friday 09 October 2015 09:14:33 Anand Moon wrote:
> As long as we use correct exynos5422-odroidxu4.dtb is used in the
> boot.scr/boot.ini ethernet come up,
> build and tested using CONFIG_USB_RTL8152=m using multi_v7_defconfig.
> 
> Not sure what is the policy for NFS booting.
> 
> Do you want CONFIG_USB_RTL8152 to be build as module in
> exynos/multi_v7_defconfig.

The NFS booting is exactly the question here: Would it be a significant
hassle for anyone to require using a ramdisk if they need NFS root?

If we all think it would be an acceptable price, we should probably
make all ethernet drivers loadable modules, as it is commonly
done on distros.

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 3/4] i2c: s3c2410: enable RuntimePM before registering to the core

2015-10-09 Thread Wolfram Sang 
From: Wolfram Sang 

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Signed-off-by: Wolfram Sang 
---

Not tested on HW. Found by code review.

 drivers/i2c/busses/i2c-s3c2410.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 50bfd8cef5f224..75f76cd644728a 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1243,6 +1243,11 @@ static int s3c24xx_i2c_probe(struct platform_device 
*pdev)
i2c->adap.nr = i2c->pdata->bus_num;
i2c->adap.dev.of_node = pdev->dev.of_node;
 
+   platform_set_drvdata(pdev, i2c);
+
+   pm_runtime_enable(>dev);
+   pm_runtime_enable(>adap.dev);
+
ret = i2c_add_numbered_adapter(>adap);
if (ret < 0) {
dev_err(>dev, "failed to add bus to i2c core\n");
@@ -1251,11 +1256,6 @@ static int s3c24xx_i2c_probe(struct platform_device 
*pdev)
return ret;
}
 
-   platform_set_drvdata(pdev, i2c);
-
-   pm_runtime_enable(>dev);
-   pm_runtime_enable(>adap.dev);
-
dev_info(>dev, "%s: S3C I2C adapter\n", dev_name(>adap.dev));
return 0;
 }
-- 
2.1.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] thermal: exynos: fix register read in TMU

2015-10-09 Thread Krzysztof Kozlowski 
W dniu 09.10.2015 o 21:07, Lukasz Majewski pisze:
> Hi Krzysztof,
> 
>> 2015-10-08 23:21 GMT+09:00 Sudip Mukherjee
>> :
>>> On Fri, Oct 02, 2015 at 08:43:52AM +0900, Krzysztof Kozlowski wrote:
 2015-10-01 23:12 GMT+09:00 Sudip Mukherjee
 :
> On Thu, Oct 01, 2015 at 10:18:57PM +0900, Krzysztof Kozlowski
> wrote:
>> 2015-10-01 20:39 GMT+09:00 Sudip Mukherjee
>> :
>>> The value of emul_con was getting overwritten if the selected
>>> soc is SOC_ARCH_EXYNOS5260. And so as a result we were
>>> reading from the wrong register in the case of
>>> SOC_ARCH_EXYNOS5260.
>>
>> How the value is overwritten if the soc is Exynos5260? I can't
>> see it (although the "else if" is still more obvious than "if"
>> but how does the description match the code?).
> The code here is:
> if (data->soc == SOC_ARCH_EXYNOS5260)
> emul_con = EXYNOS5260_EMUL_CON;
> if (data->soc == SOC_ARCH_EXYNOS5433)
> emul_con = EXYNOS5433_TMU_EMUL_CON;
> else if (data->soc == SOC_ARCH_EXYNOS7)
> emul_con = EXYNOS7_TMU_REG_EMUL_CON;
> else
> emul_con = EXYNOS_EMUL_CON;
>
> So if data->soc is SOC_ARCH_EXYNOS5260 , then emul_con becomes
> EXYNOS5260_EMUL_CON. But again for the else part it will become
> EXYNOS_EMUL_CON.

 Indeed!

 Fixes: 488c7455d74c ("thermal: exynos: Add the support for
 Exynos5433 TMU")

 Reviewed-by: Krzysztof Kozlowski 
>>>
>>> Hi Krzysztof,
>>> Who will pick this one up? I still do not see it in linux-next.
>>
>> Hi!
>>
>> I guess it is a patch for Lukasz.
>>
>> Lukasz,
>> Do you plan to pick it up or maybe this should go through samsung-soc
>> tree?
> 
> This is the only one patch, which is waiting in my queue. Since no more
> fixes available, please feel free to grab this patch to samsung-soc.
> 
> Acked-by: Lukasz Majewski 

Okay, thanks! Applied to fixes for current cycle. I'll it send later to
Kukjin (unless he picks it as well).

Best regards,
Krzysztof

--
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] thermal: exynos: fix register read in TMU

2015-10-09 Thread Lukasz Majewski 
Hi Krzysztof,

> 2015-10-08 23:21 GMT+09:00 Sudip Mukherjee
> :
> > On Fri, Oct 02, 2015 at 08:43:52AM +0900, Krzysztof Kozlowski wrote:
> >> 2015-10-01 23:12 GMT+09:00 Sudip Mukherjee
> >> :
> >> > On Thu, Oct 01, 2015 at 10:18:57PM +0900, Krzysztof Kozlowski
> >> > wrote:
> >> >> 2015-10-01 20:39 GMT+09:00 Sudip Mukherjee
> >> >> :
> >> >> > The value of emul_con was getting overwritten if the selected
> >> >> > soc is SOC_ARCH_EXYNOS5260. And so as a result we were
> >> >> > reading from the wrong register in the case of
> >> >> > SOC_ARCH_EXYNOS5260.
> >> >>
> >> >> How the value is overwritten if the soc is Exynos5260? I can't
> >> >> see it (although the "else if" is still more obvious than "if"
> >> >> but how does the description match the code?).
> >> > The code here is:
> >> > if (data->soc == SOC_ARCH_EXYNOS5260)
> >> > emul_con = EXYNOS5260_EMUL_CON;
> >> > if (data->soc == SOC_ARCH_EXYNOS5433)
> >> > emul_con = EXYNOS5433_TMU_EMUL_CON;
> >> > else if (data->soc == SOC_ARCH_EXYNOS7)
> >> > emul_con = EXYNOS7_TMU_REG_EMUL_CON;
> >> > else
> >> > emul_con = EXYNOS_EMUL_CON;
> >> >
> >> > So if data->soc is SOC_ARCH_EXYNOS5260 , then emul_con becomes
> >> > EXYNOS5260_EMUL_CON. But again for the else part it will become
> >> > EXYNOS_EMUL_CON.
> >>
> >> Indeed!
> >>
> >> Fixes: 488c7455d74c ("thermal: exynos: Add the support for
> >> Exynos5433 TMU")
> >>
> >> Reviewed-by: Krzysztof Kozlowski 
> >
> > Hi Krzysztof,
> > Who will pick this one up? I still do not see it in linux-next.
> 
> Hi!
> 
> I guess it is a patch for Lukasz.
> 
> Lukasz,
> Do you plan to pick it up or maybe this should go through samsung-soc
> tree?

This is the only one patch, which is waiting in my queue. Since no more
fixes available, please feel free to grab this patch to samsung-soc.

Acked-by: Lukasz Majewski 

> 
> Best regards,
> Krzysztof


-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
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: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

2015-10-09 Thread Arnd Bergmann 
On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote:
> 
> > I realize that building things as modules is a hassle, it is so for
> > some things more than for others, so I keep asking the question
> > to everyone to find out what a good balance is to make as much as
> > possible modules without hurting too much.
> 
> Fwiw, I don't find building modules overly cumbersome. Getting an
> initramfs capable of moving on to an NFS root is mostly a one-time
> thing (not unlike setting up the nfs root itself) and injecting modules
> into it is relatively simple (doubly so if taking advantage of the
> multiple cpio archive feature linux has). 
> 
> Interestingly, for me not building things as modules in multi_v7 tends
> to cause more work as it hides a few categories of bugs that tend to
> crop up once building distro kernels (e.g. missing module aliases,
> missing module device table entries, implicitly relying on clocks being
> active during probe as unused clocks only get turned of late in the
> init sequence etc).
> 

Ok, let's try to make all future network drivers modules in the
multi_v7_defconfig then, and get people to use an initramfs
if they need NFS root. If nobody complains too loudly for the
next few releases, we can change the existing drivers to =m as well.

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: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

2015-10-09 Thread Krzysztof Kozlowski 
W dniu 09.10.2015 o 19:28, Arnd Bergmann pisze:
> On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote:
>>
>>> I realize that building things as modules is a hassle, it is so for
>>> some things more than for others, so I keep asking the question
>>> to everyone to find out what a good balance is to make as much as
>>> possible modules without hurting too much.
>>
>> Fwiw, I don't find building modules overly cumbersome. Getting an
>> initramfs capable of moving on to an NFS root is mostly a one-time
>> thing (not unlike setting up the nfs root itself) and injecting modules
>> into it is relatively simple (doubly so if taking advantage of the
>> multiple cpio archive feature linux has). 
>>
>> Interestingly, for me not building things as modules in multi_v7 tends
>> to cause more work as it hides a few categories of bugs that tend to
>> crop up once building distro kernels (e.g. missing module aliases,
>> missing module device table entries, implicitly relying on clocks being
>> active during probe as unused clocks only get turned of late in the
>> init sequence etc).
>>
> 
> Ok, let's try to make all future network drivers modules in the
> multi_v7_defconfig then, and get people to use an initramfs
> if they need NFS root. If nobody complains too loudly for the
> next few releases, we can change the existing drivers to =m as well.

Personally I don't use NFS root and we don't have such configurations at
work. At least I am not aware of such. So from my point of view network
adapters as module is okay.

Anand,
Can you change it in multi_v7 patch to module?

Best regards,
Krzysztof
--
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: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

2015-10-09 Thread Anand Moon 
Hi Krzysztof,

On 9 October 2015 at 16:17, Krzysztof Kozlowski  wrote:
> W dniu 09.10.2015 o 19:28, Arnd Bergmann pisze:
>> On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote:
>>>
 I realize that building things as modules is a hassle, it is so for
 some things more than for others, so I keep asking the question
 to everyone to find out what a good balance is to make as much as
 possible modules without hurting too much.
>>>
>>> Fwiw, I don't find building modules overly cumbersome. Getting an
>>> initramfs capable of moving on to an NFS root is mostly a one-time
>>> thing (not unlike setting up the nfs root itself) and injecting modules
>>> into it is relatively simple (doubly so if taking advantage of the
>>> multiple cpio archive feature linux has).
>>>
>>> Interestingly, for me not building things as modules in multi_v7 tends
>>> to cause more work as it hides a few categories of bugs that tend to
>>> crop up once building distro kernels (e.g. missing module aliases,
>>> missing module device table entries, implicitly relying on clocks being
>>> active during probe as unused clocks only get turned of late in the
>>> init sequence etc).
>>>
>>
>> Ok, let's try to make all future network drivers modules in the
>> multi_v7_defconfig then, and get people to use an initramfs
>> if they need NFS root. If nobody complains too loudly for the
>> next few releases, we can change the existing drivers to =m as well.
>
> Personally I don't use NFS root and we don't have such configurations at
> work. At least I am not aware of such. So from my point of view network
> adapters as module is okay.
>
> Anand,
> Can you change it in multi_v7 patch to module?
>
> Best regards,
> Krzysztof

Yes I will change this to build as module for multi_v7, and resend the patch.

-Anand Moon
--
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: [RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

2015-10-09 Thread Kevin Hilman 
Hi Krzystof,

Krzysztof Kozlowski <k.kozlow...@samsung.com> writes:

> Introduction
> 
> This patchset tries to fix probing of usb3503 on Arndale board
> if the Samsung PHY driver is probed later (or built as a module).
>
> *The patchset was not tested on Arndale board.*
> I don't have that board. Please test it and say if the usb3503 deferred probe
> works fine and the issue is solved.

FYI... I built this series on top of  next-20151009 and using
exynos_defconfig.  I booted it on my arndale, and I still don't see the
networking come up.  Full boot log attached.

Kevin

Connected to arndale console [channel connected] (~$quit to exit)
(user:khilman) is already connected


# PYBOOT: console: connected.
~$hardreset

Command(arndale console)> hardreset
(user:khilman) Reboot arndale


U-Boot 2013.01.-rc1-dirty (Jun 28 2013 - 07:14:48) for ARNDALE5250

CPU:Exynos5250@1000MHz

Board:  for ARNDALE5250
I2C:   ready
DRAM:  2 GiB
WARNING: Caches not enabled

Checking Boot Mode ... SDMMC
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1, EXYNOS DWMMC: 2
In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot: 

# PYBOOT: u-boot: taking control.
 3  0 
ARNDALE5250 # 
ARNDALE5250 # version
version

U-Boot 2013.01.-rc1-dirty (Jun 28 2013 - 07:14:48) for ARNDALE5250
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.2-1ubuntu1) 4.7.2
GNU ld (GNU Binutils for Ubuntu) 2.22.90.20120919
ARNDALE5250 # setenv bootargs console=tty0 console=ttySAC2,115200n8 rw 
root=/dev/mmcblk1p3 rootwait rootfstype=ext4
setenv bootargs console=tty0 console=ttySAC2,115200n8 rw root=/dev/mmcblk1p3 
rootwait rootfstype=ext4
ARNDALE5250 # setenv netargs 'setenv bootargs ${bootargs} 
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:::none:192.168.1.3"'
setenv netargs 'setenv bootargs ${bootargs} 
"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:::none:192.168.1.3"'
ARNDALE5250 # if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
ARNDALE5250 # if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
ARNDALE5250 # setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
ARNDALE5250 #dhcp
 dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
DHCP client bound to address 192.168.1.167
ARNDALE5250 #setenv serverip 192.168.1.2
 setenv serverip 192.168.1.2
ARNDALE5250 # if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
ARNDALE5250 # tftp 0x4100 192.168.1.2:tmp/arndale-o13inu/zImage
tftp 0x4100 192.168.1.2:tmp/arndale-o13inu/zImage
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.167
Filename 'tmp/arndale-o13inu/zImage'.
Load address: 0x4100
Loading: *#
 #
 #
 #
 ###
done
Bytes transferred = 4209056 (4039a0 hex)
ARNDALE5250 # tftp 0x4200 
192.168.1.2:tmp/arndale-o13inu/initrd-vFFjKf.cpio.gz
tftp 0x4200 192.168.1.2:tmp/arndale-o13inu/initrd-vFFjKf.cpio.gz
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.167
Filename 'tmp/arndale-o13inu/initrd-vFFjKf.cpio.gz'.
Load address: 0x4200
Loading: *#
 #
 #
 #
 #
 
done
Bytes transferred = 5001043 (4c4f53 hex)
ARNDALE5250 #tftp 0x41f0 192.168.1.2:tmp/arndale-o13inu/tmp_2g_yE.dtb
 tftp 0x41f0 192.168.1.2:tmp/arndale-o13inu/tmp_2g_yE.dtb
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.167
Filename 'tmp/arndale-o13inu/tmp_2g_yE.dtb'.
Load address: 0x41f0
Loading: *###
done
Bytes transferred = 42207 (a4df hex)
ARNDALE5250 # printenv bootargs
printenv bootargs
bootargs=console=tty0 console=ttySAC2,115200n8 rw root=/dev/mmcblk1p3 rootwait 
rootfstype=ext4 
ip=192.168.1.167:192.168.1.2:192.168.1.25