Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
>
> Signed-off-by: Heiner Kallweit
Acked-by: Peter Rosin
Cheers,
Peter
vicetree/bindings/mux/reg-mux.yaml
> @@ -25,8 +25,12 @@ properties:
> const: 1
>
>mux-reg-masks:
> -description: an array of register offset and pre-shifted bitfield mask
> - pairs, each describing a single mux control.
> +$ref: /schemas/types.yaml#/definiti
> Signed-off-by: Chuhong Yuan
Yup, my patch fumbled the locking. Sorry, and thanks for cleaning up my mess!
Acked-by: Peter Rosin
(Spelled that as Ached-by at first, what does that mean??)
Cheers,
Peter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 15 ++-
> 1 file c
-by: Thierry Reding
Suggested-by: Sam Ravnborg
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/panel/panel-simple.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac62b5
On 2020-03-03 15:20, Thierry Reding wrote:
> On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
>> On 2020-03-02 21:34, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> The currently listed dotclock disagrees with the currently
>>> liste
On 2020-03-03 16:05, Thierry Reding wrote:
> On Tue, Mar 03, 2020 at 02:57:45PM +0000, Peter Rosin wrote:
>>
>> On 2020-03-03 15:20, Thierry Reding wrote:
>>> On Mon, Mar 02, 2020 at 10:53:56PM +, Peter Rosin wrote:
>>>> On 2020-03-02 21:34, Ville Syrj
ut who can tell?
Cheers,
Peter
> Cc: Gustaf Lindström
> Cc: Peter Rosin
> Cc: Thierry Reding
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pane
On 2020-01-06 10:24, claudiu.bez...@microchip.com wrote:
> On 02.01.2020 11:08, Sam Ravnborg wrote:
>> On Wed, Dec 18, 2019 at 02:28:28PM +0200, Claudiu Beznea wrote:
>>> From: Peter Rosin
>>>
>>> The intention was to only select a higher pixel-clock rate
On 2019-12-13 10:28, claudiu.bez...@microchip.com wrote:
>
>
> On 11.12.2019 15:28, Peter Rosin wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 2019-12-11 12:45, claudiu.bez...@microchip.com wrote
On 2019-12-11 12:45, claudiu.bez...@microchip.com wrote:
>
>
> On 10.12.2019 19:22, Peter Rosin wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 2019-12-10 15:59, claudiu.bez...@microchip.com wrote
On 2019-12-10 15:59, claudiu.bez...@microchip.com wrote:
>
>
> On 10.12.2019 16:11, Peter Rosin wrote:
>> On 2019-12-10 14:24, Claudiu Beznea wrote:
>>> This reverts commit f6f7ad3234613f6f7f27c25036aaf078de07e9b0.
>>> ("drm/atmel-hlcdc: allow selecti
e revert based on some theory of a perceived risk of toasting a panel?
In short, this revert regresses my use case and I would like at least a hook to
re-enable the removed logic.
Cheers,
Peter
> Cc: Peter Rosin
> Signed-off-by: Claudiu Beznea
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_h
On 2019-08-27 13:35, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Tue, Aug 27, 2019 at 1:09 PM Peter Rosin wrote:
>> The variable is only ever used from fbcon.c which is linked into the
>> same module. Therefore, the export is not needed.
>>
>> Signed-off-by: Pet
Probably most useful if you want no logo at all, or if you only want one
logo regardless of how many CPU cores you have.
Signed-off-by: Peter Rosin
---
Documentation/fb/fbcon.rst | 5 +
drivers/video/fbdev/core/fbcon.c | 7 +++
drivers/video/fbdev/core/fbmem.c | 12
Three shall be the number thou shalt count, and the number of the
counting shall be three. Four shalt thou not count...
One! Two! Five!
Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console
documentation")
Signed-off-by: Peter Rosin
---
Documentation/fb/fbc
The variable is only ever used from fbcon.c which is linked into the
same module. Therefore, the export is not needed.
Signed-off-by: Peter Rosin
---
drivers/video/fbdev/core/fbmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core
_logo
Cheers,
Peter
Peter Rosin (3):
fbdev: fix numbering of fbcon options
fbdev: fbmem: allow overriding the number of bootup logos
fbdev: fbmem: avoid exporting fb_center_logo
Documentation/fb/fbcon.rst | 13 +
drivers/video/fbdev/core/fbcon.c | 7 +++
drivers/vid
On 2019-08-27 10:36, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Mon, Aug 26, 2019 at 10:46 PM Peter Rosin wrote:
>> Probably most useful if you only want one logo regardless of how many
>> CPU cores you have.
>>
>> Signed-off-by: Peter
he display to only one logo instead of one for each CPU core.
Changes since v1
- do not needlessly export fb_logo_count [Matthew Wilcox]
- added patch 3/3, which removes the export of fb_center_logo
Cheers,
Peter
Peter Rosin (3):
fbdev: fix numbering of fbcon options
fbdev: fbmem: allow
The variable is only ever used from fbcon.c which is linked into the
same module. Therefore, the export is not needed.
Signed-off-by: Peter Rosin
---
drivers/video/fbdev/core/fbmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core
Probably most useful if you only want one logo regardless of how many
CPU cores you have.
Signed-off-by: Peter Rosin
---
Documentation/fb/fbcon.rst | 5 +
drivers/video/fbdev/core/fbcon.c | 7 +++
drivers/video/fbdev/core/fbmem.c | 4 +++-
include/linux/fb.h | 1 +
4
Three shall be the number thou shalt count, and the number of the
counting shall be three. Four shalt thou not count...
One! Two! Five!
Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console
documentation")
Signed-off-by: Peter Rosin
---
Documentation/fb/fbc
he display to only one logo instead of one for each CPU core.
Cheers,
Peter
Peter Rosin (2):
fbdev: fix numbering of fbcon options
fbdev: fbmem: allow overriding the number of bootup logos
Documentation/fb/fbcon.rst | 13 +
drivers/video/fbdev/core/fbcon.c | 7 +++
dri
Probably most useful if you only want one logo regardless of how many
CPU cores you have.
Signed-off-by: Peter Rosin
---
Documentation/fb/fbcon.rst | 5 +
drivers/video/fbdev/core/fbcon.c | 7 +++
drivers/video/fbdev/core/fbmem.c | 5 -
include/linux/fb.h | 1
Three shall be the number thou shalt count, and the number of the
counting shall be three. Four shalt thou not count...
One! Two! Five!
Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console
documentation")
Signed-off-by: Peter Rosin
---
Documentation/fb/fbc
On 2019-08-24 17:34, Matthew Wilcox wrote:
> On Fri, Aug 23, 2019 at 08:47:47AM +0000, Peter Rosin wrote:
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -56,6 +56,9 @@ EXPORT_SYMBOL(num_registered_fb);
>> bool f
On 2019-06-08 12:55, Wolfram Sang wrote:
> While preparing a refactoring series, I noticed that some drivers use a
> complicated way of determining the adapter of a client. The easy way is
> to use the intended pointer: client->adapter
>
> These drivers do:
>
On 2019-01-27 09:27, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 15:10:28 +
> Peter Rosin wrote:
>
>> Hi!
>>
>> I found an unfortunate issue while recoding plane handling to use
>> drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
>&g
The gpio API explicitly allows skipping the NULL check, precisely to
allow for neat support for optional gpios. Which is exactly what is at
play here.
Reported-by: Andrzej Hajda
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 6 ++
1 file changed, 2 insertions(+), 4
On 2019-01-16 17:45, Bartlomiej Zolnierkiewicz wrote:
> On 01/07/2019 11:35 AM, Peter Rosin wrote:
>> Right. So, here's an update...
>>
>> Again, it would probably be best if this went in before 5.0 is released.
>>
>> Changes since v1:
>> - rename from
On 2019-01-10 18:48, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 15:10:39 +
> Peter Rosin wrote:
>
>> The destination crtc rectangle is independent of source plane rotation.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> drivers/gpu/drm/atmel-hlcdc
Make the code easier to read and modify.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index
Optionally power down the LVDS-encoder when it is not in use.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds
On 2019-01-10 21:16, Sam Ravnborg wrote:
> Hi Peter.
>
> (Hijacking this thread as I lost the orginal mails)
Assuming you wanted to reply to this patch?
https://patchwork.kernel.org/patch/10753571/
>>> I found an unfortunate issue while recoding plane handling to use
>>>
.
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
b/Documentation/devicetree
-transmitter
binding.
Cheers,
Peter
Peter Rosin (5):
dt-bindings: display: bridge: fork out ti,ds90c185 from
lvds-transmitter
dt-bindings: display: bridge: lvds-transmitter: cleanup example
dt-bindings: display: bridge: thc63lvdm83d: use standard
powerdown-gpios
drm/bridge: lvds-encoder
DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
binding, which is meant to be generic.
The sister chip DS90C187 is similar to DS90C185, describe it here as well.
Signed-off-by: Peter Rosin
---
.../bindings/display/bridge/lvds-transmitter.txt | 10 ++--
.../bindings
Drop #address-cells and #size-cells from the root node in the
example, they are unused.
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 --
1 file changed, 2 deletions(-)
diff --git
a/Documentation/devicetree
On 2019-01-10 20:25, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 18:51:21 +
> Peter Rosin wrote:
>
>> On 2019-01-10 18:29, Boris Brezillon wrote:
>>> On Thu, 10 Jan 2019 15:10:48 +
>>> Peter Rosin wrote:
>>>
>>>> The A2Q
Ouch, the driver rotates planes clockwise, which is simply not correct.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 30 -
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
.
Disabling the plane on the next frame shift is done with the EN bit,
so use that.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu
The destination crtc rectangle is independent of source plane rotation.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc
On 2019-01-10 18:45, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 15:10:28 +
> Peter Rosin wrote:
>
>> Hi!
>>
>> I found an unfortunate issue while recoding plane handling to use
>> drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
>&g
With the help from drm_atomic_helper_check_plane_state function, clipping
now handles planes to be partially or totally off-screen. The plane is
disabled if it is not visible.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 162 +---
1 file
for various other chips (sama5d2, sama5d4, sam9n12, sam9g15, sam9g35
and sam9x35) supported by the driver (relevant to patch 4/4).
Cheers,
Peter
Peter Rosin (4):
drm/atmel-hlcdc: rotate planes counterclockwise
drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated
drm/atmel
On 2019-01-10 18:29, Boris Brezillon wrote:
> On Thu, 10 Jan 2019 15:10:48 +
> Peter Rosin wrote:
>
>> The A2Q and UPDATE bits have no effect in the channel disable registers.
>> However, since they are present, assume that the intention is to disable
>> planes, n
On 2019-01-09 11:12, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 12:31:36PM +0000, Peter Rosin wrote:
>> While trying to temporarily hide a plane, one thing that was attempted
>> was to call (from libdrm)
>>
>> drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
&
e messages, but preserve the current behaviour that also happen to
make the plane disappear with the above call.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
Side note, when
On 2019-01-07 09:59, Peter Rosin wrote:
> On 2019-01-07 09:40, Geert Uytterhoeven wrote:
>> Hi Peter,
>>
>> On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wrote:
>>> On 2019-01-06 10:33, Geert Uytterhoeven wrote:
>>>> On Mon, Nov 26, 2018 at 10:59 PM Peter Ro
On 2019-01-07 10:11, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Mon, Jan 7, 2019 at 10:03 AM Peter Rosin wrote:
>> On 2019-01-07 09:59, Peter Rosin wrote:
>>> On 2019-01-07 09:40, Geert Uytterhoeven wrote:
>>>> On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wro
On 2019-01-06 10:33, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Mon, Nov 26, 2018 at 10:59 PM Peter Rosin wrote:
>> If there are extra logos (CONFIG_FB_LOGO_EXTRA) the heights of these
>> extra logos are not considered when centering the first logo vertically.
>>
&g
On 2019-01-07 09:40, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wrote:
>> On 2019-01-06 10:33, Geert Uytterhoeven wrote:
>>> On Mon, Nov 26, 2018 at 10:59 PM Peter Rosin wrote:
>>>> If there are extra logo
in order
to avoid clutter in the generic lvds-transmitter binding.
- added a patch to remove some surplus stuff in the generic lvds-transmitter
binding.
Cheers,
Peter
Peter Rosin (5):
dt-bindings: display: bridge: fork out ti,ds90c185 from
lvds-transmitter
dt-bindings: display: bridge: lvds
.
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
b/Documentation/devicetree/bindings/display/bridge
Drop #address-cells and #size-cells from the root node in the
example, they are unused.
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 --
1 file changed, 2 deletions(-)
diff --git
a/Documentation/devicetree
DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
binding, which is meant to be generic.
The sister chip DS90C187 is similar to DS90C185, describe it here as well.
Signed-off-by: Peter Rosin
---
.../bindings/display/bridge/lvds-transmitter.txt | 8 +---
.../bindings
Make the code easier to read and modify.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index
Optionally power down the LVDS-encoder when it is not in use.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds
On 2018-12-27 22:27, Rob Herring wrote:
> On Wed, Dec 19, 2018 at 02:04:47PM +0100, Peter Rosin wrote:
>> From: Peter Rosin
>>
>> DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
>> binding, which is meant to be generic.
>>
>> The sist
From: Peter Rosin
Drop #address-cells and #size-cells from the root node in the
example, they are unused.
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 --
1 file changed, 2 deletions(-)
diff --git
a/Documentation/devicetree
From: Peter Rosin
Hi!
I'm not sure if I should have added the texas chips to the lvds_encoder_match
list in the driver, right next to the thine,thc63lvdm83d entry, but ended
up not doing that. That can always be added later, it needed...
Changes since v1:
- fork out the bindings for the texas
On 2018-12-19 12:38, Laurent Pinchart wrote:
> Hello,
>
> On Wednesday, 19 December 2018 11:57:32 EET Peter Rosin wrote:
>> On 2018-12-19 10:12, Andrzej Hajda wrote:
>>> On 19.12.2018 00:19, Peter Rosin wrote:
>>>> Add optional property to specify a power
On 2018-12-19 10:12, Andrzej Hajda wrote:
> On 19.12.2018 00:19, Peter Rosin wrote:
>> Add optional property to specify a power-down GPIO.
>> The pwdn-gpios name is already in use by the thine,thc63lvdm83d
>> binding, so go with that.
>>
>> Signed-off-by: Pete
From: Peter Rosin
Optionally power down the LVDS-encoder when it is not in use.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm
From: Peter Rosin
DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
binding, which is meant to be generic.
The sister chip DS90C187 is similar to DS90C185, describe it here as well.
Signed-off-by: Peter Rosin
---
.../bindings/display/bridge/lvds-transmitter.txt | 8
This chip is compatible with "lvds-encoder".
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Doc
Optionally power down the LVDS-encoder when it is not in use.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds
Add optional property to specify a power-down GPIO.
The pwdn-gpios name is already in use by the thine,thc63lvdm83d
binding, so go with that.
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi!
These patches are useful for me. Please consider merging.
Cheers,
Peter
Peter Rosin (3):
dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c187
dt-bindings: display: bridge: lvds-transmitter: add pwdn-gpios
drm/bridge: add pwdn-gpios support to the lvds-encoder
.../bindings
Ping?!
Cheers,
Peter
On 2018-11-08 10:54, Peter Rosin wrote:
> Blitting an image with "negative" offsets is not working since there
> is no clipping. It hopefully just crashes. For the bootup logo, there
> is protection so that blitting does not happen as the image is drawn
&g
In preparation for allowing centering of the bootup logo, make
fb_show_logo_line return where the next free framebuffer line is,
instead of returning the height of the shown logo.
Signed-off-by: Peter Rosin
---
drivers/video/fbdev/core/fbmem.c | 6 +++---
1 file changed, 3 insertions(+), 3
On 2018-11-26 15:33, Bartlomiej Zolnierkiewicz wrote:
> On 11/26/2018 03:16 PM, Peter Rosin wrote:
>> Ping?!
>
> Hi,
>
> Thank you for your patch, it will be considered for 4.21 (as it is not
> a recent regression + I'm busy with other things currently).
Right, th
If there are extra logos (CONFIG_FB_LOGO_EXTRA) the heights of these
extra logos are not considered when centering the first logo vertically.
Signed-off-by: Peter Rosin
---
drivers/video/fbdev/core/fbmem.c | 25 -
drivers/video/logo/Kconfig | 9 +
2 files
Hi!
I'm using these patches to get early display output at the center of
the screen. Maybe someone else will also find that useful?
Cheers,
Peter
Peter Rosin (2):
fbdev: fbmem: make fb_show_logo_line return the end instead of the
height
fbdev: fbmem: add config option to center
t to select I2C_MUX. So, even if it
it is a bit untidy to select stuff that is also selectable by the
user...
Acked-by: Peter Rosin
>
> Fixes: 21d808405fe4 ("drm/bridge/sii902x: Fix EDID readback")
> Signed-off-by: Fabrizio Castro
> Link: https://lists.01.org/pipermail/kbuild-all/
n of the driver, this patch won't require any DT
> changes.
>
> Since we don't want any interference during the DDC Bus
> Request/Grant procedure and while talking to the monitor, we
> have to use the adapter locking primitives rather than the
> i2c-mux locking primitives.
>
Hi!
I'm wondering about some programming details regarding the TDA998x
driver...
The bindings documentation [1] state that one should fill in the
desired register content of the AP_ENA register. However, I cannot
find any details anywhere about how one determines what is desired.
When I look for
On 2018-11-13 20:09, Russell King - ARM Linux wrote:
> On Tue, Nov 13, 2018 at 06:12:37PM +0000, Peter Rosin wrote:
>> On 2018-11-13 18:24, Russell King - ARM Linux wrote:
>>> On Tue, Nov 13, 2018 at 01:28:40PM +, Peter Rosin wrote:
>>>> Hi!
>>>>
On 2018-11-13 18:24, Russell King - ARM Linux wrote:
> On Tue, Nov 13, 2018 at 01:28:40PM +0000, Peter Rosin wrote:
>> Hi!
>>
>> I'm wondering about some programming details regarding the TDA998x
>> driver...
>>
>> The bindings documentation [1] state
On 2018-08-02 08:06, Peter Rosin wrote:
> On 2018-08-01 11:35, Russell King - ARM Linux wrote:
>> On Wed, Aug 01, 2018 at 11:01:12AM +0200, Peter Rosin wrote:
>>> I don't think it's a problem with the atmel I2C driver. IIRC, the
>>> tda998x driver issues the comma
n of the driver, this patch won't require any DT
> changes.
>
> Since we don't want any interference during the DDC Bus
> Request/Grant procedure and while talking to the monitor, we
> have to use the adapter locking primitives rather than the
> i2c-mux locking primitiv
alues") is also to blame, methinks.
Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin
---
drivers/video/fbdev/core/fbmem.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/
t; i2c-mux locking primitives.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v1->v2:
> * Incorporated comments from Peter Rosin
>
> drivers/gpu/drm/bridge/sii902x.c | 256
> ---
> 1 file changed, 188 insertions(+), 68 de
gt; Signed-off-by: Fabrizio Castro
> ---
> RFC->PATCH:
> * Incorporated Linus Walleij, Peter Rosin, and Mark Brown comments
>
> Thank you guys
>
> drivers/gpu/drm/bridge/sii902x.c | 264
> +--
> 1 file changed, 196 inserti
On 2018-11-02 17:16, Fabrizio Castro wrote:
>>> Here (and also in sii902x_i2c_bypass_deselect) you do a rmw access to the
>>> SII902X_SYS_CTRL_DATA register without coordinating with regmap. Regmap is
>>> also doing rmw accesses to that register in other parts of the driver. I
>>> think you need
gt; Signed-off-by: Fabrizio Castro
> ---
> RFC->PATCH:
> * Incorporated Linus Walleij, Peter Rosin, and Mark Brown comments
>
> Thank you guys
>
> drivers/gpu/drm/bridge/sii902x.c | 264
> +--
> 1 file changed, 196 inserti
On 2018-11-01 18:32, Fabrizio Castro wrote:
> Hello Peter,
>
> Thank you for your feedback!
>
>> Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback
>
> snip
>
>>>
>>> To further detail the problem, the system is vulnerable from before the
>>> last write
>>> performed by
On 2018-11-01 17:04, Fabrizio Castro wrote:
> Hello Peter,
>
> Thank you for your feedback!
>
>>> The "mux-locked" implementation was the one I first tried and I discovered
>>> it doesn't work for me, as other traffic on the parent adapter can get in
>>> the
>>> way. What we need for this
On 2018-11-01 12:04, Fabrizio Castro wrote:
> Hello Peter,
>
> Thank you for your feedback!
>
> snip
>
>>> Yeah, there is some issue with locking here, and that's coming down
>>> from the fact that when we call into drm_get_edid, we implicitly call
>>> i2c_transfer which ultimately locks the
On 2018-10-31 17:55, Fabrizio Castro wrote:
> Hello Linus,
>
>> Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback
>>
>> Hi Fabrizio,
>>
>> thanks for your patch!
>
> Thank you for your feedback!
>
>>
>> On Wed, Oct 31, 2018 at 1:58 PM Fabrizio Castro
>> wrote:
>>
>>> While adding
On 2018-07-06 14:43, Russell King - ARM Linux wrote:
> On Fri, Jul 06, 2018 at 11:03:46AM +0100, Russell King - ARM Linux wrote:
>> On Wed, Apr 25, 2018 at 11:01:15PM +0300, Jyri Sarha wrote:
>>> Oh yes. But in this case the substandard solution is already there and
>>> it is already widely used,
On 2018-08-27 21:24, Boris Brezillon wrote:
> On Sat, 25 Aug 2018 10:56:16 +0200
> Peter Rosin wrote:
>
>> Hi!
>>
>> The background for these patches is that our PCB interface between
>> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
>
On 2018-08-27 22:40, Boris Brezillon wrote:
> On Mon, 27 Aug 2018 22:35:05 +0200
> Boris Brezillon wrote:
>
>> On Mon, 27 Aug 2018 22:31:22 +0200
>> Peter Rosin wrote:
>>
>>> On 2018-08-27 21:24, Boris Brezillon wrote:
>>>> On Sat, 25
quot; issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon
Reviewed-by: Rob Herring
Reviewed-by: Jacopo Mondi
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/display/atmel/hlcdc-dc.txt | 23 ++
1 file changed, 23 insertions(+)
diff -
r symmetry
- reformatted comments a little bit
- spelling/grammar fixes
Peter Rosin (2):
drm/atmel-hlcdc: prefer a higher rate clock as pixel-clock base
drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 30 +++
This enables more flexible devicetrees. You can e.g. have two output
nodes where one is not enabled, without the ordering affecting things.
Prior to this patch the active nodes had to have endpoint id zero and
upwards consecutively.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc
he sys_clk
is 132MHz. In this case the highest possible pixel-clock lower than the
requested 65MHz is 52.8MHz, which is almost 20% off (and outside the
spec for the panel). The lowest possible pixel-clock higher than 65MHz
is 66MHz, which is a *much* better match, and only 1.5% off.
Signed-off-by: P
k is 65MHz and the sys_clk
is 132MHz. In this case the highest possible pixel-clock lower than the
requested 65MHz is 52.8MHz, which is almost 20% off (and outside the
spec for the panel). The lowest possible pixel-clock higher than 65MHz
is 66MHz, which is a *much* better match, and only 1.5% off.
Signed-off
Hi!
Some background can be found here:
https://lists.freedesktop.org/archives/dri-devel/2018-August/187182.html
The "10 times" discriminator in patch 2/2 can certainly be discussed...
Cheers,
Peter
Peter Rosin (2):
drm/atmel-hlcdc: prefer a higher rate clock as pixel-clock base
ue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon
Reviewed-by: Jacopo Mondi
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 +++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel
1 - 100 of 496 matches
Mail list logo
