Hello,
This patchset fixes reboot hang issue on Hardkernel's Odroid boards with
eMMC card. Those boards are designed in such a way, that the eMMC nreset
signal is routed to SoC GPIO line instead of the board reset logic. To
properly restard system, one need to set this line to zero before
performi
There are boards (like Hardkernel's Odroid boards) on which eMMC card's
reset line is connected to SoC GPIO line instead of the hardware reset
logic. In case of such boards, before performing system reboot,
additional reset of eMMC card is required to boot again properly.
This patch adds code for h
This patch add samsung,dw-mshc-reset-gpios property to the eMMC slot,
so Exynos DW MMC driver is able to properly reset eMMC card on system
restart and thus fixes hang on software reboot.
Signed-off-by: Marek Szyprowski
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
arch/arm/boot/dts
Hello,
On 2015-01-25 15:32, Sebastian Reichel wrote:
On Fri, Jan 23, 2015 at 12:11:22PM +0100, Marek Szyprowski wrote:
Frankly, I analyzed this case once again and I came to conclusion
that there is no need to make a separate reset driver for Odroid
boards. There is nothing special, specific to
Hi, Marek.
your patch should be conflicted with
"https://patchwork.kernel.org/patch/5698421/";
On 01/27/2015 05:11 PM, Marek Szyprowski wrote:
> There are boards (like Hardkernel's Odroid boards) on which eMMC card's
> reset line is connected to SoC GPIO line instead of the hardware reset
> logi
On Tue, 2015-01-27 at 09:11 +0100, Marek Szyprowski wrote:
> Hello,
>
> This patchset fixes reboot hang issue on Hardkernel's Odroid boards with
> eMMC card. Those boards are designed in such a way, that the eMMC nreset
> signal is routed to SoC GPIO line instead of the board reset logic. To
> pro
> This patchset add new devfreq_event class to provide raw data to determine
> current utilization of device which is used for devfreq governor.
>
> The following description explains the feature of two kind of devfreq class:
> - devfreq class (existing)
> : devfreq consumer device use raw data
Hello Tobias,
On 24/01/15 02:53, Tobias Jakobi wrote:
> Hello,
>
> I've tested the series on my X2 and so far I haven't encountered any
> obvious issues with it.
>
> I have a small question though. With the move to simple-audio-card the
> old driver (selected by SND_SOC_ODROIDX2) is probably goi
After removing exynos_thermal_common.[c|h] files the CONFIG_EXYNOS_THERMA_CORE
is not needed anymore.
This patch removes this entry from Kconfig.
Reported-by: Paul Bolle
Signed-off-by: Lukasz Majewski
---
drivers/thermal/samsung/Kconfig | 9 -
1 file changed, 9 deletions(-)
diff --git
Hi,
On 23 January 2015 at 12:42, Gustavo Padovan wrote:
> void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
> {
> struct exynos_drm_private *dev_priv = dev->dev_private;
> - struct drm_pending_vblank_event *e, *t;
> struct drm_crtc *drm_crtc = dev_priv
On Tue, Jan 27, 2015 at 12:59:15PM +, Daniel Stone wrote:
> Hi,
>
> On 23 January 2015 at 12:42, Gustavo Padovan wrote:
> > void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
> > {
> > struct exynos_drm_private *dev_priv = dev->dev_private;
> > - struct drm
Hello,
On 2015-01-27 09:56, Sjoerd Simons wrote:
On Tue, 2015-01-27 at 09:11 +0100, Marek Szyprowski wrote:
This patchset fixes reboot hang issue on Hardkernel's Odroid boards with
eMMC card. Those boards are designed in such a way, that the eMMC nreset
signal is routed to SoC GPIO line instead
On 24 January 2015 at 01:33, Dmitry Torokhov wrote:
> dw_mci_pltfm_remove() is not (nor should it be) marked as __exit,
> so we should not be using __exit_p() wrapper with it.
>
> Signed-off-by: Dmitry Torokhov
Thanks! Applied for next.
Kind regards
Uffe
> ---
> drivers/mmc/host/dw_mmc-exyno
On Tue, Jan 27, 2015 at 12:13:59PM +0100, Lukasz Majewski wrote:
> After removing exynos_thermal_common.[c|h] files the CONFIG_EXYNOS_THERMA_CORE
> is not needed anymore.
> This patch removes this entry from Kconfig.
>
> Reported-by: Paul Bolle
> Signed-off-by: Lukasz Majewski
This patch looks
Hi Eduardo,
> On Tue, Jan 27, 2015 at 12:13:59PM +0100, Lukasz Majewski wrote:
> > After removing exynos_thermal_common.[c|h] files the
> > CONFIG_EXYNOS_THERMA_CORE is not needed anymore.
> > This patch removes this entry from Kconfig.
> >
> > Reported-by: Paul Bolle
> > Signed-off-by: Lukasz M
On 23/01/15 06:03, Inha Song wrote:
> +static int trats2_aif1_startup(struct snd_pcm_substream *substream)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
> + int ret;
> +
> + ret = clk_p
On Tue, Jan 20, 2015 at 12:14:31PM +0100, Paul Osmialowski wrote:
> On Mon, 19 Jan 2015, Mark Brown wrote:
> >OK, so that's what should go in the changelog (along with an explanation
> >of why this preparation is required at all) - but I still don't see the
> >async bit of this I'm afraid.
> I do
On Tue, Jan 27, 2015 at 06:09:39PM +0100, Sylwester Nawrocki wrote:
> On 23/01/15 06:03, Inha Song wrote:
> > + priv->clk_mclk = of_clk_get_by_name(codec_node, "MCLK1");
> > + if (IS_ERR(priv->clk_mclk)) {
> > + dev_err(&pdev->dev, "Failed to get mclk clock\n");
> > + of_n
On Fri, Jan 23, 2015 at 02:03:29PM +0900, Inha Song wrote:
> + - samsung,audio-routing : A list of the connections between audio
> + components. each entry is a pair of strings, the first being the
> + connection's sink, the second being the connection's source
The list of valid components sh
On Fri, Jan 23, 2015 at 02:03:28PM +0900, Inha Song wrote:
> This patch add the sound machine driver for Trats2 board.
> The codec operate in master mode.
This looks like (and mostly should be) a DTified copy of the littlemill
driver. The major differences are the fact that this lacks jack
detect
The reference counting was needed when genpd supported PM domain device
callbacks. Since this option has been removed, let's also remove the
reference counting of the struct generic_pm_domain_data.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 10 ++
include/linux/pm_domai
Move the initialization of the struct generic_pm_domain_data into
genpd_alloc_dev_data(), including the assignment of the device's
->pm_domain() callback. Make corresponding changes to
genpd_free_dev_data().
These changes will make the related code more readable. It will also
decrease the critical
In a step to get consistent names of functions in genpd, rename
the internal __pm_genpd_alloc|free_dev_data() into
gendp_alloc|free_dev_data().
As discussed on the linux-pm list, let's move towards the following
name rules:
Internal functions:
genpd_*
_genpd_*
__genpd_*
External functions:
pm_ge
The error path in __pm_genpd_add_device() didn't decrease the reference
to the struct pm_subsys_data.
Let's move the calls to dev_pm_get|put_subsys_data() into
genpd_alloc|free_dev_data() to fix this issue and thus prevent a
potential memory leakage.
Signed-off-by: Ulf Hansson
---
drivers/base/
The optional genpd's ->attach_dev() callback is invoked from
__pm_genpd_add_device(). Let's add error handling from the response
from this callback and propagate the error code.
When __pm_genpd_add_device() is invoked through the generic OF-based PM
domain look-up path, the device is being probed.
While adding devices to their PM domains, dev_pm_qos_add_notifier() was
invoked while allocating the generic_pm_domain_data for the device.
Since the generic_pm_domain_data's device pointer will be assigned
after allocation, the ->genpd_dev_pm_qos_notifier() callback could be
called prior having a
While adding error handling of genpd's ->attach_dev() callback, I realized that
we also had a need to re-structure some of the code which deals with
adding/removing devices to genpd. Especially the APIs, __pm_genpd_add_device()
and pm_genpd_remove_device() deserved some attention.
Patch 1 -> 4, ca
When adding a device to a genpd, a struct generic_pm_domain_data is
allocated per device.
Verify that there are no existing generic_pm_domain_data for the device
we are about to add, since that tells us it has already been added to a
genpd.
When genpd supported PM domain device callbacks, this wa
When adding a device to a genpd, we no longer need to walk genpd's list
of existing devices to verify it hasn't already been added.
Instead we can now rely on the verification of not allowing existing
generic_pm_domain_data for a device, since that has the same meaning.
Signed-off-by: Ulf Hansson
Dear Kukjin,
Could you please pick remaining patches (patch4-patch7)?
On 01/27/2015 06:59 PM, MyungJoo Ham wrote:
>> This patchset add new devfreq_event class to provide raw data to determine
>> current utilization of device which is used for devfreq governor.
>>
>> The following description ex
30 matches
Mail list logo
