[PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[Kuninori Morimoto]

MERAM can be used for other IP blocks as well in the future.
It doesn't necessarily mean that the MERAM driver depends on the LCDC.
This patch corrects dependency.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v3 -> v4

- move config to before endpoint

 drivers/video/Kconfig |   23 +++++++++++------------
 1 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8951cbd..0fb9540 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
 	---help---
 	  Driver for the on-chip SH-Mobile HDMI controller.
 
-config FB_SH_MOBILE_MERAM
-	tristate "SuperH Mobile MERAM read ahead support for LCDC"
-	depends on FB_SH_MOBILE_LCDC
-	default y
-	---help---
-	  Enable MERAM support for the SH-Mobile LCD controller.
-
-	  This will allow for caching of the framebuffer to provide more
-	  reliable access under heavy main memory bus traffic situations.
-	  Up to 4 memory channels can be configured, allowing 4 RGB or
-	  2 YCbCr framebuffers to be configured.
-
 config FB_TMIO
 	tristate "Toshiba Mobile IO FrameBuffer support"
 	depends on FB && MFD_CORE
@@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
 	source "drivers/video/logo/Kconfig"
 endif
 
+config FB_SH_MOBILE_MERAM
+	tristate "SuperH Mobile MERAM read ahead support"
+	depends on (SUPERH || ARCH_SHMOBILE)
+	---help---
+	  Enable MERAM support for the SuperH controller.
+
+	  This will allow for caching of the framebuffer to provide more
+	  reliable access under heavy main memory bus traffic situations.
+	  Up to 4 memory channels can be configured, allowing 4 RGB or
+	  2 YCbCr framebuffers to be configured.
+
 endmenu
-- 
1.7.5.4

Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[Laurent Pinchart]

Hi Morimoto-san,

On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v3 -> v4
> 
> - move config to before endpoint

As the driver doesn't depend on FB and can also be used by other subsystems, 
would it make sense to move it out of drivers/video/ ? drivers/sh/ might be a 
candidate, although I think selecting a location based on the platform is 
frowned upon (drivers/platform/x86 comes to mind). There's probably a better 
location.

>  drivers/video/Kconfig |   23 +++++++++++------------
>  1 files changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 8951cbd..0fb9540 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
>  	---help---
>  	  Driver for the on-chip SH-Mobile HDMI controller.
> 
> -config FB_SH_MOBILE_MERAM
> -	tristate "SuperH Mobile MERAM read ahead support for LCDC"
> -	depends on FB_SH_MOBILE_LCDC
> -	default y
> -	---help---
> -	  Enable MERAM support for the SH-Mobile LCD controller.
> -
> -	  This will allow for caching of the framebuffer to provide more
> -	  reliable access under heavy main memory bus traffic situations.
> -	  Up to 4 memory channels can be configured, allowing 4 RGB or
> -	  2 YCbCr framebuffers to be configured.
> -
>  config FB_TMIO
>  	tristate "Toshiba Mobile IO FrameBuffer support"
>  	depends on FB && MFD_CORE
> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
>  	source "drivers/video/logo/Kconfig"
>  endif
> 
> +config FB_SH_MOBILE_MERAM
> +	tristate "SuperH Mobile MERAM read ahead support"
> +	depends on (SUPERH || ARCH_SHMOBILE)
> +	---help---
> +	  Enable MERAM support for the SuperH controller.
> +
> +	  This will allow for caching of the framebuffer to provide more
> +	  reliable access under heavy main memory bus traffic situations.
> +	  Up to 4 memory channels can be configured, allowing 4 RGB or
> +	  2 YCbCr framebuffers to be configured.
> +
>  endmenu
-- 
Regards,

Laurent Pinchart

Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[Florian Tobias Schandinat]

Hi Laurent,

On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> Hi Morimoto-san,
> 
> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
>> MERAM can be used for other IP blocks as well in the future.
>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
>> This patch corrects dependency.
>>
>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> ---
>> v3 -> v4
>>
>> - move config to before endpoint
> 
> As the driver doesn't depend on FB and can also be used by other subsystems, 
> would it make sense to move it out of drivers/video/ ? drivers/sh/ might be a 
> candidate, although I think selecting a location based on the platform is 
> frowned upon (drivers/platform/x86 comes to mind). There's probably a better 
> location.

Well, as long as it is related to video/graphic I think drivers/video is
a good location. There are also backlight and console in that directory
without being directly related to the framebuffer subsystem.


Best regards,

Florian Tobias Schandinat

> 
>>  drivers/video/Kconfig |   23 +++++++++++------------
>>  1 files changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 8951cbd..0fb9540 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
>>  	---help---
>>  	  Driver for the on-chip SH-Mobile HDMI controller.
>>
>> -config FB_SH_MOBILE_MERAM
>> -	tristate "SuperH Mobile MERAM read ahead support for LCDC"
>> -	depends on FB_SH_MOBILE_LCDC
>> -	default y
>> -	---help---
>> -	  Enable MERAM support for the SH-Mobile LCD controller.
>> -
>> -	  This will allow for caching of the framebuffer to provide more
>> -	  reliable access under heavy main memory bus traffic situations.
>> -	  Up to 4 memory channels can be configured, allowing 4 RGB or
>> -	  2 YCbCr framebuffers to be configured.
>> -
>>  config FB_TMIO
>>  	tristate "Toshiba Mobile IO FrameBuffer support"
>>  	depends on FB && MFD_CORE
>> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
>>  	source "drivers/video/logo/Kconfig"
>>  endif
>>
>> +config FB_SH_MOBILE_MERAM
>> +	tristate "SuperH Mobile MERAM read ahead support"
>> +	depends on (SUPERH || ARCH_SHMOBILE)
>> +	---help---
>> +	  Enable MERAM support for the SuperH controller.
>> +
>> +	  This will allow for caching of the framebuffer to provide more
>> +	  reliable access under heavy main memory bus traffic situations.
>> +	  Up to 4 memory channels can be configured, allowing 4 RGB or
>> +	  2 YCbCr framebuffers to be configured.
>> +
>>  endmenu

Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[Laurent Pinchart]

Hi Florian,

On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> > On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> >> MERAM can be used for other IP blocks as well in the future.
> >> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> >> This patch corrects dependency.
> >> 
> >> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >> ---
> >> v3 -> v4
> >> 
> >> - move config to before endpoint
> > 
> > As the driver doesn't depend on FB and can also be used by other
> > subsystems, would it make sense to move it out of drivers/video/ ?
> > drivers/sh/ might be a candidate, although I think selecting a location
> > based on the platform is frowned upon (drivers/platform/x86 comes to
> > mind). There's probably a better location.
> 
> Well, as long as it is related to video/graphic I think drivers/video is
> a good location. There are also backlight and console in that directory
> without being directly related to the framebuffer subsystem.

The MERAM can also be used by the video engine unit (a memory-to-memory format 
conversion block), the video processing unit (a multi-codec module), the 
capture engine unit (camera interface), the JPEG engine unit (a JPEG codec), 
... Not all of those are related to display, although they're all related to 
display, imaging, and or/video. 

-- 
Regards,

Laurent Pinchart

Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[Florian Tobias Schandinat]

Hi Laurent,

On 03/21/2012 02:09 PM, Laurent Pinchart wrote:
> On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
>> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
>>> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
>>>> MERAM can be used for other IP blocks as well in the future.
>>>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
>>>> This patch corrects dependency.
>>>>
>>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>>> ---
>>>> v3 -> v4
>>>>
>>>> - move config to before endpoint
>>>
>>> As the driver doesn't depend on FB and can also be used by other
>>> subsystems, would it make sense to move it out of drivers/video/ ?
>>> drivers/sh/ might be a candidate, although I think selecting a location
>>> based on the platform is frowned upon (drivers/platform/x86 comes to
>>> mind). There's probably a better location.
>>
>> Well, as long as it is related to video/graphic I think drivers/video is
>> a good location. There are also backlight and console in that directory
>> without being directly related to the framebuffer subsystem.
> 
> The MERAM can also be used by the video engine unit (a memory-to-memory format 
> conversion block), the video processing unit (a multi-codec module), the 
> capture engine unit (camera interface), the JPEG engine unit (a JPEG codec), 
> ... Not all of those are related to display, although they're all related to 
> display, imaging, and or/video. 

I see, thanks for the explanation.
I applied this patch so it can be used for such purposes without the
dependency. If there will be a better place for it in the future we can
move it than.


Best regards,

Florian Tobias Schandinat

Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[Laurent Pinchart]

Hi Florian,

On Wednesday 21 March 2012 14:26:01 Florian Tobias Schandinat wrote:
> On 03/21/2012 02:09 PM, Laurent Pinchart wrote:
> > On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
> >> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> >>> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> >>>> MERAM can be used for other IP blocks as well in the future.
> >>>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> >>>> This patch corrects dependency.
> >>>> 
> >>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >>>> ---
> >>>> v3 -> v4
> >>>> 
> >>>> - move config to before endpoint
> >>> 
> >>> As the driver doesn't depend on FB and can also be used by other
> >>> subsystems, would it make sense to move it out of drivers/video/ ?
> >>> drivers/sh/ might be a candidate, although I think selecting a location
> >>> based on the platform is frowned upon (drivers/platform/x86 comes to
> >>> mind). There's probably a better location.
> >> 
> >> Well, as long as it is related to video/graphic I think drivers/video is
> >> a good location. There are also backlight and console in that directory
> >> without being directly related to the framebuffer subsystem.
> > 
> > The MERAM can also be used by the video engine unit (a memory-to-memory
> > format conversion block), the video processing unit (a multi-codec
> > module), the capture engine unit (camera interface), the JPEG engine unit
> > (a JPEG codec), ... Not all of those are related to display, although
> > they're all related to display, imaging, and or/video.
> 
> I see, thanks for the explanation.
> I applied this patch so it can be used for such purposes without the
> dependency. If there will be a better place for it in the future we can
> move it than.

Sounds good to me. Thank you.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC

[Florian Tobias Schandinat]

On 03/21/2012 01:27 AM, Kuninori Morimoto wrote:
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Applied.


Thanks,

Florian Tobias Schandinat

> ---
> v3 -> v4
> 
> - move config to before endpoint
> 
>  drivers/video/Kconfig |   23 +++++++++++------------
>  1 files changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 8951cbd..0fb9540 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
>  	---help---
>  	  Driver for the on-chip SH-Mobile HDMI controller.
>  
> -config FB_SH_MOBILE_MERAM
> -	tristate "SuperH Mobile MERAM read ahead support for LCDC"
> -	depends on FB_SH_MOBILE_LCDC
> -	default y
> -	---help---
> -	  Enable MERAM support for the SH-Mobile LCD controller.
> -
> -	  This will allow for caching of the framebuffer to provide more
> -	  reliable access under heavy main memory bus traffic situations.
> -	  Up to 4 memory channels can be configured, allowing 4 RGB or
> -	  2 YCbCr framebuffers to be configured.
> -
>  config FB_TMIO
>  	tristate "Toshiba Mobile IO FrameBuffer support"
>  	depends on FB && MFD_CORE
> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
>  	source "drivers/video/logo/Kconfig"
>  endif
>  
> +config FB_SH_MOBILE_MERAM
> +	tristate "SuperH Mobile MERAM read ahead support"
> +	depends on (SUPERH || ARCH_SHMOBILE)
> +	---help---
> +	  Enable MERAM support for the SuperH controller.
> +
> +	  This will allow for caching of the framebuffer to provide more
> +	  reliable access under heavy main memory bus traffic situations.
> +	  Up to 4 memory channels can be configured, allowing 4 RGB or
> +	  2 YCbCr framebuffers to be configured.
> +
>  endmenu