* Re: [PATCH] staging: sm750fb: remove duplicate from fb_videomode
From: Dan Carpenter @ 2015-05-27 8:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150526152239.GA21887@x230-arch.club.entropia.de>
On Wed, May 27, 2015 at 11:59:21AM +0530, Sudip Mukherjee wrote:
> On Tue, May 26, 2015 at 05:22:39PM +0200, Michel von Czettritz wrote:
> > As suggested by Sudip this patch removes the redundant 1360x768@60
> > option from the fb_videomode struct array.
> this can be in the comments but should not be there in the commit message.
>
No no. It's fine.
I sometimes give credit in the permanent log or in the meta comments
depending on how much credit/blame is deserved. :P
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 2/2] fbcon: use the cursor blink interval provided by vt
From: Scot Doyle @ 2015-05-27 7:52 UTC (permalink / raw)
To: Andrey Wagin
Cc: Greg Kroah-Hartman, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Jiri Slaby, Michael Kerrisk,
Pavel Machek, Geert Uytterhoeven, LKML,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CANaxB-zX4GkExeCzwgYZVDVZE47DHOCnRiYe86difk4fRMK=9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 27 May 2015, Andrey Wagin wrote:
...
> I regularly execute criu tests on linux-next. For this, I use virtual
> machine from the digitalocean clould. The current version of
> linux-next hangs after a few seconds. I use git bisect to find the
> commit where the problem is appeaed. And it looks like the problem is
> in this patch.
...
> Thanks,
> Andrew
Perhaps this pending patch will help:
http://marc.info/?l=linux-kernel&m\x143219509918969&w=2
Thanks,
Scot
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: remove duplicate from fb_videomode
From: Sudip Mukherjee @ 2015-05-27 6:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150526152239.GA21887@x230-arch.club.entropia.de>
On Tue, May 26, 2015 at 05:22:39PM +0200, Michel von Czettritz wrote:
> As suggested by Sudip this patch removes the redundant 1360x768@60
> option from the fb_videomode struct array.
this can be in the comments but should not be there in the commit message.
regards
sudip
> The removed option and the option one it differ in a typo and a flag.
^ permalink raw reply
* Re: [PATCH 2/2] fbcon: use the cursor blink interval provided by vt
From: Andrey Wagin @ 2015-05-27 5:57 UTC (permalink / raw)
To: Scot Doyle
Cc: Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Greg Kroah-Hartman, Jiri Slaby, Michael Kerrisk, Pavel Machek,
Geert Uytterhoeven, LKML, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.11.1502271914040.4248@localhost>
2015-02-27 22:15 GMT+03:00 Scot Doyle <lkml14@scotdoyle.com>:
> vt now provides a cursor blink interval via vc_data. Use this
> interval instead of the currently hardcoded 200 msecs. Store it in
> fbcon_ops to avoid locking the console in cursor_timer_handler().
I regularly execute criu tests on linux-next. For this, I use virtual
machine from the digitalocean clould. The current version of
linux-next hangs after a few seconds. I use git bisect to find the
commit where the problem is appeaed. And it looks like the problem is
in this patch.
When the kernel hangs, it doesn't report anything on the screen and
there is nothing suspicious in logs after reboot.
I will try to reproduce the problem in my local enviroment to get more
information.
There is my config file:
https://github.com/avagin/criu-jenkins-digitalocean/blob/d95d9e30a7da8755c47b290630bac7ee1fe7132d/jenkins-scripts/config
Thanks,
Andrew
^ permalink raw reply
* Re: [PATCHv6 05/10] ARM: mxs: fix in tree users of ssd1306
From: Shawn Guo @ 2015-05-27 3:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maxime Ripard, Thomas Niederprüm, Sascha Hauer, plagnioj,
robh+dt, linux-fbdev, linux-kernel
In-Reply-To: <55641BE7.4090605@ti.com>
On Tue, May 26, 2015 at 10:08:23AM +0300, Tomi Valkeinen wrote:
> So should I take this via fbdev tree with the rest of the patches? If
> so, I want an ack from a relevant dts maintainer. get_maintainers.pl
> gives Shawn as the first contact for imx28-cfa10036.dts.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* Re: [PATCH v3 0/4] pci: add and use pci_ioremap_wc_bar()
From: Luis R. Rodriguez @ 2015-05-26 19:49 UTC (permalink / raw)
To: cocci
In-Reply-To: <556428E7.3050606@ti.com>
On Tue, May 26, 2015 at 11:03:51AM +0300, Tomi Valkeinen wrote:
> Hi Louis,
>
> On 21/04/15 23:20, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > This series adds pci_ioremap_wc_bar() and makes use of it
> > on a few framebuffer device drivers.
> >
> > Luis R. Rodriguez (4):
> > pci: add pci_ioremap_wc_bar()
> > video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
> > video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
> > video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
> >
> > drivers/pci/pci.c | 14 ++++++++++++++
> > drivers/video/fbdev/gxt4500.c | 2 +-
> > drivers/video/fbdev/i740fb.c | 35 ++++++-----------------------------
> > drivers/video/fbdev/kyro/fbdev.c | 33 +++++++++++----------------------
> > include/linux/pci.h | 1 +
> > include/video/kyro.h | 4 +---
> > 6 files changed, 34 insertions(+), 55 deletions(-)
>
> About this and other related series: rather than having multiple
> different patch series containing fbdev changes, going via separate
> trees, I would very much prefer to get all the requisite pci/mtrr
> related patches merged in the next merge window, and only then change
> the fbdev drivers in one series, merged via fbdev tree.
Tomi, OK, I'll ask Bjorn to drop the framebuffer driver specific changes on the
pci_iomap_wc() series then and wait until he takes only the bus specific
changes for this and the pci_iomap_wc() series. Likewise I will wait for
the x86 require changes (ioremap_uc() and pat_enabled()) stuff to be exported
before sending you the changes required for the framebuffer tree.
Luis
^ permalink raw reply
* Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
From: Felipe Balbi @ 2015-05-26 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5564BD5D.1070601@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 4480 bytes --]
On Tue, May 26, 2015 at 11:37:17AM -0700, Arun Ramamurthy wrote:
> Hi
>
> On 15-05-26 07:19 AM, Felipe Balbi wrote:
> >HI,
> >
> >On Mon, May 25, 2015 at 02:19:58PM -0700, Arun Ramamurthy wrote:
> >>
> >>
> >>On 15-05-14 05:52 PM, Felipe Balbi wrote:
> >>>Hi,
> >>>
> >>>On Wed, Apr 22, 2015 at 04:04:10PM -0700, Arun Ramamurthy wrote:
> >>>>Most of the phy providers use "select" to enable GENERIC_PHY. Since select
> >>>>is only recommended when the config is not visible, GENERIC_PHY is changed
> >>>>an invisible option. To maintain consistency, all phy providers are changed
> >>>>to "select" GENERIC_PHY and all non-phy drivers use "depends on" when the
> >>>>phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic
> >>>>dependency, so it is left as "select".
> >>>>
> >>>>Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
> >>>>---
> >>>> drivers/ata/Kconfig | 1 -
> >>>> drivers/media/platform/exynos4-is/Kconfig | 2 +-
> >>>> drivers/phy/Kconfig | 4 ++--
> >>>> drivers/usb/host/Kconfig | 4 ++--
> >>>> drivers/video/fbdev/exynos/Kconfig | 2 +-
> >>>> 5 files changed, 6 insertions(+), 7 deletions(-)
> >>>>
> >>>>diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> >>>>index 5f60155..6d2e881 100644
> >>>>--- a/drivers/ata/Kconfig
> >>>>+++ b/drivers/ata/Kconfig
> >>>>@@ -301,7 +301,6 @@ config SATA_MV
> >>>> tristate "Marvell SATA support"
> >>>> depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
> >>>> ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
> >>>>- select GENERIC_PHY
> >>>> help
> >>>> This option enables support for the Marvell Serial ATA family.
> >>>> Currently supports 88SX[56]0[48][01] PCI(-X) chips,
> >>>>diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
> >>>>index b7b2e47..b6f3eaa 100644
> >>>>--- a/drivers/media/platform/exynos4-is/Kconfig
> >>>>+++ b/drivers/media/platform/exynos4-is/Kconfig
> >>>>@@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC
> >>>> config VIDEO_S5P_MIPI_CSIS
> >>>> tristate "S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver"
> >>>> depends on REGULATOR
> >>>>- select GENERIC_PHY
> >>>>+ depends on GENERIC_PHY
> >>>> help
> >>>> This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2
> >>>> receiver (MIPI-CSIS) devices.
> >>>>diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> >>>>index 2962de2..edecdb1 100644
> >>>>--- a/drivers/phy/Kconfig
> >>>>+++ b/drivers/phy/Kconfig
> >>>>@@ -5,7 +5,7 @@
> >>>> menu "PHY Subsystem"
> >>>>
> >>>> config GENERIC_PHY
> >>>>- bool "PHY Core"
> >>>>+ bool
> >>>> help
> >>>> Generic PHY support.
> >>>>
> >>>>@@ -72,7 +72,7 @@ config PHY_MIPHY365X
> >>>> config PHY_RCAR_GEN2
> >>>> tristate "Renesas R-Car generation 2 USB PHY driver"
> >>>> depends on ARCH_SHMOBILE
> >>>>- depends on GENERIC_PHY
> >>>>+ select GENERIC_PHY
> >>>
> >>>so some you changed from depends to select...
> >>>
> >>>> help
> >>>> Support for USB PHY found on Renesas R-Car generation 2 SoCs.
> >>>>
> >>>>diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> >>>>index 5ad60e4..e2197e2 100644
> >>>>--- a/drivers/usb/host/Kconfig
> >>>>+++ b/drivers/usb/host/Kconfig
> >>>>@@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR
> >>>> config USB_EHCI_HCD_STI
> >>>> tristate "Support for ST STiHxxx on-chip EHCI USB controller"
> >>>> depends on ARCH_STI && OF
> >>>>- select GENERIC_PHY
> >>>>+ depends on GENERIC_PHY
> >>>
> >>>while others you changed from select to depends.
> >>>
> >>>NAK.
> >>>
> >>Felipe, I dont understand your concern, could you please explain it more
> >>detail? The logic behind the changes is that in cases where there was an
> >>explicit dependency, I changed it to "depends on" and in other cases I
> >>changed it to "selects". Thanks
> >
> >Since GENERIC_PHY is visible from Kconfig, it would be much nicer to
> >avoid select altogether.
> >
> Felipe, after discussion with the maintainers, I have made GENERIC_PHY an
> invisible option as part of this change. Thanks
Then, if the option is invisible, how can you "depend" on it ? It can
never be selected by poking around in Kconfig. IMO, it's
counterintuitive that you need to enable a PHY driver before you can see
your EHCI/OHCI/whatever controller listed in Kconfig.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
From: Arun Ramamurthy @ 2015-05-26 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150526141938.GA25686@saruman.tx.rr.com>
Hi
On 15-05-26 07:19 AM, Felipe Balbi wrote:
> HI,
>
> On Mon, May 25, 2015 at 02:19:58PM -0700, Arun Ramamurthy wrote:
>>
>>
>> On 15-05-14 05:52 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Wed, Apr 22, 2015 at 04:04:10PM -0700, Arun Ramamurthy wrote:
>>>> Most of the phy providers use "select" to enable GENERIC_PHY. Since select
>>>> is only recommended when the config is not visible, GENERIC_PHY is changed
>>>> an invisible option. To maintain consistency, all phy providers are changed
>>>> to "select" GENERIC_PHY and all non-phy drivers use "depends on" when the
>>>> phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic
>>>> dependency, so it is left as "select".
>>>>
>>>> Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
>>>> ---
>>>> drivers/ata/Kconfig | 1 -
>>>> drivers/media/platform/exynos4-is/Kconfig | 2 +-
>>>> drivers/phy/Kconfig | 4 ++--
>>>> drivers/usb/host/Kconfig | 4 ++--
>>>> drivers/video/fbdev/exynos/Kconfig | 2 +-
>>>> 5 files changed, 6 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
>>>> index 5f60155..6d2e881 100644
>>>> --- a/drivers/ata/Kconfig
>>>> +++ b/drivers/ata/Kconfig
>>>> @@ -301,7 +301,6 @@ config SATA_MV
>>>> tristate "Marvell SATA support"
>>>> depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
>>>> ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
>>>> - select GENERIC_PHY
>>>> help
>>>> This option enables support for the Marvell Serial ATA family.
>>>> Currently supports 88SX[56]0[48][01] PCI(-X) chips,
>>>> diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
>>>> index b7b2e47..b6f3eaa 100644
>>>> --- a/drivers/media/platform/exynos4-is/Kconfig
>>>> +++ b/drivers/media/platform/exynos4-is/Kconfig
>>>> @@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC
>>>> config VIDEO_S5P_MIPI_CSIS
>>>> tristate "S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver"
>>>> depends on REGULATOR
>>>> - select GENERIC_PHY
>>>> + depends on GENERIC_PHY
>>>> help
>>>> This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2
>>>> receiver (MIPI-CSIS) devices.
>>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>>> index 2962de2..edecdb1 100644
>>>> --- a/drivers/phy/Kconfig
>>>> +++ b/drivers/phy/Kconfig
>>>> @@ -5,7 +5,7 @@
>>>> menu "PHY Subsystem"
>>>>
>>>> config GENERIC_PHY
>>>> - bool "PHY Core"
>>>> + bool
>>>> help
>>>> Generic PHY support.
>>>>
>>>> @@ -72,7 +72,7 @@ config PHY_MIPHY365X
>>>> config PHY_RCAR_GEN2
>>>> tristate "Renesas R-Car generation 2 USB PHY driver"
>>>> depends on ARCH_SHMOBILE
>>>> - depends on GENERIC_PHY
>>>> + select GENERIC_PHY
>>>
>>> so some you changed from depends to select...
>>>
>>>> help
>>>> Support for USB PHY found on Renesas R-Car generation 2 SoCs.
>>>>
>>>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>>>> index 5ad60e4..e2197e2 100644
>>>> --- a/drivers/usb/host/Kconfig
>>>> +++ b/drivers/usb/host/Kconfig
>>>> @@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR
>>>> config USB_EHCI_HCD_STI
>>>> tristate "Support for ST STiHxxx on-chip EHCI USB controller"
>>>> depends on ARCH_STI && OF
>>>> - select GENERIC_PHY
>>>> + depends on GENERIC_PHY
>>>
>>> while others you changed from select to depends.
>>>
>>> NAK.
>>>
>> Felipe, I dont understand your concern, could you please explain it more
>> detail? The logic behind the changes is that in cases where there was an
>> explicit dependency, I changed it to "depends on" and in other cases I
>> changed it to "selects". Thanks
>
> Since GENERIC_PHY is visible from Kconfig, it would be much nicer to
> avoid select altogether.
>
Felipe, after discussion with the maintainers, I have made GENERIC_PHY
an invisible option as part of this change. Thanks
^ permalink raw reply
* Re: [PATCH v6 1/4] pci: add pci_iomap_wc() variants
From: Bjorn Helgaas @ 2015-05-26 17:40 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, tomi.valkeinen, airlied, linux-fbdev, luto,
linux-kernel, linux-pci, xen-devel, Toshi Kani, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Juergen Gross, Daniel Vetter,
Dave Airlie, Antonino Daplas, Jean-Christophe Plagniol-Villard,
Dave Hansen, Arnd Bergmann, Michael S. Tsirkin,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Borislav Petkov, Davidlohr Bueso,
konrad.wilk, ville.syrjala, david.vrabel, jbeulich,
Roger Pau Monné
In-Reply-To: <20150522002341.GM23057@wotan.suse.de>
On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
> On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> >
> > I tentatively put this (and the rest of the series) on a pci/resource
> > branch. I'm hoping you'll propose some clarification about
> > EXPORT_SYMBOL_GPL().
>
> EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
> only run that code. So for instance although we have "Dual BSD/GPL"
> tags for modules pure "BSD" tags do not exist for module tags and
> cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
> who do believe tha at run time all kernel modules are GPL [1] [2].
> And to be precise even though the FSF may claim a list of licenses
> are GPL-compatible we cannot rely on this list alone for our own
> goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
> discuss this on lkml [2].
By "propose some clarification," I meant that I hoped you would propose a
patch to Documentation/ that would give maintainers some guidance.
> ...
^ permalink raw reply
* [PATCH] staging: sm750fb: remove duplicate from fb_videomode
From: Michel von Czettritz @ 2015-05-26 15:22 UTC (permalink / raw)
To: linux-fbdev
As suggested by Sudip this patch removes the redundant 1360x768@60
option from the fb_videomode struct array.
The removed option and the option one it differ in a typo and a flag.
Signed-off-by: Michel von Czettritz <michel.von.czettritz@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 69b18f3..d90b463 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -88,9 +88,6 @@ static const struct fb_videomode lynx750_ext[] = {
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
FB_VMODE_NONINTERLACED},
- {NULL, 60, 1360, 768, 11804, 208, 64, 23, 1, 144, 3,
- FB_SYNC_HOR_HIGH_ACT|FB_VMODE_NONINTERLACED},
-
/* 1360 x 768 [1.77083:1] */
{NULL, 60, 1360, 768, 11804, 208, 64, 23, 1, 144, 3,
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
--
2.3.7
^ permalink raw reply related
* Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
From: Felipe Balbi @ 2015-05-26 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <556391FE.1020503@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 3766 bytes --]
HI,
On Mon, May 25, 2015 at 02:19:58PM -0700, Arun Ramamurthy wrote:
>
>
> On 15-05-14 05:52 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Wed, Apr 22, 2015 at 04:04:10PM -0700, Arun Ramamurthy wrote:
> >>Most of the phy providers use "select" to enable GENERIC_PHY. Since select
> >>is only recommended when the config is not visible, GENERIC_PHY is changed
> >>an invisible option. To maintain consistency, all phy providers are changed
> >>to "select" GENERIC_PHY and all non-phy drivers use "depends on" when the
> >>phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic
> >>dependency, so it is left as "select".
> >>
> >>Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
> >>---
> >> drivers/ata/Kconfig | 1 -
> >> drivers/media/platform/exynos4-is/Kconfig | 2 +-
> >> drivers/phy/Kconfig | 4 ++--
> >> drivers/usb/host/Kconfig | 4 ++--
> >> drivers/video/fbdev/exynos/Kconfig | 2 +-
> >> 5 files changed, 6 insertions(+), 7 deletions(-)
> >>
> >>diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> >>index 5f60155..6d2e881 100644
> >>--- a/drivers/ata/Kconfig
> >>+++ b/drivers/ata/Kconfig
> >>@@ -301,7 +301,6 @@ config SATA_MV
> >> tristate "Marvell SATA support"
> >> depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
> >> ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
> >>- select GENERIC_PHY
> >> help
> >> This option enables support for the Marvell Serial ATA family.
> >> Currently supports 88SX[56]0[48][01] PCI(-X) chips,
> >>diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
> >>index b7b2e47..b6f3eaa 100644
> >>--- a/drivers/media/platform/exynos4-is/Kconfig
> >>+++ b/drivers/media/platform/exynos4-is/Kconfig
> >>@@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC
> >> config VIDEO_S5P_MIPI_CSIS
> >> tristate "S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver"
> >> depends on REGULATOR
> >>- select GENERIC_PHY
> >>+ depends on GENERIC_PHY
> >> help
> >> This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2
> >> receiver (MIPI-CSIS) devices.
> >>diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> >>index 2962de2..edecdb1 100644
> >>--- a/drivers/phy/Kconfig
> >>+++ b/drivers/phy/Kconfig
> >>@@ -5,7 +5,7 @@
> >> menu "PHY Subsystem"
> >>
> >> config GENERIC_PHY
> >>- bool "PHY Core"
> >>+ bool
> >> help
> >> Generic PHY support.
> >>
> >>@@ -72,7 +72,7 @@ config PHY_MIPHY365X
> >> config PHY_RCAR_GEN2
> >> tristate "Renesas R-Car generation 2 USB PHY driver"
> >> depends on ARCH_SHMOBILE
> >>- depends on GENERIC_PHY
> >>+ select GENERIC_PHY
> >
> >so some you changed from depends to select...
> >
> >> help
> >> Support for USB PHY found on Renesas R-Car generation 2 SoCs.
> >>
> >>diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> >>index 5ad60e4..e2197e2 100644
> >>--- a/drivers/usb/host/Kconfig
> >>+++ b/drivers/usb/host/Kconfig
> >>@@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR
> >> config USB_EHCI_HCD_STI
> >> tristate "Support for ST STiHxxx on-chip EHCI USB controller"
> >> depends on ARCH_STI && OF
> >>- select GENERIC_PHY
> >>+ depends on GENERIC_PHY
> >
> >while others you changed from select to depends.
> >
> >NAK.
> >
> Felipe, I dont understand your concern, could you please explain it more
> detail? The logic behind the changes is that in cases where there was an
> explicit dependency, I changed it to "depends on" and in other cases I
> changed it to "selects". Thanks
Since GENERIC_PHY is visible from Kconfig, it would be much nicer to
avoid select altogether.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 15/21] backlight: Probe backlight devices on demand
From: Lee Jones @ 2015-05-26 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAObsKCBLVOph2DzeQqph+teiFq=uZtjShBOf+G-U2UxRAJ7jw@mail.gmail.com>
On Tue, 26 May 2015, Tomeu Vizoso wrote:
> On 26 May 2015 at 10:39, Lee Jones <lee.jones@linaro.org> wrote:
> > On Tue, 26 May 2015, Sascha Hauer wrote:
> >> On Tue, May 26, 2015 at 08:18:50AM +0100, Lee Jones wrote:
> >> > On Mon, 25 May 2015, Tomeu Vizoso wrote:
> >> >
> >> > > When looking up a backlight device through its DT node, ensure that the
> >> > > corresponding device has been registered.
> >> > >
> >> > > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >> > > ---
> >> > > drivers/video/backlight/backlight.c | 3 +++
> >> > > 1 file changed, 3 insertions(+)
> >> >
> >> > Looks reasonable.
> >> >
> >> > Until anyone screams at me, applied thanks.
> >>
> >> The compiler will scream at you when it realizes that
> >> of_platform_device_ensure() doesn't exist in your kernel...
> >
> > Yup, indeed it did.
> >
> > I assumed this was *only* enabling subsystems and that the
> > framework/API was already accepted.
> >
> > So the advice I'd give to Tomeu when sending full enablement
> > patch-sets i.e. ones which provide the framework/API *and* enable
> > subsystems in the same set, is to send the entire set to everyone, so
> > we can see what the aim of the set is and how to deal with it.
>
> Yeah, but get_maintainer.pl outputs 33 maintainer addresses, plus 1
> reviewer plus 14 mailing lists, so to avoid rejects because of too
> many recipients I went with the advice in [0] and sent each patch to
> their maintainers and list(s) and the cover letter to all lists. Also
> sent the whole series to lakml to make sure that it's at least indexed
> there.
Mails aren't usually rejected because they have too many recipients,
rather they require approval. This isn't a blocker, especially for
patch-sets like this.
> Any advice on what to do with series that span so many subsystems?
I would either ensure everyone is informed, split into two choices;
either CC everyone on every patch, or at least everyone on the
cover-letter and the core API changes. The other method is to have
the API changes accepted first, then once accepted send out the
subsystem changes [FWIW: this is the method I (wrongly) assumed you
used].
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 15/21] backlight: Probe backlight devices on demand
From: Tomeu Vizoso @ 2015-05-26 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150526083931.GC11677@x1>
On 26 May 2015 at 10:39, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 26 May 2015, Sascha Hauer wrote:
>> On Tue, May 26, 2015 at 08:18:50AM +0100, Lee Jones wrote:
>> > On Mon, 25 May 2015, Tomeu Vizoso wrote:
>> >
>> > > When looking up a backlight device through its DT node, ensure that the
>> > > corresponding device has been registered.
>> > >
>> > > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> > > ---
>> > > drivers/video/backlight/backlight.c | 3 +++
>> > > 1 file changed, 3 insertions(+)
>> >
>> > Looks reasonable.
>> >
>> > Until anyone screams at me, applied thanks.
>>
>> The compiler will scream at you when it realizes that
>> of_platform_device_ensure() doesn't exist in your kernel...
>
> Yup, indeed it did.
>
> I assumed this was *only* enabling subsystems and that the
> framework/API was already accepted.
>
> So the advice I'd give to Tomeu when sending full enablement
> patch-sets i.e. ones which provide the framework/API *and* enable
> subsystems in the same set, is to send the entire set to everyone, so
> we can see what the aim of the set is and how to deal with it.
Yeah, but get_maintainer.pl outputs 33 maintainer addresses, plus 1
reviewer plus 14 mailing lists, so to avoid rejects because of too
many recipients I went with the advice in [0] and sent each patch to
their maintainers and list(s) and the cover letter to all lists. Also
sent the whole series to lakml to make sure that it's at least indexed
there.
Any advice on what to do with series that span so many subsystems?
Thanks,
Tomeu
[0] http://lwn.net/Articles/585782/
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 15/21] backlight: Probe backlight devices on demand
From: Lee Jones @ 2015-05-26 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150526072526.GB6325@pengutronix.de>
On Tue, 26 May 2015, Sascha Hauer wrote:
> On Tue, May 26, 2015 at 08:18:50AM +0100, Lee Jones wrote:
> > On Mon, 25 May 2015, Tomeu Vizoso wrote:
> >
> > > When looking up a backlight device through its DT node, ensure that the
> > > corresponding device has been registered.
> > >
> > > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > > ---
> > > drivers/video/backlight/backlight.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> >
> > Looks reasonable.
> >
> > Until anyone screams at me, applied thanks.
>
> The compiler will scream at you when it realizes that
> of_platform_device_ensure() doesn't exist in your kernel...
Yup, indeed it did.
I assumed this was *only* enabling subsystems and that the
framework/API was already accepted.
So the advice I'd give to Tomeu when sending full enablement
patch-sets i.e. ones which provide the framework/API *and* enable
subsystems in the same set, is to send the entire set to everyone, so
we can see what the aim of the set is and how to deal with it.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/1 linux-next] video: fbdev: matrox: use swap() in matroxfb_decode_var()
From: Tomi Valkeinen @ 2015-05-26 8:32 UTC (permalink / raw)
To: Fabian Frederick, linux-kernel
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <1431970264-16195-1-git-send-email-fabf@skynet.be>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On 18/05/15 20:31, Fabian Frederick wrote:
> Use kernel.h macro definition.
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> drivers/video/fbdev/matrox/matroxfb_base.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c
> index 62539ca..2ba4e54 100644
> --- a/drivers/video/fbdev/matrox/matroxfb_base.c
> +++ b/drivers/video/fbdev/matrox/matroxfb_base.c
> @@ -591,12 +591,8 @@ static int matroxfb_decode_var(const struct matrox_fb_info *minfo,
> unsigned int max_yres;
>
> while (m1) {
> - int t;
> -
> while (m2 >= m1) m2 -= m1;
> - t = m1;
> - m1 = m2;
> - m2 = t;
> + swap(m1, m2);
> }
> m2 = linelen * PAGE_SIZE / m2;
> *ydstorg = m2 = 0x400000 % m2;
>
Thanks, I've queued this and the two other swap() patches for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/4] pci: add and use pci_ioremap_wc_bar()
From: Tomi Valkeinen @ 2015-05-26 8:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1429647634-17169-1-git-send-email-mcgrof@do-not-panic.com>
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]
Hi Louis,
On 21/04/15 23:20, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This series adds pci_ioremap_wc_bar() and makes use of it
> on a few framebuffer device drivers.
>
> Luis R. Rodriguez (4):
> pci: add pci_ioremap_wc_bar()
> video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
> video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
> video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
>
> drivers/pci/pci.c | 14 ++++++++++++++
> drivers/video/fbdev/gxt4500.c | 2 +-
> drivers/video/fbdev/i740fb.c | 35 ++++++-----------------------------
> drivers/video/fbdev/kyro/fbdev.c | 33 +++++++++++----------------------
> include/linux/pci.h | 1 +
> include/video/kyro.h | 4 +---
> 6 files changed, 34 insertions(+), 55 deletions(-)
About this and other related series: rather than having multiple
different patch series containing fbdev changes, going via separate
trees, I would very much prefer to get all the requisite pci/mtrr
related patches merged in the next merge window, and only then change
the fbdev drivers in one series, merged via fbdev tree.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Geert Uytterhoeven @ 2015-05-26 7:41 UTC (permalink / raw)
To: hs
Cc: Tomi Valkeinen, linux-kernel@vger.kernel.org,
Linux Fbdev development list, Jean-Christophe Plagniol-Villard
In-Reply-To: <55642243.5000205@denx.de>
Hi Heiko,
On Tue, May 26, 2015 at 9:35 AM, Heiko Schocher <hs@denx.de> wrote:
> Am 26.05.2015 09:25, schrieb Geert Uytterhoeven:
>>
>> On Tue, May 26, 2015 at 9:17 AM, Heiko Schocher <hs@denx.de> wrote:
>>>
>>> 4) draw only one logo even on multicores ... why must every core draw
>>> a logo? Currently each core draws the logo, and on a system with more
>>> than 4 cores, I think this looks not really good ...
>>
>>
>> I don't think each core draws a logo. They're all drawn from
>> fbcon_switch().
>
> Hmm... I have here an imx6dl based system, and it draws two logos when
> booting...
It draw one logo _for_ each cpu core, but each logo is not drawn _by_ each
cpu core.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Heiko Schocher @ 2015-05-26 7:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Tomi Valkeinen, linux-kernel@vger.kernel.org,
Linux Fbdev development list, Jean-Christophe Plagniol-Villard
In-Reply-To: <CAMuHMdWc=vsdmjxmQdSRYkQ-t_Rmn-LoTp1Jn0wgp++rEStcxw@mail.gmail.com>
Hello Geert,
Am 26.05.2015 09:25, schrieb Geert Uytterhoeven:
> On Tue, May 26, 2015 at 9:17 AM, Heiko Schocher <hs@denx.de> wrote:
>> 4) draw only one logo even on multicores ... why must every core draw
>> a logo? Currently each core draws the logo, and on a system with more
>> than 4 cores, I think this looks not really good ...
>
> I don't think each core draws a logo. They're all drawn from fbcon_switch().
Hmm... I have here an imx6dl based system, and it draws two logos when booting...
I can prevent this two logos, if I do:
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0705d88..e907ab9 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -664,8 +672,7 @@ int fb_show_logo(struct fb_info *info, int rotate)
{
int y;
- y = fb_show_logo_line(info, rotate, fb_logo.logo, 0,
- num_online_cpus());
+ y = fb_show_logo_line(info, rotate, fb_logo.logo, 0, 1);
y = fb_show_extra_logos(info, y, rotate);
return y;
>> Hmm... I do not really have a lot experience in this area ... but why
>> is the logo only drawed when booting? Is there nothing like a "redraw"
>> of it?
>
> When do you want to redraw it? On VC switch (it's drawn on the first call
> only, hence it disappears if you switch VC and back)?
> Until when should it be redrawn?
I don;t know, it was just a question ... If this is not possible, we
do not need to cover such a case, good!
bye,
Heiko
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
>
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Heiko Schocher @ 2015-05-26 7:29 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, linux-kernel@vger.kernel.org,
Linux Fbdev development list, Jean-Christophe Plagniol-Villard
In-Reply-To: <55641D89.5020103@ti.com>
Hello Tomi, Geert,
Am 26.05.2015 09:15, schrieb Tomi Valkeinen:
>
>
> On 26/05/15 10:08, Geert Uytterhoeven wrote:
>> On Tue, May 26, 2015 at 8:54 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 26/05/15 06:56, Heiko Schocher wrote:
>>>>> Without locking, the initmem may be freed while fb_find_logo() is
>>>>> running.
>>
>> Or afterwards. Drivers may keep the pointer around indefinitely.
>>
>>>> Yes, you are right, that must be added ... but has such a change a
>>>> chance to go in mainline?
>>>
>>> I don't know. To be honest, this whole thing feels a bit like hackery. I
>>> think initdata should only be accessed from initcalls, never asynchronously.
>>>
>>>> BTW: Could this not be currently a problem on multicore systems?
>>>> If lets say core 2 just draws the logo, another core 1 calls
>>>> fb_logo_late_init() and later core 1 free_initmem(), while the core 2
>>>> still draws it?
>>>
>>> Yes, I think so...
>>
>> I don't think that can happen. All initcalls should complete before initmem
>> is freed.
>
> Ah, true, the question was only about the initcalls. I was answering to
> what actually can happen with the logo code as a whole.
>
> The whole problem started when I fixed an issue where the logos were
> accessed from a workqueue. I don't remember the details, but I think drm
> always (?) sets up some console stuff via workthread. In that case we
> could have the workthread accessing the logos, while initmem is being freed.
>
>>> So, maybe it would be better to not even try to go forward with the
>>> current approach. Two approaches come to my mind:
>>>
>>> 1) Keep the logos in the memory, and don't even try to free them. I
>>> don't know many bytes they are in total, though.
>>
>> m68k/allmodconfig:
>>
>> $ size drivers/video/logo/logo*o
>> text data bss dec hex filename
>> 24 6961 0 6985 1b49 drivers/video/logo/logo_linux_clut224.o
>> 24 800 0 824 338 drivers/video/logo/logo_linux_mono.o
>> 24 3200 0 3224 c98 drivers/video/logo/logo_linux_vga16.o
>> 24 6955 0 6979 1b43 drivers/video/logo/logo_mac_clut224.o
>> 161 4 2 167 a7 drivers/video/logo/logo.o
>>
>> Not that bad... Custom logos may be larger, though.
>
> I wonder how much a simple RLE would cut down the sizes...
>
>>> 2) Make a copy of the logos to a kmalloced area at some early boot
>>> stage. Then manually free the logos at some point (after the first
>>> access to the logos? after a certain time (urgh...)?).
>>
>> 3) Draw the logos from an initcall on all frame buffers that exist at that
>> point in time. Yes, this will destroy (part of) the content that's
>> currently shown.
>
> Isn't that almost the same as now? The problem is that the fb probes are
> deferred to a very late stage, so we would not have the fbs when the
> suggested initcall would be called.
Yes, exactly, this is my problem. DRM gets probed early and returns with
EPROBE_DEFER, as the display needs a spi init sequence, but spi is not
running yet ... later, when spi is up, DRM probes again, and all is
fine, but the logo is not drawn, as fb_logo_late_init() is called before,
which prevents drawing the logo.
We maybe could call fb_logo_late_init() directly from init/main.c
before calling free_initmem() ? But here again the question, could
it be possible that another core just draws the logo?
Or does async_synchronize_full() helps us here?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Geert Uytterhoeven @ 2015-05-26 7:25 UTC (permalink / raw)
To: hs
Cc: Tomi Valkeinen, linux-kernel@vger.kernel.org,
Linux Fbdev development list, Jean-Christophe Plagniol-Villard
In-Reply-To: <55641E1E.9010607@denx.de>
On Tue, May 26, 2015 at 9:17 AM, Heiko Schocher <hs@denx.de> wrote:
> 4) draw only one logo even on multicores ... why must every core draw
> a logo? Currently each core draws the logo, and on a system with more
> than 4 cores, I think this looks not really good ...
I don't think each core draws a logo. They're all drawn from fbcon_switch().
> Hmm... I do not really have a lot experience in this area ... but why
> is the logo only drawed when booting? Is there nothing like a "redraw"
> of it?
When do you want to redraw it? On VC switch (it's drawn on the first call
only, hence it disappears if you switch VC and back)?
Until when should it be redrawn?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [PATCH 15/21] backlight: Probe backlight devices on demand
From: Sascha Hauer @ 2015-05-26 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150526071850.GA11677@x1>
On Tue, May 26, 2015 at 08:18:50AM +0100, Lee Jones wrote:
> On Mon, 25 May 2015, Tomeu Vizoso wrote:
>
> > When looking up a backlight device through its DT node, ensure that the
> > corresponding device has been registered.
> >
> > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> > ---
> > drivers/video/backlight/backlight.c | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Looks reasonable.
>
> Until anyone screams at me, applied thanks.
The compiler will scream at you when it realizes that
of_platform_device_ensure() doesn't exist in your kernel...
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Geert Uytterhoeven @ 2015-05-26 7:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: hs, linux-kernel@vger.kernel.org, Linux Fbdev development list,
Jean-Christophe Plagniol-Villard
In-Reply-To: <55641D89.5020103@ti.com>
Hi Tomi,
On Tue, May 26, 2015 at 9:15 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> 3) Draw the logos from an initcall on all frame buffers that exist at that
>> point in time. Yes, this will destroy (part of) the content that's
>> currently shown.
>
> Isn't that almost the same as now? The problem is that the fb probes are
> deferred to a very late stage, so we would not have the fbs when the
> suggested initcall would be called.
Currently it's drawn from fbcon_switch().
Some drivers draw it independently from the fbcon code
(au1200fb_drv_probe() and mmpfb_probe()).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [PATCH 15/21] backlight: Probe backlight devices on demand
From: Lee Jones @ 2015-05-26 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1432565608-26036-16-git-send-email-tomeu.vizoso@collabora.com>
On Mon, 25 May 2015, Tomeu Vizoso wrote:
> When looking up a backlight device through its DT node, ensure that the
> corresponding device has been registered.
>
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> ---
> drivers/video/backlight/backlight.c | 3 +++
> 1 file changed, 3 insertions(+)
Looks reasonable.
Until anyone screams at me, applied thanks.
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index bddc8b1..fe7833b 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -12,6 +12,7 @@
> #include <linux/device.h>
> #include <linux/backlight.h>
> #include <linux/notifier.h>
> +#include <linux/of_platform.h>
> #include <linux/ctype.h>
> #include <linux/err.h>
> #include <linux/fb.h>
> @@ -559,6 +560,8 @@ struct backlight_device *of_find_backlight_by_node(struct device_node *node)
> {
> struct device *dev;
>
> + of_platform_device_ensure(node);
> +
> dev = class_find_device(backlight_class, NULL, node, of_parent_match);
>
> return dev ? to_backlight_device(dev) : NULL;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Heiko Schocher @ 2015-05-26 7:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-kernel, Geert Uytterhoeven, linux-fbdev,
Jean-Christophe Plagniol-Villard
In-Reply-To: <556418A9.8010603@ti.com>
Hello Tomi,
Am 26.05.2015 08:54, schrieb Tomi Valkeinen:
>
>
> On 26/05/15 06:56, Heiko Schocher wrote:
>
>>> Without locking, the initmem may be freed while fb_find_logo() is
>>> running.
>>
>> Yes, you are right, that must be added ... but has such a change a
>> chance to go in mainline?
>
> I don't know. To be honest, this whole thing feels a bit like hackery. I
Full Ack ;-)
> think initdata should only be accessed from initcalls, never asynchronously.
Yes.
>> BTW: Could this not be currently a problem on multicore systems?
>> If lets say core 2 just draws the logo, another core 1 calls
>> fb_logo_late_init() and later core 1 free_initmem(), while the core 2
>> still draws it?
>
> Yes, I think so...
>
> So, maybe it would be better to not even try to go forward with the
> current approach. Two approaches come to my mind:
>
> 1) Keep the logos in the memory, and don't even try to free them. I
> don't know many bytes they are in total, though.
That was my first thought too... but we waste memory ... not nice.
> 2) Make a copy of the logos to a kmalloced area at some early boot
> stage. Then manually free the logos at some point (after the first
> access to the logos? after a certain time (urgh...)?).
maybe yes ... or ...
3) wait for all cores, until they reached SYSTEM_FREEING_MEM and
free init mem only than? But are all cores used/started when booting?
4) draw only one logo even on multicores ... why must every core draw
a logo? Currently each core draws the logo, and on a system with more
than 4 cores, I think this looks not really good ...
Hmm... I do not really have a lot experience in this area ... but why
is the logo only drawed when booting? Is there nothing like a "redraw"
of it?
Maybe others have here a good idea?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Tomi Valkeinen @ 2015-05-26 7:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: hs, linux-kernel@vger.kernel.org, Linux Fbdev development list,
Jean-Christophe Plagniol-Villard
In-Reply-To: <CAMuHMdWHP6i15Z2qZJBEW9uz7kh1_ET5N1VbOKoMw1EC7F3O0g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]
On 26/05/15 10:08, Geert Uytterhoeven wrote:
> On Tue, May 26, 2015 at 8:54 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 26/05/15 06:56, Heiko Schocher wrote:
>>>> Without locking, the initmem may be freed while fb_find_logo() is
>>>> running.
>
> Or afterwards. Drivers may keep the pointer around indefinitely.
>
>>> Yes, you are right, that must be added ... but has such a change a
>>> chance to go in mainline?
>>
>> I don't know. To be honest, this whole thing feels a bit like hackery. I
>> think initdata should only be accessed from initcalls, never asynchronously.
>>
>>> BTW: Could this not be currently a problem on multicore systems?
>>> If lets say core 2 just draws the logo, another core 1 calls
>>> fb_logo_late_init() and later core 1 free_initmem(), while the core 2
>>> still draws it?
>>
>> Yes, I think so...
>
> I don't think that can happen. All initcalls should complete before initmem
> is freed.
Ah, true, the question was only about the initcalls. I was answering to
what actually can happen with the logo code as a whole.
The whole problem started when I fixed an issue where the logos were
accessed from a workqueue. I don't remember the details, but I think drm
always (?) sets up some console stuff via workthread. In that case we
could have the workthread accessing the logos, while initmem is being freed.
>> So, maybe it would be better to not even try to go forward with the
>> current approach. Two approaches come to my mind:
>>
>> 1) Keep the logos in the memory, and don't even try to free them. I
>> don't know many bytes they are in total, though.
>
> m68k/allmodconfig:
>
> $ size drivers/video/logo/logo*o
> text data bss dec hex filename
> 24 6961 0 6985 1b49 drivers/video/logo/logo_linux_clut224.o
> 24 800 0 824 338 drivers/video/logo/logo_linux_mono.o
> 24 3200 0 3224 c98 drivers/video/logo/logo_linux_vga16.o
> 24 6955 0 6979 1b43 drivers/video/logo/logo_mac_clut224.o
> 161 4 2 167 a7 drivers/video/logo/logo.o
>
> Not that bad... Custom logos may be larger, though.
I wonder how much a simple RLE would cut down the sizes...
>> 2) Make a copy of the logos to a kmalloced area at some early boot
>> stage. Then manually free the logos at some point (after the first
>> access to the logos? after a certain time (urgh...)?).
>
> 3) Draw the logos from an initcall on all frame buffers that exist at that
> point in time. Yes, this will destroy (part of) the content that's
> currently shown.
Isn't that almost the same as now? The problem is that the fb probes are
deferred to a very late stage, so we would not have the fbs when the
suggested initcall would be called.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).