from:"Hector"

This is the format used by the bootloader framebuffer on Apple ARM64
platforms.

Reviewed-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2f15b9aa..b977f5c94562 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -571,8 +571,8 @@ static const uint32_t simpledrm_default_formats[] = {
//DRM_FORMAT_XRGB1555,
//DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB888,
-   //DRM_FORMAT_XRGB2101010,
-   //DRM_FORMAT_ARGB2101010,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_ARGB2101010,
 };
 
 static const uint64_t simpledrm_format_modifiers[] = {
-- 
2.33.0

[PATCH v3 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_toio()

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/drm_format_helper.c | 64 +
 include/drm/drm_format_helper.h |  3 ++
 2 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index dbe3e830096e..0f28dd2bdd72 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -409,6 +409,61 @@ void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, 
unsigned int dst_pitch,
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
 
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, const u32 *sbuf,
+   unsigned int pixels)
+{
+   unsigned int x;
+   u32 val32;
+
+   for (x = 0; x < pixels; x++) {
+   val32 = ((sbuf[x] & 0x00FF) << 2) |
+   ((sbuf[x] & 0xFF00) << 4) |
+   ((sbuf[x] & 0x00FF) << 6);
+   *dbuf++ = val32 | ((val32 >> 8) & 0x00300C03);
+   }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb2101010_toio - Convert XRGB to XRGB2101010 clip
+ * buffer
+ * @dst: XRGB2101010 destination buffer (iomem)
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for XRGB2101010 devices that don't natively
+ * support XRGB.
+ */
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst,
+unsigned int dst_pitch, const void 
*vaddr,
+const struct drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+   size_t linepixels = clip->x2 - clip->x1;
+   size_t dst_len = linepixels * sizeof(u32);
+   unsigned int y, lines = clip->y2 - clip->y1;
+   void *dbuf;
+
+   if (!dst_pitch)
+   dst_pitch = dst_len;
+
+   dbuf = kmalloc(dst_len, GFP_KERNEL);
+   if (!dbuf)
+   return;
+
+   vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
+   for (y = 0; y < lines; y++) {
+   drm_fb_xrgb_to_xrgb2101010_line(dbuf, vaddr, linepixels);
+   memcpy_toio(dst, dbuf, dst_len);
+   vaddr += fb->pitches[0];
+   dst += dst_pitch;
+   }
+
+   kfree(dbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
+
 /**
  * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
@@ -500,6 +555,10 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
fb_format = DRM_FORMAT_XRGB;
if (dst_format == DRM_FORMAT_ARGB)
dst_format = DRM_FORMAT_XRGB;
+   if (fb_format == DRM_FORMAT_ARGB2101010)
+   fb_format = DRM_FORMAT_XRGB2101010;
+   if (dst_format == DRM_FORMAT_ARGB2101010)
+   dst_format = DRM_FORMAT_XRGB2101010;
 
if (dst_format == fb_format) {
drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
@@ -515,6 +574,11 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap, 
fb, clip);
return 0;
}
+   } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_xrgb2101010_toio(dst, dst_pitch, 
vmap, fb, clip);
+   return 0;
+   }
}
 
return -EINVAL;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 97e4c3223af3..b30ed5de0a33 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -33,6 +33,9 @@ void drm_fb_xrgb_to_rgb888(void *dst, unsigned int 
dst_pitch, const void *sr
 void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, unsigned int dst_pitch,
const void *vaddr, const struct 
drm_framebuffer *fb,
const struct drm_rect *clip);
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst, unsigned int 
dst_pitch,
+const void *vaddr, const struct 
drm_framebuffer *fb,
+const struct drm_rect *clip);
 void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void 
*vaddr,
  const struct drm_framebuffer *fb, const struct 
drm_rect *clip);
 
-- 
2.33.0

[PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of

This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.

Acked-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
 drivers/of/platform.c  |  4 
 drivers/video/fbdev/simplefb.c | 21 +
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..793350028906 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,10 @@ static int __init of_platform_default_populate_init(void)
of_node_put(node);
}
 
+   node = of_get_compatible_child(of_chosen, "simple-framebuffer");
+   of_platform_device_create(node, NULL, NULL);
+   of_node_put(node);
+
/* Populate everything else. */
of_platform_default_populate(NULL, NULL, NULL);
 
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index b63074fd892e..57541887188b 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -541,26 +541,7 @@ static struct platform_driver simplefb_driver = {
.remove = simplefb_remove,
 };
 
-static int __init simplefb_init(void)
-{
-   int ret;
-   struct device_node *np;
-
-   ret = platform_driver_register(_driver);
-   if (ret)
-   return ret;
-
-   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
-   for_each_child_of_node(of_chosen, np) {
-   if (of_device_is_compatible(np, "simple-framebuffer"))
-   of_platform_device_create(np, NULL, NULL);
-   }
-   }
-
-   return 0;
-}
-
-fs_initcall(simplefb_init);
+module_platform_driver(simplefb_driver);
 
 MODULE_AUTHOR("Stephen Warren ");
 MODULE_DESCRIPTION("Simple framebuffer driver");
-- 
2.33.0

[PATCH v3 0/3] drm/simpledrm: Apple M1 / DT platform support fixes

Hi DRM folks,

This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.

This avoids breaking the bootloader-provided framebuffer console when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).

Changes since v2:
- Made 10-bit conversion code fill the LSBs
- Added ARGB2101010 to supported formats list
- Simplified OF core code per review feedback
Hector Martin (3):
  of: Move simple-framebuffer device handling from simplefb to of
  drm/format-helper: Add drm_fb_xrgb_to_xrgb2101010_toio()
  drm/simpledrm: Add [AX]RGB2101010 formats

 drivers/gpu/drm/drm_format_helper.c | 64 +
 drivers/gpu/drm/tiny/simpledrm.c|  4 +-
 drivers/of/platform.c   |  4 ++
 drivers/video/fbdev/simplefb.c  | 21 +-
 include/drm/drm_format_helper.h |  3 ++
 5 files changed, 74 insertions(+), 22 deletions(-)

-- 
2.33.0

[jira] [Updated] (KAFKA-13521) Supress changelog schema version breaks migration

2021-12-08 Thread Hector Geraldino (Jira)



 [ 
https://issues.apache.org/jira/browse/KAFKA-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hector Geraldino updated KAFKA-13521:
-
Issue Type: Bug  (was: Improvement)

> Supress changelog schema version breaks migration
> -
>
> Key: KAFKA-13521
> URL: https://issues.apache.org/jira/browse/KAFKA-13521
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 2.4.0, 2.5.0, 2.5.1
>Reporter: Hector Geraldino
>Priority: Major
>
> Hi,
> We recently updated the kafka-streams library in one of our apps from v2.5.0 
> to v2.5.1. This upgrade changes the header format of the state store for 
> suppress changelog topics (see 
> https://issues.apache.org/jira/browse/KAFKA-10173 and 
> [https://github.com/apache/kafka/pull/8905)]
> What we noticed was that, introducing a new version on the binary schema 
> header breaks older clients. I.e. applications running on v2.5.1 can parse 
> the v3, v2, v1 and 0 headers, while the ones running on 2.5.0 (and, I assume, 
> previous versions) cannot read headers in v3 format.
> The logged exception is:
>  
> {code:java}
> java.lang.IllegalArgumentException: Restoring apparently invalid changelog 
> record: ConsumerRecord(topic = 
> msgequator-kfns-msgequator-msgequator-suppress-buffer-store-changelog, 
> partition = 8, leaderEpoch = 405, offset = 711400430, CreateTime = 
> 1638828473341, serialized key size = 32, serialized value size = 90, headers 
> = RecordHeaders(headers = [RecordHeader(key = v, value = [3])], isReadOnly = 
> false), key = [B@5cf0e540, value = [B@40abc004)
>   at 
> org.apache.kafka.streams.state.internals.InMemoryTimeOrderedKeyValueBuffer.restoreBatch(InMemoryTimeOrderedKeyValueBuffer.java:372)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.CompositeRestoreListener.restoreBatch(CompositeRestoreListener.java:89)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StateRestorer.restore(StateRestorer.java:92)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StoreChangelogReader.processNext(StoreChangelogReader.java:350)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StoreChangelogReader.restore(StoreChangelogReader.java:94)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.TaskManager.updateNewAndRestoringTasks(TaskManager.java:401)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:779)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:697)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:670)
>  ~[msgequator-1.59.3.jar:1.59.3] {code}
>  
>  
> There's obviously no clear solution for this other than stopping/starting all 
> instances at once. A rolling bounce that takes some time to complete (in our 
> case, days) will break  instances that haven't been upgraded yet after a 
> rebalance that causes older clients to pick up the newly encoded changelog 
> partition(s)
>  
> I don't know if adding a flag on the client side that lists the supported 
> protocol versions (so it behaves like Kafka Consumers when picking the 
> rebalance protocol - cooperative or eager), or if it just needs to be 
> explicitly stated on the migration guide that a full stop/start migration is 
> required in cases where the protocol version changes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (KAFKA-13521) Supress changelog schema version breaks migration

2021-12-08 Thread Hector Geraldino (Jira)

Hector Geraldino created KAFKA-13521:


 Summary: Supress changelog schema version breaks migration
 Key: KAFKA-13521
 URL: https://issues.apache.org/jira/browse/KAFKA-13521
 Project: Kafka
  Issue Type: Improvement
  Components: streams
Affects Versions: 2.5.1, 2.5.0, 2.4.0
Reporter: Hector Geraldino


Hi,

We recently updated the kafka-streams library in one of our apps from v2.5.0 to 
v2.5.1. This upgrade changes the header format of the state store for suppress 
changelog topics (see https://issues.apache.org/jira/browse/KAFKA-10173 and 
[https://github.com/apache/kafka/pull/8905)]

What we noticed was that, introducing a new version on the binary schema header 
breaks older clients. I.e. applications running on v2.5.1 can parse the v3, v2, 
v1 and 0 headers, while the ones running on 2.5.0 (and, I assume, previous 
versions) cannot read headers in v3 format.

The logged exception is:

 
{code:java}
java.lang.IllegalArgumentException: Restoring apparently invalid changelog 
record: ConsumerRecord(topic = 
msgequator-kfns-msgequator-msgequator-suppress-buffer-store-changelog, 
partition = 8, leaderEpoch = 405, offset = 711400430, CreateTime = 
1638828473341, serialized key size = 32, serialized value size = 90, headers = 
RecordHeaders(headers = [RecordHeader(key = v, value = [3])], isReadOnly = 
false), key = [B@5cf0e540, value = [B@40abc004)
at 
org.apache.kafka.streams.state.internals.InMemoryTimeOrderedKeyValueBuffer.restoreBatch(InMemoryTimeOrderedKeyValueBuffer.java:372)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.CompositeRestoreListener.restoreBatch(CompositeRestoreListener.java:89)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StateRestorer.restore(StateRestorer.java:92)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.processNext(StoreChangelogReader.java:350)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.restore(StoreChangelogReader.java:94)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.TaskManager.updateNewAndRestoringTasks(TaskManager.java:401)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:779)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:697)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:670)
 ~[msgequator-1.59.3.jar:1.59.3] {code}
 

 

There's obviously no clear solution for this other than stopping/starting all 
instances at once. A rolling bounce that takes some time to complete (in our 
case, days) will break  instances that haven't been upgraded yet after a 
rebalance that causes older clients to pick up the newly encoded changelog 
partition(s)

 

I don't know if adding a flag on the client side that lists the supported 
protocol versions (so it behaves like Kafka Consumers when picking the 
rebalance protocol - cooperative or eager), or if it just needs to be 
explicitly stated on the migration guide that a full stop/start migration is 
required in cases where the protocol version changes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (KAFKA-13521) Supress changelog schema version breaks migration

2021-12-08 Thread Hector Geraldino (Jira)

Hector Geraldino created KAFKA-13521:


 Summary: Supress changelog schema version breaks migration
 Key: KAFKA-13521
 URL: https://issues.apache.org/jira/browse/KAFKA-13521
 Project: Kafka
  Issue Type: Improvement
  Components: streams
Affects Versions: 2.5.1, 2.5.0, 2.4.0
Reporter: Hector Geraldino


Hi,

We recently updated the kafka-streams library in one of our apps from v2.5.0 to 
v2.5.1. This upgrade changes the header format of the state store for suppress 
changelog topics (see https://issues.apache.org/jira/browse/KAFKA-10173 and 
[https://github.com/apache/kafka/pull/8905)]

What we noticed was that, introducing a new version on the binary schema header 
breaks older clients. I.e. applications running on v2.5.1 can parse the v3, v2, 
v1 and 0 headers, while the ones running on 2.5.0 (and, I assume, previous 
versions) cannot read headers in v3 format.

The logged exception is:

 
{code:java}
java.lang.IllegalArgumentException: Restoring apparently invalid changelog 
record: ConsumerRecord(topic = 
msgequator-kfns-msgequator-msgequator-suppress-buffer-store-changelog, 
partition = 8, leaderEpoch = 405, offset = 711400430, CreateTime = 
1638828473341, serialized key size = 32, serialized value size = 90, headers = 
RecordHeaders(headers = [RecordHeader(key = v, value = [3])], isReadOnly = 
false), key = [B@5cf0e540, value = [B@40abc004)
at 
org.apache.kafka.streams.state.internals.InMemoryTimeOrderedKeyValueBuffer.restoreBatch(InMemoryTimeOrderedKeyValueBuffer.java:372)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.CompositeRestoreListener.restoreBatch(CompositeRestoreListener.java:89)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StateRestorer.restore(StateRestorer.java:92)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.processNext(StoreChangelogReader.java:350)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.restore(StoreChangelogReader.java:94)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.TaskManager.updateNewAndRestoringTasks(TaskManager.java:401)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:779)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:697)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:670)
 ~[msgequator-1.59.3.jar:1.59.3] {code}
 

 

There's obviously no clear solution for this other than stopping/starting all 
instances at once. A rolling bounce that takes some time to complete (in our 
case, days) will break  instances that haven't been upgraded yet after a 
rebalance that causes older clients to pick up the newly encoded changelog 
partition(s)

 

I don't know if adding a flag on the client side that lists the supported 
protocol versions (so it behaves like Kafka Consumers when picking the 
rebalance protocol - cooperative or eager), or if it just needs to be 
explicitly stated on the migration guide that a full stop/start migration is 
required in cases where the protocol version changes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [PATCH v2 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_toio()

2021-12-07 Thread Hector Martin


Hi, thanks for the review!

On 07/12/2021 18.40, Thomas Zimmermann wrote:

Hi

Am 07.12.21 um 08:29 schrieb Hector Martin:

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.

Signed-off-by: Hector Martin 
---
   drivers/gpu/drm/drm_format_helper.c | 62 +
   include/drm/drm_format_helper.h |  3 ++
   2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index dbe3e830096e..edd611d3ab6a 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -409,6 +409,59 @@ void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, 
unsigned int dst_pitch,
   }
   EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
   
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, const u32 *sbuf,

+   unsigned int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   *dbuf++ = ((sbuf[x] & 0x00FF) << 2) |
+ ((sbuf[x] & 0xFF00) << 4) |
+ ((sbuf[x] & 0x00FF) << 6);


This isn't quite right. The lowest two destination bits in each
component will always be zero. You have to do the shifting as above and
for each component the two highest source bits have to be OR'ed into the
two lowest destination bits. For example the source bits in a component
are numbered 7 to 0

   | 7 6 5 4 3 2 1 0 |

then the destination bits should be

   | 7 6 5 4 3 2 1 0 7 6 |



I think both approaches have pros and cons. Leaving the two LSBs always 
at 0 yields a fully linear transfer curve with no discontinuities, but 
means the maximum brightness is slightly less than full. Setting them 
fully maps the brightness range, but creates 4 double wide steps in the 
transfer curve (also it's potentially slightly slower CPU-wise).


If you prefer the latter I'll do that for v2.

--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[PATCH v2 3/3] drm/simpledrm: Add XRGB2101010 format

This is the format used by the bootloader framebuffer on Apple ARM64
platforms.

Reviewed-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2f15b9aa..edadfd9ee882 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -571,7 +571,7 @@ static const uint32_t simpledrm_default_formats[] = {
//DRM_FORMAT_XRGB1555,
//DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB888,
-   //DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XRGB2101010,
//DRM_FORMAT_ARGB2101010,
 };
 
-- 
2.33.0

[PATCH v2 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_toio()

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/drm_format_helper.c | 62 +
 include/drm/drm_format_helper.h |  3 ++
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index dbe3e830096e..edd611d3ab6a 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -409,6 +409,59 @@ void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, 
unsigned int dst_pitch,
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
 
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, const u32 *sbuf,
+   unsigned int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   *dbuf++ = ((sbuf[x] & 0x00FF) << 2) |
+ ((sbuf[x] & 0xFF00) << 4) |
+ ((sbuf[x] & 0x00FF) << 6);
+   }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb2101010_toio - Convert XRGB to XRGB2101010 clip
+ * buffer
+ * @dst: XRGB2101010 destination buffer (iomem)
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for XRGB2101010 devices that don't natively
+ * support XRGB.
+ */
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst,
+unsigned int dst_pitch, const void 
*vaddr,
+const struct drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+   size_t linepixels = clip->x2 - clip->x1;
+   size_t dst_len = linepixels * sizeof(u32);
+   unsigned y, lines = clip->y2 - clip->y1;
+   void *dbuf;
+
+   if (!dst_pitch)
+   dst_pitch = dst_len;
+
+   dbuf = kmalloc(dst_len, GFP_KERNEL);
+   if (!dbuf)
+   return;
+
+   vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
+   for (y = 0; y < lines; y++) {
+   drm_fb_xrgb_to_xrgb2101010_line(dbuf, vaddr, linepixels);
+   memcpy_toio(dst, dbuf, dst_len);
+   vaddr += fb->pitches[0];
+   dst += dst_pitch;
+   }
+
+   kfree(dbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
+
 /**
  * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
@@ -500,6 +553,10 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
fb_format = DRM_FORMAT_XRGB;
if (dst_format == DRM_FORMAT_ARGB)
dst_format = DRM_FORMAT_XRGB;
+   if (fb_format == DRM_FORMAT_ARGB2101010)
+   fb_format = DRM_FORMAT_XRGB2101010;
+   if (dst_format == DRM_FORMAT_ARGB2101010)
+   dst_format = DRM_FORMAT_XRGB2101010;
 
if (dst_format == fb_format) {
drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
@@ -515,6 +572,11 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap, 
fb, clip);
return 0;
}
+   } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_xrgb2101010_toio(dst, dst_pitch, 
vmap, fb, clip);
+   return 0;
+   }
}
 
return -EINVAL;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 97e4c3223af3..b30ed5de0a33 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -33,6 +33,9 @@ void drm_fb_xrgb_to_rgb888(void *dst, unsigned int 
dst_pitch, const void *sr
 void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, unsigned int dst_pitch,
const void *vaddr, const struct 
drm_framebuffer *fb,
const struct drm_rect *clip);
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst, unsigned int 
dst_pitch,
+const void *vaddr, const struct 
drm_framebuffer *fb,
+const struct drm_rect *clip);
 void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void 
*vaddr,
  const struct drm_framebuffer *fb, const struct 
drm_rect *clip);
 
-- 
2.33.0

[PATCH v2 1/3] of: Move simple-framebuffer device handling from simplefb to of

This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.

Signed-off-by: Hector Martin 
---
 drivers/of/platform.c  |  5 +
 drivers/video/fbdev/simplefb.c | 21 +
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..e097f40b03c0 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,11 @@ static int __init of_platform_default_populate_init(void)
of_node_put(node);
}
 
+   for_each_child_of_node(of_chosen, node) {
+   if (of_device_is_compatible(node, "simple-framebuffer"))
+   of_platform_device_create(node, NULL, NULL);
+   }
+
/* Populate everything else. */
of_platform_default_populate(NULL, NULL, NULL);
 
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index b63074fd892e..57541887188b 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -541,26 +541,7 @@ static struct platform_driver simplefb_driver = {
.remove = simplefb_remove,
 };
 
-static int __init simplefb_init(void)
-{
-   int ret;
-   struct device_node *np;
-
-   ret = platform_driver_register(_driver);
-   if (ret)
-   return ret;
-
-   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
-   for_each_child_of_node(of_chosen, np) {
-   if (of_device_is_compatible(np, "simple-framebuffer"))
-   of_platform_device_create(np, NULL, NULL);
-   }
-   }
-
-   return 0;
-}
-
-fs_initcall(simplefb_init);
+module_platform_driver(simplefb_driver);
 
 MODULE_AUTHOR("Stephen Warren ");
 MODULE_DESCRIPTION("Simple framebuffer driver");
-- 
2.33.0

[PATCH v2 0/3] drm/simpledrm: Apple M1 / DT platform support fixes

Hi DRM folks,

This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.

This avoids breaking the bootloader-provided framebuffer console when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).

Changes since v1:
- Moved the OF platform device setup code from simplefb into common
  code, instead of duplicating it in simpledrm
- Rebased on drm-tip

Hector Martin (3):
  of: Move simple-framebuffer device handling from simplefb to of
  drm/format-helper: Add drm_fb_xrgb_to_xrgb2101010_toio()
  drm/simpledrm: Add XRGB2101010 format

 drivers/gpu/drm/drm_format_helper.c | 62 +
 drivers/gpu/drm/tiny/simpledrm.c|  2 +-
 drivers/of/platform.c   |  5 +++
 drivers/video/fbdev/simplefb.c  | 21 +-
 include/drm/drm_format_helper.h |  3 ++
 5 files changed, 72 insertions(+), 21 deletions(-)

-- 
2.33.0

Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

2021-11-29 Thread Hector Geraldino (BLOOMBERG/ 919 3RD A)

Hello again Tom, kafka devs

First, congrats on becoming a PMC member! That's so cool.

Since your last reply I've updated the KIP trying to address some of your 
suggestions. A few more details have been added to the motivation section, and 
also went ahead and opened a draft pull-request with the changes I think are 
needed for this KIP, with the hope that it makes it easier to discuss the 
general approach and any other concerns the community may have.

KIP: 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-795%3A+Add+public+APIs+for+AbstractCoordinator
PR: https://github.com/apache/kafka/pull/11515

Looking forward for some community feedback.

Regards,
Hector

From: dev@kafka.apache.org At: 11/11/21 17:15:17 UTC-5:00To:  
dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

Hi Tom,

Thanks for taking time reviewing the KIP. 

I think it's reasonable to ask if Kafka's Group Coordination protocol should be 
used for use cases other than the distributed event log. This was actually 
briefly addressed by Gwen Shapira during her presentation at the strangeloop 
conference in '18 (a link to the video is included in the KIP), in which she 
explain in greater details the protocol internals.

We should also keep in mind that this protocol is already being used for other 
use cases outside of core Kafka: Confluent Schema Registry uses it to determine 
leadership between members of a cluster, Kafka Connect uses it for task 
assignments, same with Kafka Stream for partition and task distributions, and 
so on. So having a public, stable API not just for new use cases (like ours) 
but existing ones is IMHO a good thing to have. I'll amend the KIP and add a 
bit more details to the motivation and alternatives sections, so the usefulness 
of this KIP is better understood.

Now, for the first point of your technical observations (regarding 
protocolTypes()), I don't think it matters in this context, as the protocol 
name and subtype are only relevant in the context of a consumer group and group 
rebalance. It really doesn't matter if two different libraries decide to name 
their protocols the same.

For item #2, I was under the impression that, because these classes all 
implement the org.apache.kafka.common.protocol.[Message, ApiMessage] interface, 
they are implicitly part of the Kafka protocol and the top-level API. Isn't 
that really the case?

And finally, for #3, the goal I had in mind when creating this KPI was a small 
one: to provide an interface that users can rely on when extending the 
AbstactCoordinator. So my thought was that, while the AbstractCoordinator 
itself uses some internal APIs (like ConsumerNetworkClient, ConsumerMetadata 
and so on) those can remain internal. But it probably makes sense to at least 
explore the possibility of moving the whole AbstractCoordinator class to be 
part of the public API. I'll do that exercise, see what it entails, and update 
the KIP with my findings.


Thanks again!
Hector


From: dev@kafka.apache.org At: 11/10/21 06:43:59 UTC-5:00To:  Hector Geraldino 
(BLOOMBERG/ 919 3RD A ) ,  dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

Hi Hector,

Thanks for the KIP.

At a high level, I think the question to be answered by the community is
"Should Kafka really be providing this kind of cluster management API?".
While Kafka clients need this to provide their functionality it's a
different thing to expose that as a public API of the project, which is
otherwise about providing a distributed event log/data streaming
platform/. Having a public
API brings a significant commitment for API compatibility, which could
impair the ability of the project to change the API in order to make
improvements to the Kafka clients. The current AbstractCoordinator not
being a supported API means we don't currently have to reason about
compatibility here. So I think it would help the motivation section of the
KIP to describe in a bit more detail the use case(s) you have for
implementing your own coordinators. For example, are these applications
using Kafka otherwise, or just to leverage this API? And what alternatives
to implementing your own coordinators did you consider, and why did you
reject them?

From a technical point of view, there are a number of issues I think would
need addressing in order to do something like this:

1. There probably ought to be a way to ensure that protocolTypes() don't
collide, or at least reduce the chances of a collision. While probably
unlikely in practice the consequences of different protocols having the
same name could be pretty confusing to debug.
2. JoinGroupRequestData and JoinGroupResponseData are not public classes
(none of the *RequestData or *ResponseData classes are, intentionally), so
there would have to be an abstraction for them.
3. It's all well and good having an interface that anyone can implement,
but there is no supported Kafka API w

Re: [PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

2021-11-22 Thread Hector Martin


On 22/11/2021 18.52, Pekka Paalanen wrote:

On Wed, 17 Nov 2021 23:58:28 +0900
Hector Martin  wrote:


Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.

Signed-off-by: Hector Martin 
---
  drivers/gpu/drm/drm_format_helper.c | 64 +
  include/drm/drm_format_helper.h |  4 ++
  2 files changed, 68 insertions(+)


Hi Hector,

I'm curious, since the bootloader seems to always set up a 10-bit mode,
is there a reason for it that you can guess? Is the monitor in WCG or
even HDR mode?


My guess is that Apple prefer to use 10-bit framebuffers for seamless 
handover with their graphics stack, which presumably uses 10-bit 
framebuffers these days. It seems to be unconditional; I've never seen 
anything but 10 bits across all Apple devices, both with the internal 
panels on laptops and with bog standard external displays on the Mac 
Mini via HDMI. HDR is not necessary, even very dumb capture cards and 
old screens get a 10-bit framebufer in memory.


The only time I see an 8-bit framebuffer is with *no* monitor connected 
on the Mini, in which case you get an 8-bit 640x1136 dummy framebuffer 
(that's the iPhone 5 screen resolution... :-) )


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

Re: reportbug fail

2021-11-21 Thread Richard Hector


On 21/11/21 3:04 am, Lee wrote:

I wanted to create a bug report for meld but couldn't find any info on
how to other than "use reportbug" :(


I see your problem is solved, but for future reference, this page has 
info on reporting bugs via email:


https://www.debian.org/Bugs/Reporting

Cheers,
Richard

Re: [PATCH 1/3] drm/simpledrm: Bind to OF framebuffers in /chosen

2021-11-19 Thread Hector Martin


On 18/11/2021 18.19, Thomas Zimmermann wrote:

Hi

Am 17.11.21 um 15:58 schrieb Hector Martin:

@@ -897,5 +898,21 @@ static struct platform_driver simpledrm_platform_driver = {
   
   module_platform_driver(simpledrm_platform_driver);
   
+static int __init simpledrm_init(void)

+{
+   struct device_node *np;
+
+   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
+   for_each_child_of_node(of_chosen, np) {
+   if (of_device_is_compatible(np, "simple-framebuffer"))
+   of_platform_device_create(np, NULL, NULL);
+   }
+   }
+
+   return 0;
+}
+
+fs_initcall(simpledrm_init);
+


Simpledrm is just a driver, but this is platform setup code. Why is this
code located here and not under arch/ or drivers/firmware/?

I know that other drivers do similar things, it doesn't seem to belong here.


This definitely doesn't belong in either of those, since it is not arch- 
or firmware-specific. It is implementing support for the standard 
simple-framebuffer OF binding, which specifies that it must be located 
within the /chosen node (and thus the default OF setup code won't do the 
matching for you); this applies to all OF platforms [1]


Adding Rob; do you think this should move from simplefb/simpledrm to 
common OF code? (where?)


[1] Documentation/devicetree/bindings/display/simple-framebuffer.yaml

--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[PATCH v2] iommu/io-pgtable-arm: Fix table descriptor paddr formatting

2021-11-19 Thread Hector Martin

Table descriptors were being installed without properly formatting the
address using paddr_to_iopte, which does not match up with the
iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte
format, as it does not handle the high bits properly.

This was found on Apple T6000 DARTs, which require a new pte format
(different shift); adding support for that to
paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit
addresses would end up incorrect in that case.

Fixes: 6c89928ff7a0 ("iommu/io-pgtable-arm: Support 52-bit physical address")
Acked-by: Robin Murphy 
Signed-off-by: Hector Martin 
---
 drivers/iommu/io-pgtable-arm.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index dd9e47189d0d..94ff319ae8ac 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -315,11 +315,12 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
*data,
 static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
 arm_lpae_iopte *ptep,
 arm_lpae_iopte curr,
-struct io_pgtable_cfg *cfg)
+struct arm_lpae_io_pgtable *data)
 {
arm_lpae_iopte old, new;
+   struct io_pgtable_cfg *cfg = >iop.cfg;
 
-   new = __pa(table) | ARM_LPAE_PTE_TYPE_TABLE;
+   new = paddr_to_iopte(__pa(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
new |= ARM_LPAE_PTE_NSTABLE;
 
@@ -380,7 +381,7 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, 
unsigned long iova,
if (!cptep)
return -ENOMEM;
 
-   pte = arm_lpae_install_table(cptep, ptep, 0, cfg);
+   pte = arm_lpae_install_table(cptep, ptep, 0, data);
if (pte)
__arm_lpae_free_pages(cptep, tblsz, cfg);
} else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) {
@@ -592,7 +593,7 @@ static size_t arm_lpae_split_blk_unmap(struct 
arm_lpae_io_pgtable *data,
__arm_lpae_init_pte(data, blk_paddr, pte, lvl, 1, [i]);
}
 
-   pte = arm_lpae_install_table(tablep, ptep, blk_pte, cfg);
+   pte = arm_lpae_install_table(tablep, ptep, blk_pte, data);
if (pte != blk_pte) {
__arm_lpae_free_pages(tablep, tablesz, cfg);
/*
-- 
2.33.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Bug#1000139: lxc-templates: Bad security sources on bullseye container built on buster

2021-11-18 Thread Richard Hector

Package: lxc-templates
Version: 3.0.4-0+deb10u1
Severity: normal

Dear Maintainer,

Bug #970067 has been fixed, enabling the building of bullseye machines
with a correct sources.list

It is only available in bullseye+, however, so building a bullseye
container on buster doesn't work correctly (the security sources line is
wrong).

Could this be fixed in buster as well?

Thanks,
Richard

[ansible-project] lineinfile in lxc_container?

2021-11-18 Thread Richard Hector

Hi all,

I'm using ansible to set up lxc containers, using delegation to the
container host.

One task looks like this:

- name: add ansible user to sudoers
lineinfile:
dest: "/var/lib/lxc/{{ inventory_hostname }}/rootfs/etc/sudoers"
state: present
regexp: "^ansible"
line: 'ansible ALL=(ALL) NOPASSWD: ALL'
insertafter: '^root'
validate: '/usr/sbin/visudo -cf %s'
delegate_to: "{{ container_host }}"
when: start_container|bool

That has been working fine, until I tried to create a debian bullseye
container on a buster host. Unfortunately, the sudoers format has
changed slightly, so the buster visudo won't accept the bullseye sudoers
file (#includedir is now @includedir).

I tried giving the path to the bullseye visudo, but it's dynamically
linked and doesn't work on the buster system.

I could potentially use the lxc_container module to run a command in the
container, but that means I lose lineinfile, and have to do more stuff
manually.

Or I could use my temporary workaround, and just assume my sudoers file
is ok, and skip validation.

Another option is to add an extra lineinfile task (before that one) to
replace @includedir with #includedir, since it's backwards compatible,
but that seems too hackish.

Any other suggestions?

Cheers,
Richard

--
You received this message because you are subscribed to the Google Groups "Ansible
Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/39771264-b079-ff6e-15a6-e018d95dd6fd%40walnut.gen.nz.

[PATCH] iommu/io-pgtable-arm: Fix table descriptor paddr formatting

Table descriptors were being installed without properly formatting the
address using paddr_to_iopte, which does not match up with the
iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte
format, as it does not handle the high bits properly.

This was found on Apple T6000 DARTs, which require a new pte format
(different shift); adding support for that to
paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit
addresses would end up incorrect in that case.

Signed-off-by: Hector Martin 
---
 drivers/iommu/io-pgtable-arm.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index dd9e47189d0d..b636e2737607 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -315,12 +315,12 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
*data,
 static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
 arm_lpae_iopte *ptep,
 arm_lpae_iopte curr,
-struct io_pgtable_cfg *cfg)
+struct arm_lpae_io_pgtable *data)
 {
arm_lpae_iopte old, new;
 
-   new = __pa(table) | ARM_LPAE_PTE_TYPE_TABLE;
-   if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
+   new = paddr_to_iopte(__pa(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
+   if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_NS)
new |= ARM_LPAE_PTE_NSTABLE;
 
/*
@@ -332,11 +332,11 @@ static arm_lpae_iopte 
arm_lpae_install_table(arm_lpae_iopte *table,
 
old = cmpxchg64_relaxed(ptep, curr, new);
 
-   if (cfg->coherent_walk || (old & ARM_LPAE_PTE_SW_SYNC))
+   if (data->iop.cfg.coherent_walk || (old & ARM_LPAE_PTE_SW_SYNC))
return old;
 
/* Even if it's not ours, there's no point waiting; just kick it */
-   __arm_lpae_sync_pte(ptep, 1, cfg);
+   __arm_lpae_sync_pte(ptep, 1, >iop.cfg);
if (old == curr)
WRITE_ONCE(*ptep, new | ARM_LPAE_PTE_SW_SYNC);
 
@@ -380,7 +380,7 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, 
unsigned long iova,
if (!cptep)
return -ENOMEM;
 
-   pte = arm_lpae_install_table(cptep, ptep, 0, cfg);
+   pte = arm_lpae_install_table(cptep, ptep, 0, data);
if (pte)
__arm_lpae_free_pages(cptep, tblsz, cfg);
} else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) {
@@ -592,7 +592,7 @@ static size_t arm_lpae_split_blk_unmap(struct 
arm_lpae_io_pgtable *data,
__arm_lpae_init_pte(data, blk_paddr, pte, lvl, 1, [i]);
}
 
-   pte = arm_lpae_install_table(tablep, ptep, blk_pte, cfg);
+   pte = arm_lpae_install_table(tablep, ptep, blk_pte, data);
if (pte != blk_pte) {
__arm_lpae_free_pages(tablep, tablesz, cfg);
/*
-- 
2.33.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()


On 17/11/2021 23.56, Thomas Zimmermann wrote:

Hi

Am 17.11.21 um 15:22 schrieb Hector Martin:

The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.

Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin 


Thanks for your patch, but you're probably on the wrong branch. We
rewrote this code recently and fixed the issue in drm-misc-next. [1][2]


Oops. I was on linux-next as of Nov 1. Looks like I missed it by a week!

Sounds like I'm going to have to rebase/rewrite the other series I just 
sent too...


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[PATCH 3/3] drm/simpledrm: Enable XRGB2101010 format

This is the format used by the bootloader framebuffer on Apple ARM64
platforms, and is already supported by simplefb. This avoids regressing
on these platforms when simpledrm is enabled and replaces simplefb.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2c84f2ea1fa2..b4b69f3a7e79 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -571,7 +571,7 @@ static const uint32_t simpledrm_default_formats[] = {
//DRM_FORMAT_XRGB1555,
//DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB888,
-   //DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XRGB2101010,
//DRM_FORMAT_ARGB2101010,
 };
 
-- 
2.33.0

[PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/drm_format_helper.c | 64 +
 include/drm/drm_format_helper.h |  4 ++
 2 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index 69fde60e36b3..5998e57d6ff2 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -378,6 +378,60 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst, 
unsigned int dst_pitch
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_dstclip);
 
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, u32 *sbuf,
+   unsigned int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   *dbuf++ = ((sbuf[x] & 0x00FF) << 2) |
+ ((sbuf[x] & 0xFF00) << 4) |
+ ((sbuf[x] & 0x00FF) << 6);
+   }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb2101010_dstclip - Convert XRGB to XRGB2101010 
clip
+ * buffer
+ * @dst: XRGB2101010 destination buffer (iomem)
+ * @dst_pitch: destination buffer pitch
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for XRGB2101010 devices that don't natively
+ * support XRGB.
+ *
+ * This function applies clipping on dst, i.e. the destination is a
+ * full (iomem) framebuffer but only the clip rect content is copied over.
+ */
+void drm_fb_xrgb_to_xrgb2101010_dstclip(void __iomem *dst,
+   unsigned int dst_pitch, void *vaddr,
+   struct drm_framebuffer *fb,
+   struct drm_rect *clip)
+{
+   size_t linepixels = clip->x2 - clip->x1;
+   size_t dst_len = linepixels * 4;
+   unsigned int y, lines = clip->y2 - clip->y1;
+   void *dbuf;
+
+   dbuf = kmalloc(dst_len, GFP_KERNEL);
+   if (!dbuf)
+   return;
+
+   vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
+   dst += clip_offset(clip, dst_pitch, sizeof(u32));
+   for (y = 0; y < lines; y++) {
+   drm_fb_xrgb_to_xrgb2101010_line(dbuf, vaddr, linepixels);
+   memcpy_toio(dst, dbuf, dst_len);
+   vaddr += fb->pitches[0];
+   dst += dst_pitch;
+   }
+
+   kfree(dbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_dstclip);
+
 /**
  * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
@@ -464,6 +518,10 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned 
int dst_pitch,
fb_format = DRM_FORMAT_XRGB;
if (dst_format == DRM_FORMAT_ARGB)
dst_format = DRM_FORMAT_XRGB;
+   if (fb_format == DRM_FORMAT_ARGB2101010)
+   fb_format = DRM_FORMAT_XRGB2101010;
+   if (dst_format == DRM_FORMAT_ARGB2101010)
+   dst_format = DRM_FORMAT_XRGB2101010;
 
if (dst_format == fb_format) {
drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
@@ -482,6 +540,12 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned 
int dst_pitch,
  vmap, fb, clip);
return 0;
}
+   } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_xrgb2101010_dstclip(dst, dst_pitch,
+  vmap, fb, clip);
+   return 0;
+   }
}
 
return -EINVAL;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index e86925cf07b9..a0faa710878b 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -29,6 +29,10 @@ void drm_fb_xrgb_to_rgb888(void *dst, void *src, struct 
drm_framebuffer *fb,
 void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst, unsigned int 
dst_pitch,
   void *vaddr, struct drm_framebuffer *fb,
   struct drm_rect *clip);
+void drm_fb_xrgb_to_xrgb2101010_dstclip(void __iomem *dst,
+   unsigned int dst_pitch, void *vaddr,
+   struct drm_framebuffer *fb,
+   struct drm_rect *clip);
 void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
  struct drm_rect *clip);
 
-- 
2.33.0

[PATCH 1/3] drm/simpledrm: Bind to OF framebuffers in /chosen

This matches the simplefb behavior; these nodes are not matched by the
standard OF machinery. This fixes a regression when simpledrm replaces
simeplefb.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 481b48bde047..2c84f2ea1fa2 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -897,5 +898,21 @@ static struct platform_driver simpledrm_platform_driver = {
 
 module_platform_driver(simpledrm_platform_driver);
 
+static int __init simpledrm_init(void)
+{
+   struct device_node *np;
+
+   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
+   for_each_child_of_node(of_chosen, np) {
+   if (of_device_is_compatible(np, "simple-framebuffer"))
+   of_platform_device_create(np, NULL, NULL);
+   }
+   }
+
+   return 0;
+}
+
+fs_initcall(simpledrm_init);
+
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL v2");
-- 
2.33.0

[PATCH 0/3] drm/simpledrm: Apple M1 / DT platform support fixes

Hi DRM folks,

This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.

This avoids breaking the bootloader-provided framebuffer console when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).

Hector Martin (3):
  drm/simpledrm: Bind to OF framebuffers in /chosen
  drm/format-helper: Add drm_fb_xrgb_to_xrgb2101010_dstclip()
  drm/simpledrm: Enable XRGB2101010 format

 drivers/gpu/drm/drm_format_helper.c | 64 +
 drivers/gpu/drm/tiny/simpledrm.c| 19 -
 include/drm/drm_format_helper.h |  4 ++
 3 files changed, 86 insertions(+), 1 deletion(-)

-- 
2.33.0

[PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()