Re: [PATCH 00/12] Re-introduce Exynos4212 support and add Samsung Galaxy Tab 3 8.0 boards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16/04/2023 12:53, Krzysztof Kozlowski wrote:
On 16/04/2023 12:49, Artur Weber wrote:
On 16/04/2023 12:34, Krzysztof Kozlowski wrote:
On 16/04/2023 12:26, Artur Weber wrote:
On 16/04/2023 12:16, Artur Weber wrote:
This patches re-introduces the Exynos4212 platform and adds support
for the Samsung Galaxy Tab 3 8.0 series of tablets that uses it:

    - Samsung Galaxy Tab 3 8.0 WiFi (SM-T310/lt01wifi)
    - Samsung Galaxy Tab 3 8.0 3G (SM-T311/lt013g)
    - Samsung Galaxy Tab 3 8.0 LTE (SM-T315/lt01lte)

What works:

    - Display and backlight
    - Touchscreen (without touchkeys)
    - GPIO buttons, hall sensor
    - WiFi and Bluetooth
    - USB, fuel gauge, charging (partial)
    - Accelerometer and magnetometer
    - WiFi model only: light sensor

This patchset depends on "[PATCH 0/3] Add Samsung S6D7AA0 panel
controller driver" for the display panel support for the Samsung Galaxy
3 8.0 boards.

Why? DTS and ARM code cannot depend on driver changes. Please rework
your patchsets to remove any of such dependencies.

Ah, that makes sense. I'll re-send the patchset in a second with the
panel node removed.

I am sorry, I don't understand. Why would you remove anything from DTS?
Are bindings NAKed?

The dependency display panel patchset introduces the panel and its bindings, which in turn are included in the Tab3 DTSI. It was submitted at roughly the same time as this series, and hasn't been fully reviewed or merged as of writing. (I have seen your comments on that patchset, and I will be addressing them shortly.) So the bindings haven't been explicitly ACKed yet (assuming you mean the Acked-by reply).

In response to:

> Please rework your patchsets to remove any of such dependencies.

I suggested that I could remove the panel node from the DTSI for the time being. The intent was to submit it in a separate patch later, once the display is reviewed/merged, and thus actually available in the kernel; this way, the two patches could be reviewed and merged separately.

I could instead wait for the display patchset to get reviewed/merged first, then resubmit this series, if that's preferable.

I apologize for the confusion.

Best regards,
Artur Weber




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux